T3 出行基于 Hudi+Kyuubi 的現(xiàn)代技術(shù)棧探索
過去的幾年里,隨著大數(shù)據(jù)的進(jìn)一步發(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ù)棧進(jìn)行了一些探索,并初步打造了特征平臺。在本文中,我將給大家分享下 T3 出行結(jié)合公司業(yè)務(wù)場景,在現(xiàn)代技術(shù)棧這方面,做的一些探索于與實(shí)踐,以及在此基礎(chǔ)上打造的特征平臺。
一、什么是 Modern Data Stack
現(xiàn)代數(shù)據(jù)棧是最近幾年出現(xiàn)的一個新名詞,其本質(zhì)是一系列構(gòu)建在數(shù)據(jù)倉庫周圍的工具。其主要出發(fā)點(diǎn)是給公司內(nèi)部,如算法、數(shù)據(jù)處理、數(shù)據(jù)分析等團(tuán)隊提供一個更簡單易用的產(chǎn)品,提升公司整體的運(yùn)營決策效率。
1、Modern Data Stack 的特點(diǎn)
從字面上分析,Modern 譯為現(xiàn)代化,寓意簡單通用,Data Stack 就是圍繞數(shù)據(jù)而展開的各種技術(shù)組件的組合。現(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í)是技術(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)生和推廣,進(jì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ī)模機(jī)器學(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ù)場景分為三個點(diǎn):支持長尾、非結(jié)構(gòu)化的數(shù)據(jù)和小文件、算法業(yè)務(wù)場景。
1、支付長尾
T3 是一個出行企業(yè),所以有很多的訂單場景,而出行訂單場景,在傳統(tǒng)數(shù)倉里面臨一個支付長尾的問題,業(yè)務(wù)層面訂單支付周期可能長達(dá)數(shù)月,會存在長達(dá)數(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ù)還有一些低延遲的場景,會實(shí)時產(chǎn)生結(jié)構(gòu)化的小文件,比如車聯(lián)網(wǎng)的雷達(dá)點(diǎn)云數(shù)據(jù)和日志打點(diǎn)數(shù)據(jù)。
3、算法業(yè)務(wù)場景
T3 的算法業(yè)務(wù)場景,主要分為三塊:
營銷業(yè)務(wù):需要用戶畫像、廣告推廣。
風(fēng)控業(yè)務(wù):主要是保證出行安全,以及一些判責(zé)處理。
運(yùn)力調(diào)度:車輛運(yùn)力管理,智能調(diào)度。
三、T3 出行的 MDS 初步打造
圍繞 T3 出行業(yè)務(wù)場景的特性,我們進(jìn)行了現(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 做加強(qiáng),彌補(bǔ)了 Spark Thrift Server 多租戶授權(quán)、高可用性特性的缺失,并在此基礎(chǔ)上做了相關(guān)的拓展。后續(xù) Kyuubi 開始演化精進(jìn),向統(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)控和配置進(jìn)行持久化存儲,引擎配置可以在線更新。
- 在 Kyuubi 引擎管理的基礎(chǔ)上,加強(qiáng)一些更細(xì)粒度的管理,如用戶的流量管控、查詢頻次等,希望基于這個統(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 報表進(jìn)行可視化的展示。
整體的流程大致如下圖所示:
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ù)進(jìn)行調(diào)度,它通過 Kyuubi,對接 Spark 引擎,Spark 再對 Hudi 的數(shù)據(jù)進(jìn)行加工處理。通過 Dolphin schedule 多租戶管理,再結(jié)合 Kyuubi 的租戶管理能力,T3 實(shí)現(xiàn)了 Spark 資源隔離,讓不同的租戶,即不同業(yè)務(wù)部門,連接不同的資源池,使用不同的資源配置。目前 T3 的任務(wù)日調(diào)度量大概是5萬多,已經(jīng)平穩(wěn)運(yù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 來進(jìn)行任務(wù)調(diào)度。
資源編排層面:目前是在 Yarn 上進(jìn)行,后面會逐步遷移到 K8S 上進(jìn)行資源編排,目前算法平臺的一些開發(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ù)給到模型,讓模型實(shí)現(xiàn)在線推理計算,產(chǎn)生業(yè)務(wù)效果。
2、特征平臺作用
從模型研發(fā)流程圖中,可以看到線上線下都會用到模型的特征數(shù)據(jù),這中間的特征加工過程,特征元信息,需要一個平臺來統(tǒng)一管理。
而且有一些特征加工,比如說一些 ETL 的任務(wù),可能是需要寫 Spark 任務(wù),這樣對算法工程師不太友好,需要一些迭代,以及跨團(tuán)隊的溝通,效率很低,這也需要系統(tǒng)化的解決。
另外正常的特征計算一般是輕量級的任務(wù),如果沒有做好特征統(tǒng)一管理,可能就下推到了在線模型服務(wù),里面會再做一些前置處理,以及特征轉(zhuǎn)化。這樣預(yù)處理被留在模型服務(wù)里面,甚至模型內(nèi)部去進(jìn)行,這增大模型在線推理的一個時延,這個代價還是比較大的。
基于以上幾點(diǎn)原因,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ù)集定義指標(biāo)工具,作為特征數(shù)據(jù)的 Datasource。以及也需要一個特征存儲管理組件,保證能夠跟數(shù)據(jù)湖架構(gòu)很好的組合對接。
(1)Metricflow
我們經(jīng)過調(diào)研,選擇了 Metricflow 這個開源組件,這是一個在國外比較流行的指標(biāo)管理組件。它可以將簡單的度量定義轉(zhuǎn)化為一個可用的 SQL,并針對選擇的 SQL 引擎去執(zhí)行。另外它可以連接數(shù)據(jù)倉庫,構(gòu)建一個度量邏輯。同時也提供 Python SDK ,可以讓用戶在 Python 環(huán)境下進(jìn)行分析,比如在 Jupyter 上直接運(yùn)行分析指標(biāo)。同時它能物化一些指標(biāo),根據(jù)定義好的指標(biāo)和維度,能夠?qū)⒁恍┓且?guī)范化的數(shù)據(jù)集進(jìn)行一個快速存儲,背后實(shí)現(xiàn)是基于 Yarn 語義,按照它的一個規(guī)范定義一個數(shù)據(jù)源還有指標(biāo),然后Metricsflow 內(nèi)部會解析語義文件,按照各個步驟生成 Dig,Dig 的表述會傳遞給選擇的 SQL 優(yōu)化器,然后生成對接的數(shù)據(jù)源所需要的 SQL 語義,并進(jìn)行執(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 層的一個維度表,然后進(jìn)行了 left join 操作。通過將查詢配置化管理,它會根據(jù)所選擇的數(shù)據(jù)源 Hive 或 Kyuubi,轉(zhuǎn)化成對應(yīng)的 SQL 然后進(jìn)行執(zhí)行。
參考 Metricflow 對指標(biāo)語義的定義,T3 對它做了一些拓展,以支撐非結(jié)構(gòu)化數(shù)據(jù)集定義。比如一些非結(jié)構(gòu)化的 OBS 數(shù)據(jù),通過定義其 OBS 文件路徑,就可以查詢獲取。另外拓展后還支持自定義數(shù)據(jù)屬性,比如針對視頻文件?,在 CV 的訓(xùn)練場景,算法需要的一些像素級別、地理位置、時間場景等屬性,這些也都可以在語義中定義,后續(xù)使用時可以直接獲取。
(3)Feast-特征存儲管理
?上面提到了特征存儲管理模塊,T3 選擇了 Feast。Feast 是一個用于機(jī)器學(xué)習(xí)的開源特征存儲組件,對管理現(xiàn)有的技術(shù)架構(gòu),以產(chǎn)生用于模型訓(xùn)練和在線推理的分析數(shù)據(jù)提供了便捷。Feast 是 Tecton(一個美國機(jī)器學(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è)施進(jìn)行了分離,并提供了離線特征可以發(fā)布為實(shí)時特征的能力,讓離線加工好的特征可以直接提供給在線模型推理使用,保證了特征加工的一致性和時效性。同時針對特征數(shù)據(jù)字段較多,數(shù)字化的特性,存儲會進(jìn)行定制化的序列化壓縮,在有限影響性能基礎(chǔ)上大大節(jié)省了存儲空間。
(4)元數(shù)據(jù)管理
特征平臺在 Metricflow 和 Feast 的基礎(chǔ)上,進(jìn)行了封裝和二次開發(fā),實(shí)現(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ù)集來進(jìn)行管理。
而對于業(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í)時數(shù)據(jù)處理架構(gòu)。
離線數(shù)據(jù)處理架構(gòu),以數(shù)據(jù)源為出點(diǎn),根據(jù)數(shù)據(jù)源的定義,通過 Spark 進(jìn)行數(shù)據(jù)集的清洗提取,再進(jìn)行特征的視圖封裝,然后進(jìn)行特征加工,加工好的特征視圖數(shù)據(jù)會存儲到Feast,進(jìn)行特征的統(tǒng)一管理。最后則是通過一個 UI 界面的方式,來提供不同團(tuán)隊使用。
另外加工好的特征,用戶可以在特征平臺上,看到它的數(shù)據(jù)集來源,特征加工的邏輯。特征平臺會對這些特征進(jìn)行一些權(quán)限管理,讓特征盡可能復(fù)用,這大大提高了特征使用的效率。
實(shí)時數(shù)據(jù)處理架構(gòu),則是通過 Kafka 消息隊列,根據(jù)消息里面封裝好的特征視圖的,進(jìn)行邏輯加工后,再通過 feature transform,最后進(jìn)行一個存儲。
所有經(jīng)過處理的特征數(shù)據(jù)都會以 Data frame 的方式,提供給模型訓(xùn)練,比如在算法平臺的 Jupyter 上面進(jìn)行開發(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ù)集進(jìn)行離線或者實(shí)時的特征工程處理,加工成為特征數(shù)據(jù),并對特征數(shù)據(jù)進(jìn)行統(tǒng)一管理,統(tǒng)一對外部業(yè)務(wù)算法團(tuán)隊使用。
而特征任務(wù)計算流程,以及其血緣關(guān)系,都會通過任務(wù)調(diào)度 Dolphin schedule 進(jìn)行統(tǒng)一管理,它負(fù)責(zé)和任務(wù)流的源數(shù)據(jù),以及上下游任務(wù)進(jìn)行打通,并且能夠看到每個特征加工的任務(wù)情況。
特征平臺則會對特征的元數(shù)據(jù),比如特征名字、特征來源、特征的 schema 等進(jìn)行管理,以及對整個鏈路,也是做了完善的監(jiān)控,做到了任務(wù)全流程的數(shù)據(jù)源管理。另外特征平臺離線和實(shí)時計算產(chǎn)出的特征數(shù)據(jù),會提供到模型服務(wù)使用。
當(dāng)然特征計算是需要用戶自行開發(fā)一個調(diào)度任務(wù),并進(jìn)行維護(hù),特征平臺會提供一個 SDK 給到算法工程師,他們可以通過 Python SDK 和特征平臺進(jìn)行數(shù)據(jù)交互。
基于以上設(shè)計,就形成了當(dāng)前 T3 出行現(xiàn)代技術(shù)棧的整體架構(gòu)。?
總結(jié)
回顧主題,現(xiàn)代數(shù)據(jù)棧的目標(biāo)是大大簡化用戶管理數(shù)據(jù)的難度,讓用戶更加關(guān)心于數(shù)據(jù)本身,而非組件本身。T3 出行是在數(shù)據(jù)湖基礎(chǔ)上,所打造的特征平臺。希望能和大家進(jìn)一步交流,通過現(xiàn)代數(shù)據(jù)棧更好的推動業(yè)務(wù),同時降低開發(fā)和維護(hù)成本。也希望現(xiàn)代數(shù)據(jù)棧能在國內(nèi)有更好的發(fā)展。
六、問答環(huán)節(jié)
Q1:特征計算是在什么樣的團(tuán)隊,是業(yè)務(wù)團(tuán)隊還是數(shù)據(jù)團(tuán)隊?
A1:特征工程是算法團(tuán)隊做的,而打造特征平臺主要是為算法團(tuán)隊提供輔助,比如說數(shù)據(jù)提取,原始數(shù)據(jù)加工。如果沒有特征平臺,那會給公司增加溝通成本,增加一些跨部門溝通,比如說算法同學(xué)找數(shù)倉團(tuán)隊要數(shù)據(jù),甚至于可能一些工程團(tuán)隊需要他們跨部門進(jìn)行協(xié)助。而有了特征平臺后,絕大多數(shù)場景,比如像數(shù)據(jù)集的一個提取,算法同學(xué)可以直接通過封裝好的 Python SDK,外加一些必要的配置文件,直接去調(diào)用獲取加工好的數(shù)據(jù)集,整個過程算法團(tuán)隊可以自助完成。
Q2:風(fēng)控是自研的還是組件?有什么組件可以推薦。
A2:不同公司的風(fēng)控場景一般不一樣,不過主要都是基于策略和算法進(jìn)行配合著來做,這個沒有什么特定的組件,需要公司先根據(jù)業(yè)務(wù)定制風(fēng)控策略,然后在策略的基礎(chǔ)上開發(fā)算法,進(jìn)行過濾,二者相輔相成。
Q3:特征工程有哪些基本的組件?
A3:特征工程主要是對原始數(shù)據(jù)集進(jìn)行算法處理,例如通過 bagging 算法,是一些統(tǒng)計類的操作。算法加工完之后,存儲在 Feast,是做了向量序列化操作后存儲的。這個跟 Hudi 是沒有關(guān)系的,Hudi 存的是一些原始數(shù)據(jù)集的一個存儲。
今天的分享就到這里,謝謝大家。