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

一、什么是 Modern Data Stack

現(xiàn)代數(shù)據(jù)棧是最近幾年出現(xiàn)的一個(gè)新名詞，其本質(zhì)是一系列構(gòu)建在數(shù)據(jù)倉(cāng)庫(kù)周圍的工具。其主要出發(fā)點(diǎn)是給公司內(nèi)部，如算法、數(shù)據(jù)處理、數(shù)據(jù)分析等團(tuán)隊(duì)提供一個(gè)更簡(jiǎn)單易用的產(chǎn)品，提升公司整體的運(yùn)營(yíng)決策效率。

1、Modern Data Stack 的特點(diǎn)

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

2、為什么要有 Modern Data Stack

為什么會(huì)有現(xiàn)代數(shù)據(jù)棧概念，這其實(shí)是技術(shù)發(fā)展的一個(gè)演變過(guò)程。十幾年前，那時(shí)都是以傳統(tǒng)數(shù)據(jù)庫(kù)為主，都是從 Oracle、IBM 這類數(shù)據(jù)庫(kù)廠商中做選擇，選擇不多，定好數(shù)據(jù)庫(kù)后，公司的技術(shù)架構(gòu)也只能根據(jù)廠商的意見來(lái)打造。

而現(xiàn)在隨著企業(yè)數(shù)據(jù)規(guī)模、應(yīng)用數(shù)量增長(zhǎng)，以及應(yīng)用技術(shù)組件豐富完善，云計(jì)算的產(chǎn)生和推廣，進(jìn)一步推動(dòng)了數(shù)據(jù)庫(kù)領(lǐng)域的發(fā)展。這使得現(xiàn)在數(shù)據(jù)軟件價(jià)格和使用門檻大幅降低，企業(yè)有了更多的選擇，可以根據(jù)具體的數(shù)據(jù)業(yè)務(wù)場(chǎng)景，來(lái)選擇最合適的技術(shù)組件，從而圍繞企業(yè)自身業(yè)務(wù)需求，量身打造一個(gè)足夠低廉、性能足夠優(yōu)秀的架構(gòu)。

當(dāng)然現(xiàn)代數(shù)據(jù)棧的目的，依舊是從數(shù)據(jù)中提煉出有價(jià)值信息，為業(yè)務(wù)提供決策支撐，推動(dòng)公司的業(yè)務(wù)發(fā)展。

3、Modern Data Stack 組成

現(xiàn)代數(shù)據(jù)棧主要分為數(shù)據(jù)統(tǒng)一存儲(chǔ)、數(shù)據(jù)處理、數(shù)據(jù)分析、數(shù)據(jù)智能這四個(gè)部分，每個(gè)組成部分解決的問(wèn)題如下所示：

統(tǒng)一存儲(chǔ)：解決數(shù)據(jù)孤島、降低數(shù)據(jù)環(huán)境的復(fù)雜度。

數(shù)據(jù)處理：原始數(shù)據(jù)加工、轉(zhuǎn)換、ETL、任務(wù)調(diào)度。

數(shù)據(jù)分析：提取有用信息和形成商業(yè)結(jié)論。

數(shù)據(jù)智能：大規(guī)模機(jī)器學(xué)習(xí)和深度學(xué)習(xí)等技術(shù)對(duì)數(shù)據(jù)價(jià)值信息提取。

二、T3 出行的業(yè)務(wù)場(chǎng)景

T3 出行是一家基于車聯(lián)網(wǎng)驅(qū)動(dòng)的智慧出行平臺(tái)，擁有海量且豐富的數(shù)據(jù)源。因?yàn)檐嚶?lián)網(wǎng)數(shù)據(jù)多樣性，隨著業(yè)務(wù)發(fā)展，數(shù)據(jù)的增多，最初的傳統(tǒng)數(shù)倉(cāng)架構(gòu)，遇到了諸多挑戰(zhàn)，亟需新的架構(gòu)迭代升級(jí)，更好的支撐公司業(yè)務(wù)發(fā)展。

通過(guò)歸納總結(jié)，T3 原來(lái)數(shù)倉(cāng)架構(gòu)面臨挑戰(zhàn)的業(yè)務(wù)場(chǎng)景分為三個(gè)點(diǎn)：支持長(zhǎng)尾、非結(jié)構(gòu)化的數(shù)據(jù)和小文件、算法業(yè)務(wù)場(chǎng)景。

1、支付長(zhǎng)尾

T3 是一個(gè)出行企業(yè)，所以有很多的訂單場(chǎng)景，而出行訂單場(chǎng)景，在傳統(tǒng)數(shù)倉(cāng)里面臨一個(gè)支付長(zhǎng)尾的問(wèn)題，業(yè)務(wù)層面訂單支付周期可能長(zhǎng)達(dá)數(shù)月，會(huì)存在長(zhǎng)達(dá)數(shù)月的超長(zhǎng)業(yè)務(wù)閉環(huán)窗口，同時(shí)也帶來(lái)了冷熱數(shù)據(jù)的更新問(wèn)題。在長(zhǎng)尾訂單支付后，很久之前的數(shù)據(jù)需要做一些更新，在傳統(tǒng)數(shù)倉(cāng)里面去做很麻煩，要做級(jí)聯(lián)更新，鏈路長(zhǎng)，成本高。

2、非結(jié)構(gòu)化數(shù)據(jù)和大量小文件

T3  出行的數(shù)據(jù)除了結(jié)構(gòu)化數(shù)據(jù)之外，還有很多非結(jié)構(gòu)化數(shù)據(jù)，比如說(shuō)出行產(chǎn)生音視頻數(shù)據(jù)，還有車聯(lián)網(wǎng)相關(guān)的信號(hào)數(shù)據(jù)。同時(shí)，之前的數(shù)倉(cāng)架構(gòu)，因?yàn)閿?shù)據(jù)更新太多，產(chǎn)生了很多小文件。另外 T3 的業(yè)務(wù)還有一些低延遲的場(chǎng)景，會(huì)實(shí)時(shí)產(chǎn)生結(jié)構(gòu)化的小文件，比如車聯(lián)網(wǎng)的雷達(dá)點(diǎn)云數(shù)據(jù)和日志打點(diǎn)數(shù)據(jù)。

3、算法業(yè)務(wù)場(chǎng)景

T3 的算法業(yè)務(wù)場(chǎng)景，主要分為三塊：

營(yíng)銷業(yè)務(wù)：需要用戶畫像、廣告推廣。

風(fēng)控業(yè)務(wù)：主要是保證出行安全，以及一些判責(zé)處理。

運(yùn)力調(diào)度：車輛運(yùn)力管理，智能調(diào)度。

三、T3 出行的 MDS 初步打造

圍繞 T3 出行業(yè)務(wù)場(chǎng)景的特性，我們進(jìn)行了現(xiàn)代技術(shù)棧的一個(gè)初步的打造，主要是圍繞 Apache Hudi 和 Apache Kyuubi 展開。

1、Apache Hudi 體系

?為了解決前面說(shuō)的支付長(zhǎng)尾和大量小文件的問(wèn)題，我們引入了 Apache Hudi 這個(gè)組件。Hudi 是一個(gè)流式湖倉(cāng)一體的平臺(tái)，支持海量數(shù)據(jù)塊的更新，它保證在時(shí)間軸上執(zhí)行操作都是原子性的，這樣保證了事物，適合 T3 訂單類數(shù)據(jù)存儲(chǔ)。

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

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

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

2、Apache Kyuubi 體系

為了更好地支撐 T3 內(nèi)部數(shù)據(jù)分析的場(chǎng)景，我們引入了 Apache Kyuubi 作為統(tǒng)一的網(wǎng)關(guān)。

Kyuubi 是一個(gè) Thrift JDBC/ODBC 服務(wù)，由網(wǎng)易數(shù)帆發(fā)起，具備多租戶和分布式等特性，為大數(shù)據(jù)查詢引擎如 Spark、Flink 等提供 SQL 等查詢服務(wù)。它最早是對(duì) Spark Thrift Server 做加強(qiáng)，彌補(bǔ)了 Spark Thrift Server 多租戶授權(quán)、高可用性特性的缺失，并在此基礎(chǔ)上做了相關(guān)的拓展。后續(xù) Kyuubi 開始演化精進(jìn)，向統(tǒng)一網(wǎng)關(guān)的場(chǎng)景發(fā)展，以滿足企業(yè)內(nèi)諸如 ETL、BI 報(bào)表等多種大數(shù)據(jù)場(chǎng)景的應(yīng)用。

T3 出行對(duì)于 Kyuubi 的使用除了在 ETL 和 OLAP 場(chǎng)景以外，還做了以下應(yīng)用與拓展：

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

3、T3 數(shù)據(jù)分析處理流程

基于 Hudi 和 Kyuubi，T3 的數(shù)據(jù)分析和處理流程的設(shè)計(jì)，也變得簡(jiǎn)單清晰，下面逐一道來(lái)。

（1）數(shù)據(jù)分析流程

對(duì)于數(shù)據(jù)分析場(chǎng)景，主要是使用 HUE Web UI 和 BI 分析工具（帆軟），二者連接Kyuubi 這個(gè)統(tǒng)一網(wǎng)關(guān)。

HUE 一般是數(shù)據(jù)開發(fā)時(shí)候使用，通過(guò) Kyuubi 連接 Spark 引擎，去執(zhí)行 Spark SQL ，然后加工 Hudi 的數(shù)據(jù)，獲得計(jì)算結(jié)果，從而完成整個(gè)開發(fā)。

BI 分析工具也是通過(guò) Kyuubi，連接 Presto Engine 引擎后，查詢加工好的 ODS 層數(shù)據(jù)后，通過(guò) BI 報(bào)表進(jìn)行可視化的展示。

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

T3 通過(guò)接入 Kyuubi 網(wǎng)關(guān)，收斂了數(shù)據(jù)分析入口，從而可以更好地管控用戶使用。當(dāng)然這也簡(jiǎn)化了用戶的使用成本，畢竟用戶不需要關(guān)心 Kyuubi 后面的引擎，不需要對(duì)接各種引擎的驅(qū)動(dòng)，只需要對(duì)接 Kyuubi 即可，做到了開箱即用。

（2）數(shù)據(jù)處理流程

關(guān)于數(shù)據(jù)處理的場(chǎng)景，T3 在通過(guò) Dolphin schedule 對(duì)處理任務(wù)進(jìn)行調(diào)度，它通過(guò) Kyuubi，對(duì)接 Spark 引擎，Spark 再對(duì) Hudi 的數(shù)據(jù)進(jìn)行加工處理。通過(guò) Dolphin schedule 多租戶管理，再結(jié)合 Kyuubi 的租戶管理能力，T3 實(shí)現(xiàn)了 Spark 資源隔離，讓不同的租戶，即不同業(yè)務(wù)部門，連接不同的資源池，使用不同的資源配置。目前 T3 的任務(wù)日調(diào)度量大概是5萬(wàn)多，已經(jīng)平穩(wěn)運(yùn)行了大半年，可以說(shuō)這個(gè)架構(gòu)還是很穩(wěn)定的。

4、T3 整體的數(shù)據(jù)湖架構(gòu)

基于 Hudi 和 Kyuubi 的一個(gè)基座，T3 搭建的數(shù)據(jù)湖架構(gòu)，整體的形態(tài)如下圖所示：

基于上圖架構(gòu)設(shè)計(jì)，逐個(gè)簡(jiǎn)單介紹下：

一站式平臺(tái)的入口：這個(gè)主要是對(duì)接不同的平臺(tái)，比如帆軟、特征平臺(tái)、算法平臺(tái)等。

計(jì)算中間件：主要是用到 Kyuubi ，它作為統(tǒng)一網(wǎng)關(guān)，來(lái)支撐各類分析場(chǎng)景。

任務(wù)調(diào)度：主要通過(guò) Dolphin Scheduler 來(lái)進(jìn)行任務(wù)調(diào)度。

資源編排層面：目前是在 Yarn 上進(jìn)行，后面會(huì)逐步遷移到 K8S 上進(jìn)行資源編排，目前算法平臺(tái)的一些開發(fā)場(chǎng)景已經(jīng)遷移，后面所有的 Spark 和 Flink Job 也會(huì)陸續(xù)遷移。

數(shù)據(jù)存儲(chǔ)管理：表的元數(shù)據(jù)存儲(chǔ)主要還是使用 Hive Metastore；業(yè)務(wù)結(jié)構(gòu)化數(shù)據(jù)，則是用 Hudi 的表來(lái)管理，數(shù)據(jù)則是存儲(chǔ)在華為云的 OBS 上；非結(jié)構(gòu)化數(shù)據(jù)，也是存在 OBS。相比于早期的 HDFS 存儲(chǔ)，大大降低了存儲(chǔ)成本。

數(shù)據(jù)接入層：主要是通過(guò) Kafka 和 Canal 的訂閱數(shù)據(jù)，然后入湖，持久化到 OBS。

四、特征平臺(tái) On MDS

1、模型開發(fā)流程

基于數(shù)據(jù)湖的架構(gòu)，T3 打造了一個(gè)特征平臺(tái)，在描述特征平臺(tái)之前，先介紹模型開發(fā)的一個(gè)大致流程，大致如下圖所示：

模型研發(fā)流程始于數(shù)據(jù)采集，大數(shù)據(jù)工程師利用采集的原始數(shù)據(jù)，通過(guò) Spark 離線計(jì)算，加工生成算法需要的特征數(shù)據(jù)集，從而給到算法工程師用來(lái)訓(xùn)練模型，調(diào)參，等模型穩(wěn)定后，就可以把訓(xùn)練好的模型部署上線，交付給到業(yè)務(wù)使用。業(yè)務(wù)方則通過(guò)傳入特征數(shù)據(jù)給到模型，讓模型實(shí)現(xiàn)在線推理計(jì)算，產(chǎn)生業(yè)務(wù)效果。

2、特征平臺(tái)作用

從模型研發(fā)流程圖中，可以看到線上線下都會(huì)用到模型的特征數(shù)據(jù)，這中間的特征加工過(guò)程，特征元信息，需要一個(gè)平臺(tái)來(lái)統(tǒng)一管理。

而且有一些特征加工，比如說(shuō)一些 ETL 的任務(wù)，可能是需要寫 Spark 任務(wù)，這樣對(duì)算法工程師不太友好，需要一些迭代，以及跨團(tuán)隊(duì)的溝通，效率很低，這也需要系統(tǒng)化的解決。

另外正常的特征計(jì)算一般是輕量級(jí)的任務(wù)，如果沒(méi)有做好特征統(tǒng)一管理，可能就下推到了在線模型服務(wù)，里面會(huì)再做一些前置處理，以及特征轉(zhuǎn)化。這樣預(yù)處理被留在模型服務(wù)里面，甚至模型內(nèi)部去進(jìn)行，這增大模型在線推理的一個(gè)時(shí)延，這個(gè)代價(jià)還是比較大的。

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

3、特征平臺(tái)的整體流程

整體來(lái)說(shuō)，特征平臺(tái)在算法加工的流程中，扮演著數(shù)據(jù)集的提取、加工和管理的角色，它將加工好的樣本提供給模型開發(fā)和使用。訓(xùn)練好的模型部署在模型服務(wù)后，模型服務(wù)也會(huì)直接去特征平臺(tái)去拿加工好的特征數(shù)據(jù)，然后統(tǒng)一提供給業(yè)務(wù)服務(wù)。

4、特征平臺(tái)技術(shù)棧選型

在特征平臺(tái)的流程中，涉及到數(shù)據(jù)集的管理，因此在技術(shù)棧選項(xiàng)上，需要一個(gè)數(shù)據(jù)集定義指標(biāo)工具，作為特征數(shù)據(jù)的 Datasource。以及也需要一個(gè)特征存儲(chǔ)管理組件，保證能夠跟數(shù)據(jù)湖架構(gòu)很好的組合對(duì)接。

（1）Metricflow

我們經(jīng)過(guò)調(diào)研，選擇了 Metricflow 這個(gè)開源組件，這是一個(gè)在國(guó)外比較流行的指標(biāo)管理組件。它可以將簡(jiǎn)單的度量定義轉(zhuǎn)化為一個(gè)可用的 SQL，并針對(duì)選擇的 SQL 引擎去執(zhí)行。另外它可以連接數(shù)據(jù)倉(cāng)庫(kù)，構(gòu)建一個(gè)度量邏輯。同時(shí)也提供 Python SDK ，可以讓用戶在 Python 環(huán)境下進(jìn)行分析，比如在 Jupyter 上直接運(yùn)行分析指標(biāo)。同時(shí)它能物化一些指標(biāo)，根據(jù)定義好的指標(biāo)和維度，能夠?qū)⒁恍┓且?guī)范化的數(shù)據(jù)集進(jìn)行一個(gè)快速存儲(chǔ)，背后實(shí)現(xiàn)是基于 Yarn 語(yǔ)義，按照它的一個(gè)規(guī)范定義一個(gè)數(shù)據(jù)源還有指標(biāo)，然后Metricsflow 內(nèi)部會(huì)解析語(yǔ)義文件，按照各個(gè)步驟生成 Dig，Dig 的表述會(huì)傳遞給選擇的 SQL 優(yōu)化器，然后生成對(duì)接的數(shù)據(jù)源所需要的 SQL 語(yǔ)義，并進(jìn)行執(zhí)行。

當(dāng)然 Metricflow 主要支持是在連接數(shù)倉(cāng)數(shù)據(jù)庫(kù)這塊，對(duì)一些非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)，它不太能很好的支撐，所以基于它的語(yǔ)義層，T3 做了一些拓展。

（2）數(shù)據(jù)集語(yǔ)義

?下圖是一個(gè)數(shù)據(jù)集語(yǔ)義 Demo，可以在該語(yǔ)義中設(shè)置數(shù)據(jù)集的名稱，Owner、所屬項(xiàng)目、數(shù)據(jù)集的描述。除此之外，它可以定義數(shù)據(jù)集的查詢邏輯。比如說(shuō)查詢的主表，Demo 中主表是 test 表，它關(guān)聯(lián)到某個(gè) DIM 層的一個(gè)維度表，然后進(jìn)行了 left join 操作。通過(guò)將查詢配置化管理，它會(huì)根據(jù)所選擇的數(shù)據(jù)源 Hive 或 Kyuubi，轉(zhuǎn)化成對(duì)應(yīng)的 SQL 然后進(jìn)行執(zhí)行。

參考 Metricflow 對(duì)指標(biāo)語(yǔ)義的定義，T3 對(duì)它做了一些拓展，以支撐非結(jié)構(gòu)化數(shù)據(jù)集定義。比如一些非結(jié)構(gòu)化的 OBS 數(shù)據(jù)，通過(guò)定義其 OBS 文件路徑，就可以查詢獲取。另外拓展后還支持自定義數(shù)據(jù)屬性，比如針對(duì)視頻文件?，在 CV 的訓(xùn)練場(chǎng)景，算法需要的一些像素級(jí)別、地理位置、時(shí)間場(chǎng)景等屬性，這些也都可以在語(yǔ)義中定義，后續(xù)使用時(shí)可以直接獲取。

（3）Feast-特征存儲(chǔ)管理

?上面提到了特征存儲(chǔ)管理模塊，T3 選擇了 Feast。Feast 是一個(gè)用于機(jī)器學(xué)習(xí)的開源特征存儲(chǔ)組件，對(duì)管理現(xiàn)有的技術(shù)架構(gòu)，以產(chǎn)生用于模型訓(xùn)練和在線推理的分析數(shù)據(jù)提供了便捷。Feast 是 Tecton（一個(gè)美國(guó)機(jī)器學(xué)習(xí)數(shù)據(jù)平臺(tái)）提供的一個(gè)開源版本特征管理模塊，它支持離線特征存儲(chǔ)，也支持在線特征管理，保證了特征的一致性。

Feast 通過(guò)統(tǒng)一的 Feast Server，對(duì)外提供了 Restful Api，供 Python SDK 或 J?ava SDK 調(diào)用，提供了統(tǒng)一的輸出。

總的來(lái)說(shuō)，F(xiàn)east 通過(guò)提供從特征檢索中抽象出特征存儲(chǔ)的單一訪問(wèn)層，將算法開發(fā)和數(shù)據(jù)基礎(chǔ)設(shè)施進(jìn)行了分離，并提供了離線特征可以發(fā)布為實(shí)時(shí)特征的能力，讓離線加工好的特征可以直接提供給在線模型推理使用，保證了特征加工的一致性和時(shí)效性。同時(shí)針對(duì)特征數(shù)據(jù)字段較多，數(shù)字化的特性，存儲(chǔ)會(huì)進(jìn)行定制化的序列化壓縮，在有限影響性能基礎(chǔ)上大大節(jié)省了存儲(chǔ)空間。

（4）元數(shù)據(jù)管理

特征平臺(tái)在 Metricflow 和 Feast 的基礎(chǔ)上，進(jìn)行了封裝和二次開發(fā)，實(shí)現(xiàn)了元數(shù)據(jù)的管理。

對(duì)應(yīng)像視頻數(shù)據(jù)，車輛網(wǎng)數(shù)據(jù)，這些非結(jié)構(gòu)化的數(shù)據(jù)，T3 參考了 Metricflow 的語(yǔ)義層，對(duì)非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)的一些目錄，以及自定義屬性做了拓展，把它們都作為一個(gè)數(shù)據(jù)集來(lái)進(jìn)行管理。

而對(duì)于業(yè)務(wù)結(jié)構(gòu)化數(shù)據(jù)，則是存儲(chǔ)在 Hudi 或者 Hive 的表里面。表的 Meta 信息則是使用 Hive Metastore 來(lái)這些存儲(chǔ)管理。

通過(guò)上述操作，特征平臺(tái)完成了對(duì)元數(shù)據(jù)、數(shù)據(jù)集的定義和管理。

5、特征平臺(tái)內(nèi)部架構(gòu)

特征平臺(tái)的內(nèi)部架構(gòu)，主要分為兩塊：離線數(shù)據(jù)的處理架構(gòu)和實(shí)時(shí)數(shù)據(jù)處理架構(gòu)。

離線數(shù)據(jù)處理架構(gòu)，以數(shù)據(jù)源為出點(diǎn)，根據(jù)數(shù)據(jù)源的定義，通過(guò) Spark 進(jìn)行數(shù)據(jù)集的清洗提取，再進(jìn)行特征的視圖封裝，然后進(jìn)行特征加工，加工好的特征視圖數(shù)據(jù)會(huì)存儲(chǔ)到Feast，進(jìn)行特征的統(tǒng)一管理。最后則是通過(guò)一個(gè) UI 界面的方式，來(lái)提供不同團(tuán)隊(duì)使用。

另外加工好的特征，用戶可以在特征平臺(tái)上，看到它的數(shù)據(jù)集來(lái)源，特征加工的邏輯。特征平臺(tái)會(huì)對(duì)這些特征進(jìn)行一些權(quán)限管理，讓特征盡可能復(fù)用，這大大提高了特征使用的效率。

實(shí)時(shí)數(shù)據(jù)處理架構(gòu)，則是通過(guò) Kafka 消息隊(duì)列，根據(jù)消息里面封裝好的特征視圖的，進(jìn)行邏輯加工后，再通過(guò) feature transform，最后進(jìn)行一個(gè)存儲(chǔ)。

所有經(jīng)過(guò)處理的特征數(shù)據(jù)都會(huì)以 Data frame 的方式，提供給模型訓(xùn)練，比如在算法平臺(tái)的 Jupyter 上面進(jìn)行開發(fā)和模型訓(xùn)練，或者是提供給模型服務(wù)，通過(guò) feature vector 特征向量的方式，傳遞給在線模型服務(wù)。整個(gè)過(guò)程都是通過(guò)特征平臺(tái)這個(gè)統(tǒng)一的出口，做了統(tǒng)一的管理。這讓整個(gè)特征加工模型訓(xùn)練，形成一個(gè)閉環(huán)。

6、特征平臺(tái) On MDS 架構(gòu)

?總的來(lái)說(shuō)，特征平臺(tái)的整體架構(gòu)，是使用數(shù)據(jù)湖，以及一些在線數(shù)據(jù)源，通過(guò)大數(shù)據(jù)清洗提取數(shù)據(jù)集，再通過(guò)數(shù)據(jù)集進(jìn)行離線或者實(shí)時(shí)的特征工程處理，加工成為特征數(shù)據(jù)，并對(duì)特征數(shù)據(jù)進(jìn)行統(tǒng)一管理，統(tǒng)一對(duì)外部業(yè)務(wù)算法團(tuán)隊(duì)使用。

而特征任務(wù)計(jì)算流程，以及其血緣關(guān)系，都會(huì)通過(guò)任務(wù)調(diào)度 Dolphin schedule 進(jìn)行統(tǒng)一管理，它負(fù)責(zé)和任務(wù)流的源數(shù)據(jù)，以及上下游任務(wù)進(jìn)行打通，并且能夠看到每個(gè)特征加工的任務(wù)情況。

特征平臺(tái)則會(huì)對(duì)特征的元數(shù)據(jù)，比如特征名字、特征來(lái)源、特征的 schema 等進(jìn)行管理，以及對(duì)整個(gè)鏈路，也是做了完善的監(jiān)控，做到了任務(wù)全流程的數(shù)據(jù)源管理。另外特征平臺(tái)離線和實(shí)時(shí)計(jì)算產(chǎn)出的特征數(shù)據(jù)，會(huì)提供到模型服務(wù)使用。

當(dāng)然特征計(jì)算是需要用戶自行開發(fā)一個(gè)調(diào)度任務(wù)，并進(jìn)行維護(hù)，特征平臺(tái)會(huì)提供一個(gè) SDK 給到算法工程師，他們可以通過(guò) Python SDK 和特征平臺(tái)進(jìn)行數(shù)據(jù)交互。

基于以上設(shè)計(jì)，就形成了當(dāng)前 T3 出行現(xiàn)代技術(shù)棧的整體架構(gòu)。?

總結(jié)

回顧主題，現(xiàn)代數(shù)據(jù)棧的目標(biāo)是大大簡(jiǎn)化用戶管理數(shù)據(jù)的難度，讓用戶更加關(guān)心于數(shù)據(jù)本身，而非組件本身。T3 出行是在數(shù)據(jù)湖基礎(chǔ)上，所打造的特征平臺(tái)。希望能和大家進(jìn)一步交流，通過(guò)現(xiàn)代數(shù)據(jù)棧更好的推動(dòng)業(yè)務(wù)，同時(shí)降低開發(fā)和維護(hù)成本。也希望現(xiàn)代數(shù)據(jù)棧能在國(guó)內(nèi)有更好的發(fā)展。

六、問(wèn)答環(huán)節(jié)

Q1：特征計(jì)算是在什么樣的團(tuán)隊(duì)，是業(yè)務(wù)團(tuán)隊(duì)還是數(shù)據(jù)團(tuán)隊(duì)？

A1：特征工程是算法團(tuán)隊(duì)做的，而打造特征平臺(tái)主要是為算法團(tuán)隊(duì)提供輔助，比如說(shuō)數(shù)據(jù)提取，原始數(shù)據(jù)加工。如果沒(méi)有特征平臺(tái)，那會(huì)給公司增加溝通成本，增加一些跨部門溝通，比如說(shuō)算法同學(xué)找數(shù)倉(cāng)團(tuán)隊(duì)要數(shù)據(jù)，甚至于可能一些工程團(tuán)隊(duì)需要他們跨部門進(jìn)行協(xié)助。而有了特征平臺(tái)后，絕大多數(shù)場(chǎng)景，比如像數(shù)據(jù)集的一個(gè)提取，算法同學(xué)可以直接通過(guò)封裝好的 Python SDK，外加一些必要的配置文件，直接去調(diào)用獲取加工好的數(shù)據(jù)集，整個(gè)過(guò)程算法團(tuán)隊(duì)可以自助完成。

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

A2：不同公司的風(fēng)控場(chǎng)景一般不一樣，不過(guò)主要都是基于策略和算法進(jìn)行配合著來(lái)做，這個(gè)沒(méi)有什么特定的組件，需要公司先根據(jù)業(yè)務(wù)定制風(fēng)控策略，然后在策略的基礎(chǔ)上開發(fā)算法，進(jìn)行過(guò)濾，二者相輔相成。

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

A3：特征工程主要是對(duì)原始數(shù)據(jù)集進(jìn)行算法處理，例如通過(guò) bagging 算法，是一些統(tǒng)計(jì)類的操作。算法加工完之后，存儲(chǔ)在 Feast，是做了向量序列化操作后存儲(chǔ)的。這個(gè)跟 Hudi 是沒(méi)有關(guān)系的，Hudi 存的是一些原始數(shù)據(jù)集的一個(gè)存儲(chǔ)。

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