TikTok的主要收入來自直播和電商，這要求實時處理數據，比批處理更復雜，涉及多流連接和維度表更新，需要更多開發和維護資源，且為保障系統穩定，常導致資源浪費。本文邀請了TikTok數據平臺團隊分享他們如何利用Apache Doris構建實時數據架構，可作為高效實時數據倉庫的范例學習。

1. TikTok的實時數據倉庫

圖片

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

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

圖片

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

新的架構基于Apache Doris，結構更簡單，類似于離線Hive設置。這種基于Doris的架構的關鍵在于將亞秒級調度引擎與OLAP引擎相結合。這使得數據分層和重用離線開發成為可能。

2. OLAP引擎

為服務于TikTok的直播業務，OLAP引擎應在以下方面表現良好。

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

圖片

TikTok解決這些挑戰的方式如下。

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

3. 實時排行榜

實時數據倉庫如何支持TikTok的直播業務？

它構建了一個實時排行榜來監測其直播業務的表現。如前所述，它從Flink 遷移到了Apache Doris，新方案對元數據有明確的定義。元數據從實時表中的字段解析而來并給出定義。定義元數據是對排行榜業務邏輯的抽象。這還涉及實時排行榜的分區邏輯定義。通過簡單的配置，可以快速創建相應的Flink任務。

圖片

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

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