數據中臺的概念提出很多年，很多企業運用的也很深入了，雖然聽的很多，不過在過往的工作經歷中沒有體會到數據中臺的必要性，對數據中臺的角色和定位很模糊。
什麼是數據中臺？
數據中臺有哪些功能？
我的業務是否需要數據中臺？
近年由於工作中不同場景的切換應用，體會到數據中臺的用武之地，實操了不少數據平臺的使用。以工作經歷和使用視角進行來詮釋數據中臺。
一、工作中出現的麻煩
1. 需要使用其他業務系統的數據，如何做？
通用做法：和對應業務系統研發團隊進行業務對接，定義好需要的業務數據結構，雙方通過開發接口實現數據的訪問。
弊端：溝通代價大(跨部門甚至跨企業)、實施週期長(從需求、開發到測試對接一整套流程)、開發成本高(普遍需要定製開發費用)。
思考：這種高頻出現的需求，能否找到一套直接實現數據間交互的方法，免去不同團隊之間的理解拉平成本。
2. 歷史業務大量沉澱的數據都是文件格式(如excel), 如何利用甚至分析這些數據？
通用做法：需要使用的時候，找到對這塊業務很熟悉的同事，進行手工整理及統計。
弊端：數據完整性不確定、數據準確性不確定，數據分析很主觀。
思考：是否有工具將這種數據實現定期同步到數據庫，進行數據應用和分析。
3. 歷史數據錯誤率很高，不同業務系統擁有同緯度數據，但數據又不統一，怎麼做數據校驗及修正？
通用做法：每個業務系統各成一派，覺得數據不對，進行各自系統的維護。
弊端：無法形成正確有效的數據資產。
思考：建設一套公共數據倉庫，統一維護管理，對外通過接口實現數據共享。
二、數據中臺的誕生
需要一套包含數據入庫、數據治理、數據分享的平臺來完成上述工作中的痛點，這就是典型的圍繞數據倉庫的初步數據中臺定位。
三、數據中臺的組成
1. 數據集成(ETL)：通過低代碼方式實現數據同步、數據遷移，形成數據數倉化，應該包含功能：數據源管理、離線數據同步、實時數據同步、數據遷移監控及預警等功能
2. 數據集市(API集市)：通過數據模型、SQL、腳本、存儲過程等可以無代碼快速實現90%的API快速開發，包含API註解式開發、API網關、API部署及資源監控等功能
3. 數據清洗平臺：定義數據標準，統計及分析數據質量，低代碼式數據修復及驗證。
通過數據集成、數據清洗、數據集市實現數據拿得到、可管理、用起來的業務目標。