馮俊晨-data fun 火花思維分享.pdf

1、火花思維數據分析體系火花思維數據分析體系建設和實戰分享建設和實戰分享DataFun,2024分享分享內容內容痛在痛在哪里哪里自研系統的局限性方案方案選型選型為什么我們選擇了火山引擎運營策略運營策略如何將工具潛力變成業務能力未來未來展望展望大模型時代的數據分析長什么樣？痛在痛在哪里哪里自研系統的自研系統的局限性局限性前端能力不足，前端能力不足，v1未實現未實現實時交互式分析，實時交互式分析，選擇了保存選擇了保存SQL為圖表的為圖表的MVP方案方案限制了只有會SQL的分析師才能創建和修改圖表，降低了響應速度技技術術架構上選擇了架構上選擇了presto+redis緩存緩存這個架構不支持高性能維度表查

2、詢，P95達到30秒以上，使用體驗較差數據結構上選擇了一個可視化圖表對應一個數據結構上選擇了一個可視化圖表對應一個SQL（或者一個（或者一個物化視圖）物化視圖）復用性差，例如日表、周表、月表得維護3段SQLBI系統必須要會寫系統必須要會寫SQL才能做分析才能做分析以頁面以頁面ID和行為和行為ID作為最細粒度，導致點位作為最細粒度，導致點位爆炸爆炸據稱抖音app的點位數量在6000個左右，火花點位在1w以上沒有自助測試驗證機制，拉長了協作鏈條沒有自助測試驗證機制，拉長了協作鏈條產品經理和分析師不能參與測試環境驗證，而QA無法驗證埋點的分析意圖，特別是某些關鍵屬性的錯漏缺乏交互式分析機制，只能寫缺

3、乏交互式分析機制，只能寫SQL串聯埋點串聯埋點疊加兩個問題，生產效率很低，分析師特別不愿意去分析行為日志。行為日志系統的行為日志系統的分析效率分析效率低下低下2個產品，個產品，2前端前端3后端后端2測試的產研團隊測試的產研團隊給舊系統打補丁成本太高開發全新系統人力又不足自研團隊的自研團隊的”雞肋雞肋”處境處境為什么選擇火山為什么選擇火山引擎引擎數據數據預處理預處理接入數據源種類接入數據源種類：比superset豐富、與FineBI相似，飛書生態加分調度系統調度系統：選型時未認真比較的組件。要考慮和調度系統對接和批量重跑可視化建?？梢暬＃邯毺貎瀯?，對于非分析師非常友好?？梢暬梢暬治龇治鰣D

4、表類型圖表類型：豐富度不如superset，但是常見圖表都有配置格式自定義程度格式自定義程度：表格格式化能力不如FineBI，但是遠強于superset上卷上卷/下鉆下鉆：與FineBI和superset相似查詢性能查詢性能：同等配置下查詢性能最好，但是用戶直觀體驗相差無幾輔助分析輔助分析：選型時未認真比較的組件。表格的匯總/同環比計算高頻使用智能歸因智能歸因分析分析火山引擎獨門絕技，當時選型的決定性因素。對于指標的異動，利用同一個數據集里維度進行自動歸因分析，并按照維度變量的差異度進行排序對于加法指標（DAU），幾乎替代分析師工作對于乘法指標（平均用時），極大節約分析師時間對于除法指標（轉化

5、率），只有參考意義BI系統系統歸因分析（歸因分析（加法）加法）歸因分析（歸因分析（乘法）乘法）可視化可視化分析分析常用行為分析組件常用行為分析組件：與神策差不多單人細查與分群分析單人細查與分群分析：與神策差不多固化套件固化套件：遜于神策的行業模版數據數據治理治理埋點管理平臺埋點管理平臺：神策自身不帶管理平臺，不具備治理能力 神策生態中有三方平臺，提供可視化點位管理可視化測試環境可視化測試環境：與神策差不多點位生命周期管理點位生命周期管理：火山獨特功能，但是實際使用價值不是很大AB Test系統系統動態分流系統（多臂老虎機），在國內生態里只有火山引擎提供該功能。這是當時選型的決定性因素簡而言之，

6、動態分流下，實驗組和對照組的流量分配比例不固定，如果實驗組效果好，會自動擴量；如果效果不好，會自動縮量。這樣一方面可以保護業務結果，降低實驗風險；另一方面節約實驗時間，特別有利于小流量實驗行為行為數據分析系統數據分析系統動態實驗動態實驗支持小流量增長支持小流量增長嘗試嘗試靜態實驗動態實驗有點小貴有點小貴 但很好用但很好用運營策略運營策略如何將工具潛力變成業務能力數據分析產品是一個需求驅動的內容平臺數據分析產品是一個需求驅動的內容平臺對于專業數據分析人員，對于專業數據分析人員，提高生產效率提高生產效率主要靠系統本身的能力 對于分析的助力更重要對于非專業分析人員，降低生產門檻對于非專業分析人員，降

7、低生產門檻重視培訓，更重視工作坊 做好業務核心場景的數據集市，控制數據集的認知復雜度提高內容生產的提高內容生產的效率效率更更“高級高級”的形式不一定是更有效的解決方案的形式不一定是更有效的解決方案為什么“表格”是流量最高的圖表形式為什么 歸因分析 無法在火花落地創造看數的需求創造看數的需求是比提高產數的效率更重要為什么行為分析系統日活提不上來業務痛點決定解決方案的業務痛點決定解決方案的形式形式助力朋友圈有效分享率提升12%成功案例：為設計插上數據的翅膀成功案例：為設計插上數據的翅膀打通設計素材標簽和行為日志，構建海報物料選擇、展示和轉化的指標寬表根據設計團隊提供的分析思路進行數據看板的構建，兼

8、顧周報、月報的監控需求和根據設計元素進行deep dive的分析需求第一階段：深度第一階段：深度介入數據管線和看板介入數據管線和看板設計人員在定期匯報的異動分析時有了新的問題，新的設計實驗驗證有了新的問題通過培訓和工作坊，逐步提高設計團隊自問自答的能力第二階段：鼓勵設計人員自己進行可視化分析第二階段：鼓勵設計人員自己進行可視化分析助力業務團隊超額完成GMV目標5%成功案例：后服務成功案例：后服務團隊數據管理工作臺團隊數據管理工作臺背景：每個地區有一個數據運營，數據運營主要工作職能（之一）是下載表格，然后根據管理架構進行分拆可視化建模+行列權限 使得數據運營可以讓一線管理者直接下載相關數據，極大

9、解放了數據運營的生產效率數據運營將數據搬運的時間拿來做策略效果分析第一階段：從搬運到第一階段：從搬運到分析分析政策變化多，活動周期短，難以依靠分析師更新數據寬表可視化建模/自定義SQL臨時應急，一個具備初級SQL能力的同學可以解決大部分業務需求長期固定的觀察項目才提出數據寬表需求第二階段：定制第二階段：定制數據集數據集未來未來展望展望人人都可以有一個分析師助手直接產出業務直接產出業務洞見洞見我們需要的不是更快的可視化分析，而是更快的業務洞察我們需要的不是更快的可視化分析，而是更快的業務洞察OLAP不會是不會是LLM時代的版本時代的版本答案答案從數據集市到問題集合面向大模型的元數據面向大模型的元數據治理治理業務的抽象建模、企業業務的抽象建模、企業知識和元數據管理一定會沉淀在企業知識和元數據管理一定會沉淀在企業內部內部OLAP時代是維度建模，時代是維度建模，LLM時代該怎么建模？時代該怎么建模？Metrics Layer？Visit Our Website：https:THANK YOU