本文將總結下數(shù)據(jù)中臺的相關理論知識。Flink平臺化需要改進的點等等。

參考：《數(shù)據(jù)中臺》

數(shù)據(jù)中臺

數(shù)據(jù)匯聚

數(shù)據(jù)匯聚是數(shù)據(jù)中臺必須提供的核心工具，把各種異構網(wǎng)絡、異構數(shù)據(jù)源的數(shù)據(jù)方便地采集到數(shù)據(jù)中臺中進行集中存儲，為后續(xù)的加工建模做準備。數(shù)據(jù)匯聚方式一般有數(shù)據(jù)庫同步、埋點、網(wǎng)絡爬蟲、消息隊列等；從匯聚的時效性來分，有離線批量匯聚和實時采集。

• 數(shù)據(jù)采集工具 Canal、DataX、Sqoop

數(shù)據(jù)開發(fā)

數(shù)據(jù)開發(fā)模塊主要面向開發(fā)人員、分析人員，提供離線、實時、算法開發(fā)工具。

離線開發(fā)

作業(yè)調度

• 依賴調度：所有父作業(yè)運行完成后，當前作業(yè)才能開始運行。圖64中的作業(yè)B，只有父作業(yè)A和C運行完成后，才能開始被調度。

• 時間調度：可指定作業(yè)的調度開始時間。圖64中的作業(yè)B，只有到達05：00后才能開始被調度。

基線控制 在大數(shù)據(jù)離線作業(yè)中，作業(yè)執(zhí)行時間較長，經(jīng)常遇到急著用數(shù)據(jù)發(fā)現(xiàn)數(shù)據(jù)還沒出來的情況。采用算法對作業(yè)完成時間進行智能預測，根據(jù)預測，當作業(yè)無法正常產(chǎn)出且動態(tài)調整無法完成時，調度中心會及時通過監(jiān)控告警通知運維值班人員提前介入處理，為大數(shù)據(jù)作業(yè)執(zhí)行留出充裕的時間。

異構存儲 企業(yè)內部的存儲計算引擎呈多元化趨勢。離線開發(fā)中心針對每種類型的計算引擎會開發(fā)不同的組件，例如，針對Oracle開發(fā)Oracle插件，針對Hadoop體系分別開發(fā)出Hive、Spark、MR等插件。用戶在界面新建各種作業(yè)類型，在執(zhí)行時自動根據(jù)作業(yè)的類型尋找相應的插件來運行作業(yè)。

代碼校驗 對于常見的SQL任務類型，SQL檢查器會做好嚴格的管控，做到事前發(fā)現(xiàn)問題。

多環(huán)境級聯(lián) 通過環(huán)境級聯(lián)的方式靈活支持企業(yè)的各類環(huán)境需求，方便對資源、權限進行控制和隔離。每個環(huán)境有獨立的Hive數(shù)據(jù)庫、Yarn調度隊列，甚至不同的Hadoop集群。常見的環(huán)境如下：

• 單一環(huán)境：只有一個生產(chǎn)環(huán)境，內部管理簡單。

• 經(jīng)典環(huán)境：開發(fā)環(huán)境中存放脫敏數(shù)據(jù)、供開發(fā)測試使用，上生產(chǎn)環(huán)境走發(fā)布流程，用于真實數(shù)據(jù)生產(chǎn)。任務、資源和函數(shù)必須在開發(fā)環(huán)境下進行新建、修改或刪除，再經(jīng)過提交、創(chuàng)建發(fā)布包、同意發(fā)布三個操作后，才能同步到生產(chǎn)環(huán)境。

• 復雜環(huán)境：企業(yè)有外部人員和內部人員，會給外部人員提供一個脫敏管控的環(huán)境，外部人員開發(fā)完的數(shù)據(jù)模型經(jīng)過測試后發(fā)布到內部開發(fā)環(huán)境。

推薦依賴 隨著業(yè)務的不斷深入，數(shù)據(jù)開發(fā)人員需要開發(fā)的作業(yè)會不斷累加。既能保證準確找到需要定位的上游作業(yè)，又能保證不會形成環(huán)路。

獲取推薦依賴的核心原理在于上下游作業(yè)輸入和輸出的表級血緣依賴圖；通過血緣分析當前作業(yè)的輸入和輸出，找到合適的上游作業(yè)；對合適的作業(yè)進行環(huán)路檢測，剔除存在閉環(huán)的作業(yè)；返回合適的節(jié)點列表。

數(shù)據(jù)權限 企業(yè)內部計算引擎多樣化，數(shù)據(jù)權限管理面臨如下問題：

• 部分引擎擁有獨立的權限管理系統(tǒng)（例如Oracle、HANA、LibrA），導致權限申請需要到每一種引擎上單獨操作，讓使用變得復雜。

• 同一種計算引擎，不同廠商的權限系統(tǒng)有多種，例如Hadoop自身無數(shù)據(jù)權限系統(tǒng)，由不同廠商各自去實現(xiàn)，目前主要有兩種策略：RBAC（Role-Based Access Control）：如Cloudera用的是Sentry，華為的FI也是類似的機制 PBAC（Policy-Based Access Control）：如Hortonworks用的Ranger

• 數(shù)據(jù)權限是由大數(shù)據(jù)集群或數(shù)據(jù)庫運維人員管理的，開發(fā)人員無法直接操作或者接觸，所有的權限申請都需要運維人員開通，造成運維人員負擔過重。在實際開發(fā)中，一般需要運維人員把整個庫的權限授權給某個開發(fā)負責人，然后庫里面的表、字段、函數(shù)的權限管理由開發(fā)負責人負責就行。數(shù)據(jù)權限管理中心提供界面化操作，數(shù)據(jù)申請方直接在頁面上進行各種權限的申請，數(shù)據(jù)管理方在界面上審核權限，執(zhí)行同意或拒絕操作。同時，所有權限的申請、審批都會有記錄，便于進行權限審計。在統(tǒng)一數(shù)據(jù)權限服務中，會對接底層的各種權限管理系統(tǒng)，例如Sentry、Ranger、Oracle，同時對數(shù)據(jù)權限管理中心提供服務，執(zhí)行權限的申請、授權、撤銷等操作。

實時開發(fā)

元數(shù)據(jù)管理

SQL驅動

組件化開發(fā)

智能運維

任務的管理、代碼發(fā)布、運維、監(jiān)控、告警等一系列集成工具，方便使用，提升效率。重跑、重跑下游、補數(shù)據(jù)。

數(shù)據(jù)體系

有了數(shù)據(jù)匯聚、數(shù)據(jù)開發(fā)模塊，中臺已經(jīng)具備傳統(tǒng)數(shù)據(jù)倉庫（后面簡稱：數(shù)倉）平臺的基本能力，可以做數(shù)據(jù)的匯聚以及各種數(shù)據(jù)開發(fā)，就可以建立企業(yè)的數(shù)據(jù)體系。之前說數(shù)據(jù)體系是中臺的血肉，開發(fā)、管理、使用的都是數(shù)據(jù)。

中臺數(shù)據(jù)體系應具備以下特征：

• 覆蓋全域數(shù)據(jù)：數(shù)據(jù)集中建設、覆蓋所有業(yè)務過程數(shù)據(jù)，業(yè)務中臺在數(shù)據(jù)體系中總能找到需要的數(shù)據(jù)。

• 結構層次清晰：縱向的數(shù)據(jù)分層、橫向主題域、業(yè)務過程劃分，讓整個層次結構清晰易理解。

• 數(shù)據(jù)準確一致：定義一致性指標，統(tǒng)一命名、統(tǒng)一業(yè)務含義、統(tǒng)一計算口徑，并有專業(yè)團隊負責建模，保證數(shù)據(jù)的準確一致。

• 性能提升：統(tǒng)一的規(guī)劃設計，選用合理的數(shù)據(jù)模型，清晰的定義并統(tǒng)一規(guī)范，并且考慮使用場景，使整體性能更好。

• 降低成本：數(shù)據(jù)體系的建設使得數(shù)據(jù)能被業(yè)務共享，這避免了大量煙囪式的重復建設，節(jié)約了計算、存儲和人力成本。

• 方便易用：易用的總體原則是越往后越能方便地直接使用數(shù)據(jù)，把一些復雜的處理盡可能前置，必要時做適當?shù)娜哂嗵幚怼?/p>

不同行業(yè)的數(shù)據(jù)體系建設：

• 地產(chǎn)行業(yè)

• 證券行業(yè)

• 零售行業(yè)

• 制造行業(yè)

• 傳媒行業(yè)

• 檢務行業(yè)

貼源數(shù)據(jù)層ODS 對各業(yè)務系統(tǒng)數(shù)據(jù)進行采集、匯聚，盡可能保留原始業(yè)務流程數(shù)據(jù)，與業(yè)務系統(tǒng)基本保持一致，僅做簡單整合、非結構化數(shù)據(jù)結構化處理或者增加標識數(shù)據(jù)日期描述信息，不做深度清洗加工。表名：ODS_系統(tǒng)簡稱_業(yè)務系統(tǒng)表名 字段名：與業(yè)務系統(tǒng)字段名保持一致，字段類型也盡可能保持一致 對于數(shù)據(jù)量比較大的業(yè)務表，采用增量同步的方式，則要同時建立增量表和全量表，增量表命名加后綴：ODS_系統(tǒng)簡稱_業(yè)務系統(tǒng)表名_delta。對于日志、文件等半結構數(shù)據(jù)，不僅要存儲原始數(shù)據(jù)，還要存儲結構化之后的數(shù)據(jù)。

使用DataX同步數(shù)據(jù)步驟：1）確定業(yè)務系統(tǒng)源表與貼源數(shù)據(jù)層目標表 2）配置數(shù)據(jù)字段映射關系，目標表可能會增加采集日期、分區(qū)、原系統(tǒng)標識等必要信息，業(yè)務相關內容不做轉換 3）如果是增量同步或著有條件的同步部分數(shù)據(jù)，則配置數(shù)據(jù)同步條件 4）清理目標表對應數(shù)據(jù) 5）啟動同步任務，往貼源數(shù)據(jù)層目標表導入數(shù)據(jù) 6）驗證任務是否可以正確運行，并且采集到準確數(shù)據(jù) 7）發(fā)布采集任務，加入生產(chǎn)調度，并配置相關限速、容錯、質量監(jiān)控、告警機制

統(tǒng)一數(shù)倉層DW

• 明細數(shù)據(jù)層DWD

• 匯總數(shù)據(jù)層DWS 與傳統(tǒng)數(shù)據(jù)倉庫功能基本一致，對全歷史業(yè)務過程數(shù)據(jù)進行建模存儲。對來源于業(yè)務系統(tǒng)的數(shù)據(jù)進行重新組織。業(yè)務系統(tǒng)是按照業(yè)務流程方便操作的方式來組織數(shù)據(jù)的，而統(tǒng)一數(shù)倉層從業(yè)務易理解的視角來重新組織，定義一致的指標、維度，各業(yè)務板塊、業(yè)務域按照統(tǒng)一規(guī)范獨立建設，從而形成統(tǒng)一規(guī)范的標準業(yè)務數(shù)據(jù)體系。

標簽數(shù)據(jù)層TDM 面向對象建模，對跨業(yè)務板塊、跨數(shù)據(jù)域的特定對象數(shù)據(jù)進行整合，通過IDMapping把各個業(yè)務板塊、各個業(yè)務過程中的同一對象的數(shù)據(jù)打通，形成對象的全域標簽體系，方便深度分析、挖掘、應用。

應用數(shù)據(jù)層ADS 按照業(yè)務的需要從統(tǒng)一數(shù)倉層、標簽數(shù)據(jù)層抽取數(shù)據(jù)，并面向業(yè)務的特殊需要加工業(yè)務特定數(shù)據(jù)，以滿足業(yè)務及性能需求，向特定應用組裝應用數(shù)據(jù)。

數(shù)據(jù)資產(chǎn)管理

數(shù)據(jù)資產(chǎn)管理包括對數(shù)據(jù)資產(chǎn)目錄、元數(shù)據(jù)、數(shù)據(jù)質量、數(shù)據(jù)血緣、數(shù)據(jù)生命周期等進行管理和展示，以一種更直觀的方式展現(xiàn)企業(yè)的數(shù)據(jù)資產(chǎn)，提升企業(yè)的數(shù)據(jù)意識。數(shù)據(jù)資產(chǎn)對上支持以價值挖掘和業(yè)務賦能為導向的數(shù)據(jù)應用開發(fā)，對下依托大數(shù)據(jù)平臺實現(xiàn)數(shù)據(jù)全生命周期的管理，并對企業(yè)數(shù)據(jù)資產(chǎn)的價值、質量進行評估，促進企業(yè)數(shù)據(jù)資產(chǎn)不斷自我完善，持續(xù)向業(yè)務輸出動力。

數(shù)據(jù)治理

傳統(tǒng)的數(shù)據(jù)治理通常包含數(shù)據(jù)標準管理、元數(shù)據(jù)管理、數(shù)據(jù)質量管理、數(shù)據(jù)安全管理、數(shù)據(jù)生命周期管理等內容。

數(shù)據(jù)服務體系

前面利用數(shù)據(jù)匯聚、數(shù)據(jù)開發(fā)建設企業(yè)的數(shù)據(jù)資產(chǎn)，利用數(shù)據(jù)管理展現(xiàn)企業(yè)的數(shù)據(jù)資產(chǎn)，但是并沒有發(fā)揮數(shù)據(jù)的價值。數(shù)據(jù)服務體系就是把數(shù)據(jù)變?yōu)橐环N服務能力，通過數(shù)據(jù)服務讓數(shù)據(jù)參與到業(yè)務， 快速開發(fā)企業(yè)的業(yè)務中臺等。

查詢服務

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

分析服務

借助分析組件高效的大數(shù)據(jù)分析能力，對數(shù)據(jù)進行關聯(lián)分析，分析結果通過API形式供上層應用調用。1）支持多源數(shù)據(jù)接入：企業(yè)的數(shù)據(jù)經(jīng)過清洗加工轉換成數(shù)據(jù)資產(chǎn)后，最終通過服務作用于業(yè)務系統(tǒng)，基于企業(yè)異構存儲的現(xiàn)狀，要求分析服務能夠支持與Hive、ES、Greenplum、MySQL、Oracle、本地文件等多種數(shù)據(jù)源進行連接。2）高性能即席查詢：隨著企業(yè)數(shù)據(jù)爆發(fā)式增長，傳統(tǒng)的數(shù)據(jù)分析工具遇到分析能力的瓶頸，也就是對大數(shù)據(jù)量的分析越來越乏力。因此，這就要求分析服務內置高速計算引擎，以對數(shù)據(jù)進行高性能的即席計算，實現(xiàn)億級數(shù)據(jù)毫秒級（至多秒級）分析和計算，減少用戶等待時間。3）多維數(shù)據(jù)分析 分析服務除了支持常規(guī)的數(shù)據(jù)分析、上卷下鉆、切片切塊之外，還應該支持多維的數(shù)據(jù)分析以及深層次的數(shù)據(jù)挖掘，發(fā)現(xiàn)數(shù)據(jù)背后的關聯(lián)關系。4）靈活對接業(yè)務系統(tǒng)

推薦服務

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

圈人服務

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

離線平臺

蘇寧

蘇寧大數(shù)據(jù)離線任務開發(fā)調度平臺實踐蘇寧大數(shù)據(jù)離線任務開發(fā)調度平臺實踐：任務調度模塊架構設計

蘇寧離線平臺產(chǎn)品功能圖：

蘇寧調度模塊功能圖：

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

跨任務流依賴的實現(xiàn)：FTP事件機制，即在 FTP 服務器上建立標識文件，一個事件對應一個標識文件地址，當 FTP 服務器上的標識文件生成的時候，我們認為業(yè)務系統(tǒng)已經(jīng)完成作業(yè)，需要觸發(fā)平臺任務執(zhí)行。

“華佗”平臺，實施任務診斷：

立即觸發(fā)的任務，放入DelayQueue的隊列頭部 周期調度的任務，使用Quartz 依賴觸發(fā)的任務，使用zk，各個子節(jié)點監(jiān)聽自己的父節(jié)點，所有父節(jié)點執(zhí)行完畢則可觸發(fā)執(zhí)行

實時平臺

美團點評

使用了Grafana，可以內嵌到自己的平臺。

bilibili

SQL化編程

DAG拖拽編程

一體化托管運維

實時平臺由實時傳輸和實時計算兩部分組成，平臺底層統(tǒng)一管理元數(shù)據(jù)、血緣、權限以及作業(yè)運維等。實時傳輸主要負責將數(shù)據(jù)傳入到大數(shù)據(jù)體系中。實時計算基于 BSQL 提供各種應用場景支持。

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

上層核心基于 Flink 構建運行池。再向上一層滿足多種維表場景，包括 MySQL、Redis、HBase。狀態(tài)（State）部分在 RocksDB 基礎上，還擴展了 MapDB、Redis。Flink 需要 IO 密集是很麻煩的問題，因為 Flink 的資源調度體系內有內存和 CPU，但 IO 單位未做統(tǒng)一管理。當某一個作業(yè)對 IO 有強烈的需求時，需要分配很多以 CPU 或內存為單位的資源，且未必能夠很好的滿足 IO 的擴展。所以本質上 bilibili 現(xiàn)階段是將 IO 密集的資源的 State 轉移到 Redis 上做緩解。數(shù)據(jù)經(jīng)過 BSQL 計算完成之后傳輸?shù)綄崟r數(shù)倉，如 Kafka、HBase、ES 或 MySQL、TiDB。最終到 AI 或 BI、報表以及日志中心。

場景

• AI工程方向，解決了廣告、搜索、推薦的流式Joiner和維表Joiner

• 實時計算的特征支持，支持 Player 以及 CDN 的質量監(jiān)控。包括直播、PCU、卡頓率、CDN 質量等；

• 用戶增長，即如何借助實時計算進行渠道分析、調整渠道投放效果；

• 實時 ETL，包括 Boss 實時播報、實時大屏、看板等。

網(wǎng)易

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

事件管理

對于分布式平臺的任務操作而言，當前任務啟動過程中只允許一個人操作，而不允許兩個人同時操作，這就需要以下幾個模塊來共同配合：

• Server：事件執(zhí)行的發(fā)起者，接受事件的請求，進行數(shù)據(jù)校驗，拼裝，將事件發(fā)送給 Kernel 執(zhí)行。

• Kernel：事件具體邏輯的執(zhí)行者，根據(jù)請求向集群發(fā)送指令(Shell 腳本方式)。

• Admin：事件執(zhí)行結果的確認者，根據(jù)事件類型，獲取事件的最終結果，保證結果的正確性。

以啟動場景為例：

首先，Server 會接收到來自用戶的啟動請求，之后會創(chuàng)建一個分布式鎖，Admin 會監(jiān)控這個鎖。

然后， Server 向 Kernel 提交任務，提交之后會立即返回，返回之后就會立即更新數(shù)據(jù)庫中的狀態(tài)，將狀態(tài)更新為啟動中，這樣在頁面上用戶就能夠看到任務是啟動中的狀態(tài)了。

接下來，Server 就會等待內核的 Shell 腳本的執(zhí)行結果，如果 Shell 腳本執(zhí)行成功了，就會去寫 Zookeeper，寫完 Zookeeper 之后 Admin 模塊就會馬上檢測到 Zookeeper 節(jié)點有狀態(tài)發(fā)生了修改，Admin 會立即去獲取 YARN 上的任務狀態(tài)，如果獲取到任務狀態(tài)是運行中，就將數(shù)據(jù)庫的任務狀態(tài)更新為運行中，這會在前端看到任務就已經(jīng)是運行狀態(tài)了。

最后一步是 Admin 更為完數(shù)據(jù)庫之后，會釋放掉 Zookeeper 上的鎖，其他人這時候就可以操作這個任務了。

Server、Kernel 和 Admin 這三個模塊都是不可靠的，那么如何保證其穩(wěn)定和高可用呢？Server 可以通過部署多個，水平擴展來實現(xiàn)，Kernel 則會由 Server 來進行監(jiān)聽，當發(fā)現(xiàn) Kernel 掛了，可以由 Server 重新拉起或者重新創(chuàng)建。而 Admin 的高可用則是通過熱備來實現(xiàn)的，如果主 Admin 掛掉了，可以馬上遷移到備 Admin，備 Admin 可以迅速將元數(shù)據(jù)以及任務信息全部加載進來接替工作，進而實現(xiàn)高可用。

平臺任務狀態(tài)管理

平臺的任務狀態(tài)主要由 Server 和 Admin 來控制。Server 主要控制初始狀態(tài)的執(zhí)行，Admin 則主要負責控制所有與 YARN 相關的狀態(tài)交互。

任務調試

SQL 類型的任務支持調試功能，用戶可以根據(jù)不同的 source 表和 dim 表，上傳不同的 csv 文件作為輸入數(shù)據(jù)，進行調試。調試執(zhí)行由指定的 kernel 來完成，sloth-server 負責組裝請求，調用 kernel，返回結果，搜集日志。

日志檢索

在 YARN 集群的每個節(jié)點上面部署 Filebeat，通過 Filebeat 將節(jié)點上面的任務日志寫入到 Kafka 消息隊列中，然后通過 Logstash 進行解析處理，之后寫入 ES 集群中。主要用于兩個用途，一個是通過界面 Kibana 來提供給開發(fā)和運維人員使用，另外一個就是將運行時狀態(tài)的任務日志直接在界面上展示供用戶進行搜索和查看。

監(jiān)控

在監(jiān)控方面，使用的是 influxdb metric report 組件對于指標進行監(jiān)控。時序數(shù)據(jù)庫使用的是網(wǎng)易自研的 ntsdb 時序數(shù)據(jù)庫，其能夠支持動態(tài)擴展和高可用等功能。監(jiān)控指標的使用方式有兩種：一種是通過 Grafana 的界面來查看指標；另外一種是報警模塊會從Ntsdb中獲取相關指標數(shù)據(jù)并進行監(jiān)控報警。

報警

Sloth 流計算平臺支持常見的任務失敗，數(shù)據(jù)滯留延遲，failover 報警，也支持用戶自定義規(guī)則報警，包括對于輸入 QPS、輸出 QPS，戶自定義延遲的監(jiān)控等。以輸入 QPS 為例，可以設置當連續(xù)幾個周期內 QPS 低于某一值時就觸發(fā)報警。此外，報警方式也支持多樣化的工具，比如各種網(wǎng)易內部的聊天工具、郵件、電話以及短信等，對于任務調試階段，為了避免被騷擾，可以設置任務報警抑制時間間隔。

實時數(shù)倉

目前網(wǎng)易很多產(chǎn)品已經(jīng)開始實時數(shù)倉的建設了，但仍舊處于持續(xù)完善過程中。實時數(shù)倉的建設和離線數(shù)倉大致相同，只不過實時數(shù)倉是經(jīng)過實時計算平臺進行處理的。大致的過程就是首先收集日志、埋點數(shù)據(jù)等，將其寫入到 Kafka 里面，經(jīng)過實時計算平臺進行處理，將 ODS 層中的明細數(shù)據(jù)抽取出來，在進行匯總以及維度關聯(lián)等操作，將結果寫入到 Redis，Kudu 等，再通過數(shù)據(jù)服務提供給前端的業(yè)務使用。

?

電商應用-數(shù)據(jù)分析

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

電商應用-搜索推薦

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

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

離線數(shù)倉與實時數(shù)倉

從0建設離線數(shù)倉

建設數(shù)倉

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

• ETL過程：打通你的任督二脈（離線+實時），讓數(shù)據(jù)在整個環(huán)節(jié)中流通起來

• 數(shù)據(jù)分層：一套低耦合、高內聚的層級，是十分重要的，總不想業(yè)務、數(shù)據(jù)等一變化，數(shù)倉像又投胎了一次

• 數(shù)據(jù)集成：多業(yè)務場景下，打破數(shù)據(jù)信息壁壘，避免數(shù)據(jù)歧義，統(tǒng)一數(shù)據(jù)服務

• 規(guī)范化：良好的流程化、規(guī)范化設計，易維護、高擴展

• 監(jiān)控與輔助：質量監(jiān)控、調度管理、元數(shù)據(jù)管理、信息安全管理

• 走向服務：對外api服務/自助查詢平臺/OLAP分析平臺

ETL

業(yè)務數(shù)據(jù)往往涉及多種數(shù)據(jù)源，數(shù)據(jù)存儲也常常會有多種選擇。文本數(shù)據(jù)、日志數(shù)據(jù)、RMDB、Nosql等。則要求etl工具能夠覆蓋這些業(yè)務場景。工具有datax/sqoop/kettle/informatica等等。ETL一般為最開始的部分，凌晨之后的時間點。a：避免集中式的對某個jdbc海量同步，影響業(yè)務(部分從庫可能提供查詢服務)、b：明確調度的時間，應盡可能的在某個時間段內完成(不能僅依靠調度，實現(xiàn)任務流的串行；為后期的大作業(yè)空間，占用等待的系統(tǒng)資源)

分層

Stage緩沖層 事務性數(shù)據(jù)，每日增量方式進行數(shù)據(jù)同步。需要注意數(shù)據(jù)同步時的邊界問題，避免臟數(shù)據(jù)。對于非事務性數(shù)據(jù)，一般通過快照/全量更新。不對外開放數(shù)據(jù)查詢。

ods層 一般場景下，我們認為該層數(shù)據(jù)與線上保持一致。實際處理過程中，為了處理時間維度上的數(shù)據(jù)變化，會記錄數(shù)據(jù)的變化軌跡。對于該部分數(shù)據(jù)，應該有選擇的實施，避免業(yè)務處理過程變得復雜和問題發(fā)生后難以回溯。

dim/dw層 (模型層) dim：維度層 dw：主題事實及業(yè)務寬表 在ods基礎上，設計一個寬表/模型層，通過維度建模的方式，實現(xiàn)維度數(shù)據(jù)與事實數(shù)據(jù)的分離（星型模型）。

da層（應用層） 面向不同的應用，聚合類的數(shù)據(jù)層。該層對于dim/dw層的使用，是對模型層的一個檢視維度。

代碼規(guī)范

腳本格式規(guī)范：腳本頭部注釋編碼規(guī)范、注釋規(guī)范、sql規(guī)范參考goole規(guī)范

文件/表命名規(guī)范：一個文件中，只應該有一張表，其余只能是臨時表；表名稱應與文件名相同

字段命名規(guī)范：去除多詞同義，和同詞多義的問題。尤其是在模型層（一般也叫做一致性維度）

區(qū)別

離線數(shù)倉主要基于sqoop、datax、hive等技術來構建 T+1 的離線數(shù)據(jù)，通過定時任務每天垃取增量數(shù)據(jù)導入到hive表中，然后創(chuàng)建各個業(yè)務相關的主題，對外提供T+1的數(shù)據(jù)查詢接口。實時數(shù)倉主要是基于數(shù)據(jù)采集工具，如canal等原始數(shù)據(jù)寫入到kafka這樣的數(shù)據(jù)通道中，最后一般都是寫入到類似于HBase這樣的OLAP存儲系統(tǒng)中。對外提供分鐘級別，甚至秒級別的查詢方案。

數(shù)倉類型準確性實時性穩(wěn)定性

離線數(shù)倉	準確度高	時延一般在一天	穩(wěn)定性好，方便重算
實時數(shù)倉	準確度低，數(shù)據(jù)延遲、數(shù)據(jù)亂序造成數(shù)據(jù)準確度低	分鐘級延遲	穩(wěn)定性差，需要考慮數(shù)據(jù)回溯處理

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

實時數(shù)倉的實施關鍵點：

端到端數(shù)據(jù)延遲、數(shù)據(jù)流量的監(jiān)控

故障的快速恢復能力

數(shù)據(jù)的回溯處理，系統(tǒng)支持消費指定時間段內的數(shù)據(jù)

實時數(shù)據(jù)從實時數(shù)倉中查詢，T+1數(shù)據(jù)借助離線通道修正

數(shù)據(jù)地圖、數(shù)據(jù)血緣關系的梳理

業(yè)務數(shù)據(jù)質量的實時監(jiān)控，初期可以根據(jù)規(guī)則的方式來識別質量狀況

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

原始層 明細層 匯總層 應用層

ods：原始數(shù)據(jù)層，事實數(shù)據(jù)，存儲在kafka中 dwd：數(shù)據(jù)明細層，可以做一些join等加寬處理，可以存儲在kafka和redis中 dim：維度數(shù)據(jù)，如存儲在HBase中的數(shù)據(jù) dm：MySQL -> 匯總指標模型；Greenplum -> 明細，多維分析關聯(lián)；HBase -> 匯總指標(大量并發(fā))；Redis -> 匯總、大列表TopN

數(shù)據(jù)中臺解決方案

零售行業(yè)

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

ROI：投資回報率（ROI）是指通過投資而應返回的價值，它涵蓋了企業(yè)的獲利目標。利潤和投入的經(jīng)營所必備的財產(chǎn)相關，因為管理人員必須通過投資和現(xiàn)有財產(chǎn)獲得利潤。又稱會計收益率、投資利潤率。

總結

以上是生活随笔為你收集整理的关于数据中台的深度思考与总结，20000 字不到一丢丢。。。的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。