本次分享分為四大部分，第一部分總體介紹翼支付公司概況和業務，在數據治理過程面臨的場景、目標、挑戰；第二部分介紹數據開發與治理平臺，其中涉及到的任務開發與雙環境部署運行；第三部分介紹數據平臺的架構，分享在系統架構、調度引擎選型、數據總線、質量監控與資源隔離、計算優化等實踐經驗；第四部分與大家共同探討未來面臨的問題和可以優化的方面，展望更優的平臺目標。

一、翼支付公司與業務介紹

?天翼電子商務有限公司（以下簡稱“翼支付”）是中國電信集團有限公司的成員企業，是國資委雙百改革和發改委第四批混改“雙試點”企業，也是“雙試點”企業中唯一的金融科技公司。公司以翼支付 APP 為載體，面向 7000 萬月活用戶，提供民生繳費、消費購物、金融理財等服務內容，依托區塊鏈、云計算、大數據、人工智能等技術，賦能超 1000 萬家線下商戶門店及 170 余家線上知名電商。秉持“響應監管、服務民生、資源共享、合作多贏”的理念，聚焦“開放、安全、便捷”的核心產品力，翼支付堅持通過服務投入與產品升級，構建貼合需求的管理與業務體系，以交流融合的業務實踐，推動產業各方實現數字化轉型。

構建數據開發與治理平臺的業務場景：滿足數倉、各業務部門快速開發、離線計算、數據集成、實時數據開發、數據服務等功能，提升數據開發與治理效率。

我們的目標：構建先樞-數據開發與治理平臺，集成數據集成、離線計算、實時計算、數據服務，提供一個一體的集成化開發平臺，一站式滿足數據開發人員研發訴求。

我們所面對的挑戰：海量數據處理、高并發請求、低延遲時效性?、業務多樣性、場景復雜性。

二、數據開發與治理平臺介紹

1、任務開發流程

任務開發首先需要創建業務流程，這里的業務流程（Flow）用來管理一組任務，任務主要是數倉的離線調度，涉及到數據集成、發布以及 SparkSQL 的離線任務。在開發完任務腳本之后，再進行任務核心參數的設置，比如運行的優先級隊列、任務的相互依賴關系、運行參數，在配置完參數后，接著對任務可以測試執行，測試運行通過后可以對任務進行上線。這里任務以業務流程（Flow）為單位進行上線，上線完成后，交給管理員的任務審核，審核主要檢查任務消耗資源、并行度、開發規范等，審核通過后發布到生產環境中。發布到生產環境后，通過提交到調度引擎進行日常定時調度工作。

數據開發中包含了一些功能，在畫布中新建業務流程，拖拽相關任務節點到畫布上，進行任務節點依賴配置。根據業務分類，提供了一系列任務開發功能，包含了五種任務類型：

① 數據同步：包含像 Oracle、OceanBase、Mysql、SFTP、Hbase 的數據接入與發布；

② Spark任務：SparkSQL 的離線計算；

③ 機器學習：AI 模型任務；

④ Kylin 任務：調度 Kylin 數倉 job；

⑤ 觸發型任務：滿足外部平臺的接口觸發數據治理平臺啟動數據任務，比如外部系統進行人群圈選數據推送、其他數據加工相關工作。

SparkSQL 任務開發編輯器頁面，包含的功能有：

① 新建 SparkSQL 任務：通過拖拽建立 SparkSQL 任務節點并編寫腳本，完成編輯后，可通過語法校驗，提示 SQL 編寫報錯問題；

② 單次執行：Spark 任務提交到集群運行，測試通過后，可以進行提交，最終保存，經過任務審核后，即可部署到生產進行運行；

③ 自動任務依賴配置：系統會自動通過 SQL 語法解析到任務來源表，數倉按照統一開發規范，每一個任務有唯一的去向表，做到任務之間最細粒度統一，便于管理，來源表可以有多個，通過 SQL 解析拿到對應源表，通過任務解析，找到上下游節點，自動生成邊關系；

④ 手動添加依賴：通過手動搜索任務，添加任務到依賴上；

⑤ SparkSQL 權限解析：根據從元數據配置的用戶相關權限，進行用戶對應數據庫表的操作權限；

⑥ 血緣關系：如圖展示一個任務流程 Flow 下面的所有任務跨 Flow 血緣關系。

早期數據開發與治理平臺是單環境架構，但在平臺任務上線時，會遇到一些偶發問題，比如線上任務緊急修復上線時，SQL 腳本未經過審核，導致任務會占用過多資源，還有 SQL 相關代碼不規范等問題，因此使用了雙環境上線流程解決腳本流程規范。

所有的 Flow 在開發和生產各有一份，通過鏡像的操作，每個 Flow 和 Task 有相關的 code 標識一一對應，唯一區別是開發環境的 Flow 的 code 有 dev 前綴，比如開發環境任務 code 為 dev0001，那么生產環境的任務 code 對應為 0001，方便系統和用戶區分。

在調度層面，這樣的區分方式可以避免底層調度引擎、數倉層感受到上層的變化，比如 dev 環境的 Flow 有相關任務在運行，而其對應的生產任務也在運行，但是通過唯一的任務 code 進行區分，能使這些任務同時運行在兩個環境，生產正常調度，開發環境并行開發。

在底層設計層面，開發環境去掉前綴，即可映射到生產環境任務，同時在應用層可以統一存儲，也就是生產環境和開發環境的 Flow 和 Task，可以分別在一張 Flow 表和 Task 表中進行存儲，簡化設計，令底層數倉和調度層無感知。

版本管理為了滿足數倉開發腳本的、任務之間依賴、業務流程配置、調度更改的版本回溯的需求，針對所有 Task 和 Flow 進行版本管理，再發布到生產，生產同步到開發環境，都可選擇任意版本進行發布和回滾。

三、平臺技術架構實踐

1、整體架構概述

上圖展示了整體系統架構：上面模塊是應用層，下面是調度層。

配置管理：包含業務空間管理、成員管理和庫映射管理。空間、成員管理是對應部門人員之間的資源、數據權限隔離；庫映射管理，適用于解決來源庫與去向庫映射關系，比如數據接入時，落到哪些倉庫，可以通過配置進行管理；

數據開發：包含數據集成、離線開發、數據發布、實時作業和 FlinkSQL 指標開發。

任務管理：包含業務流程管理、任務上下線、任務重跑補數操作以及任務的血緣依賴管理。

外部服務：元數據功能，主要用于在用戶創建表后，對表詳情進行查看，以及從中獲取所有表、庫、權限；用戶中心功能，主要用于配置相關平臺用戶賬戶管理和各子平臺的權限管理；AI 服務功能，主要用于管理機器學習模型任務，通過接口調用該機器學習服務；質量作業功能，主要用于在數據任務開發完成后，核驗數據的質量。

調度層：Airflow 是調度的核心模塊，橙色部分為圍繞 Airflow 擴展開發的組件，包括任務管理，自定義 Operator（支持 SparkSQL 和數據交換相關的任務提交）。

2、調度引擎

關于調度引擎，最初對比的有 Zeus、Airflow、Azkaban。Zeus 支持分布式調度，但對 Hadoop、Spark、數據交換調度不完善，社區活躍度下降；Airflow 的 Python 擴展方便，功能完善穩定，2.X 支持多 Master 分布式調度，社區活躍；Azkaban，由 Java 開發，但調度任務功能相對簡單；最終選擇 Airflow1.10（技術選型時 2.x 版本還未穩定）作為生產離線調度引擎。

Airflow 目前僅提供一些 Web 界面上的管理操作，沒有提供相關 Rest 接口，用戶將 Airflow 的 DAG 文件放在 DAG Directory，Scheduler 進行掃描，會把對應的 DAG 的元數據存儲到 MetaData 的 DataBase，DAG 對應上層應用的業務流程 Flow，管理了一組任務。Workers 支持擴展，分布式部署多節點。在生產環境中 Airflow 主要適合使用 CalaryExector 部署，本地環境使用 LocalExector 進行任務的調度。在翼支付生產中使用 Redis 作為 Celery 任務緩存隊列，來加速任務調度性能。

Airflow 1.10 提供的 WebApi 比較少，在原生功能中使用 Git 或 Ceph 進行 DAG 文件存儲，用戶需要自己生成 DAG 文件放到集群節點，從流程來看引入對應組件，復雜性會提高，用戶側需要涉及生成對應的 DAG，上層應用生成 DAG 及業務流程管理工作。為了解決這些問題，通過擴展開發 Rest 接口功能，管理 DAG 的生成和 DAG 任務元數據，上面應用層通過 Rest 參數傳遞，幫助屏蔽底層調度引擎相關工作。DAG 文件上傳到對應 Scheduler 和 Worker 節點后，Scheduler 會以 5 分鐘為周期掃描，掃描到任務 DAG，才能完成任務的上線，之后進行 Dag 上線的回調動作，通過底層完成上線回調上層應用，避免了上層應用對上線的任務定期輪詢狀態，DagWorker 等待 DAG 上線成功進行回調完成任務的上線。

對于 DAG 文件的生成如上圖所示。

external_task：對應外部任務，task >> task2，表示任務 2 依賴任務 1，同時也依賴了外部任務 ExternalTask1。整個 Python 文件就是 Airflow 調度的 DAG，AirFlow 內部會解析其中的 DAG 及其依賴關系，生成調度的元數據。

3、數據總線

我們使用 Datax 作為數據總線的核心模塊，基于以上模板文件來執行任務，其調度是單機運行，但是 Datax 擴展性很好，并且預留了任務調度器接口，擴展 Source、Sink 以及數據轉換邏輯、過濾開發，基于 Datax 封裝了數據總線的任務管理功能。用戶在頁面輸入參數，通過 Reader、Writer 插件來渲染生成 Datax 模板文件，Datahub 模塊將文件通過 Yarn api 提交給對應的 Yarn 集群，之所以選用 Yarn 調度，是因為 Datax 是單機運行，不能做好多節點任務的調度。對比了 YarnCluster 與 K8S，暫時離線計算任務沒有完全 K8S 容器化，采用 Yarn 的統一大數據離線調度任務提交到 Yarn 集群離線計算。

4、資源隔離、計算優化

資源隔離主要是對實時離線、不同任務之間集群隔離，比如數倉之間的業務轉換、推數、任務分發不同類型作業。

數倉核心任務置于一級隊列，其他部門基于其上，劃分了子任務隊列，有核心、重要、普通，三級優先級隊列的資源隔離。

動態限流低優先級任務保障核心任務并發，當任務隊列滿了，先不提交普通任務，普通任務大多凌晨調度，新任務的限流可以保障普通任務的并發限制，避免普通任務優先調度，占用資源，核心任務需要等待計算資源。

在凌晨之前做普通任務的監控，避免普通任務調度之前被其他日常任務運行資源占滿。

Spark 任務的優化包括：小文件治理，任務優化主要是資源優化、數據傾斜、Join 優化，以及任務拆分。

5、數據質量監控

質量監控主要在五大方面：及時性、準確性、完整性、一致性以及數據有效性進行分析改進。

數據質量監控的架構如上圖所示，上面會配置相關的質量監控規則以及監控任務，質量規則分為強規則和弱規則，針對強規則進行任務熔斷，對于弱規則進行事后分析改進。規則通過 SQL 對任務的數據一致性校驗，整個規則任務以 SparkSQL 作業提交上進行計算生成規則報告，最后進行分析改進任務。

上面是作業的運行詳情，質量作業通過 SQL 模板生成任務、作業名稱，每條模板生成一條規則與記錄，針對單個表會啟動多個規則進行校驗，單表的多字段校驗，輸出規則。若針對一張表有十個規則，第一個優先規則不滿足，就會中斷校驗，直接返回流程。

6、云原生實踐

數據開發平臺流程涉及到實時、離線、數據總線、質量作業、監控、先覺 AI 模型，平臺服務基于微服務架構進行拆分到不同子服務，滿足業務快速迭代，從開發初期一直到最后上線經過多版本開發，模塊變動對其他服務影響比較大，傳統的大后端服務開發模式進行開發，模塊的耦合影響重，通過對各個服務的拆分很好的解決了這些問題。

通過公司 KCS 的 CI/CD 平臺提供服務的快速測試，迭代，部署上線。基礎設施配有統一監控告警功能及自動擴容能力，提升服務穩定性。

整個開發平臺迭代中，也伴隨著數據治理流程，工作成效比較顯著。整體計算成本降低 87%，模型特征計算時效提前 7.5 小時，看板數據查詢時效提升 40 倍。

四、未來展望

數據開發與治理平臺拆分的服務較多，與離線調度緊密相關，需要更好的性能與擴展。

可觀測性：可以及時發現服務的不穩定性問題。比如當任務越來越多，任務之間狀態會有并發沖突，帶來的性能問題需要及時解決。

計算效率：目前有比較多的 SparkSQL 作業，需要根據專家經驗和實際場景針不斷優化離線 SQL。

異地容災：現在的大數據集群部署在同一個機房，包括離線、實時計算。單機房會有異地備份訴求，需要多機房進行數據災備，以及實時計算跨集群、在線數據服務應用實現跨機房容災。

五、問答環節

Q1：數據權限是怎樣管控和實現的？

A1：數據權限分為兩塊，用戶在平臺所屬組織的權限與空間管理的那塊進行了部分綁定，用戶所屬部門的操作權限限定了平臺的數據權限；在元數據模塊有設置用戶對庫表的相關權限，UDF 的需要加解密的敏感數據也會關聯到用戶，用戶新建任務，其 SQL 解析后會涉及相關的表，與相關表的操作權限進行校驗綁定。

Q2：數據治理是怎樣做的，如何提升效果？

A2：早期的煙囪式的開發，計算成本相對高，計算性能較低，數倉針對其任務，伴隨著數倉數據治理過程的需求，平臺迭代研發滿足數倉的開發作業的流程，平臺針對調度任務的性能以及計算任務的性能優化作了相關支持，整體計算資源可以達到更好的效果。