起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識數據中臺建設系列篇：什么樣的企業適合建設數據中臺
編輯導語：近年來，數據中臺特別火熱，數據中臺有著它的巨大價值。但是并不是所有企業都適合建設數據中臺，需要依照實際情況進行理性分析，按需選擇。我們一起來看看什么樣的企業才適合建設數據中臺吧。
上篇文章（數據中臺建設系列篇：什么是數據中臺）我們聊清楚了什么是數據中臺，也知道了數據中臺的巨大價值，那是不是就可以開始建設數據中臺了呢？
我想，在正式進入數據中臺建設之前，我們來聊聊什么樣的企業適合建設數據中臺，以便大家能夠按照企業實際情況，理性分析，按需選擇，防止盲目跟風帶來巨大損失。
一、建設數據中臺
前企業常見數據痛點由于工作原因，參與了多個數據中臺項目，在此過程中，我發現很多企業在建設數據中臺前通常會存在一系列的痛點，總結起來，可以概括為以下5大類：
1. 指標口徑不統一
兩張報表里面名稱相同的指標【銷售額】，展示的結果卻不一樣，業務懷疑數據有問題，便找開發排查，排查結果顯示，這兩個指標，一個含稅，一個不含稅。業務人員面對這些指標的時候，如果不知道指標的業務口徑，很難去使用這些數據。
2. 需求響應時間長
隨著需求的不斷增長，運營和分析師抱怨需求的交付時間太長，無法滿足快速發展和變化的業務對數據的敏捷研發要求。
3. 取數效率低
隨著數據的不斷增長，面對海量的數據表，運營和分析師們準確找到數據、理解數據變得越來越困難，大量臨時取數工作只能依賴數據研發來完成，使得數據研發無法專注于數倉模型的構建上，從而形成【數據不完善——研發忙于各種臨時取數需求——數據不完善】的惡性循環。
4. 數據質量差
時常有數據結果計算錯誤，導致做出錯誤的業務決策的情況發生。數據bug頻發，故障溯源和恢復常常消耗大量時間。
5. 數據成本大
隨著業務的發展和時間的推移，企業數據成本呈線性增長，企業每年要為此花費大量的真金白銀。
通常，這些問題會隨著數據中臺的成功上線被解決掉。那數據中臺是如何解決這些痛點的呢，在回答這個問題之前，我們先看看以上這些痛點背后的原因是什么？
二、問題背后的原因是什么
1. 指標口徑不一致
通常表現在3各方面：業務口徑不一致、計算邏輯不一致、數據來源不一致。
業務口徑不一致：業務口徑不一致的指標，應該要有不同的標識去區分，比如上面提到的銷售額這一指標，明明口徑是不一致的，但卻沒有區分，容易讓業務誤解。
計算邏輯不一致：業務口徑的描述往往是一段話，但對于一些計算邏輯比價復雜的指標，一段話通常是描述不清楚的，如果碰巧兩個相同業務口徑的指標是不同的數據研發實現的，極有可能會出現計算邏輯不一致的情況。
數據來源不一致：對于部分指標，有多個數據源可供選擇，如果數據源正好有些細微差異不被發現時，即使加工邏輯一樣，也有可能結果不一致。另外，實時數據和離線數據也會有一定差異。
因此，要實現一致性，就要確保對同一個指標，只有一個業務口徑，只加工一次，且數據來源必須一致。
2. 需求響應速度慢
主要在于煙囪式的開發模式，使得數據復用性低，導致大量重復邏輯代碼的研發，影響需求響應速度。
比如，兩個指標都需要對同一份原始數據進行清洗，原則上來說，只用一個任務對原始數據做清洗，產出一張明細表，另一個指標開發時，便可直接引用已經清洗好的明細表，這樣便可節省一個清洗邏輯的研發工作量。但現實往往是對同一份原始數據做了兩次清。洗。
因此，要解決需求響應速度慢的問題，就要提升數據的復用性，確保相同數據只加工一次，實現數據的共享。
3. 取數效率低
主要表現在兩個方面，一方面是找不到數據，另一方面是取不到數據。
要解決找不到數據的問題，就要構建企業數據資產目錄，讓數據使用者快速找到并理解數據。取不到數據的主要是非技術人員不會寫SQL去提取數據，所以可以為其提供自助取數工具，使其簡單快速的獲取數據。
4. 數據質量低
背后的原因主要是數據問題很難被主動發現和快速修復，經常是使用數據的人反饋投訴時才知道有問題。
數據的加工鏈路一般比較長，有時超過幾十個上百個節點，收到問題反饋時，研發需要逐個任務去排查，然后再重跑有問題的任務及其下游鏈路的每個任務，這一過程往往需要花費很長的時間，導致故障恢復效率低。
因此，要解決數據質量低的問題，就要實現在業務反饋問題之前主動發現問題，并能快速恢復。
數據成本問題主要是數據重復建設導致的存儲和計算資源的浪費，因此，解決這一問題的關鍵是提升數據共享能力，避免數據重復建設，消除冗余數據。
三、數據中臺是如何解決這些問題的
1. 構建全局一致的指標詞典，實現指標體系化管理
按照數倉主題域的方式對所有指標統一命名、分類，明確指標口徑、數據來源、計算邏輯，產出企業的指標詞典，由專門團隊來負責指標口徑的管控；
設計上線方便業務人員查詢的指標詞典管理系統，所有的數據產品、數據報表都引用指標系統的口徑，當鼠標Hover到某個指標上時，浮現該指標的指標口徑定義。
2. 統一數倉建模，構建全局一直的公共層，提升數據復用性
制定統一的數倉建模規范，在模型設計階段，強制相同聚合粒度的模型，度量不能重復，保證相同粒度的指標、度量只加工一次；建設數據地圖，方便數據研發能快速查找并準確理解數據。
3. 提供企業數據地圖和自助取數系統
數據中臺構建了企業數據地圖，數據使用者可通過數據地圖快速了解企業當前有哪些數據，在哪張表里可以看到，關聯了哪些指標和維度；
非技術人員可通過自主取數工具，選取指標，勾選指標的可分析維度，添加篩選條件，點擊查詢，就可以方便獲取數據。
4. 配置數據質量稽核規則和數據預警
通過配置數據質量稽核規則和數據預警，對數據一致性、完整性、正確性和及時性進行監控，確保第一時間發現、恢復、通知數據問題。
5. 上線數據成本治理系統
數據治理系統可實現表維度、任務維度、應用維度的全面數據治理。比如一個30天內沒有被訪問的報表，我們認為其產出價值較低，這時我們可以結合這個報表的所有上游表和下游表產出任務，計算這張表的加工成本，有了價值和成本，便可計算出ROI，根據RO評估，實現低價值報表的及時發現和下線。
四、什么樣的企業適合建設數據中臺
數據中臺的構建需要大量人力物力的投入，所以數據中臺的建設一定要結合企業的現狀，按需選擇，不可盲目跟風。在我看來，企業在選擇是否構建數據中臺的時，可以從以下幾個方面思考：
首先，看企業是否有一定的信息基礎，是否實現了業務數據化的過程，有了一定的數據沉淀，數據中臺，顧名思義，數據是基礎，畢竟巧婦難為無米之炊；
其次，企業是否存在業務數據孤島，是否有需要整合各個業務系統的數據，進行關聯分析的需求，如果有，需要通過構建數據中臺，打通數據孤島，整合各業務系統數據，滿足關聯分析的需求。
比如某零售企業，在業務發展初期，商品、銷售、供應鏈等都是獨立的數據倉庫，后期要構建智能補貨系統，需要打通多個業務系統的數據，因此選擇建設數據中臺。
最后，在日常的數據使用過程中是否遇到指標口徑不一致、需求響應速度慢、數據質量差、數據成本高等痛點。
如果滿足前兩個條件，且在數據應用中存在以上所述的一些痛點，那建議你可以考慮將數據中臺項目提上日程了。
作者：微微；熱愛技術的產品一枚，持續更新數據中臺系列文章，“數據人創作者聯盟”成員。
本文由@一個數據人的自留地 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
????