導讀：
位元組跳動旗下有許多產品，每天有大量的資料需要接收和計算。其中，以抖音、頭條等為代表的產品以實時推薦和流計算為核心，這些都需要消耗大量的計算資源和儲存資源。巨大的資料量和快速準確的計算需求，給技術架構帶來了巨大的挑戰。
本次分享的主題為“位元組跳動流式數倉和實時服務分析的思考和實踐”，將圍繞以下3點展開：
位元組跳動產品架構的業務困境
流式數倉和實時服務分析的實踐
火山引擎雲原生計算
——
01
業務困境
1. 位元組內部場景分析
位元組跳動（下稱“位元組”）旗下擁有今日頭條、抖音等多款產品，每天服務著數億使用者，由此產生的資料量和計算量也非常大：
EB 級別海量的儲存空間
每天平均 70PB 資料的增量
每秒鐘百萬次數的實時推薦請求
超過 400 萬核的流式計算資源、500 萬核的批式計算資源
在進行大資料分析的時候，對資料通常有兩種處理方式：
1。 描述已經發生過的資料，比如，過去發生了什麼，為什麼發生，通常採用批計算來處理；
2。 描述正在發生的資料，比如，此時正在發生什麼，將要發生什麼，這些通常採用流計算來處理，也是今日頭條、抖音等產品實時推薦的核心。
2. 遇到的典型問題
如上圖所示，位元組內部對於資料的處理也分為兩條鏈路：流計算鏈路和批計算鏈路。兩條鏈路有著不同的儲存以及資料處理方式，給整個架構帶來了挑戰：
1. 資料和系統冗餘
，流批兩套系統採用了兩套技術棧，兩套儲存系統，在使用過程中需要分別維護，這使工程師運維和學習的成本非常高；
2. 資料一致性和正確性問題
，資料來自多個源頭，採用了流批兩種處理方式，處理邏輯不一樣，程式碼不可複用，在 ETL 的計算過程中資料被反覆引用，這些都可能使最終的業務資料發生變化，導致資料不一致；
3. Serving 效能問題
，有些業務的主要場景比較簡單，但也需要消耗大量的資源，比如簡單的點查，往往要求高 QPS。如果採用傳統大資料的方案，把主鍵拼起來，那麼中間的結合是松耦合的，如果要同時達到高 QPS，這種拼接方案在計算上和資源上的投資都會很大，效能問題也很嚴重。
針對上述困境，位元組團隊選擇了
流式數倉和實時服務分析融合的解決方案
。
——
02
流式數倉和實時服務分析實踐
1. 流數倉和服務數倉融合
位元組透過實踐將 Streaming Warehouse 流式數倉和實時服務分析進行融合，Streaming Warehouse 做資料處理，實時服務分析做資料服務，兩者結合可以解決三個問題：
Flink Table Store 解決資料和系統冗餘問題
基於 Flink 流批一體，解決資料冗餘性和正確性問題
實時服務分析引擎最佳化解決服務效能問題
2. 對流批一體的思考
在做流式數倉以及實時數倉的產品以前，位元組內部的架構師一直在思考一個問題：流批一體的核心到底是什麼？
最終團隊認為，儲存就是流批一體的核心，儲存就是所有資料分析的基礎。
如上圖所示，流資料隨著時間的推移不停地變化，沒有邊界，從資料庫的角度來看，每次 Binlog 之後會有一定的儲存寫入到硬碟中做持久化，每一個 Snapshot 對應 Binlog 實時位點，這樣整個 Snapshot 就是一個有邊界的批式資料，像上圖一樣一個桶一個桶地放著，兩者結合就是完整的流批一體。
Binlog 和 Snapshot 兩個加起來，在資料庫中既能處理流資料也可以處理批資料，所以位元組團隊將 Flink 的 Table Store 技術作為了最核心的基礎支撐。
3. Flink Table Store
（1）全新的 Flink 內建儲存
Flink Table Store 有以下特性：
Snapshot + Log
滿足所有“實時” User Case
儲存易用，直接查詢 DFS
從 Flink Table Store 的定位來看，Flink Table Store 有 Snapshot，支援批處理，加上 Log 流，同時還提供統一的儲存，可滿足所有面向實時分析服務的 User Case。
其次，Flink Table Store 儲存易用，可直接像 DFS 分散式檔案系統或物件儲存一樣使用，這對整個效率的提升、儲存成本和效能的平衡都有很大作用。
（2）儲存結構
Flink Table Store 的儲存結構包括兩部分：
依賴於流式的其他訊息佇列元件的 Log Queue
基於列存的分散式檔案系統
兩部分結合可以支援流讀（Streaming Reading）、批讀（Batch Reading）以及 Lookup Join。
（3）流批一體
Flink 有支援流批一體的特性，在讀取方面，可以支援流讀，可以讀取 Log Changes，也可以支援批讀，讀 Snapshot，還可以對批流進行融合讀取，Hybrid read 讀，還可以支援點查。在寫入方面，既可以支援持續地流式資料插入，也可以支援分割槽，支援 Overwrite 的批寫。
整個底層跟資料服務是類似的，可以基於分散式檔案系統，底層是無服務的狀態，能做到計算和儲存分離。同時，Flink Table Store 本身是基於列存的，也具備列存所具有的高效能的分析特性，比如壓縮比。
（4）全面支援 SQL
目前業界沒有外部儲存可以支援 Flink SQL 的所有能力
，要麼不支援定義，要麼不支援 Change，或者不支援批寫，也有的不支援 Online 查詢，這會造成流式儲存、讀取、查詢的困難。
Flink Table Store 可以全面支援 Flink SQL。透過 Flink Table Store 儲存後的資料，只要有這個業務邏輯，有主鍵可選，就能夠進行任意的 DDL 定義，還支援所有的型別，如訊息型別或 DML。在此基礎上，我們就可以把查詢或定義做得更好。
（5）Merge Tree
Merge Tree 是用於實時計算核心的內部基礎，FlinkState，ClickHouse 及 HBase，包括 HSAP，都是基於 Merge Tree 的。Merge Tree 本身支援大量快速更新的能力，包括更新寫增量檔案，以及基於 Sorted File 按需 Merge。
Merge Tree 還可以支援高效分析和點查，它的全域性有序性可以做到很好地 Data Skiping，提升檢索、查詢的效率。
根據這些特點，位元組團隊用 Flink Table Store 搭建實時數倉和實時服務分析的底層根基，並在上面進行進一步最佳化。
（6）位元組 Flink OLAP 最佳化
Flink OLAP 能力是流數倉的核心之一，位元組團隊基於 Flink 構建了全新的 OLAP 引擎，已支援 User Growth、電商、幸福裡、飛書等業務，共 11 個叢集 6000+ Core AP 資源，每天 Query 50w+。同時為了支援業務在使用 Flink OLAP 的過程中查詢 Latency 和 QPS 的需求，對 Flink 引擎架構和功能實現進行了大量深入最佳化，使業務查詢效能提升 50% 以上，節省了計算資源；在小規模資料量下，Flink 複雜作業執行的 QPS 從 10 提高到 100 以上，簡單作業執行的 QPS 從 30 提高到 1000 以上。
我們在最佳化位元組內部 Flink OLAP 能力的同時，正在跟社群合作，積極將相關最佳化回饋社群，在
［FLINK-25318］ Improvement of scheduler and execution for Flink OLAP
下建立了 20 多個子任務，有部分已經合併入主分支，剩餘的也在設計和開發中，後續計劃跟社群一起共同推進 Flink OLAP 能力建設和完善。
4. 實現資料流端到端一致性
在 ETL 過程中，同一份資料來源會進行多次計算，一些 ETL 的結果資料在對使用者提供查詢分析服務的同時也作為資料來源執行下一輪，這時就會產生
三個一致性問題：
資料來源到 ETL Exact Once
ETL 寫入單表 Exact Once
多箇中間表的關聯一致性
如上文所提到，在沒有 Flink Table Store 和實現流批一體之前，計算分為流計算鏈路和批計算鏈路，兩條鏈路有各自獨立的計算叢集和排程，資料有不同的入口和不同的處理方式，這種模式下做資料的端到端一致性挑戰很大，成本非常高。
實現流批一體後，透過自動排程資源，自動排程流式鏈路的資料處理流程，把鏈路中的資料流程透過中間表的事務寫入，保證中間資料鏈路的一致性。同時 Flink 的本身的 Exact Once 特性也能保證在 ETL 中間過程的鏈路上一致性。
位元組團隊透過流批一體化解決了資料跟系統的資料冗餘以及一致性的問題，在此基礎上，我們進一步對效能進行了最佳化。
5. 採用雲原生和實時服務分析提升效能
（1）雲原生架構
位元組的產品基本都是基於雲原生架構進行改造，基於容器化，在公共雲上全託管的 Serverless 模式。
在這個模式下，上層的使用者只需要關注業務應用和規劃，下面的資源運維管理和排程分配由技術團隊處理，使用者使用門檻低，同時也避免業務深度介入運維管理。
同時，雲原生基於存算分離，彈性很高，能夠滿足高效的橫向擴充套件。像頭條和抖音等產品，在晚上到睡覺之前，使用者的使用需求很高，這個時候對實時計算效能要求也非常高，使用者睡覺後，使用需求下降，此時對效能的要求相對較低，彈性就可以往下放，雲原生的彈性優勢在這個場景下得到了非常好的體現。
此外，
團隊還透過高效的分散式引擎來解決服務效能問題：
多方式加速查詢，透過 SSD、RDMA、PMEM、記憶體等手段，提升查詢及 Shuffle 效率
物化檢視滿足資料預計算
用 C++ 重寫向量化引擎，提升整體效率
幾個改變下來，可以滿足像頭條、抖音等產品實時的寫入、更新、高併發要求以及資料的視覺化，使用者在產品內進行點選動作後就可以立即推送其關心或感興趣的影片和新聞。
（2）實時服務分析引擎
位元組團隊研發了新一代面向大資料場景的實時服務分析系統，既能夠滿足使用者高 QPS，低 Latency 的線上 Serving 需求，也能滿足使用者對於海量資料的實時分析需求。
傳統的 OLAP 分析模式實際上是靜態的，在分析的時候需要預設好的檢視或模型，海量分析時，透過預設的分析模型，分析出來的結果給到 Serving 對應的資料庫，如 HBase，Redis，MySQL，在這個過程中 Serving 跟分析是分離的。
同時位元組團隊在業務的決策過程中發現，用 OLAP 的使用者對分析的要求實際上是不固定的，且與 OLAP 本身的現狀不相符，使用者需要的是靈活、不固定、按需的分析。
因此，
我們對實時分析的服務引擎做了兩點最佳化：
1。 服務與分析整合，使分析和服務一體化
2。 支援海量資料實時寫入、實時更新、實時分析，支援標準 SQL（相容MySQL語法）
（3）實時服務分析引擎典型場景
位元組內部在使用實時服務的典型場景主要是推薦類的特徵分析，如推薦中用的機器學習特徵，這類場景帶來了
新的挑戰：
資料實時可見資料需要實時寫入，實時查詢，使用者需要資料實時可見
資料寫入吞吐大
查詢併發高（QPS 百萬級別），對於查詢時延要求（毫秒級別）；使用者特徵明細資料龐大，任意時間視窗的線上聚合難以滿足時延的需求
當前沒有一個系統能夠滿足使用者所有需求，使用者通常需要 KV+OLAP+Batch 來滿足業務需求
對於這些挑戰，位元組團隊做了兩個最佳化：一是使用 MV 對明細資料進行聚合，二是透過髒讀來滿足使用者對時效性的要求。
以上，是位元組雲原生部門的兩個重點的產品，流式數倉和實時服務分析引擎。
——
03
火山引擎雲原生計算
火山引擎產品的特點是，基於位元組內部業務孵化，經過了大規模的實踐檢驗後才進行商業化，技術比較成熟，相比開源最大的特點是雲原生化。
上圖是火山引擎雲原生計算的大資料解決方案，共由5部分組成。
最中間部分是核心引擎，分別是：
用於流式計算的 Serverless Flink
用於批式計算的 Serverless Spark 和 Ray 動態引擎
用於儲存的火山引擎自研的大資料統一儲存 CloudFS 和 Iceberg
上述引擎基於開源，但根據位元組的業務特性進行了增強和加固。
上層是資料的開發和管理
，專案和許可權管理可以對每個地方進行細化的許可權管理；此外還有元資料管理、作業開發、任務排程，及 API 服務，總的來說能夠做到端到端的維護。
右側的資料服務
，右側的資料服務，包括能夠提供標準的訊息佇列、100% 相容 Kafka 的 BMQ，還有開放搜尋引擎 Open Search，及實時計算 Flink 到實時服務分析的資料服務。
最下層的資源和排程
，提供雲原生 Operator 對資源排程進行最佳化，還支援多雲管理和混合部署，提升計算鏈路使用過程中的資源利用效率。
在業務流程上，從資料整合到資料分析，再到資料服務，雲原生計算產品體系可以端到端地服務客戶的整個流程。
總的來說
，火山引擎雲原生計算產品體系在雲原生的基礎上，提供了一站式的大資料管理平臺，能夠實現實時和離線計算合一，透過資源排程和資料開發管理，進行了整體的端到端的最佳化。
——
04
Q&A環節
Q1：資料來源做 ETL 寫入到單表時 Exact Once 的度怎麼保證？
A1：採用了 Flink 的 Exact Once 特性。
Q2：Starrocks 的效能對比測試
A2：據瞭解目前沒有過效能的對比測試，另外，位元組內部的站內場景比較多，碰到的問題也比較多，我們是基於雲原生改造的，所以在 QPS 上做得比較深的，這是我們跟開源不太一樣的地方。
Q3：怎麼樣看待 Flink Table Store？
A3：Flink Table Store 在流批一體的場景下是有非常好的能力，目前位元組內部使用的 Flink Table Store 跟開源並行同步的。
今天的分享就到這裡，謝謝大家。
分享嘉賓：汪建鋒 火山引擎 技術專家
編輯整理：張瑋
出品平臺：DataFunTalk
01/分享嘉賓
汪建鋒｜火山引擎
雲原生實時數倉技術專家
火山引擎雲原生實時數倉產品經理，擁有十多年大資料和AI相關產品和方案架構等工作，當前主要負責火山引擎雲原生實時資料庫產品的產品設計和商業化工作。
02/關於我們
DataFun：
專注於大資料、人工智慧技術應用的分享與交流。發起於2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會，已邀請超過2000位專家和學者參與分享。其公眾號 DataFunTalk 累計生產原創文章800+，百萬+閱讀，15萬+精準粉絲。
