作為企業(yè)數(shù)字化建設(shè)的必備要素，易用的數(shù)據(jù)引擎能幫助企業(yè)提升數(shù)據(jù)使用效率，更好提升數(shù)據(jù)應(yīng)用價值，夯實數(shù)字化建設(shè)基礎(chǔ)。

數(shù)據(jù)導(dǎo)入是衡量OLAP引擎性能及易用性的重要標(biāo)準(zhǔn)之一，高效的數(shù)據(jù)導(dǎo)入能力能夠加速數(shù)據(jù)實時處理和分析的效率。作為一款OLAP引擎，火山引擎云原生數(shù)據(jù)倉庫ByteHouse源于開源ClickHouse，在字節(jié)跳動多年打磨下，提供更豐富的能力和更強(qiáng)性能，能為用戶帶來極速分析體驗，支撐實時數(shù)據(jù)分析和海量離線數(shù)據(jù)分析，具備便捷的彈性擴(kuò)縮容能力，極致的分析性能和豐富的企業(yè)級特性。

隨著ByteHouse內(nèi)外部用戶規(guī)模不斷擴(kuò)大， 越來越多用戶對數(shù)據(jù)導(dǎo)入提出更高的要求，這也為ByteHouse的數(shù)據(jù)導(dǎo)入能力帶來了更大的挑戰(zhàn)。

本篇文章來源于ByteHouse產(chǎn)品專家在火山引擎數(shù)智平臺（VeDI）主辦的“數(shù)智化轉(zhuǎn)型背景下的火山引擎大數(shù)據(jù)技術(shù)揭秘”線下Meeup的演講，將從ByteHouse數(shù)據(jù)庫架構(gòu)演進(jìn)、增強(qiáng)HaKafka引擎實現(xiàn)方案、增強(qiáng)Materialzed MySQL實現(xiàn)方案、案例實踐和未來展望四個部分展開分享。

ByteHouse數(shù)據(jù)庫的架構(gòu)演進(jìn)

作為一款分析型數(shù)據(jù)庫，ByteHouse已經(jīng)應(yīng)用在互聯(lián)網(wǎng)、金融、汽車領(lǐng)域，幫助企業(yè)實現(xiàn)人群洞察、行為分析、 IOT 風(fēng)控等場景的實時分析。

ByteHouse的演進(jìn)

• 從2017年開始，字節(jié)內(nèi)部的整體數(shù)據(jù)量不斷上漲，為了支撐實時分析的業(yè)務(wù)，字節(jié)內(nèi)部開始了對各種數(shù)據(jù)庫的選型。經(jīng)過多次實驗，在實時分析版塊，字節(jié)內(nèi)部決定開始試水ClickHouse。

• 2018年到2019年，字節(jié)內(nèi)部的ClickHouse業(yè)務(wù)從單一業(yè)務(wù)，逐步發(fā)展到了多個不同業(yè)務(wù)，適用到更多的場景，包括BI 分析、A/B測試、模型預(yù)估等。

• 在上述這些業(yè)務(wù)場景的不斷實踐之下，研發(fā)團(tuán)隊基于原生ClickHouse做了大量的優(yōu)化，同時又開發(fā)了非常多的特性。

• 2020年， ByteHouse正式在字節(jié)跳動內(nèi)部立項，2021年通過火山引擎對外服務(wù)。

• 截止2022年3月，ByteHouse在字節(jié)內(nèi)部總節(jié)點數(shù)達(dá)到18000個，而單一集群的最大規(guī)模是2400個節(jié)點。

ByteHouse的架構(gòu)

ByteHouse架構(gòu)分為分布式架構(gòu)和云原生架構(gòu)兩種。分布式架構(gòu)的主要特點就是單集群可以支持 2000 多個節(jié)點的“大兵團(tuán)”；通過分布式的并行計算體現(xiàn)的高性能，能夠充分利用每個節(jié)點的計算和存儲資源；云原生實現(xiàn)了存算分離，計算資源通過容器化進(jìn)行彈性和秒級的擴(kuò)容，這對業(yè)務(wù)是無感知的。

從分布式架構(gòu)來看，ByteHouse具備MPP 1.0特點：

• 存算一體：通過本地存儲能夠保證它極致的這種查詢性能。

• 自研的表引擎：包含 HaMergeTree和 HaUniqueMergeTree。

• 在社區(qū) RBO 優(yōu)化器的基礎(chǔ)上增強(qiáng) RBO 加 CBO 的結(jié)合的查詢優(yōu)化，并基于 CBO 的分布式計劃能夠在集群模式下計算全局最優(yōu)的查詢計劃。

• 支持?jǐn)?shù)據(jù)的冷熱分存，同時兼顧性能和成本。

• 增強(qiáng)關(guān)鍵的數(shù)據(jù)類型，從而優(yōu)化查詢性能。

• 通過統(tǒng)一的管控面提供可視化的管理查詢和運維，從內(nèi)到外給用戶提供優(yōu)質(zhì)的使用體驗。

但MPP 1.0存在資源隔離、擴(kuò)容等痛點，由此演進(jìn)到云原生架構(gòu)，即MPP 2.0：其中存算分離通過結(jié)合 shared-everything 存儲和 shared-nothing 計算層，避免了傳統(tǒng) MPP 架構(gòu)中數(shù)據(jù)重新分配 (re-sharding) 的問題。

好處在于：

• 更好地實現(xiàn)資源隔離。每個用戶不同的計算都提交到不同的計算組，并進(jìn)行計算資源和存儲資源的擴(kuò)容，再結(jié)合按量計費的計費策略可以降低用戶使用成本。

• 底層存儲既支持HDFS，也支持 S3 對象存儲，能夠讓 ByteHouse實現(xiàn)真正的云原生。

ByteHouse技術(shù)優(yōu)勢

在增強(qiáng)型數(shù)據(jù)導(dǎo)入場景中，ByteHouse核心優(yōu)勢體現(xiàn)在自研表引擎：

• 在社區(qū)版的基礎(chǔ)上，ByteHouse對表引擎做了進(jìn)一步增強(qiáng)，使其能夠?qū)崿F(xiàn)開源的ClickHouse所做不到的場景。

• 高可用引擎，相比社區(qū)高可用引擎，可以支持表的數(shù)量更多，集群的規(guī)模更大，穩(wěn)定性會更高。

• 實時數(shù)據(jù)引擎，相比社區(qū)實時數(shù)據(jù)引擎，消費能力更強(qiáng)，支持 at least once 的語義，排除單點寫入的性能故障。

• Unique引擎，相比社區(qū)Unique引擎，ByteHouse沒有更新延遲問題，能夠?qū)崿F(xiàn)真正實時的 upsert。

• Bitmap 引擎，在特定的場景比如用戶圈選圈群的場景中支持大量的交并補操作，能夠使整體的性能提升 10 - 50 倍以上。

這里具體再介紹一下ByteHouse自研引擎的優(yōu)勢——與導(dǎo)入密切相關(guān)的表引擎。

首先，ByteHouse 提供的HaMergeTree方案能夠降低 ZK 負(fù)載，提升可承載的數(shù)據(jù)量級。

• ClickHouse 社區(qū)版本： 社區(qū)提供的ReplicatedMergeTree表引擎讓 ClickHouse 實現(xiàn)了從單機(jī)到集群的演進(jìn)，通過ZK節(jié)點來同步并維護(hù)兩個MergeTree之間的元數(shù)據(jù)和數(shù)據(jù)。痛點在于，在 TB 級的數(shù)據(jù)量級之下， ZK 重復(fù)地進(jìn)行分發(fā)日志和數(shù)據(jù)交換等操作，極大地增加了ZK的壓力，使ZK 成為整個集群的故障點。

• ByteHouse 自研HaMergeTree： 將元數(shù)據(jù)的同步和數(shù)據(jù)的同步解耦，ZK只負(fù)責(zé)元數(shù)據(jù)的同步，而數(shù)據(jù)的同步是通過 LogExchange 來實現(xiàn)，在兩個MergeTree之間進(jìn)行對等拷貝。優(yōu)勢在于，降低了 ZK 的負(fù)載，即使是承載 PB 級的數(shù)據(jù)量，集群也能夠平穩(wěn)地運行。

其次， ByteHouse 提供的HaMergeTree方案能平衡讀寫性能。

• ClickHouse 社區(qū)版本： 提供ReplacingMerge Tree實現(xiàn)了對唯一鍵的支持；使用Merge-on-read的實現(xiàn)邏輯，在不同批次的數(shù)據(jù)中包含著相同的 key ，需要在讀時做合并，讓相同的 key 返回最新的版本。痛點在于，數(shù)據(jù)存在延遲、滯后，降低讀的性能。

• ByteHouse 自研的HaUniqueMergeTree： 引入了 delete bitmap 的組件在數(shù)據(jù)插入時即標(biāo)記刪除，然后在數(shù)據(jù)查詢時過濾掉標(biāo)記刪除的數(shù)據(jù)。優(yōu)勢在于，整體上平衡了讀和寫的性能，保障了讀取時性能一致性。

增強(qiáng)HaKafka引擎實現(xiàn)方案

HaKafka 引擎架構(gòu)介紹

社區(qū)版Kafka 優(yōu)勢 ： 由于社區(qū)版ClickHouse是一個分布式結(jié)構(gòu)，其數(shù)據(jù)分布在多個Shard上，Kafka引擎可以在多個Shard上去做并發(fā)的寫入，而在同一個Shard內(nèi)可以啟動多線程做并發(fā)寫入，并具備本地盤的極致的性能讀寫。

社區(qū)版 Kafka 不足 ：

• 在內(nèi)外部業(yè)務(wù)的場景中，會經(jīng)常遇到唯一鍵場景，由于社區(qū)版本的 Kafka的 high level 的消費模式（這種模式就決定無法預(yù)知數(shù)據(jù)被寫入到哪一個Shard上），所以很難滿足這一類場景。

• 社區(qū)版的 Kafka 引擎沒有高可用，即使ClickHouse是多副本的，在當(dāng)一個節(jié)點發(fā)生宕機(jī)時，無法保證另一個節(jié)點繼續(xù)消費。

HaKafka引擎架構(gòu)（分布式架構(gòu)）

保持社區(qū)版本兩級并發(fā)兩大的優(yōu)化點：

• 引入高可用，讓備節(jié)點處于 stand-by 的狀態(tài)，一旦主節(jié)點發(fā)生宕機(jī)，備節(jié)點立刻繼續(xù)進(jìn)行消費。

• 升級為low-level的消費模式，當(dāng)數(shù)據(jù)寫入的時候，相同的 key 會寫到相同的 partition 里面，保證在同一個Shard下支持的唯一鍵場景。

ByteHouse增強(qiáng)HaKafka引擎核心功能實現(xiàn)

• 高可用（主備切換）

在備節(jié)點上起一個 stand by的consumer ，通過 ZK 來進(jìn)行選組，選到的主節(jié)點進(jìn)行消費，當(dāng)主節(jié)點發(fā)生宕機(jī)或者無法進(jìn)行服務(wù)時，在秒級之內(nèi)切換到備節(jié)點上，讓備節(jié)點繼續(xù)消費。

假設(shè)現(xiàn)在 replica 1因為故障宕機(jī)了，無法繼續(xù)進(jìn)行消費，那么Z K能在秒級內(nèi)把 replica 2 選為leader。replica 2 隨即會立即啟動相同數(shù)量的消費者，啟動之后會繼續(xù)從 replica 1 的消費位置開始繼續(xù)進(jìn)行消費。

• 替換節(jié)點

隨著集群規(guī)模的增大，節(jié)點數(shù)越來越多的情況下，不可避免地遇到節(jié)點故障，這個時候就需要替換節(jié)點。

對于分布式架構(gòu)，替換節(jié)點一個重要的操作就是拷貝數(shù)據(jù)，在拷貝數(shù)據(jù)的時候意味著新的節(jié)點的數(shù)據(jù)是不全的，如圖示，示意圖 replica 1為新替換的節(jié)點，還處于數(shù)據(jù)拷貝的狀態(tài)，即數(shù)據(jù)是不全，如果此時實施消費的 leader 起在了 replica 1，就意味著 最新的消費數(shù)據(jù)會寫進(jìn) replica 1，但是它缺失一部分舊的數(shù)據(jù)。

而replica 2有舊的數(shù)據(jù)，它的最新數(shù)據(jù)還需要從replica 1進(jìn)行拷貝，那這個時候下載之內(nèi)沒有一個副本上面的數(shù)據(jù)是完整的，所有的節(jié)點就不可能對外提供服務(wù)。

這時HaKafka會做強(qiáng)制限制，如果 replica 1是一個新節(jié)點，且還在拷貝數(shù)據(jù)的狀態(tài)，那么就會強(qiáng)制把 leader 切換成 replica 2，由 replica 2 繼續(xù)去消費最新的數(shù)據(jù)，replica 1保持繼續(xù)拷貝數(shù)據(jù)，這樣可以保證在節(jié)點替換的過程中至少有一個副本是能夠正常提供服務(wù)。

• Memory table

不同于社區(qū)的Memory Table和底層存儲綁定，ByteHouse的Memory Table是和Hakafka綁定的，主要使用在有百列或者千列的大寬表的場景。

對于ClickHouse來說，每一次導(dǎo)入的寫的文件的數(shù)量和列數(shù)是成正比的。如果列很多，但是每批次寫入的數(shù)據(jù)量不大，這時每一次寫入就會造成很多的碎片，這對于 IO的消耗會比較高，寫入的性能其實也會比較差。

針對這種情況，考慮使用Memory Table，讓寫不直接落盤，每一次寫先寫到Memory Table中，攢到一定的批次或者到達(dá)一定的時間之后再一次性刷盤。

當(dāng)數(shù)據(jù)寫入Memory Table之后，就可以對外提供查詢服務(wù)了，因為 memory table 是跟 Kafka 綁定的，在同一個下的內(nèi)是唯一的。當(dāng)查詢來了之后，只需要路由到對應(yīng)的消費節(jié)點下 the Memory Table，就能保證了數(shù)據(jù)查詢的一致性。

• 云原生架構(gòu)增強(qiáng)

分布式架構(gòu)的痛點在于：

1.節(jié)點故障： 字節(jié)的集群規(guī)模較大，每周/每天會遇到節(jié)點故障的問題，需要進(jìn)行節(jié)點替換，是一個比較大的負(fù)擔(dān)。

2.讀寫沖突問題： 隨著集群的接入的業(yè)務(wù)越來越多，數(shù)據(jù)量越來越大的情況下，每一個節(jié)點同時承擔(dān)著查詢和寫入的操作，之間會有沖突。

3.擴(kuò)容成本： 唯一鍵的場景對數(shù)據(jù)分布要求非常嚴(yán)格，擴(kuò)容在這種場景下很難支持，因為擴(kuò)容之后partition的映射關(guān)系發(fā)生了變化。

云原生架構(gòu)優(yōu)點在于，存算分離、自動擴(kuò)容、自動容錯輕量級的擴(kuò)縮容等，因為云原生支持事物，讓我們可以將消費語義增強(qiáng)到exactly once。

• 在云原生架構(gòu)下的 Kafka 引擎是如何通過事務(wù)來實現(xiàn) exactly once：

  • 事務(wù)保證： 因為云原生架構(gòu)有事務(wù)的支持，所以每一輪的消費都需要有事物來保證。因為 Catalog 的元信息和 Catalog 元信息的交互是在 Server 端進(jìn)行的，所以第一步會通過 RPC 的請求向 Server 端請求創(chuàng)建消費事務(wù)，然后客戶端創(chuàng)建正常，創(chuàng)建消費事務(wù)之后會把 transaction ID 給consumer， consumer 拿到這種全聲音 ID 之后就可以開始正常地消費了。之后它就會從分配到的 partition 里面不停地消費數(shù)據(jù)，當(dāng)消費到足夠的數(shù)據(jù)量或者消費滿足一定的時間時，它就會把消費的這數(shù)據(jù)轉(zhuǎn)換為對應(yīng)的 part 文件并dump到存儲層。在 dump 之后，數(shù)據(jù)是不可見的，因為這個時候的 transaction 還沒有提交，所以在第五步的時候，還是會通過一個 RPC 的 call 把剛才 dump 的元信息消費的 offseed 提交到 catalog 中。這一步是一個原子性的提交，也是我們的消費語義升級從 at least once 到 exactly once 的一個核心關(guān)鍵點

  • 容錯保證： 因為manager 和它具體之間的任務(wù)是在不同的節(jié)點上的，所以需要有一定的這種容錯機(jī)制。當(dāng)前是讓 manager 和 task 之間保持一種一個雙向的心跳機(jī)制來保證，比如說manager每隔 10 秒鐘會去探活一次，看看當(dāng)前任務(wù)是否正常運行，如果沒有在正常運行，它就會重新拉起一個新的task。而對于 task 來說，它每一次的消費都會有兩次的 RPC call 和 Server 端做交互，這兩次的 RPC 交互都會向 manager 去校驗自身的有效性，如果校驗到自己當(dāng)前是一個失效的狀態(tài)，它就會把自己 kill 掉，從而保證整個全局的唯一任務(wù)的運行。

  • 

  • Memory Buffer ： 與社區(qū)相似，Memory Buffer和底層的存儲表綁定。因為都是寫入底表的，不僅Kafka的導(dǎo)入可以用，Flink的導(dǎo)入也可以用。memory buffer 的使用場景是高頻的小批量的導(dǎo)入場景，因為每一次導(dǎo)入都會寫一個part，不停地寫 part 會對集群產(chǎn)生壓力。而 ClickHouse 的話，對 ClickHouse 來說 part 越多性能越差，所以使用 memory buffer 來緩存小批量的數(shù)據(jù)，到達(dá)一定批次之后再進(jìn)行導(dǎo)入。首先需要有一個事務(wù)的保證，才能保證導(dǎo)入的完整性和一致性。另外它需要有WAL，因為首先把數(shù)據(jù)要先寫到 WAL 中，數(shù)據(jù)寫入到 WAL 中之后，就認(rèn)為導(dǎo)入成功了，因為 WAL 本身也是一個持久化的存儲，數(shù)據(jù)寫入 WAL 之后，再將數(shù)據(jù)寫入到 memory buffer。當(dāng)數(shù)據(jù)寫入了 memory buffer 之后就可以對外提供查詢服務(wù)。

增強(qiáng) Materialzed MySQL 實現(xiàn)方案

社區(qū)版 Materialzed MySQL 介紹

物化 MySQL 將MySQL的表映射到 ClickHouse 中， ClickHouse 服務(wù)會讀取binlog，并執(zhí)行 DDL 和 DML 的請求，實現(xiàn)了這種基于實現(xiàn)了基于 MySQL binlog 的實時 CDC 同步。它的架構(gòu)很簡單，不依賴于數(shù)據(jù)同步工具，使用自身的資源就能將整個 MySQL 的數(shù)據(jù)庫同步到 ClickHouse中，并且時效性很好，因為實時同步的延時一般在秒級、毫秒級到秒級之間。

社區(qū)版本的這種物化MySQL 在很大程度上去解決了 MySQL 數(shù)據(jù)庫到 ClickHouse 之間的這種實時同步。在實際業(yè)務(wù)、實際場景中，遇到不少問題：

1.社區(qū)版本的物化MySQL，它是不支持同步到分布式表，也不支持跳過DDL，缺乏這些功能就很難將數(shù)據(jù)庫的引擎應(yīng)用到實際生產(chǎn)中。

2.社區(qū)版本的物化 MySQL 不支持在數(shù)據(jù)同步發(fā)生異常時進(jìn)行輔助，發(fā)生異常的時候發(fā)起重新同步的命令，它沒有同步的日志信息和沒有同步的狀態(tài)信息，缺少了這些信息會導(dǎo)致同步發(fā)生異常的時候，很難在短期內(nèi)把這些任務(wù)重新啟動。

基于這些問題和痛點， ByteHouse在社區(qū)版本的物化 MySQL 的基礎(chǔ)之上做了一些功能增強(qiáng)易用性，降低了運維成本，讓數(shù)據(jù)的同步更加穩(wěn)定。

ByteHouse的物化 MySQL 結(jié)合了HaUniqueMergeTree表引擎：結(jié)合這樣的表引擎之后，它就能夠?qū)崿F(xiàn)數(shù)據(jù)的實時去重能力，同時它能夠支持分布式的能力，我們通過底層的中間的參數(shù)優(yōu)化，比如 include tables、 exclude tables、 SKIP DDL 等等能夠允許用戶自定義同步的表的同步范圍。

通過下 model 這樣的一個參數(shù)，能夠支持分布式表的同步，然后通過 Rethink 參數(shù)的設(shè)置支持將額外增加的表啟動獨立的數(shù)據(jù)同步任務(wù)去進(jìn)行 CDC 同步，在出現(xiàn)異常的時候，我們也支持跳過這種不支持的 DDL 語句。另外，可以通過系統(tǒng)日志的抓取和展示進(jìn)行可視化的運維。

ByteHouse增強(qiáng)Materialzed MySQL核心功能實現(xiàn)

• 實時去重 / 分布式

社區(qū)版的物化 MySQL 使用的是ReplacingMergeTree，每一個同步任務(wù)都會將源端的 MySQL 數(shù)據(jù)庫同步到 ClickHouse 的某一個節(jié)點上面，它不支持按照分片邏輯將數(shù)據(jù)分布到所有的節(jié)點，也無法利用 ClickHouse 整個集群的分布式計算和存儲能力，所ByteHouse的物化MySQL 支持分布式地同步利用。我們利用HaUniqueMergeTree表引擎，將每張表同步到對應(yīng)的分布式節(jié)點上，充分利用集群的這種分布式計算能力，同時通過表引擎的實時 upsert 能力來實現(xiàn)快速地去重。

• 異步 Resync

這里有三個對象， SYNC manager是用來管理主 SYNC 線程和 Resync 線程，然后 SYNC task 和 resync task 各自管理各自的任務(wù)。比如說一個 MySQL 的庫有 100 張表，我們選了 50 張表進(jìn)行同步，所以在同步進(jìn)行過程中，當(dāng) think task 同步到 binlog 的 position 位置，比如到 1000 的時候，用戶修改了配置之后，它增加了 30 張表。增加 30 張表的時候， SYNC manager 就會啟動 Resync task 去同步另外 30 張表，那這個時候 SYNC task 是繼續(xù)執(zhí)行的；RESYNC task 會從 position 0 開始，它先做全量的同步，然后再做增量的同步。所以當(dāng)?shù)竭_(dá)某一個階段，比如說 sync task 跑到了 position 1500 的時候， resync task 跑到了 position 1490 的時候，這時 SYNC manager 就會去判斷兩者的誤差，這個 position 的誤差在一定的閾值之內(nèi)，在一定閾值之內(nèi)之后，它會將 SYNC task 停止1秒鐘，將 RESYNC task 合并到 SYNC task 中。合并成功之后，這 80 張表就都會通過SYNC task 繼續(xù)同步，而 RESYNC task 這個任務(wù)就會被停止掉。這就是現(xiàn)在 RESYNC task 做了一個能力實現(xiàn)。

• 可視化運維

通過可視化的任務(wù)監(jiān)控和任務(wù)啟停異常的重啟任務(wù)告警這些方式實現(xiàn)了物化 MySQL 的可視化易用性的極大提升。

案例實踐與未來展望

案例一：短視頻直播

該場景下的數(shù)據(jù)是批流一體寫入，為了維護(hù)和管理抖音創(chuàng)作者的數(shù)據(jù)，并且面向這種業(yè)務(wù)運營和達(dá)人經(jīng)營提供數(shù)據(jù)查詢服務(wù)，需要將短視頻和直播的實時數(shù)據(jù)和離線數(shù)據(jù)做融合，來構(gòu)建 B端的數(shù)據(jù)分析。

• 問題： 首先，創(chuàng)作者是唯一的，需要我們進(jìn)行數(shù)據(jù)去重。第二，數(shù)據(jù)源是比較多樣化的，所以它整個字段超過 4000 ＋，是典型的大寬表場景。第三，T+1的數(shù)據(jù)，T+1數(shù)據(jù)離線同步后，T+0數(shù)據(jù)要對它進(jìn)行更新。第四，是對任何指標(biāo)的實時查詢需要秒級出結(jié)果，這是業(yè)務(wù)面臨的問題。

• 解決方案： 第一，我們采用了自研的 Unique表引擎來做實時的去重，并且能夠讓數(shù)據(jù)在寫入時就可以實時去重、實時查詢。第二，通過 Kafka 引擎的 memory table 來實現(xiàn)大寬表數(shù)據(jù)先緩存，到達(dá)了一定的批次之后再集中刷盤。通過對 Byte house 的優(yōu)化方案有效地解決了碎片化、IO負(fù)載高的問題，能夠支持 10 億＋創(chuàng)作數(shù)據(jù)實時寫入和實時查詢。

案例二：營銷實時數(shù)據(jù)的監(jiān)控

營銷實時監(jiān)控是對業(yè)務(wù)營銷活動效果的實時查詢和實時回收，希望通過這種實時回收來動態(tài)調(diào)整獎品的實時發(fā)放策略來做到最終的 IOR、ROI 的提升。這就要求數(shù)據(jù)實時寫入、落盤延時要非常低，對數(shù)據(jù)處理的性能也有很高的要求。在數(shù)據(jù)傳送上面需要保證數(shù)據(jù)傳輸?shù)奈ㄒ恍?#xff0c;以保證獎品不會重復(fù)發(fā)放，也不會丟失。

• 解決方案： 我們在方案上首先采用自研的Kafka 引擎來支持流式數(shù)據(jù)的實時寫入，實時寫入便實時入庫。通過 low-level 的這種消費來保證數(shù)據(jù)的有序分片，再通過增強(qiáng)的消費語義 exactly once 保證數(shù)據(jù)的精準(zhǔn)一次傳輸。最后我們通過自研的Unique引擎來實現(xiàn)實時的這種 upsert 的語義，讓數(shù)據(jù)實時寫入、實時去重。通過 ByteHouse 方案的優(yōu)化，營銷業(yè)務(wù)的每一個節(jié)點的實時性能達(dá)到了 30 MB/s/node，分析性能也是在秒級的延時，讓運營人員能根據(jù)不同用戶群，實時發(fā)放獎勵，并秒級地監(jiān)控獎品發(fā)放的進(jìn)展，從而調(diào)整獎品的發(fā)放策略。

案例三：游戲廣告的數(shù)據(jù)分析

游戲廣告數(shù)據(jù)分析是在廣告業(yè)務(wù)中會做一些人群圈選、廣告投放、效果反饋等投放策略，用戶行為預(yù)測這些全流程的統(tǒng)計和監(jiān)控來實現(xiàn)廣告營銷過程的數(shù)字化，提升整個廣告游戲投放的 ROI 。

• 問題： 業(yè)務(wù)數(shù)據(jù)和日志數(shù)據(jù)要求實時寫入、實時去重，由于體量比較大，所以寫入壓力和查詢壓力都比較大。

• 解決方案： 首先使用 Kafka 引擎來支持流式數(shù)據(jù)寫入，通過 low level 消費模式保障數(shù)據(jù)的有序分片，再通過 Unique引擎來實現(xiàn)數(shù)據(jù)的唯一性，并且實時地去重。在業(yè)務(wù)數(shù)據(jù)方面，我們使用物化MySQL來保障業(yè)務(wù)數(shù)據(jù)從 MySQL 到 ByteHouse 之間能夠?qū)崟r同步。最后使用自研的查詢優(yōu)化器來優(yōu)化查詢性能，通過ByteHouse 的優(yōu)化之后，廣告效果分析從原來的小時級提升到了現(xiàn)在的秒級延時數(shù)據(jù)查詢的性能，單線程同步 20+MB/s ，并且整個查詢性能提升了 3 倍，用戶的收益和體驗得到了明顯的改善。

未來戰(zhàn)略：全鏈路和一體化

• 端到端。從語法轉(zhuǎn)換、數(shù)據(jù)遷移，到數(shù)據(jù)校驗，形成完整的全鏈路方案。

• 一體化。通過DES的邏輯復(fù)制能力實現(xiàn) TP / AP 的一體化，同時實現(xiàn)數(shù)據(jù)倉庫和數(shù)據(jù)集市的一體化。

• 資源隔離。支持用戶使用共享資源池或者數(shù)據(jù)庫引擎來進(jìn)行數(shù)據(jù)的同步，也支持用戶通過獨享的資源池來進(jìn)行高效數(shù)據(jù)同步。

• 多引擎方案。除了基于 ClickHouse 引擎的基礎(chǔ)能力，我們也會去探索更多的底層引擎能力來增強(qiáng)ByteHouse的數(shù)據(jù)同步。