數據中臺的思考與總結

數據中臺的思考與總結

數據中臺

數據匯聚

數據匯聚是數據中臺必須提供的核心工具，把各類異構網絡、異構數據源的數據方便地採集到數據中臺中進行集中存儲，爲後續的加工建模作準備。數據匯聚方式通常有數據庫同步、埋點、網絡爬蟲、消息隊列等；從匯聚的時效性來分，有離線批量匯聚和實時採集。

數據採集工具:

• Canal
• DataX
• Sqoop

數據開發

數據開發模塊主要面向開發人員、分析人員，提供離線、實時、算法開發工具。

離線開發

1. 做業調度
   • 依賴調度：全部父做業運行完成後，當前做業才能開始運行。圖64中的做業B，只有父做業A和C運行完成後，才能開始被調度。
   • 時間調度：可指定做業的調度開始時間。圖64中的做業B，只有到達05：00後才能開始被調度。
2. 基線控制 在大數據離線做業中，做業執行時間較長，常常遇到急着用數據發現數據還沒出來的狀況。採用算法對做業完成時間進行智能預測，根據預測，看成業沒法正常產出且動態調整沒法完成時，調度中心會及時經過監控告警通知運維值班人員提早介入處理，爲大數據做業執行留出充裕的時間。
3. 異構存儲 企業內部的存儲計算引擎呈多元化趨勢。離線開發中心針對每種類型的計算引擎會開發不一樣的組件，例如，針對Oracle開發Oracle插件，針對Hadoop體系分別開發出Hive、Spark、MR等插件。用戶在界面新建各類做業類型，在執行時自動根據做業的類型尋找相應的插件來運行做業。
4. 代碼校驗 對於常見的SQL任務類型，SQL檢查器會作好嚴格的管控，作到事前發現問題。
5. 多環境級聯 經過環境級聯的方式靈活支持企業的各種環境需求，方便對資源、權限進行控制和隔離。每一個環境有獨立的Hive數據庫、Yarn調度隊列，甚至不一樣的Hadoop集羣。常見的環境以下：
   • 單一環境：只有一個生產環境，內部管理簡單。
   • 經典環境：開發環境中存放脫敏數據、供開發測試使用，上生產環境走發佈流程，用於真實數據生產。 任務、資源和函數必須在開發環境下進行新建、修改或刪除，再通過提交、建立發佈包、贊成發佈三個操做後，才能同步到生產環境。
   • 複雜環境：企業有外部人員和內部人員，會給外部人員提供一個脫敏管控的環境，外部人員開發完的數據模型通過測試後發佈到內部開發環境。
6. 推薦依賴 隨着業務的不斷深刻，數據開發人員須要開發的做業會不斷累加。既能保證準確找到須要定位的上游做業，又能保證不會造成環路。

獲取推薦依賴的核心原理在於上下游做業輸入和輸出的表級血緣依賴圖； 經過血緣分析當前做業的輸入和輸出，找到合適的上游做業； 對合適的做業進行環路檢測，剔除存在閉環的做業； 返回合適的節點列表。

1. 數據權限 企業內部計算引擎多樣化，數據權限管理面臨以下問題：
   • 部分引擎擁有獨立的權限管理系統（例如Oracle、HANA、LibrA），致使權限申請須要到每一種引擎上單獨操做，讓使用變得複雜。
   • 同一種計算引擎，不一樣廠商的權限系統有多種，例如Hadoop自身無數據權限系統，由不一樣廠商各自去實現，目前主要有兩種策略：
   • RBAC（Role-Based Access Control）：如Cloudera用的是Sentry，華爲的FI也是相似的機制
   • PBAC（Policy-Based Access Control）：如Hortonworks用的Ranger * 數據權限是由大數據集羣或數據庫運維人員管理的，開發人員沒法直接操做或者接觸，全部的權限申請都須要運維人員開通，形成運維人員負擔太重。在實際開發中，通常須要運維人員把整個庫的權限受權給某個開發負責人，而後庫裏面的表、字段、函數的權限管理由開發負責人負責就行。 數據權限管理中心提供界面化操做，數據申請方直接在頁面上進行各類權限的申請，數據管理方在界面上審覈權限，執行贊成或拒絕操做。同時，全部權限的申請、審批都會有記錄，便於進行權限審計。在統一數據權限服務中，會對接底層的各類權限管理系統，例如Sentry、Ranger、Oracle，同時對數據權限管理中心提供服務，執行權限的申請、受權、撤銷等操做。

實時開發

1. 元數據管理
2. SQL驅動
3. 組件化開發

智能運維

任務的管理、代碼發佈、運維、監控、告警等一系列集成工具，方便使用，提高效率。重跑、重跑下游、補數據。

數據體系

有了數據匯聚、數據開發模塊，中臺已經具有傳統數據倉庫（後面簡稱：數倉）平臺的基本能力，能夠作數據的匯聚以及各類數據開發，就能夠創建企業的數據體系。以前說數據體系是中臺的血肉，開發、管理、使用的都是數據。

中臺數據體系應具有如下特徵：

• 覆蓋全域數據：數據集中建設、覆蓋全部業務過程數據，業務中臺在數據體系中總能找到須要的數據。
• 結構層次清晰：縱向的數據分層、橫向主題域、業務過程劃分，讓整個層次結構清晰易理解。
• 數據準確一致：定義一致性指標，統一命名、統一業務含義、統一計算口徑，並有專業團隊負責建模，保證數據的準確一致。
• 性能提高：統一的規劃設計，選用合理的數據模型，清晰的定義並統一規範，而且考慮使用場景，使總體性能更好。
• 下降成本：數據體系的建設使得數據能被業務共享，這避免了大量煙囪式的重複建設，節約了計算、存儲和人力成本。
• 方便易用：易用的整體原則是越日後越能方便地直接使用數據，把一些複雜的處理儘量前置，必要時作適當的冗餘處理。

不一樣行業的數據體系建設：

• 地產行業

• 證券行業

• 零售行業

• 製造行業

• 傳媒行業

• 檢務行業

1. 貼源數據層ODS

對各業務系統數據進行採集、匯聚，儘量保留原始業務流程數據，與業務系統基本保持一致，僅作簡單整合、非結構化數據結構化處理或者增長標識數據日期描述信息，不作深度清洗加工。 表名：ODS_系統簡稱_業務系統表名 字段名：與業務系統字段名保持一致，字段類型也儘量保持一致 對於數據量比較大的業務表，採用增量同步的方式，則要同時創建增量表和全量表，增量表命名加後綴：ODS_系統簡稱_業務系統表名_delta。 對於日誌、文件等半結構數據，不只要存儲原始數據，還要存儲結構化以後的數據。

使用DataX同步數據步驟： 1）肯定業務系統源表與貼源數據層目標表 2）配置數據字段映射關係，目標表可能會增長採集日期、分區、原系統標識等必要信息，業務相關內容不作轉換 3）若是是增量同步或着有條件的同步部分數據，則配置數據同步條件 4）清理目標表對應數據 5）啓動同步任務，往貼源數據層目標表導入數據 6）驗證任務是否能夠正確運行，而且採集到準確數據 7）發佈採集任務，加入生產調度，並配置相關限速、容錯、質量監控、告警機制

1. 統一數倉層DW
   • 明細數據層DWD
   • 彙總數據層DWS 與傳統數據倉庫功能基本一致，對全歷史業務過程數據進行建模存儲。對來源於業務系統的數據進行從新組織。業務系統是按照業務流程方便操做的方式來組織數據的，而統一數倉層從業務易理解的視角來從新組織，定義一致的指標、維度，各業務板塊、業務域按照統一規範獨立建設，從而造成統一規範的標準業務數據體系。
2. 標籤數據層TDM

面向對象建模，對跨業務板塊、跨數據域的特定對象數據進行整合，經過IDMapping把各個業務板塊、各個業務過程當中的同一對象的數據打通，造成對象的全域標籤體系，方便深度分析、挖掘、應用。

1. 應用數據層ADS

按照業務的須要從統一數倉層、標籤數據層抽取數據，並面向業務的特殊須要加工業務特定數據，以知足業務及性能需求，向特定應用組裝應用數據。

數據資產管理

數據資產管理包括對數據資產目錄、元數據、數據質量、數據血緣、數據生命週期等進行管理和展現，以一種更直觀的方式展示企業的數據資產，提高企業的數據意識。 數據資產對上支持以價值挖掘和業務賦能爲導向的數據應用開發，對下依託大數據平臺實現數據全生命週期的管理，並對企業數據資產的價值、質量進行評估，促進企業數據資產不斷自我完善，持續向業務輸出動力。

數據治理

傳統的數據治理一般包含數據標準管理、元數據管理、數據質量管理、數據安全管理、數據生命週期管理等內容。

數據服務體系

前面利用數據匯聚、數據開發建設企業的數據資產，利用數據管理展示企業的數據資產，可是並無發揮數據的價值。數據服務體系就是把數據變爲一種服務能力，經過數據服務讓數據參與到業務， 快速開發企業的業務中臺等。

查詢服務

輸入特定的查詢條件，返回該條件下的數據，以API形式供上層應用調用。 1）支持配置查詢標識，底層數據組織通常會對該標識創建索引，以加快查詢速度 2）支持配置過濾項 3）支持查詢結果配置，包括數據排序規則和分頁規則。

分析服務

藉助分析組件高效的大數據分析能力，對數據進行關聯分析，分析結果經過API形式供上層應用調用。 1）支持多源數據接入：企業的數據通過清洗加工轉換成數據資產後，最終經過服務做用於業務系統，基於企業異構存儲的現狀，要求分析服務可以支持與Hive、ES、Greenplum、MySQL、Oracle、本地文件等多種數據源進行鏈接。 2）高性能即席查詢：隨着企業數據爆發式增加，傳統的數據分析工具遇到分析能力的瓶頸，也就是對大數據量的分析愈來愈乏力。所以，這就要求分析服務內置高速計算引擎，以對數據進行高性能的即席計算，實現億級數據毫秒級（至多秒級）分析和計算，減小用戶等待時間。 3）多維數據分析 分析服務除了支持常規的數據分析、上卷下鑽、切片切塊以外，還應該支持多維的數據分析以及深層次的數據挖掘，發現數據背後的關聯關係。 4）靈活對接業務系統

推薦服務

按約定的格式提供歷史日誌行爲數據和實時訪問數據，推薦模型就會生成相應的推薦API，從而爲上層應用提供推薦服務。 推薦服務即所謂的千人千面，對不一樣的人對物的行爲進行數據挖掘，構建每一個人與物之間的關係程度，來推薦人、物以知足用戶的興趣愛好，以提高用戶對業務的粘性。每一個人打開手機淘寶看到的內容都不同，這就是一種基於人的興趣愛好的推薦服務能力。 1）支持不一樣行業的推薦：不一樣行業背後的推薦邏輯是有區別的 2）支持不一樣場景的推薦：之內容資訊爲例，在用戶冷啓動場景下，應該推薦哪些資訊？在用戶已有瀏覽行爲的場景下，又該爲其推薦哪些資訊？ 3）支持推薦效果優化：從導入的原始數據開始，通過推薦組件生成推薦數據，再根據用戶的瀏覽數據不斷修正推薦模型，從而使推薦效果不斷優化

圈人服務

從全量用戶數據中，基於標籤組合篩選符合指定特徵條件的人羣，並經過API形式供上層應用調用。 1）支持人羣圈選：經過SQL代碼或標籤取值組合等多種方式，實現人員查找，幫用戶找到對的人羣 2）支持人羣計量：營銷部門或者廣告公司使用圈人服務圈選出目標人羣后，每每還要考慮人羣量是否符合預期，由於預算有限，不可能不計成本的對人羣進行營銷。 3）支持多渠道對接：將人羣名單導出到相應的下游系統。最簡單的名單導出方式是先下載文件，再由業務人員導入相應的業務系統中。或者直接對接到短信系統、微信投放接口、營銷活動系統等。

離線平臺

蘇寧

蘇寧大數據離線任務開發調度平臺實踐

蘇寧大數據離線任務開發調度平臺實踐：任務調度模塊架構設計

蘇寧離線平臺產品功能圖：

蘇寧調度模塊功能圖：

蘇寧離線平臺總體架構圖：

跨任務流依賴的實現： FTP事件機制，即在 FTP 服務器上創建標識文件，一個事件對應一個標識文件地址，當 FTP 服務器上的標識文件生成的時候，咱們認爲業務系統已經完成做業，須要觸發平臺任務執行。

「華佗」平臺，實施任務診斷：

當即觸發的任務，放入DelayQueue的隊列頭部 週期調度的任務，使用Quartz 依賴觸發的任務，使用zk，各個子節點監聽本身的父節點，全部父節點執行完畢則可觸發執行

實時平臺

美團點評

使用了Grafana，能夠內嵌到本身的平臺。

bilibili

SQL化編程

DAG拖拽編程

一體化託管運維

實時平臺由實時傳輸和實時計算兩部分組成，平臺底層統一管理元數據、血緣、權限以及做業運維等。實時傳輸主要負責將數據傳入到大數據體系中。實時計算基於 BSQL 提供各類應用場景支持。

以下圖所示，實時傳輸有 APP 日誌、數據庫 Binlog、服務端日誌或系統日誌。bilibili 內部的 Lancer 系統解決數據落地到 Kafka 或 HDFS。計算體系主要圍繞 Saber 構建一套 BSQL，底層基於 YARN 進行調度管理。

上層核心基於 Flink 構建運行池。再向上一層知足多種維表場景，包括 MySQL、Redis、HBase。狀態（State）部分在 RocksDB 基礎上，還擴展了 MapDB、Redis。Flink 須要 IO 密集是很麻煩的問題，由於 Flink 的資源調度體系內有內存和 CPU，但 IO 單位未作統一管理。當某一個做業對 IO 有強烈的需求時，須要分配不少以 CPU 或內存爲單位的資源，且未必可以很好的知足 IO 的擴展。因此本質上 bilibili 現階段是將 IO 密集的資源的 State 轉移到 Redis 上作緩解。數據通過 BSQL 計算完成以後傳輸到實時數倉，如 Kafka、HBase、ES 或 MySQL、TiDB。最終到 AI 或 BI、報表以及日誌中心。

場景

• AI工程方向，解決了廣告、搜索、推薦的流式Joiner和維表Joiner
• 實時計算的特徵支持，支持 Player 以及 CDN 的質量監控。包括直播、PCU、卡頓率、CDN 質量等；
• 用戶增加，即如何藉助實時計算進行渠道分析、調整渠道投放效果；
• 實時 ETL，包括 Boss 實時播報、實時大屏、看板等。

網易

目前網易流計算覆蓋了絕大多數場景，包括廣告、電商大屏、ETL、數據分析、推薦、風控、搜索、直播等。

事件管理

對於分佈式平臺的任務操做而言，當前任務啓動過程當中只容許一我的操做，而不容許兩我的同時操做，這就須要如下幾個模塊來共同配合：

• Server：事件執行的發起者，接受事件的請求，進行數據校驗，拼裝，將事件發送給 Kernel 執行。
• Kernel：事件具體邏輯的執行者，根據請求向集羣發送指令(Shell 腳本方式)。
• Admin：事件執行結果的確認者，根據事件類型，獲取事件的最終結果，保證結果的正確性。

以啓動場景爲例：

首先，Server 會接收到來自用戶的啓動請求，以後會建立一個分佈式鎖，Admin 會監控這個鎖。

而後， Server 向 Kernel 提交任務，提交以後會當即返回，返回以後就會當即更新數據庫中的狀態，將狀態更新爲啓動中，這樣在頁面上用戶就可以看到任務是啓動中的狀態了。

接下來，Server 就會等待內核的 Shell 腳本的執行結果，若是 Shell 腳本執行成功了，就會去寫 Zookeeper，寫完 Zookeeper 以後 Admin 模塊就會立刻檢測到 Zookeeper 節點有狀態發生了修改，Admin 會當即去獲取 YARN 上的任務狀態，若是獲取到任務狀態是運行中，就將數據庫的任務狀態更新爲運行中，這會在前端看到任務就已是運行狀態了。

最後一步是 Admin 更爲完數據庫以後，會釋放掉 Zookeeper 上的鎖，其餘人這時候就能夠操做這個任務了。

Server、Kernel 和 Admin 這三個模塊都是不可靠的，那麼如何保證其穩定和高可用呢？Server 能夠經過部署多個，水平擴展來實現，Kernel 則會由 Server 來進行監聽，當發現 Kernel 掛了，能夠由 Server 從新拉起或者從新建立。而 Admin 的高可用則是經過熱備來實現的，若是主 Admin 掛掉了，能夠立刻遷移到備 Admin，備 Admin 能夠迅速將元數據以及任務信息所有加載進來接替工做，進而實現高可用。

平臺任務狀態管理

平臺的任務狀態主要由 Server 和 Admin 來控制。Server 主要控制初始狀態的執行，Admin 則主要負責控制全部與 YARN 相關的狀態交互。

任務調試

SQL 類型的任務支持調試功能，用戶能夠根據不一樣的 source 表和 dim 表，上傳不一樣的 csv 文件做爲輸入數據，進行調試。調試執行由指定的 kernel 來完成，sloth-server 負責組裝請求，調用 kernel，返回結果，蒐集日誌。

日誌檢索

在 YARN 集羣的每一個節點上面部署 Filebeat，經過 Filebeat 將節點上面的任務日誌寫入到 Kafka 消息隊列中，而後經過 Logstash 進行解析處理，以後寫入 ES 集羣中。主要用於兩個用途，一個是經過界面 Kibana 來提供給開發和運維人員使用，另一個就是將運行時狀態的任務日誌直接在界面上展現供用戶進行搜索和查看。

監控

在監控方面，使用的是 influxdb metric report 組件對於指標進行監控。時序數據庫使用的是網易自研的 ntsdb 時序數據庫，其可以支持動態擴展和高可用等功能。監控指標的使用方式有兩種： 一種是經過 Grafana 的界面來查看指標； 另一種是報警模塊會從Ntsdb中獲取相關指標數據並進行監控報警。

報警

Sloth 流計算平臺支持常見的任務失敗，數據滯留延遲，failover 報警，也支持用戶自定義規則報警，包括對於輸入 QPS、輸出 QPS，戶自定義延遲的監控等。以輸入 QPS 爲例，能夠設置當連續幾個週期內 QPS 低於某一值時就觸發報警。此外，報警方式也支持多樣化的工具，好比各類網易內部的聊天工具、郵件、電話以及短信等，對於任務調試階段，爲了不被騷擾，能夠設置任務報警抑制時間間隔。

實時數倉

目前網易不少產品已經開始實時數倉的建設了，但仍舊處於持續完善過程當中。實時數倉的建設和離線數倉大體相同，只不過實時數倉是通過實時計算平臺進行處理的。大體的過程就是首先收集日誌、埋點數據等，將其寫入到 Kafka 裏面，通過實時計算平臺進行處理，將 ODS 層中的明細數據抽取出來，在進行彙總以及維度關聯等操做，將結果寫入到 Redis，Kudu 等，再經過數據服務提供給前端的業務使用。x

電商應用-數據分析

實時活動分析、首頁資源分析、流量漏斗以及實時毛利計算等。

電商應用-搜索推薦

電商的搜索推薦場景則主要包括用戶實時足跡、用戶實時特徵、商品實時特徵、實時 CTR CVR 樣本組建、首頁 A 區輪播、B 區活動精選等 UV、PV 實時統計等。 網絡營銷中的常見名詞解釋：

CPC (Cost Per Click): 按點擊計費 CPA (Cost Per Action): 按成果數計費 CPM (Cost Per Mille): 按千次展示計費 CVR (Click Value Rate): 轉化率，衡量CPA廣告效果的指標 CTR (Click Through Rate): 點擊率 PV (Page View): 流量 ADPV (Advertisement Page View): 載有廣告的pageview流量ADimp (ADimpression): 單個廣告的展現次數 PV單價: 每PV的收入，衡量頁面流量變現能力的指標 

離線數倉與實時數倉

從0建設離線數倉

建設數倉

數據倉庫定義：在企業管理和決策中面向主題的、集成的、與時間相關的、不可修改的數據集合。 數據倉庫目標：數據資產、決策信息。

• ETL過程：打通你的任督二脈（離線+實時），讓數據在整個環節中流通起來
• 數據分層：一套低耦合、高內聚的層級，是十分重要的，總不想業務、數據等一變化，數倉像又投胎了一次
• 數據集成：多業務場景下，打破數據信息壁壘，避免數據歧義，統一數據服務
• 規範化：良好的流程化、規範化設計，易維護、高擴展
• 監控與輔助：質量監控、調度管理、元數據管理、信息安全管理
• 走向服務：對外api服務/自助查詢平臺/OLAP分析平臺

ETL

業務數據每每涉及多種數據源，數據存儲也經常會有多種選擇。文本數據、日誌數據、RMDB、Nosql等。則要求etl工具可以覆蓋這些業務場景。 工具備datax/sqoop/kettle/informatica等等。 ETL通常爲最開始的部分，凌晨以後的時間點。a：避免集中式的對某個jdbc海量同步，影響業務(部分從庫可能提供查詢服務)、b：明確調度的時間，應儘量的在某個時間段內完成(不能僅依靠調度，實現任務流的串行；爲後期的大做業空間，佔用等待的系統資源)

分層

1. Stage緩衝層 事務性數據，每日增量方式進行數據同步。須要注意數據同步時的邊界問題，避免髒數據。 對於非事務性數據，通常經過快照/全量更新。不對外開放數據查詢。

2. ods層 通常場景下，咱們認爲該層數據與線上保持一致。實際處理過程當中，爲了處理時間維度上的數據變化，會記錄數據的變化軌跡。對於該部分數據，應該有選擇的實施，避免業務處理過程變得複雜和問題發生後難以回溯。

3. dim/dw層 (模型層) dim：維度層 dw：主題事實及業務寬表 在ods基礎上，設計一個寬表/模型層，經過維度建模的方式，實現維度數據與事實數據的分離（星型模型）。

4. da層（應用層） 面向不一樣的應用，聚合類的數據層。該層對於dim/dw層的使用，是對模型層的一個檢視維度。

代碼規範

1. 腳本格式規範：腳本頭部註釋編碼規範、註釋規範、sql規範參考goole規範
2. 文件/表命名規範：一個文件中，只應該有一張表，其他只能是臨時表；表名稱應與文件名相同
3. 字段命名規範：去除多詞同義，和同詞多義的問題。尤爲是在模型層（通常也叫作一致性維度）

區別

離線數倉主要基於sqoop、datax、hive等技術來構建 T+1 的離線數據，經過定時任務天天垃取增量數據導入到hive表中，而後建立各個業務相關的主題，對外提供T+1的數據查詢接口。 實時數倉主要是基於數據採集工具，如canal等原始數據寫入到kafka這樣的數據通道中，最後通常都是寫入到相似於HBase這樣的OLAP存儲系統中。對外提供分鐘級別，甚至秒級別的查詢方案。

數倉類型	準確性	實時性	穩定性
離線數倉	準確度高	時延通常在一天	穩定性好，方便重算
實時數倉	準確度低，數據延遲、數據亂序形成數據準確度低	分鐘級延遲	穩定性差，須要考慮數據回溯處理

數據倉庫的建設主要包括數據的採集、數據的處理、數據歸檔、數據應用四個方面。 當前主要的應用場景包括報表展現、即席查詢、BI展現、數據分析、數據挖掘、模型訓練等方面。 數據倉庫的建設是面向主題的、集成性的、不可更新的、時許變化的。

實時數倉的實施關鍵點：

1. 端到端數據延遲、數據流量的監控
2. 故障的快速恢復能力
3. 數據的回溯處理，系統支持消費指定時間段內的數據
4. 實時數據從實時數倉中查詢，T+1數據藉助離線通道修正
5. 數據地圖、數據血緣關係的梳理
6. 業務數據質量的實時監控，初期能夠根據規則的方式來識別質量情況

其實，你須要的不是實時數倉，須要的是一款合適且強大的OLAP數據庫。 在實時數倉的建設中，OLAP數據庫的選型直接制約實時數倉的可用性和功能性。

原始層

明細層

彙總層

應用層

• ods：原始數據層，事實數據，存儲在kafka中
• dwd：數據明細層，能夠作一些join等加寬處理，能夠存儲在kafka和redis中
• dim：維度數據，如存儲在HBase中的數據
• dm：MySQL -> 彙總指標模型；Greenplum -> 明細，多維分析關聯；HBase -> 彙總指標(大量併發)；Redis -> 彙總、大列表TopN

數據中臺解決方案

零售行業

RPS (Revenue Per Search): 每搜索產生的收入，衡量搜索結果變現能力指標 

　 ROI： 投資回報率（ROI）是指經過投資而應返回的價值，它涵蓋了企業的獲利目標。利潤和投入的經營所必備的財產相關，由於管理人員必須經過投資和現有財產得到利潤。又稱會計收益率、投資利潤率。