資料中臺的思考與總結
資料中臺
資料匯聚
資料匯聚是資料中臺必須提供的核心工具，把各種異構網路、異構資料來源的資料方便地採集到資料中臺中進行集中儲存，為後續的加工建模做準備。資料匯聚方式一般有資料庫同步、埋點、網路爬蟲、訊息佇列等；從匯聚的時效性來分，有離線批量匯聚和實時採集。
資料採集工具:
- Canal
- DataX
- Sqoop
資料開發
資料開發模組主要面向開發人員、分析人員，提供離線、實時、演算法開發工具。
離線開發
- 作業排程
- 依賴排程：所有父作業執行完成後，當前作業才能開始執行。圖64中的作業B，只有父作業A和C執行完成後，才能開始被排程。
- 時間排程：可指定作業的排程開始時間。圖64中的作業B，只有到達05：00後才能開始被排程。
- 基線控制 在大資料離線作業中，作業執行時間較長，經常遇到急著用資料發現資料還沒出來的情況。採用演算法對作業完成時間進行智慧預測，根據預測，當作業無法正常產出且動態調整無法完成時，排程中心會及時通過監控告警通知運維值班人員提前介入處理，為大資料作業執行留出充裕的時間。
- 異構儲存 企業內部的儲存計算引擎呈多元化趨勢。離線開發中心針對每種型別的計算引擎會開發不同的元件，例如，針對Oracle開發Oracle外掛，針對Hadoop體系分別開發出Hive、Spark、MR等外掛。使用者在介面新建各種作業型別，在執行時自動根據作業的型別尋找相應的外掛來執行作業。
- 程式碼校驗 對於常見的SQL任務型別，SQL檢查器會做好嚴格的管控，做到事前發現問題。
- 多環境級聯 通過環境級聯的方式靈活支援企業的各類環境需求，方便對資源、許可權進行控制和隔離。每個環境有獨立的Hive資料庫、Yarn排程佇列，甚至不同的Hadoop叢集。常見的環境如下：
- 單一環境：只有一個生產環境，內部管理簡單。
- 經典環境：開發環境中存放脫敏資料、供開發測試使用，上生產環境走釋出流程，用於真實資料生產。 任務、資源和函式必須在開發環境下進行新建、修改或刪除，再經過提交、建立釋出包、同意釋出三個操作後，才能同步到生產環境。
- 複雜環境：企業有外部人員和內部人員，會給外部人員提供一個脫敏管控的環境，外部人員開發完的資料模型經過測試後釋出到內部開發環境。
- 推薦依賴 隨著業務的不斷深入，資料開發人員需要開發的作業會不斷累加。既能保證準確找到需要定位的上游作業，又能保證不會形成環路。
獲取推薦依賴的核心原理在於上下游作業輸入和輸出的表級血緣依賴圖； 通過血緣分析當前作業的輸入和輸出，找到合適的上游作業； 對合適的作業進行環路檢測，剔除存在閉環的作業； 返回合適的節點列表。
- 資料許可權 企業內部計算引擎多樣化，資料許可權管理面臨如下問題：
- 部分引擎擁有獨立的許可權管理系統（例如Oracle、HANA、LibrA），導致許可權申請需要到每一種引擎上單獨操作，讓使用變得複雜。
- 同一種計算引擎，不同廠商的許可權系統有多種，例如Hadoop自身無資料許可權系統，由不同廠商各自去實現，目前主要有兩種策略：
- RBAC（Role-Based Access Control）：如Cloudera用的是Sentry，華為的FI也是類似的機制
- PBAC（Policy-Based Access Control）：如Hortonworks用的Ranger * 資料許可權是由大資料叢集或資料庫運維人員管理的，開發人員無法直接操作或者接觸，所有的許可權申請都需要運維人員開通，造成運維人員負擔過重。在實際開發中，一般需要運維人員把整個庫的許可權授權給某個開發負責人，然後庫裡面的表、欄位、函式的許可權管理由開發負責人負責就行。 資料許可權管理中心提供介面化操作，資料申請方直接在頁面上進行各種許可權的申請，資料管理方在介面上稽核許可權，執行同意或拒絕操作。同時，所有許可權的申請、審批都會有記錄，便於進行許可權審計。在統一資料許可權服務中，會對接底層的各種許可權管理系統，例如Sentry、Ranger、Oracle，同時對資料許可權管理中心提供服務，執行許可權的申請、授權、撤銷等操作。
實時開發
- 後設資料管理
- SQL驅動
- 元件化開發
智慧運維
任務的管理、程式碼釋出、運維、監控、告警等一系列整合工具，方便使用，提升效率。重跑、重跑下游、補資料。
資料體系
有了資料匯聚、資料開發模組，中臺已經具備傳統資料倉儲（後面簡稱：數倉）平臺的基本能力，可以做資料的匯聚以及各種資料開發，就可以建立企業的資料體系。之前說資料體系是中臺的血肉，開發、管理、使用的都是資料。
中臺資料體系應具備以下特徵：
- 覆蓋全域資料：資料集中建設、覆蓋所有業務過程資料，業務中臺在資料體系中總能找到需要的資料。
- 結構層次清晰：縱向的資料分層、橫向主題域、業務過程劃分，讓整個層次結構清晰易理解。
- 資料準確一致：定義一致性指標，統一命名、統一業務含義、統一計算口徑，並有專業團隊負責建模，保證資料的準確一致。
- 效能提升：統一的規劃設計，選用合理的資料模型，清晰的定義並統一規範，並且考慮使用場景，使整體效能更好。
- 降低成本：資料體系的建設使得資料能被業務共享，這避免了大量煙囪式的重複建設，節約了計算、儲存和人力成本。
- 方便易用：易用的總體原則是越往後越能方便地直接使用資料，把一些複雜的處理儘可能前置，必要時做適當的冗餘處理。
不同行業的資料體系建設：
- 地產行業
- 證券行業
- 零售行業
- 製造行業
- 傳媒行業
- 檢務行業
- 貼源資料層ODS
對各業務系統資料進行採集、匯聚，儘可能保留原始業務流程資料，與業務系統基本保持一致，僅做簡單整合、非結構化資料結構化處理或者增加標識資料日期描述資訊，不做深度清洗加工。 表名：ODS_系統簡稱_業務系統表名 欄位名：與業務系統欄位名保持一致，欄位型別也儘可能保持一致 對於資料量比較大的業務表，採用增量同步的方式，則要同時建立增量表和全量表，增量表命名加字尾：ODS_系統簡稱_業務系統表名_delta。 對於日誌、檔案等半結構資料，不僅要儲存原始資料，還要儲存結構化之後的資料。
使用DataX同步資料步驟： 1）確定業務系統源表與貼源資料層目標表 2）配置資料欄位對映關係，目標表可能會增加採集日期、分割槽、原系統標識等必要資訊，業務相關內容不做轉換 3）如果是增量同步或著有條件的同步部分資料，則配置資料同步條件 4）清理目標表對應資料 5）啟動同步任務，往貼源資料層目標表匯入資料 6）驗證任務是否可以正確執行，並且採集到準確資料 7）釋出採集任務，加入生產排程，並配置相關限速、容錯、質量監控、告警機制
- 統一數倉層DW
- 明細資料層DWD
- 彙總資料層DWS 與傳統資料倉儲功能基本一致，對全歷史業務過程資料進行建模儲存。對來源於業務系統的資料進行重新組織。業務系統是按照業務流程方便操作的方式來組織資料的，而統一數倉層從業務易理解的視角來重新組織，定義一致的指標、維度，各業務板塊、業務域按照統一規範獨立建設，從而形成統一規範的標準業務資料體系。
- 標籤資料層TDM
物件導向建模，對跨業務板塊、跨資料域的特定物件資料進行整合，通過IDMapping把各個業務板塊、各個業務過程中的同一物件的資料打通，形成物件的全域標籤體系，方便深度分析、挖掘、應用。
- 應用資料層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：明確排程的時間，應儘可能的在某個時間段內完成(不能僅依靠排程，實現任務流的序列；為後期的大作業空間，佔用等待的系統資源)
分層
-
Stage緩衝層 事務性資料，每日增量方式進行資料同步。需要注意資料同步時的邊界問題，避免髒資料。 對於非事務性資料，一般通過快照/全量更新。不對外開放資料查詢。
-
ods層 一般場景下，我們認為該層資料與線上保持一致。實際處理過程中，為了處理時間維度上的資料變化，會記錄資料的變化軌跡。對於該部分資料，應該有選擇的實施，避免業務處理過程變得複雜和問題發生後難以回溯。
-
dim/dw層 (模型層) dim：維度層 dw：主題事實及業務寬表 在ods基礎上，設計一個寬表/模型層，通過維度建模的方式，實現維度資料與事實資料的分離（星型模型）。
-
da層（應用層） 面向不同的應用，聚合類的資料層。該層對於dim/dw層的使用，是對模型層的一個檢視維度。
程式碼規範
- 指令碼格式規範：指令碼頭部註釋編碼規範、註釋規範、sql規範參考goole規範
- 檔案/表命名規範：一個檔案中，只應該有一張表，其餘只能是臨時表；表名稱應與檔名相同
- 欄位命名規範：去除多詞同義，和同詞多義的問題。尤其是在模型層（一般也叫做一致性維度）
區別
離線數倉主要基於sqoop、datax、hive等技術來構建 T+1 的離線資料，通過定時任務每天垃取增量資料匯入到hive表中，然後建立各個業務相關的主題，對外提供T+1的資料查詢介面。 實時數倉主要是基於資料採集工具，如canal等原始資料寫入到kafka這樣的資料通道中，最後一般都是寫入到類似於HBase這樣的OLAP儲存系統中。對外提供分鐘級別，甚至秒級別的查詢方案。
| 數倉型別 | 準確性 | 實時性 | 穩定性 |
|---|---|---|---|
| 離線數倉 | 準確度高 | 時延一般在一天 | 穩定性好，方便重算 |
| 實時數倉 | 準確度低，資料延遲、資料亂序造成資料準確度低 | 分鐘級延遲 | 穩定性差，需要考慮資料回溯處理 |
資料倉儲的建設主要包括資料的採集、資料的處理、資料歸檔、資料應用四個方面。 當前主要的應用場景包括報表展示、即席查詢、BI展示、資料分析、資料探勘、模型訓練等方面。 資料倉儲的建設是面向主題的、整合性的、不可更新的、時許變化的。
實時數倉的實施關鍵點：
- 端到端資料延遲、資料流量的監控
- 故障的快速恢復能力
- 資料的回溯處理，系統支援消費指定時間段內的資料
- 實時資料從實時數倉中查詢，T+1資料藉助離線通道修正
- 資料地圖、資料血緣關係的梳理
- 業務資料質量的實時監控，初期可以根據規則的方式來識別質量狀況
其實，你需要的不是實時數倉，需要的是一款合適且強大的OLAP資料庫。 在實時數倉的建設中，OLAP資料庫的選型直接制約實時數倉的可用性和功能性。
原始層
明細層
彙總層
應用層
- ods：原始資料層，事實資料，儲存在kafka中
- dwd：資料明細層，可以做一些join等加寬處理，可以儲存在kafka和redis中
- dim：維度資料，如儲存在HBase中的資料
- dm：MySQL -> 彙總指標模型；Greenplum -> 明細，多維分析關聯；HBase -> 彙總指標(大量併發)；Redis -> 彙總、大列表TopN
資料中臺解決方案
零售行業
RPS (Revenue Per Search): 每搜尋產生的收入，衡量搜尋結果變現能力指標
ROI： 投資回報率（ROI）是指通過投資而應返回的價值，它涵蓋了企業的獲利目標。利潤和投入的經營所必備的財產相關，因為管理人員必須通過投資和現有財產獲得利潤。又稱會計收益率、投資利潤率。