【业务建模_2】通用数据工具
背景
在公司做數(shù)據(jù)工作會接觸很多相關(guān)工具，這里會匯總一些核心并更理想化的工具。
工具匯總
1.打點(diǎn)平臺
module,op,參數(shù)數(shù)組(s0-s5),常用參數(shù),[實際打點(diǎn)位置截圖,打點(diǎn)觸發(fā)條件說明]
——后兩者暫時沒有，但在使用過程中發(fā)現(xiàn)經(jīng)常不知道某個打點(diǎn)到底是什么意思。打點(diǎn)變化太快了，而且歷史打點(diǎn)不規(guī)范經(jīng)常沒有人上傳原型流程圖；實時測試打點(diǎn)有延遲，測完發(fā)現(xiàn)少很多認(rèn)為應(yīng)該有的點(diǎn)，多了一些不應(yīng)該有的點(diǎn)；有些點(diǎn)可能是開發(fā)直接加的點(diǎn)，未經(jīng)過打點(diǎn)平臺，沒有中文名字比較難理解；即使有的點(diǎn)看懂了，實際觸發(fā)條件并不一定是所想的。
另外，日志中經(jīng)常有一系列相關(guān)的點(diǎn)需要一起看，增加系列（也可以說增加多層module）和系列層級也許會更好。
有什么工具可以圖形化顯示op關(guān)系？比如我以前用Excel樹狀結(jié)構(gòu)來表示，但op太多太復(fù)雜也很難看。
——其實我想過在可視化日志統(tǒng)計上實現(xiàn)這樣的功能，即在圖形甚至原型流程圖上顯示uv/轉(zhuǎn)化率/pv比uv等數(shù)據(jù)；還有個想法是在看單個人的日志時發(fā)現(xiàn)很難理解用戶操作流程，能直接開發(fā)個工具將日志流復(fù)現(xiàn)為原型流程圖甚至動態(tài)的app操作更好了（想得美==）。
2.事件分析&漏斗分析
基于日志數(shù)據(jù)，甚至整合常用維度（比如城市、性別等）。
事件分析，即基于一個度量事物（比如uv），能進(jìn)行篩選，并可按某些維度分組計算。
漏斗分析，即基于一系列事件的某個度量事物，能篩選，并能組織漏斗上下層級是left join還是只是不left join（上下層事件互相獨(dú)立）。
3.timeline
按時間點(diǎn)組織，將各個時間點(diǎn)發(fā)生的版本升級、功能變化等等時間記錄下來，并標(biāo)簽可能影響的指標(biāo)，便于分析時關(guān)聯(lián)上。
——這個是我一直想做但沒做的。
4.hive/spark
這一套指整個離線數(shù)倉，t+1同步。通常需要了解線上表（找開發(fā)問）+同步過程（數(shù)倉負(fù)責(zé)，涉及數(shù)據(jù)字典和同步規(guī)則——增量全量拉鏈等）+線下表。
hive/spark是在持續(xù)版本更新的，UDF也需要數(shù)倉去建，所以在寫SQL應(yīng)用某些函數(shù)時遇到不能解決的可以問數(shù)倉。
5.報表&可視化平臺
大小公司必不可少的，使用者通常是不懂?dāng)?shù)據(jù)的業(yè)務(wù)人員+老板。差一點(diǎn)的就直接是報表和固定的可視化內(nèi)容，好一點(diǎn)是能由分析師自建可視化內(nèi)容共享出來。
這里涉及到數(shù)據(jù)表建模，中間表任務(wù)，前端可視化控件。
——其實最重要的是數(shù)據(jù)表建模，玩過tableau都知道就是一些事實表+維度表，然后創(chuàng)建各種維度和計算度量就好。但很多時候沒有人知道數(shù)據(jù)建模這個職能的存在，所以經(jīng)常是分析師玩自己的，BI團(tuán)隊建自己的，然后并沒有人用。
6.實時流量平臺
這個主要針對需要實時監(jiān)控的指標(biāo)，例如收入，uv等。
7.定時郵件任務(wù)&表任務(wù)工具
分析師經(jīng)常會接到一些快速報表需求，直接用SQL出表，此時定時郵件任務(wù)就很好用了。
很多時候底層表太麻煩，或一條SQL很難搞定的，也會自己建中間表；或者有些外部數(shù)據(jù)要應(yīng)用到SQL中，建表輔助也是很好用的。
——其實有建表+郵件工具+可視化控件，報表需求分析師都能搞定。
轉(zhuǎn)載于:https://www.cnblogs.com/everda/p/10382987.html
總結(jié)
以上是生活随笔為你收集整理的【业务建模_2】通用数据工具的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： .NET Core开发日志——配置
- 下一篇： javaScript学习之正则表达式初探