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

1. TikTok的實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)

圖片

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

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

圖片

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

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

2. OLAP引擎

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

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

圖片

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

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

3. 實(shí)時(shí)排行榜

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

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

圖片

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

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