專場16.1-字節跳動數據質量管理實踐：流批數據質量解決方案-何舒青（脫敏版）.pptx

《專場16.1-字節跳動數據質量管理實踐：流批數據質量解決方案-何舒青（脫敏版）.pptx》由會員分享，可在線閱讀，更多相關《專場16.1-字節跳動數據質量管理實踐：流批數據質量解決方案-何舒青（脫敏版）.pptx（27頁珍藏版）》請在三個皮匠報告上搜索。

1、抖音集團數據質量實踐,何舒青火山引擎DataLeap數據質量技術負責人,火山引擎DataLeap流批數據質量解決方案,1.數據質量挑戰2.解決方案3.最佳實踐4.未來演進方向,大綱,什么是數據質量(廣義),定義：數據的一組滿足固有特性(質量維度)要求的程度,六維度：完整性準確性一致性及時性規范性唯一性,數據質量在抖音集團內部(狹義),數據質量平臺針對數據及其生產鏈路的數據質量管理平臺代表功能對數據開發平臺產出的 Hive 表數據進行主鍵重復檢測，如果存在重復則進行報警典型場景,注：上圖標紅文字表示抖音集團數據質量平臺具有的功能,應用規模-監控規模：萬級別-DAU：千級別,數據任務產出Hive表

2、但是因為HMS 主從延遲,下游任務會讀到臟數據，質量監控發現異常，阻止下游任務運行。,01,內部挑戰,7,數據質量挑戰,User Story 1：某內部指標平臺，業務數據由Hive定期同步到ClickHouse；希望每次同步任務后檢查Hive與ClickHouse中的指標是否一致；如果不一致，報警并熔斷任務,User Story 2：某流量級產品商業化系統，M級日志條數/秒；希望秒級監控日志延遲、關鍵字段空值，T+1檢測日志波動率；,User Story 3：某數據開發團隊希望能夠規范化數據上線流程；數據上線報告中必須產出新舊數據對比報告。,數據質量挑戰,需求場景復雜,海量數據,有限資源,VS

3、,02,解決方案,產品功能架構,離線數據質量監控-解決批和微批監控場景流式數據質量監控-解決流式監控場景數據探查-解決數據內容探查場景數據對比-解決新舊表數據不一致場景,產品功能簡介,離線數據質量監控,實時數據質量監控,數據對比,系統架構,圖片區域,整體技術框架,Scheduler-外部調度器，觸發離線監控Backend-后端服務，服務層Executor-執行器，計算單元Monitor-狀態流轉服務，提供重復報警等功能Alert Center-外部報警服務，接收各種報警事件,離線數據檢測流程,圖片區域,離線數據監控、探查、對比，執行流程一致：1.監控觸發調度系統調用質量模塊Backend AP

4、I2.作業提交Backend以Cluster模式提交Spark作業至Yarn3.結果回傳作業結束(成功、失敗)，Driver將結果sink 至Backend4.消息觸發Backend 根據結果觸發相應動作(eg:報警、消息提示),優劣,劣勢：1.非CPU密集型查詢較重不需要啟動Spark的作業仍會啟動一個Spark作業，如ES SQL 查詢2.依賴Yarn做調度穩定性不夠高,優勢：1.調度系統低耦合低相比于其他直接依賴于調度系統執行監控2.事件觸發，高效；Backend水平擴展能力強事務需要處理好3.沒有Quota 限制把Quota 問題轉化為用戶資源問題,流式監控執行,圖片區域,流式監控流程

5、：1.根據規則定義，創建Flink作業2.根據報警條件，注冊Bosun報警事件3.Flink作業消費Kafka數據，計算監控指標寫Metrics4.Bosun基于Metrics的時序數據，定時檢測，觸發報警5.Backend接收報警回調，處理報警發送邏輯,Executor 實現,圖片區域,注：Executor 基于Apache Griffin 項目中的 measure 改造,Executor(Griffin Measure)是一個Spark Application功能包括：-適配Data Source-數據轉化為DataFrame-規則轉化為sql操作-計算結果選型原因:-擴展性強，可適配hi

6、ve/mysql等不同data source-計算性能強-支持多種監控類型,改造：-改造Source、Sink 使其能夠通過Http 訪問遠程API-部分功能增強、修改，eg：支持正則表達式-流式監控從Spark Engine切換為Flink Engine，優化整體流式監控方案,Monitor 實現,功能：-提供重復報警、消息失敗重試功能-提供executor 心跳異常檢測功能架構要點：有狀態服務，主節點對外提供服務；主備保證HA接收Backend事件：監控失敗、報警內存定時隊列，事件性觸發機制,03,最佳實踐,表行數信息 優先HMS獲取,主要流程：1.引擎記錄表行數到相應分區信息中2.優先從

7、HMS獲取行數，失敗則fallback到提交Spark作業效果：HMS獲取行數占比約 90%HMS行數監控平均運行時長 5s.,注：這個功能需要推動底層服務配合支持，比如spark 需要把保存在本地metric 里面的信息寫入到Hive MetaStore 中，其他數據傳輸系統也需要支持。,離線監控優化,1.Griffin Measure 模塊功能裁剪&優化：裁剪掉部分異常數據收集功能 優化非必要的join 流程2.執行參數優化 根據不同的監控類型，添加不同的參數(shuffle to hdfs etc.)根據監控特性，默認參數優化（上調vcore etc.）效果：各類監控平均運行時長縮短 1

8、0%,21,引入OLAP 加速執行,在數據探查場景：-引入presto-快速fail機制，大數據量、計算復雜的探查任務fallback到提交Spark作業效果：-執行中位數從 7 min 下降至 38s，-presto 成功率 90%注：目前在嘗試利用presto加速數據質量監控,流式監控的資源使用優化,1.Kafka 數據抽樣Flink Kafka Connector 支持抽樣，即直接操作kafka topic 的offset 來達到抽樣的目的。比如，我們按照1%的比例進行抽樣，原來上W個partition的Topic，我們只需要*個機器就可以支撐。,2.單Topic 多Rule 優化和離線

9、監控相比，流式作業相對而言需要占用更多高優資源利用監控不是CPU 密集型作業的特性，復用讀取部分，單slot 中執行多個rule,04,未來演進方向,24,底層引擎統一，流批一體,當前引擎：批式：Spark流式：FlinkOLAP:Presto 未來探索：流&批：FlinkOLAP:Flink Or Presto？,智能、便捷、優化,1.智能基于智能算法實現主動式數據質量問題發現根據數據等級自動推薦質量規則2.便捷數據據探查&數據對比應用與數據開發流程質量報警的自動歸因3.優化-單一Job，同時運行多個監控-監控和數據探查結合,26,歡迎加入,歡迎加入 火山引擎DataLeap1.大數據研發治理套件：DataLeap2.開源數據集成引擎：BitSail 還有更多.,