0 導讀

大數據是企業發展的重要生產力，數據開發是數據資產內容建設的主戰場，是數據價值生產過程中的核心環節。近年來隨着快手業務的高速發展，越來越多不同角色的用戶開始進行數據開發。開發平臺面臨如何低門檻滿足產品、技術、運營、數據工程師等角色開發需求；超過 EB 級別數據量和日均百萬級的任務數，如何能夠降低運維成本；在資源有限的情況下如何保證數據準時產出等挑戰。本文主要介紹面臨如上挑戰快手大數據開發平臺的解決方案和實踐經驗。

本文是快手數據平臺在 SACC 2022 中國系統架構師大會《大數據架構應用設計與實踐》專題分享內容整理而成，主要圍繞下面三點展開介紹：

• 01 快手大數據平臺

• 02 快手大數據開發平臺建設實踐

• 03 未來規劃

1 快手大數據平臺

快手是一款全民短視頻社區，用於用戶記錄和分享生產、生活的平臺。快手的使命是幫助人們發現所需、發揮所長，持續提升每個人獨特的幸福感。一些核心數據如下：

• 流量方面，日活用戶數 3.47 億，月活用戶數 5.867 億，平均使用時長 125.2 分鐘

• 內容方面，月活用戶中內容創作者佔比超過 25%

• 粘性方面，互關用戶對數累計超過 200 億

快手大數據平臺作爲業務的重要合作伙伴。希望以領先的大數據技術，激活數據價值，賦能業務，打造快手核心競爭力 ，爲快手業務的飛速發展提供數據新能源。快手作爲頭部短視頻平臺，快手大數據的體量規模巨大，當前整個大數據集羣規模數萬臺、總數據量 EB 級別、日淨增數據量 PB 級別、日任務數數十萬級別、平臺日活躍用戶數萬級別。

2 快手大數據開發平臺建設實踐

本節主要從以下三個部分來展開介紹

• 2.1 平臺定位與發展歷程

• 2.2 平臺核心模塊與關鍵技術

• 2.3 低代碼開發實踐

2.1 平臺定位與發展歷程

從數據的流動上看大數據生命週期主要包括六個階段：

• 數據上報階段：將移動端、PC 端等產生的用戶行爲等數據；Mysql 的 binlog 等數據上報到數據採集服務中

• 數據採集階段：將上報的數據統一收集到 Kafka 消息隊列中

• 數據同步階段：將 Kafka 中的數據同步到數據倉庫 Hive 中

• 數據加工階段：離線開發基於數據倉庫 Hive 中原始數據進行離線數倉建設；實時開發基於 kafka 中的數據進行加工

• 數據分發階段：將加工好的結果數據通過數據分發同步到 OLAP、OLTP 等存儲中

• 數據服務階段：通過服務化 API 的形式對外提供數據服務，滿足看板、線上推薦 / 搜索等數據使用場景

快手一站式大數據開發平臺主要涵蓋數據同步、加工、分發三個核心環節，滿足用戶的一站式數據開發和運維體驗。

快手一站式大數據開發平臺的發展歷史可以主要劃分爲三個階段：

• 原始時代：在 2016 年，大多基於開源工具完成數據開發和運維，例如離線開發和調度基於 Airflow，數據同步基於 Sqoop 等。整體數據開發的用戶規模在百人左右，任務數在數千左右

• 1.0 時代：在 2019 年，成立統一的數據工具和產品技術團隊來負責大數據平臺工具和產品統一建設。由此進入快手大數據開發平臺的 1.0 時代，進過 3 年左右建設，到 2021 年底基本完成一站式大數據開發平臺建設，涵蓋同步、離線、實時等數據開發的核心環節，具備通用化的同步和調度基座，並且提供體系化的保障能力。整體數據開發的用戶規模增長到數千人，任務量增長到數十萬規模

• 2.0 時代：在 2022 年初，隨着業務發展，越來越多研發、產品、運營等不同角色的用戶使用數據開發。目前快手大數據開發平臺中有超過 90% 的是非數據平臺的同學，此類用戶往往對大數據的技術瞭解較少，開發門檻較高。因此快手大數據開發平臺逐步在低代碼、智能化等方面進行探索來降低用戶開發門檻

快手大數據開發平臺目前服務包括短視頻、直播、電商、廣告等內部業務。整體規模在業界屬於頭部平臺，目前離線任務量在數十萬級別、實時任務量在數萬級別、日增數據量在 PB 級別、重要鏈路任務數超過數千。

2.2 平臺整體架構

整體架構主要分爲三層：

• 引擎層：

• 統一調度引擎 Kwaiflow，主要複雜離線場景下的任務定時、依賴調度等能力

• 統一數據目錄 Kwaicat，主要負責管理 Mysql、Kafka、Redis 等異構數據源信息

• 服務層：由於數據同步、離線開發、實時開發所面臨的挑戰和技術差異較大，所以在服務能力上分爲 3 個服務獨立建設

• 數據同步主要對外提供多類型同步任務發佈、執行以及任務監控能力

• 離線開發主要對外提供代碼提示、規範驗證、測試環境隔離等開發能力以及運維管理、任務診斷、補數據等運維能力

• 實時開發主要對外提供 Flink SQL/Jar 類型的實時任務開發和運維能力

• 產品層：

• 通過把目錄樹、版本管理等通用化能力沉澱，結合應用層統一框架，以一站式形式對外提供開發運維能力，主要包括數據查詢、開發中心、運維中心、系統管理 4 大模塊

2.2 平臺核心模塊與關鍵技術

本節主要從數據同步、離線開發、實時開發以及 SLA 保障四個模塊來展開介紹

2.2.1 數據同步

典型業務場景：

• 實時同步場景，將 Kafka 中的數據實時同步到 Hive、ClickHouse 等存儲中

• 離線同步場景，將數據定時的在 Hive、Redis、ClickHouse 等異構數據存儲之間進行交換

整體架構主要分爲三層

• API 層負責提供任務創建、更新、下線和運維能力

• 存儲層負責存儲元信息，包括任務信息，分區檢查點、運行事件等信息

• 調度層

• 實時同步包括兩大模塊，協調器負責作業調度、數據源檢查、異步分區發佈等功能；執行器負責數據拉取、解析、寫入功能

• 離線同步任務調度能力通過 Kwaiflow 來實現。執行器負責數據拉取、解析、寫入功能

在快手，每天的 Kafka 消息數非常大，可以達到數十萬億量級。業務對數據的時效性要求非常高，需要分鐘級的就緒時間。面對實時同步的低延遲保障，主要有兩個問題：

1. 流量過大消費不及時。快手的業務場景，高峯期 QPS 高達幾個億，pb 非常複雜可能會有上千甚至上萬個字段。在活動數據量徒增 10 倍甚至 100 倍等場景時，無法通過擴分區等常規手段進行處理。快手通過多線程模式解決該問題，將數據同步過程中各個環節通過隊列解耦，數據讀取後放入到隊列中，由多個線程併發來進行數據解析、轉換和寫入操作。並且可以通過配置來指定線程的數量，從而更好的充分利用計算資源加速大數據量的同步效率。

2. 拖尾問題。數據同步是一個分佈式系統，整個同步任務完成時間取決於最晚完成的子任務決定，例如 100 個分區，只有 1 個沒有完成數據也無法就緒。常見的導致拖尾問題的原因有數據傾斜、調度不均勻、算力不均勻。爲了優化拖尾問題快手主要通過以下方式

• 分級限速，通過限制低優任務的調度來保障高優任務能夠得到充分的資源

• 任務重分佈，針對調度可能出現不均勻的情況，例如很多個大作業或者高優作業調度到一個節點上，資源無法保障，定時進行任務重分佈，保障大作業儘可能的分佈均勻

• 基準核，通過跑分方式來拉齊新舊程度、型號等不同的機器間性能基準，通過對照基準服務器來折算不同比例拉齊機器間的實際算力差距

經過優化目前快手的平均拖尾時間大概在 2min 左右

在快手，目前大概有幾十種存儲引擎，針對離線同步數據源種類非常多的問題，借鑑星型模型思想，通過引入同步框架層實現數據源讀和寫插件化開發，加速離線同步接入新引擎的效率。

離線同步任務執行過程，讀插件讀取數據來源存儲中的數據，通過統一數據傳輸對象完成數據的轉換處理，之後寫插件完成數據寫入到數據去向存儲中。同時爲加速大數據量任務的執行速度，基於 MR 框架實現任務的分佈式執行，首先會將數據來源存儲的底層文件進行分組，之後父任務會拆分成對應數量的子任務，每個子任務處理一個文件組的數據實現併發執行，之後將子任務的結果進行合併。

2.2.2 離線開發

• 調度層，整體依賴 Kwaiflow 來實現任務的例行調度

• 服務層，整體包括任務開發和任務運維兩大模塊

• 任務開發模塊，SQLScan 服務支持 SQL 解析、規範校驗等能力提升用戶代碼編寫效率和規範程度；SQL 渲染服務支持 SQL 模版和渲染能力，並基於模版支持環境隔離能力

• 任務運維模塊，通過增量消費和全量同步方式從基礎服務中採集任務調度信息、引擎信息等。通過實時、定時方式加工任務畫像、實例血緣關係、任務執行診斷分析等數據提供包括任務運維、全鏈路監控告警、任務智能診斷等任務運維保障能力

• 產品層，提供包括數據查詢、任務開發、任務運維、監控告警、系統管理等產品化能力

在快手離線開發主要面臨如下問題和挑戰，

1. 開發效率低、質量差，包括測試流程不規範缺少環境隔離導致線上數據污染，開發流程和規範落地難，測試驗證效率低等問題。

2. 快手業務複雜，且數據量非常大（TB 級別表），整個任務依賴鏈路長、執行環節多、涉及系統多。任務分析運維效率非常低。

針對開發效率低、質量差的問題，將離線任務的開發流程標準化爲任務編寫、配置、調試、審覈、上線 5 個步驟的模版化開發流程。

• 任務開發過程中，通過 SQLScan 服務，將 SQL 進行解析得到 AST 抽象語法樹進行語法規則驗證；通過語法樹獲取到 SQL 中包含的各種信息（包括表、字段、函數等）進行信息提示。通過規則引擎驗證 SQL 是否符合預設的編碼、依賴、權限等規範。通過抽象規範 DSL 實現平臺、部門等不同生效範圍的開發規範配置化。

• 任務測試發佈過程中，核心是環境隔離，以及測試結果的驗證。通過 SQL 渲染服務，傳入 SQL 模版 和 運行上下文信息，實現邏輯環境隔離能力，避免測試環節污染線上數據。並提供宏變量、條件 / 分支等表達拓展 SQL 表達場景。渲染後的代碼提交至任務調度進行執行，通過任務診斷服務 如果測試失敗診斷失敗原因，如果成功則進行數據結果驗證（包括行數、枚舉值、多表對比等），分析任務執行的資源消耗、以及是否存在數據傾斜等異常的健康度分析。最終生成診斷報告提供審覈依據，完成任務的一鍵發佈上線。

數據加工任務執行涉及分佈式系統多（任務調度、計算引擎等），問題排查對專業能力要求非常高，用戶自助式運維門檻高。同時隨着業務發展任務量不斷增長導致 Oncall 壓力巨大。

爲滿足用戶自主式運維且降低 Oncall 壓力。快手構建多層級全生命週期的任務診斷系統

• 數據採集：採集任務調度、計算引擎、資源調度等分佈式系統的任務執行信息

• 診斷算法：通過固定規則、圖遍歷和圖對比等算法對任務執行前、中、後的整個過程進行分析和比對，提供多層級任務診斷能力

• 診斷能力：任務執行前未啓動原因；執行中數據傾斜、執行計劃異常等異常診斷；執行後失敗原因、健康度分析等能力。並提供相應的優化建議

幫助用戶完成從發現問題、分析問題、解決問題自助式運維閉環。目前可以覆蓋數據傾斜、OOM、資源不足等常見 15 種場景，通過樣本驗證準確率超過 90%。

2.2.3 實時開發

相比離線，實時因爲其實效性的優勢，在快手越來越多的業務場景開始進行實時的開發，典型的包括活動大屏、實時監控等業務場景。

整體框架上

• API 層：提供任務發佈、管理以及 UDF、邏輯表等生產資源的管理能力

• 服務層：提供任務調試、任務發佈和監控報警的能力

• 調試能力：通過將任務改寫進行執行（跑固定時間或輸出固定條數結果）並將數據結果可視化展示給用戶

• 發佈能力：通過協調器完成應用指令下發到 Flink 引擎以及 Flink 任務的狀態同步

• 監控報警：通過採集 Flink 和 Yarn 的數據進行任務健康檢查和監控報警能力

在快手實時開發面臨的主要挑戰是，Jar 模式開發更加靈活但是門檻高效率低。SQL 模式門檻更低，但需對接 Kafka、Redis 等不同存儲， 如何降低實時開發門檻是重要的建設目標之一

爲降低實時開發對接不同異構數據源成本，將數據源抽象爲邏輯表。通過在 SQL 中使用邏輯表來描述不同數據源。用戶可以方便使用 SQL 操作對應邏輯表完成異構數據源之間的 Join 等加工操作，SQL 提交後自動解析優化後轉化成實際的 Flink SQL 完成最終的執行和計算。在快手通過調研，SQL 化開發效率相比 Jar 模式提升超過 70%。

2.2.4 SLA 保障

隨着快手業務的發展，任務量越來越大。任務間的依賴變得複雜且鏈路長，下圖是快手目前線上一個真實的任務依賴圖。目前快手有數十萬任務，以核心日報爲例，鏈路深度超過 20 層，上游任務超過 2 千個，且橫跨多個部門。再加上資源有限，想要保障數據準時產出十分困難。

爲保障數據準時產出，快手整體採用分級保障策略，通過組織 + 規範 + 工具相結合的方式保障策略落地。

• 組織：通過數據研發、數據架構、開發工具等多角色參與的 SLA 保障虛擬組織保障工作的推進和落地

• 規範：通過制定優先級管理和 SLA 故障定級規範統一拉齊 SLA 的標準

• 工具：通過基線工具完成 SLA 保障的具體實施和監控

快手任務優先級體系分爲 P0 ～ P3 四個級別，依次是公司級核心數據，部門級重要數據，部門級次要數據和不重要的數據，資源分配的優先級權重依次遞減。任務個數和對應的資源消耗也基本呈金字塔分佈。

工具層面主要是通過基線工具完成 SLA 保障的具體實施和監控。主要包括優先級管理和進度監控兩大能力。

• 優先級管理：通過優先級服務，基於血緣自動推導上游任務優先級。優先級的變化自動歸因，避免計算錯誤導致問題。最終加載到緩存中提供統一的任務畫像查詢出口完成系統間的逐級下發，最終通過爲高優任務隔離、優先提供更多的資源等手段來保障高優任務的 SLA。

• 進度監控：通過進度預測和監控服務，基於實例血緣關係，通過順推算法預測任務進度，並結合關鍵路徑算法預測鏈路餘量是否足夠，提供餘量預警、餘量變差、基線破線完善的鏈路報警策略。通過逆推算法預測任務的最晚開始和結束時間，並結合實時的實例失敗事件。提供任務啓動過晚、執行膨脹、執行失敗完善的任務報警策略。通過診斷分析，快速定位鏈路報警中的關鍵節點和影響範圍，分析任務報警的原因。進行及時的報警進處理避免及時性故障。

除了日常場景，針對春節等大型活動，在資源有限的情況下，可通過基線進行快速調整優先級保障活動數據的準時產出。目前保障任務的及時性異常基本可以提前到 90min 監控發現，可以有充足的時間來處理避免故障。

2.3 低代碼開發實踐

2.3.1 背景介紹

客戶端埋點數據可以分爲業務埋點，用於描述用戶行爲，例如訪問、曝光等數據；技術埋點，用於分析系統性能、監控等數據。客戶端研發在監控和排查問題場景下經常需要對技術埋點數據進行分析，當前在快手進行技術埋點分析面臨很多問題，主要包括

• 排期難：

• 排期長：與業務埋點需求不同，技術埋點分析需求，通常沒有專門的 DE、DA 資源，需求通常需要等排期

• 更新多：客戶端指標口徑靈活、簡單，需要經常更新，每次更新還要等 DE、DA 資源，要至少 3 ~ 5 天才能落地

• 自助難：

• 平臺多：一個技術埋點分析需求，需要進行數據同步、離線開發、實時開發、申請資源等步驟，操作路徑長

• 門檻高：客戶端同學不太擅長寫 SQL，且需要學習各個平臺的操作流程，學習成本高

2.3.2 解決思路

業務埋點分析場景，特點是強調質量、重規範；加工邏輯複雜。對工具要求是流程規範可擴展，通用化基礎能力。

技術埋點分析場景，特點是強調效率；加工邏輯簡單。對工具要求是低門檻、自閉環

快手針對不同場景特點，進行分層式的加工能力建設，整體自上而下，靈活性提高，效率降低；自下而上，靈活性降低，效率提高。具體包括

• 標準模版化任務，提供 Hive、Bash 等標準化任務，滿足任務級通用化開發場景

• 自定義鏈路化任務，基於標準模版化任務，滿足鏈接級通用化開發場景

• 場景化解決方案，針對固定開發場景，提供場景化解決方案降低開發門檻

2.3.3 技術架構

低代碼服務底層依賴埋點元數據、離線開發、實時開發等基礎能力。採用 “配置即生產” 的配置化模式，用戶通過表單化的任務配置，即可以便捷地完成數據接入、加工、分發，進行數據加工和分析。任務發佈後，自動探查數據來源並通過實時數據分流、任務分組合並、優化計算邏輯等多種方式，減少資源消耗。之後自動解析配置生成任務代碼，並完成任務編排和執行。

2.3.4 成功收益

通過上述低代碼場景落地，帶來收益如下：

1. 門檻降低：通過 SQ 配置化，弱化實時邏輯表、離線數據鏈路，用戶無需關心 SQL、邏輯表、離線鏈路，降低使用門檻。改變以往依賴 DE&DA 進行數據分析的模式，客戶端研發可以自助接入。

2. 操作路徑優化：通過場景化任務類型完成通用能力的打通，之前多個平臺的操作步驟縮短爲 1 個平臺操作

3. 降低成本：通過實時數據分流、任務分組合並、優化計算邏輯等多種方式，減少資源消耗。

通過調研用戶反饋平均人效提升 70%。

3 未來規劃

1.0 時代主要實現一站式，2.0 時代希望能夠進一步降低數據開發門檻實現數據民主化，即人人都會數據開發。具體包括

• 通過場景化，拖拽化等低代碼形式進一步降低數據開發門檻；

• 基於邏輯模型，自動生成和優化物理模型，提升數據交付效率；通過智能調度、診斷等能力提升自動化運維效率

• 基於 Hudi + Flink 的批流一體，統一離線和實時場景下開發語言降低學習成本

作者簡介：韓江，曾就職於百度。2018 年加入快手，當前主要負責快手一站式大數據開發平臺的相關的服務和產品建設，包括離線開發、實時開發、任務運維與管理等內容。近幾年深耕在數據開發領域，熟知數據生產全鏈路整體解決方案，有豐富的大數據開發和數據治理相關經驗。

快手數據中臺團隊介紹：快手核心大數據中臺團隊，爲全公司構建業界領先的智能大數據生產和分析平臺，賦能全業務線提升公司數據創新效率。目前涉及方向包括數據開發工具鏈（離線和實時數據開發平臺、數據同步、大規模工作流調度、全鏈路質檢平臺）、數據服務工具鏈（智能指標模型平臺、百萬級併發數據服務化平臺）、數據分析工具鏈（一站式數據分析平臺、專題式數據分析產品）、數據管理工具鏈（全鏈路元數據平臺、資源管理平臺、數據地圖、數據安全平臺）。也歡迎優秀同學加入我們！

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Xf9q624iYkQz8PhJNfT7sw