TikTok的主要收入來自直播和電商，這要求實時處理數(shù)據(jù)，比批處理更復(fù)雜，涉及多流連接和維度表更新，需要更多開發(fā)和維護資源，且為保障系統(tǒng)穩(wěn)定，常導(dǎo)致資源浪費。本文邀請了TikTok數(shù)據(jù)平臺團隊分享他們?nèi)绾卫肁pache Doris構(gòu)建實時數(shù)據(jù)架構(gòu)，可作為高效實時數(shù)據(jù)倉庫的范例學(xué)習(xí)。

1. TikTok的實時數(shù)據(jù)倉庫

圖片

在遷移到Apache Doris前，TikTok通過Flink傳輸實時數(shù)據(jù)，并使用Kafka在不同數(shù)據(jù)層間實現(xiàn)數(shù)據(jù)流動。由于Kafka本身沒有邏輯表，因此在其上開發(fā)不如在Hive上那么容易。對于TikTok來說，實時數(shù)據(jù)與離線數(shù)據(jù)之間的數(shù)據(jù)量存在顯著差距。由于與實時數(shù)據(jù)相關(guān)的開發(fā)、運營和資源成本，團隊傾向于降低實時數(shù)據(jù)的要求，但這只是一種臨時的解決方案。

• 開發(fā)成本：由于Flink是一個具有增量狀態(tài)的狀態(tài)化數(shù)據(jù)流引擎，它要求開發(fā)者對底層架構(gòu)有更深入的了解，尤其是在多流JOIN操作中。增量狀態(tài)使其無法像Hive那樣將完整的數(shù)據(jù)狀態(tài)存儲到內(nèi)存。實時數(shù)據(jù)需要巨大的存儲容量，并且需要使用各種計算引擎（例如OLTP引擎MySQL，OLAP引擎ClickHouse和Apache Doris，以及KV存儲Abase、Tier和Redis）滿足不同的計算需求，這增加了開發(fā)的復(fù)雜性。增量狀態(tài)也使得測試更具挑戰(zhàn)性。
• 維護成本：復(fù)雜的多流JOIN操作通常需要存儲大量狀態(tài)數(shù)據(jù)，這可能導(dǎo)致穩(wěn)定性問題，特別是在處理連續(xù)的實時流時。TikTok的直播業(yè)務(wù)在不斷創(chuàng)新。當(dāng)數(shù)據(jù)模式發(fā)生變化時，直接部署可能因狀態(tài)結(jié)構(gòu)的改變而導(dǎo)致數(shù)據(jù)恢復(fù)失敗。
• 資源問題：在實時場景中，資源的低效利用是一個常見問題。例如，在銷售活動開始時，通常會有短暫的流量激增，但幾分鐘后流量會迅速下降。然而，為了確保整個活動期間的穩(wěn)定性，必須全天候維持高水平的資源，這導(dǎo)致了資源的浪費。

圖片

基于Flink的架構(gòu)在TikTok中已是一個成熟的解決方案。它主要用于成熟的業(yè)務(wù)應(yīng)用。在數(shù)據(jù)存儲方面，它利用Kafka提供的邏輯表格式。盡管缺乏字段、約束和高數(shù)據(jù)可追溯性，這種邏輯表方法仍支持了超過一半的實時數(shù)據(jù)開發(fā)。

新的架構(gòu)基于Apache Doris，結(jié)構(gòu)更簡單，類似于離線Hive設(shè)置。這種基于Doris的架構(gòu)的關(guān)鍵在于將亞秒級調(diào)度引擎與OLAP引擎相結(jié)合。這使得數(shù)據(jù)分層和重用離線開發(fā)成為可能。

2. OLAP引擎

為服務(wù)于TikTok的直播業(yè)務(wù)，OLAP引擎應(yīng)在以下方面表現(xiàn)良好。

• 跨站點災(zāi)難恢復(fù)：這為直播提供了穩(wěn)定性保證，以避免因服務(wù)不可用而導(dǎo)致的重大財務(wù)損失。
• 讀寫隔離：這是穩(wěn)定性的另一個保障。
• 跨集群ETL：數(shù)據(jù)分散在不同的集群中，用于不同的業(yè)務(wù)場景。例如，集群 B 和 C 都處理交易數(shù)據(jù)，這些數(shù)據(jù)應(yīng)該從集群 B 同步到 C，否則會導(dǎo)致跨業(yè)務(wù)線的數(shù)據(jù)倉庫重復(fù)建設(shè)，并對人力和資源造成負擔(dān)。

圖片

TikTok解決這些挑戰(zhàn)的方式如下。

• 跨站點災(zāi)難恢復(fù)：每個表都存儲了三個副本。這些副本分布在數(shù)據(jù)中心中，以確保每個站點的可用性。生產(chǎn)端的消息隊列經(jīng)過中間處理后到達消費端，形成了完整的數(shù)據(jù)服務(wù)鏈路。在單個數(shù)據(jù)中心中斷的情況下，生產(chǎn)和消費都有相應(yīng)的策略來確保服務(wù)效率和穩(wěn)定性。
• 讀寫隔離：讀寫流量被路由到不同的集群組。
• 跨集群 ETL：對于跨集群的讀寫，TikTok根據(jù)不同的業(yè)務(wù)需求和時間敏感性采用了兩種機制。一種是使用Spark將數(shù)據(jù)源格式讀入Yarn集群，然后同步到其他集群。另一種是利用Apache Doris的跨集群復(fù)制能力。Spark on Doris方法更穩(wěn)定，不消耗Doris的計算資源，而第二種方法更高效。

3. 實時排行榜

實時數(shù)據(jù)倉庫如何支持TikTok的直播業(yè)務(wù)？

它構(gòu)建了一個實時排行榜來監(jiān)測其直播業(yè)務(wù)的表現(xiàn)。如前所述，它從Flink 遷移到了Apache Doris，新方案對元數(shù)據(jù)有明確的定義。元數(shù)據(jù)從實時表中的字段解析而來并給出定義。定義元數(shù)據(jù)是對排行榜業(yè)務(wù)邏輯的抽象。這還涉及實時排行榜的分區(qū)邏輯定義。通過簡單的配置，可以快速創(chuàng)建相應(yīng)的Flink任務(wù)。

圖片

然而，對這種實時排行榜的需求激增，對Flink架構(gòu)帶來了幾方面的挑戰(zhàn)。首先，過多的排行榜導(dǎo)致任務(wù)激增，使得資源管理更困難，尤其是需要24/7運行的實時流處理。其次，來自實時任務(wù)的警報越來越頻繁。此外，大量任務(wù)共享同一消息隊列，增加了流量，給HDFS帶來了額外的負擔(dān)。此外，由于電商中的大型促銷活動往往持續(xù)較長時間，長周期計算對Flink的穩(wěn)定性構(gòu)成威脅，也使得回溯變得困難。為解決這些問題，維護人員通常需要在狀態(tài)相對較小、回溯壓力較輕的午夜進行操作。

與Flink的解決方案相比，基于Doris的數(shù)據(jù)倉庫消耗的資源更少，產(chǎn)生的警報也更少。此外，由于狀態(tài)存儲在Doris表中，長周期計算變得更加靈活。