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

一、什么是 Modern Data Stack

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

1、Modern Data Stack 的特點

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

2、為什么要有 Modern Data Stack

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

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

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

3、Modern Data Stack 組成

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

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

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

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

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

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

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

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

1、支付長尾

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

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

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

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

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

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

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

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

三、T3 出行的 MDS 初步打造

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

1、Apache Hudi 體系

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

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

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

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

2、Apache Kyuubi 體系

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

任務(wù)調(diào)度：主要通過 Dolphin Scheduler 來進行任務(wù)調(diào)度。

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

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

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

四、特征平臺 On MDS

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

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

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

2、特征平臺作用

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

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

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

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

3、特征平臺的整體流程

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

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

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

（1）Metricflow

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

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

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

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

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

（3）Feast-特征存儲管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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

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

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

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

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

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

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