過去的幾年里，隨著大數據的進一步發展，現代數據棧的生態愈加豐富完善，而數據湖在這期間幾乎已成為現代數據棧的必備品，它的出現大大簡化了用戶管理數據的難度，讓用戶更加關心于數據本身，而非組件本身。T3 出行在數據湖基礎上，對現代數據棧進行了一些探索，并初步打造了特征平臺。在本文中，我將給大家分享下 T3 出行結合公司業務場景，在現代技術棧這方面，做的一些探索于與實踐，以及在此基礎上打造的特征平臺。

一、什么是 Modern Data Stack

現代數據棧是最近幾年出現的一個新名詞，其本質是一系列構建在數據倉庫周圍的工具。其主要出發點是給公司內部，如算法、數據處理、數據分析等團隊提供一個更簡單易用的產品，提升公司整體的運營決策效率。

1、Modern Data Stack 的特點

從字面上分析，Modern 譯為現代化，寓意簡單通用，Data Stack 就是圍繞數據而展開的各種技術組件的組合?，F在數據處理的領域有著豐富且復雜的業務場景，我們需要從這些場景里面，通過大數據技術把有價值的數據給提取出來。而界內并沒有一個技術或者產品能夠把數據處理的各個環節都做好，因此這就涉及到大數據技術組件組合的問題，如何把現代的這些大數據技術組件更好地組合起來，就是現代數據棧要解決的命題。

2、為什么要有 Modern Data Stack

為什么會有現代數據棧概念，這其實是技術發展的一個演變過程。十幾年前，那時都是以傳統數據庫為主，都是從 Oracle、IBM 這類數據庫廠商中做選擇，選擇不多，定好數據庫后，公司的技術架構也只能根據廠商的意見來打造。

而現在隨著企業數據規模、應用數量增長，以及應用技術組件豐富完善，云計算的產生和推廣，進一步推動了數據庫領域的發展。這使得現在數據軟件價格和使用門檻大幅降低，企業有了更多的選擇，可以根據具體的數據業務場景，來選擇最合適的技術組件，從而圍繞企業自身業務需求，量身打造一個足夠低廉、性能足夠優秀的架構。

當然現代數據棧的目的，依舊是從數據中提煉出有價值信息，為業務提供決策支撐，推動公司的業務發展。

3、Modern Data Stack 組成

現代數據棧主要分為數據統一存儲、數據處理、數據分析、數據智能這四個部分，每個組成部分解決的問題如下所示：

統一存儲：解決數據孤島、降低數據環境的復雜度。

數據處理：原始數據加工、轉換、ETL、任務調度。

數據分析：提取有用信息和形成商業結論。

數據智能：大規模機器學習和深度學習等技術對數據價值信息提取。

二、T3 出行的業務場景

T3 出行是一家基于車聯網驅動的智慧出行平臺，擁有海量且豐富的數據源。因為車聯網數據多樣性，隨著業務發展，數據的增多，最初的傳統數倉架構，遇到了諸多挑戰，亟需新的架構迭代升級，更好的支撐公司業務發展。

通過歸納總結，T3 原來數倉架構面臨挑戰的業務場景分為三個點：支持長尾、非結構化的數據和小文件、算法業務場景。

1、支付長尾

T3 是一個出行企業，所以有很多的訂單場景，而出行訂單場景，在傳統數倉里面臨一個支付長尾的問題，業務層面訂單支付周期可能長達數月，會存在長達數月的超長業務閉環窗口，同時也帶來了冷熱數據的更新問題。在長尾訂單支付后，很久之前的數據需要做一些更新，在傳統數倉里面去做很麻煩，要做級聯更新，鏈路長，成本高。

2、非結構化數據和大量小文件

T3  出行的數據除了結構化數據之外，還有很多非結構化數據，比如說出行產生音視頻數據，還有車聯網相關的信號數據。同時，之前的數倉架構，因為數據更新太多，產生了很多小文件。另外 T3 的業務還有一些低延遲的場景，會實時產生結構化的小文件，比如車聯網的雷達點云數據和日志打點數據。

3、算法業務場景

T3 的算法業務場景，主要分為三塊：

營銷業務：需要用戶畫像、廣告推廣。

風控業務：主要是保證出行安全，以及一些判責處理。

運力調度：車輛運力管理，智能調度。

三、T3 出行的 MDS 初步打造

圍繞 T3 出行業務場景的特性，我們進行了現代技術棧的一個初步的打造，主要是圍繞 Apache Hudi 和 Apache Kyuubi 展開。

1、Apache Hudi 體系

?為了解決前面說的支付長尾和大量小文件的問題，我們引入了 Apache Hudi 這個組件。Hudi 是一個流式湖倉一體的平臺，支持海量數據塊的更新，它保證在時間軸上執行操作都是原子性的，這樣保證了事物，適合 T3 訂單類數據存儲。

同時 Hudi 為了更好的支撐數據分析場景，支持了兩種表模式，寫時復制（Copy on Write，COW）表和讀時合并（Merge On Read，MOR）表。

以及還支持了三種查詢模式，包括快照查詢、增量查詢還有讀優化查詢。Hudi 通過上述特性支持，讓業務根據不同的場景，選擇最合適的表模式和查詢方式，更好地支撐了業務分析。

另外 Hudi 支持對象存儲，如阿里云的 OSS、AWS S3、華為的 OBS。T3 出行在將部分對象數據從 HDFS 遷移到 OBS 后，一定程度上降低了存儲的成本。?

2、Apache Kyuubi 體系

為了更好地支撐 T3 內部數據分析的場景，我們引入了 Apache Kyuubi 作為統一的網關。

Kyuubi 是一個 Thrift JDBC/ODBC 服務，由網易數帆發起，具備多租戶和分布式等特性，為大數據查詢引擎如 Spark、Flink 等提供 SQL 等查詢服務。它最早是對 Spark Thrift Server 做加強，彌補了 Spark Thrift Server 多租戶授權、高可用性特性的缺失，并在此基礎上做了相關的拓展。后續 Kyuubi 開始演化精進，向統一網關的場景發展，以滿足企業內諸如 ETL、BI 報表等多種大數據場景的應用。

T3 出行對于 Kyuubi 的使用除了在 ETL 和 OLAP 場景以外，還做了以下應用與拓展：

• 在開源的版本基礎上做了些拓展功能，添加了監控管理頁面。
• 最新的開源版本 Kyuubi 除去支持 Spark，還支持了 Doris 、Trino、Presto 以及  Flink，公司會更新使用版本，引入新特性。
• 監控和配置進行持久化存儲，引擎配置可以在線更新。
• 在 Kyuubi 引擎管理的基礎上，加強一些更細粒度的管理，如用戶的流量管控、查詢頻次等，希望基于這個統一網關做更多的拓展。

3、T3 數據分析處理流程

基于 Hudi 和 Kyuubi，T3 的數據分析和處理流程的設計，也變得簡單清晰，下面逐一道來。

（1）數據分析流程

對于數據分析場景，主要是使用 HUE Web UI 和 BI 分析工具（帆軟），二者連接Kyuubi 這個統一網關。

HUE 一般是數據開發時候使用，通過 Kyuubi 連接 Spark 引擎，去執行 Spark SQL ，然后加工 Hudi 的數據，獲得計算結果，從而完成整個開發。

BI 分析工具也是通過 Kyuubi，連接 Presto Engine 引擎后，查詢加工好的 ODS 層數據后，通過 BI 報表進行可視化的展示。

整體的流程大致如下圖所示：

T3 通過接入 Kyuubi 網關，收斂了數據分析入口，從而可以更好地管控用戶使用。當然這也簡化了用戶的使用成本，畢竟用戶不需要關心 Kyuubi 后面的引擎，不需要對接各種引擎的驅動，只需要對接 Kyuubi 即可，做到了開箱即用。

（2）數據處理流程

關于數據處理的場景，T3 在通過 Dolphin schedule 對處理任務進行調度，它通過 Kyuubi，對接 Spark 引擎，Spark 再對 Hudi 的數據進行加工處理。通過 Dolphin schedule 多租戶管理，再結合 Kyuubi 的租戶管理能力，T3 實現了 Spark 資源隔離，讓不同的租戶，即不同業務部門，連接不同的資源池，使用不同的資源配置。目前 T3 的任務日調度量大概是5萬多，已經平穩運行了大半年，可以說這個架構還是很穩定的。

4、T3 整體的數據湖架構

基于 Hudi 和 Kyuubi 的一個基座，T3 搭建的數據湖架構，整體的形態如下圖所示：

基于上圖架構設計，逐個簡單介紹下：

一站式平臺的入口：這個主要是對接不同的平臺，比如帆軟、特征平臺、算法平臺等。

計算中間件：主要是用到 Kyuubi ，它作為統一網關，來支撐各類分析場景。

任務調度：主要通過 Dolphin Scheduler 來進行任務調度。

資源編排層面：目前是在 Yarn 上進行，后面會逐步遷移到 K8S 上進行資源編排，目前算法平臺的一些開發場景已經遷移，后面所有的 Spark 和 Flink Job 也會陸續遷移。

數據存儲管理：表的元數據存儲主要還是使用 Hive Metastore；業務結構化數據，則是用 Hudi 的表來管理，數據則是存儲在華為云的 OBS 上；非結構化數據，也是存在 OBS。相比于早期的 HDFS 存儲，大大降低了存儲成本。

數據接入層：主要是通過 Kafka 和 Canal 的訂閱數據，然后入湖，持久化到 OBS。

四、特征平臺 On MDS

1、模型開發流程

基于數據湖的架構，T3 打造了一個特征平臺，在描述特征平臺之前，先介紹模型開發的一個大致流程，大致如下圖所示：

模型研發流程始于數據采集，大數據工程師利用采集的原始數據，通過 Spark 離線計算，加工生成算法需要的特征數據集，從而給到算法工程師用來訓練模型，調參，等模型穩定后，就可以把訓練好的模型部署上線，交付給到業務使用。業務方則通過傳入特征數據給到模型，讓模型實現在線推理計算，產生業務效果。

2、特征平臺作用

從模型研發流程圖中，可以看到線上線下都會用到模型的特征數據，這中間的特征加工過程，特征元信息，需要一個平臺來統一管理。

而且有一些特征加工，比如說一些 ETL 的任務，可能是需要寫 Spark 任務，這樣對算法工程師不太友好，需要一些迭代，以及跨團隊的溝通，效率很低，這也需要系統化的解決。

另外正常的特征計算一般是輕量級的任務，如果沒有做好特征統一管理，可能就下推到了在線模型服務，里面會再做一些前置處理，以及特征轉化。這樣預處理被留在模型服務里面，甚至模型內部去進行，這增大模型在線推理的一個時延，這個代價還是比較大的。

基于以上幾點原因，T3 需要打造特征平臺，將人和人之間的溝通，變成人和平臺之間的交互。將特征控制權交還給算法工程師，提高特征開發迭代的一個效率。通過特征管理，將權重更高的特征工程，放在那個特征加工的前面，盡可能地減少在線模型的時延，提高在線推理的一個效率。

3、特征平臺的整體流程

整體來說，特征平臺在算法加工的流程中，扮演著數據集的提取、加工和管理的角色，它將加工好的樣本提供給模型開發和使用。訓練好的模型部署在模型服務后，模型服務也會直接去特征平臺去拿加工好的特征數據，然后統一提供給業務服務。

4、特征平臺技術棧選型

在特征平臺的流程中，涉及到數據集的管理，因此在技術棧選項上，需要一個數據集定義指標工具，作為特征數據的 Datasource。以及也需要一個特征存儲管理組件，保證能夠跟數據湖架構很好的組合對接。

（1）Metricflow

我們經過調研，選擇了 Metricflow 這個開源組件，這是一個在國外比較流行的指標管理組件。它可以將簡單的度量定義轉化為一個可用的 SQL，并針對選擇的 SQL 引擎去執行。另外它可以連接數據倉庫，構建一個度量邏輯。同時也提供 Python SDK ，可以讓用戶在 Python 環境下進行分析，比如在 Jupyter 上直接運行分析指標。同時它能物化一些指標，根據定義好的指標和維度，能夠將一些非規范化的數據集進行一個快速存儲，背后實現是基于 Yarn 語義，按照它的一個規范定義一個數據源還有指標，然后Metricsflow 內部會解析語義文件，按照各個步驟生成 Dig，Dig 的表述會傳遞給選擇的 SQL 優化器，然后生成對接的數據源所需要的 SQL 語義，并進行執行。

當然 Metricflow 主要支持是在連接數倉數據庫這塊，對一些非結構化數據存儲，它不太能很好的支撐，所以基于它的語義層，T3 做了一些拓展。

（2）數據集語義

?下圖是一個數據集語義 Demo，可以在該語義中設置數據集的名稱，Owner、所屬項目、數據集的描述。除此之外，它可以定義數據集的查詢邏輯。比如說查詢的主表，Demo 中主表是 test 表，它關聯到某個 DIM 層的一個維度表，然后進行了 left join 操作。通過將查詢配置化管理，它會根據所選擇的數據源 Hive 或 Kyuubi，轉化成對應的 SQL 然后進行執行。

參考 Metricflow 對指標語義的定義，T3 對它做了一些拓展，以支撐非結構化數據集定義。比如一些非結構化的 OBS 數據，通過定義其 OBS 文件路徑，就可以查詢獲取。另外拓展后還支持自定義數據屬性，比如針對視頻文件?，在 CV 的訓練場景，算法需要的一些像素級別、地理位置、時間場景等屬性，這些也都可以在語義中定義，后續使用時可以直接獲取。

（3）Feast-特征存儲管理

?上面提到了特征存儲管理模塊，T3 選擇了 Feast。Feast 是一個用于機器學習的開源特征存儲組件，對管理現有的技術架構，以產生用于模型訓練和在線推理的分析數據提供了便捷。Feast 是 Tecton（一個美國機器學習數據平臺）提供的一個開源版本特征管理模塊，它支持離線特征存儲，也支持在線特征管理，保證了特征的一致性。

Feast 通過統一的 Feast Server，對外提供了 Restful Api，供 Python SDK 或 J?ava SDK 調用，提供了統一的輸出。

總的來說，Feast 通過提供從特征檢索中抽象出特征存儲的單一訪問層，將算法開發和數據基礎設施進行了分離，并提供了離線特征可以發布為實時特征的能力，讓離線加工好的特征可以直接提供給在線模型推理使用，保證了特征加工的一致性和時效性。同時針對特征數據字段較多，數字化的特性，存儲會進行定制化的序列化壓縮，在有限影響性能基礎上大大節省了存儲空間。

（4）元數據管理

特征平臺在 Metricflow 和 Feast 的基礎上，進行了封裝和二次開發，實現了元數據的管理。

對應像視頻數據，車輛網數據，這些非結構化的數據，T3 參考了 Metricflow 的語義層，對非結構化數據存儲的一些目錄，以及自定義屬性做了拓展，把它們都作為一個數據集來進行管理。

而對于業務結構化數據，則是存儲在 Hudi 或者 Hive 的表里面。表的 Meta 信息則是使用 Hive Metastore 來這些存儲管理。

通過上述操作，特征平臺完成了對元數據、數據集的定義和管理。

5、特征平臺內部架構

特征平臺的內部架構，主要分為兩塊：離線數據的處理架構和實時數據處理架構。

離線數據處理架構，以數據源為出點，根據數據源的定義，通過 Spark 進行數據集的清洗提取，再進行特征的視圖封裝，然后進行特征加工，加工好的特征視圖數據會存儲到Feast，進行特征的統一管理。最后則是通過一個 UI 界面的方式，來提供不同團隊使用。

另外加工好的特征，用戶可以在特征平臺上，看到它的數據集來源，特征加工的邏輯。特征平臺會對這些特征進行一些權限管理，讓特征盡可能復用，這大大提高了特征使用的效率。

實時數據處理架構，則是通過 Kafka 消息隊列，根據消息里面封裝好的特征視圖的，進行邏輯加工后，再通過 feature transform，最后進行一個存儲。

所有經過處理的特征數據都會以 Data frame 的方式，提供給模型訓練，比如在算法平臺的 Jupyter 上面進行開發和模型訓練，或者是提供給模型服務，通過 feature vector 特征向量的方式，傳遞給在線模型服務。整個過程都是通過特征平臺這個統一的出口，做了統一的管理。這讓整個特征加工模型訓練，形成一個閉環。

6、特征平臺 On MDS 架構

?總的來說，特征平臺的整體架構，是使用數據湖，以及一些在線數據源，通過大數據清洗提取數據集，再通過數據集進行離線或者實時的特征工程處理，加工成為特征數據，并對特征數據進行統一管理，統一對外部業務算法團隊使用。

而特征任務計算流程，以及其血緣關系，都會通過任務調度 Dolphin schedule 進行統一管理，它負責和任務流的源數據，以及上下游任務進行打通，并且能夠看到每個特征加工的任務情況。

特征平臺則會對特征的元數據，比如特征名字、特征來源、特征的 schema 等進行管理，以及對整個鏈路，也是做了完善的監控，做到了任務全流程的數據源管理。另外特征平臺離線和實時計算產出的特征數據，會提供到模型服務使用。

當然特征計算是需要用戶自行開發一個調度任務，并進行維護，特征平臺會提供一個 SDK 給到算法工程師，他們可以通過 Python SDK 和特征平臺進行數據交互。

基于以上設計，就形成了當前 T3 出行現代技術棧的整體架構。?

總結

回顧主題，現代數據棧的目標是大大簡化用戶管理數據的難度，讓用戶更加關心于數據本身，而非組件本身。T3 出行是在數據湖基礎上，所打造的特征平臺。希望能和大家進一步交流，通過現代數據棧更好的推動業務，同時降低開發和維護成本。也希望現代數據棧能在國內有更好的發展。

六、問答環節

Q1：特征計算是在什么樣的團隊，是業務團隊還是數據團隊？

A1：特征工程是算法團隊做的，而打造特征平臺主要是為算法團隊提供輔助，比如說數據提取，原始數據加工。如果沒有特征平臺，那會給公司增加溝通成本，增加一些跨部門溝通，比如說算法同學找數倉團隊要數據，甚至于可能一些工程團隊需要他們跨部門進行協助。而有了特征平臺后，絕大多數場景，比如像數據集的一個提取，算法同學可以直接通過封裝好的 Python SDK，外加一些必要的配置文件，直接去調用獲取加工好的數據集，整個過程算法團隊可以自助完成。

Q2：風控是自研的還是組件？有什么組件可以推薦。

A2：不同公司的風控場景一般不一樣，不過主要都是基于策略和算法進行配合著來做，這個沒有什么特定的組件，需要公司先根據業務定制風控策略，然后在策略的基礎上開發算法，進行過濾，二者相輔相成。

Q3：特征工程有哪些基本的組件？

A3：特征工程主要是對原始數據集進行算法處理，例如通過 bagging 算法，是一些統計類的操作。算法加工完之后，存儲在 Feast，是做了向量序列化操作后存儲的。這個跟 Hudi 是沒有關系的，Hudi 存的是一些原始數據集的一個存儲。

今天的分享就到這里，謝謝大家。