[[377991]]

圖片來(lái)自 Pexels 

eBay 廣告數(shù)據(jù)平臺(tái)為 eBay 第一方廣告主(使用 Promoted Listing 服務(wù)的賣(mài)家)提供了廣告流量、用戶(hù)行為和效果數(shù)據(jù)分析功能。

廣告賣(mài)家通過(guò)賣(mài)家中心(Seller Hub)的營(yíng)銷(xiāo)標(biāo)簽頁(yè)、效果標(biāo)簽頁(yè)和公開(kāi)API，有效掌控和對(duì)比店鋪的營(yíng)銷(xiāo)活動(dòng)和推廣商品的流量、銷(xiāo)量的實(shí)時(shí)和歷史數(shù)據(jù)，并通過(guò)網(wǎng)頁(yè)或者 API 下載數(shù)據(jù)分析報(bào)告。

這一系統(tǒng)上線(xiàn)之初使用了自研的分布式 SQL 引擎，構(gòu)建在對(duì)象存儲(chǔ)系統(tǒng)之上。3 年前隨著廣告流量增加，我們把數(shù)據(jù)引擎切換到 Druid 上。

這一平臺(tái)的主要挑戰(zhàn)如下：

• 數(shù)據(jù)量大：每日的插入數(shù)據(jù)記錄有數(shù)百億條，每秒的插入峰值接近一百萬(wàn)條。
• 離線(xiàn)數(shù)據(jù)攝入：在不影響實(shí)時(shí)數(shù)據(jù)攝入的情況下，每天需要對(duì)前 1-2 天的數(shù)據(jù)進(jìn)行在線(xiàn)替換。

根據(jù)上游數(shù)據(jù)團(tuán)隊(duì)發(fā)布清洗過(guò)的每日數(shù)據(jù)，廣告數(shù)據(jù)平臺(tái)需要在不影響查詢(xún)的情況下每日替換實(shí)時(shí)數(shù)據(jù)，數(shù)據(jù)切換要求實(shí)現(xiàn)跨節(jié)點(diǎn)的全局原子操作。

• 完整性和一致性：面向賣(mài)家的財(cái)務(wù)數(shù)據(jù)，離線(xiàn)更新后的數(shù)據(jù)要求不能有遺漏和重復(fù);實(shí)時(shí)數(shù)據(jù)要求端對(duì)端的延遲在十秒內(nèi)。

Druid vs ClickHouse

Druid 于 2011 年由 Metamarkets 開(kāi)發(fā)，是一款高性能列式在線(xiàn)分析和存儲(chǔ)引擎。它于 2012 年開(kāi)源，2015 年成為 Apache 基金會(huì)旗下項(xiàng)目。

Druid 在業(yè)界使用廣泛，為千億級(jí)數(shù)據(jù)提供亞秒級(jí)的查詢(xún)延遲，擅長(zhǎng)高可用、水平擴(kuò)展。

另外為數(shù)據(jù)攝入提供了很多非常方便的聚合、轉(zhuǎn)換模版，內(nèi)建支持多種數(shù)據(jù)源，最快可以在幾十分鐘內(nèi)配置好新的數(shù)據(jù)表，包括數(shù)據(jù)定義和數(shù)據(jù)攝入鏈路(Lambda 架構(gòu))，大大提高了開(kāi)發(fā)效率。

ClickHouse 由俄羅斯最大的搜索引擎公司 Yandex 研發(fā)，設(shè)計(jì)目標(biāo)是支持 Yandex.Metrica(世界第二大 Web 分析平臺(tái))生成用戶(hù)分析報(bào)表等核心功能。

ClickHouse 是一個(gè)數(shù)據(jù)庫(kù)管理系統(tǒng)(DBMS)，有數(shù)據(jù)庫(kù)、表、視圖、DDL、DML 等概念，并提供了較為完整的 SQL 支持。

其核心特性有如下幾點(diǎn)：

• 高效的數(shù)據(jù)存儲(chǔ)：通過(guò)數(shù)據(jù)壓縮和列式存儲(chǔ)，可以達(dá)到最高 10 倍的數(shù)據(jù)壓縮率。
• 高效的數(shù)據(jù)查詢(xún)：通過(guò)主鍵索引、向量化引擎處理、多處理器并發(fā)和分布式查詢(xún)，最大壓榨 CPU 的所有能力，在中小規(guī)模的數(shù)據(jù)量上尤為突出。
• 靈活的數(shù)據(jù)定義和接入：通過(guò)支持 SQL 語(yǔ)言、JDBC 和關(guān)系模型，降低學(xué)習(xí)和遷移成本，可以和其他現(xiàn)有數(shù)據(jù)的產(chǎn)品無(wú)縫集成。

為什么遷移?

運(yùn)維

Druid 雖然提供了很多非常方便的數(shù)據(jù)攝入功能，但它的組件構(gòu)成也較為復(fù)雜，節(jié)點(diǎn)類(lèi)型有 6 種(Overload，Coordinator，Middle Manager，Indexer，Broker 和 Historical)。

除了自身的節(jié)點(diǎn)，Druid 還依賴(lài)于 MySQL 存儲(chǔ)元數(shù)據(jù)信息、Zookeeper 選舉 Coordinator 和 Overlord、HDFS 備份歷史數(shù)據(jù)。

ClickHouse 的架構(gòu)采用了對(duì)等節(jié)點(diǎn)的設(shè)計(jì)，節(jié)點(diǎn)只有一種類(lèi)型，沒(méi)有主從節(jié)點(diǎn)。如果使用了副本功能，則依賴(lài)于 Zookeeper 保存數(shù)據(jù)段的同步進(jìn)度。

與此同時(shí)，eBay 的基礎(chǔ)架構(gòu)團(tuán)隊(duì)提出在定制 ClickHouse 的基礎(chǔ)上，向產(chǎn)品團(tuán)隊(duì)提供列式數(shù)據(jù)庫(kù)存儲(chǔ)的服務(wù)。

除了運(yùn)維和生命周期管理，基礎(chǔ)架構(gòu)團(tuán)隊(duì)對(duì) ClickHouse 進(jìn)行改造和二次開(kāi)發(fā)，進(jìn)一步提高了數(shù)據(jù)攝入和存儲(chǔ)的效率，并在離線(xiàn)攝入方面彌補(bǔ)了和 Druid 的功能差距。

延時(shí)數(shù)據(jù)插入

Druid 通過(guò)引入實(shí)時(shí)數(shù)據(jù)的索引任務(wù)，把實(shí)時(shí)數(shù)據(jù)處理成一個(gè)個(gè)分段數(shù)據(jù)(segment)，并歸檔成歷史數(shù)據(jù)。成為分段數(shù)據(jù)之后，該時(shí)段數(shù)據(jù)即不可寫(xiě)入。

由于并發(fā)實(shí)時(shí)索引任務(wù)數(shù)的限制，我們?cè)O(shè)置了 3 個(gè)小時(shí)的窗口長(zhǎng)度(每個(gè)小時(shí)一個(gè)任務(wù))，因此超過(guò) 3 個(gè)小時(shí)的數(shù)據(jù)就無(wú)法寫(xiě)入。

在某些極端情況下，例如上游數(shù)據(jù)延遲或者實(shí)時(shí)數(shù)據(jù)消費(fèi)過(guò)于滯后，就會(huì)導(dǎo)致離線(xiàn)數(shù)據(jù)替換前這部分?jǐn)?shù)據(jù)的缺失。ClickHouse 則沒(méi)有這個(gè)限制，任意分區(qū)都可以隨時(shí)寫(xiě)入。

主鍵優(yōu)化

ClickHouse 支持的主鍵并不是傳統(tǒng)意義下關(guān)系型數(shù)據(jù)庫(kù)的主鍵。傳統(tǒng)的主鍵要求每條表記錄都有唯一的鍵值，通過(guò)查詢(xún)主鍵可以唯一地查詢(xún)到一條表記錄。

而在 ClickHouse 中，主鍵定義了記錄在存儲(chǔ)中排序的順序，允許重復(fù)，所以稱(chēng)之為排序鍵似乎更加合理。

事實(shí)上在 ClickHouse 里的主鍵定義通過(guò) ORDER BY 聲明，僅在個(gè)別場(chǎng)景中允許和排序鍵不一致(但必須是排序鍵的前綴)。

由于我們的產(chǎn)品是給賣(mài)家提供分析功能，幾乎所有的查詢(xún)限定在了單一賣(mài)家維度，因此通過(guò)主鍵按照賣(mài)家排序，可以極大地提高查詢(xún)效率以及數(shù)據(jù)壓縮率。

系統(tǒng)架構(gòu)

 

圖 1

如圖 1 所示，系統(tǒng)由 4 個(gè)部分組成：

• 實(shí)時(shí)數(shù)據(jù)獲取模塊，接入 eBay 的行為和交易實(shí)時(shí)消息平臺(tái)。
• 離線(xiàn)數(shù)據(jù)替換模塊，接入 eBay 內(nèi)部的數(shù)據(jù)倉(cāng)庫(kù)平臺(tái)。
• ClickHouse 部署和外圍數(shù)據(jù)服務(wù)。
• 報(bào)表服務(wù)，支撐廣告主、商家后臺(tái)和 eBay 公開(kāi) API。

實(shí)戰(zhàn)經(jīng)歷

Schema 設(shè)計(jì)

ClickHouse 提供了豐富的 Schema 配置。這方面需要根據(jù)業(yè)務(wù)場(chǎng)景和數(shù)據(jù)模式反復(fù)斟酌和多次試驗(yàn)，因?yàn)椴煌倪x擇會(huì)對(duì)存儲(chǔ)和性能有數(shù)量級(jí)的影響，一個(gè)錯(cuò)誤的選擇會(huì)導(dǎo)致后期巨大的調(diào)優(yōu)和變更成本。

①表引擎

ClickHouse 的存儲(chǔ)引擎的核心是合并樹(shù)(MergeTree)，以此為基礎(chǔ)衍生出：

• 匯總合并樹(shù)(SummingMergeTree)
• 聚合合并樹(shù)(AggregationMergeTree)
• 版本折疊樹(shù)(VersionCollapsingTree)等常用的表引擎

另外上述所有的合并樹(shù)引擎都有復(fù)制功能(ReplicatedXXXMergeTree)的對(duì)應(yīng)版本。

我們的廣告數(shù)據(jù)平臺(tái)的展示和點(diǎn)擊數(shù)據(jù)選擇了復(fù)制匯總合并樹(shù)。這兩類(lèi)用戶(hù)行為數(shù)據(jù)量極大，減小數(shù)據(jù)量節(jié)省存儲(chǔ)開(kāi)銷(xiāo)并提升查詢(xún)效率是模式設(shè)計(jì)的主要目標(biāo)。

ClickHouse 在后臺(tái)按照給定的維度匯總數(shù)據(jù)，降低了 60% 的數(shù)據(jù)量。

銷(xiāo)售數(shù)據(jù)選擇了普通的復(fù)制合并樹(shù)，一方面由于銷(xiāo)售數(shù)據(jù)對(duì)某些指標(biāo)有除匯總以外的聚合需求，另一方面由于本身數(shù)據(jù)量不大，合并數(shù)據(jù)的需求并不迫切。

②主鍵

一般情況下，ClickHouse 表的主鍵(Primary Key)和排序鍵(Order By Key)相同，但是采用了匯總合并樹(shù)引擎(SummingMergeTree)的表可以單獨(dú)指定主鍵。

把一些不需要排序或者索引功能的維度字段從主鍵里排除出去，可以減小主鍵的大小(主鍵運(yùn)行時(shí)需要全部加載到內(nèi)存中)，提高查詢(xún)效率。

③壓縮

ClickHouse支持列級(jí)別的數(shù)據(jù)壓縮，顯著地減少原始數(shù)據(jù)的存儲(chǔ)量，這也是列存儲(chǔ)引擎的巨大優(yōu)勢(shì)。查詢(xún)階段，較小的存儲(chǔ)占用也可以減少 IO 量。

對(duì)不同列選擇一種合適的壓縮算法和等級(jí)，能把壓縮和查詢(xún)的平衡做到性?xún)r(jià)比最優(yōu)。

ClickHouse 的所有列默認(rèn)使用 LZ4 壓縮。除此以外，一般的數(shù)據(jù)列可以選擇更高壓縮率的算法如 LZ4HC，ZSTD。

而對(duì)于類(lèi)似時(shí)間序列的單調(diào)增長(zhǎng)數(shù)據(jù)可以選擇 DoubleDelta，Gorilla 等特殊壓縮算法。

LZ4HC 和 ZSTD 等高壓縮率的算法還可以自己選擇壓縮級(jí)別。在我們的生產(chǎn)數(shù)據(jù)集上，ZSTD 算法對(duì) String 類(lèi)型字段壓縮效果較為顯著。LZ4HC 是 LZ4 的高壓縮比改進(jìn)版，更適用于非字符串類(lèi)型。

更高的壓縮率意味著更少的存儲(chǔ)空間，同時(shí)由于降低了查詢(xún)的 IO 量，可以間接提升查詢(xún)性能。

不過(guò) CPU 也不是大風(fēng)刮來(lái)的，數(shù)據(jù)的插入性能就成了犧牲品。根據(jù)我們內(nèi)部測(cè)試的數(shù)據(jù)，在我們的生產(chǎn)數(shù)據(jù)集上使用 LZ4HC(6) 相比 LZ4 可以節(jié)省 30% 的數(shù)據(jù)，但實(shí)時(shí)數(shù)據(jù)攝取性能下降了 60%。

④低基

值得一提的是，對(duì)于基數(shù)較低的列(即列值多樣性低)，可以使用 LowCardinality 來(lái)降低原始存儲(chǔ)空間(從而降低最終存儲(chǔ)空間)。

如果在使用壓縮算法的情況下對(duì)一字符串類(lèi)型的列使用 LowCardinality，還能再縮小 25% 的空間量。

在我們的測(cè)試數(shù)據(jù)集上，如果整表組合使用 LowCardinality、LZ4HC(6) 和 ZSTD(15)，整體壓縮比大約在原來(lái)的 13% 左右。

離線(xiàn)數(shù)據(jù)替換

①挑戰(zhàn)

針對(duì)廣告主的數(shù)據(jù)報(bào)表要求數(shù)據(jù)準(zhǔn)確、一致。實(shí)時(shí)的行為數(shù)據(jù)存在少量的 bot 數(shù)據(jù)(需要離線(xiàn)清除)，另外廣告的歸因也需要在離線(xiàn)階段重新調(diào)整。

因此我們引入了離線(xiàn)數(shù)據(jù)鏈路，在實(shí)時(shí)數(shù)據(jù)寫(xiě)入 24-72 小時(shí)之后，用離線(xiàn)數(shù)據(jù)替換實(shí)時(shí)數(shù)據(jù)。

其中的挑戰(zhàn)如下：

• 廣告系統(tǒng)每天需要處理的用戶(hù)離線(xiàn)數(shù)據(jù)量近 1TB，在此之前，需要耗費(fèi)大量時(shí)間將數(shù)據(jù)從 Hadoop 導(dǎo)入 Druid。

另外，導(dǎo)入期間的 I/O、CPU 和內(nèi)存的開(kāi)銷(xiāo)對(duì)查詢(xún)的壓力不小。如何在保證數(shù)據(jù)一致性的同時(shí)，亦確保數(shù)據(jù)遷移的效率，是問(wèn)題的關(guān)鍵。

• 如何在數(shù)據(jù)替換期間，確保用戶(hù)可見(jiàn)的數(shù)據(jù)波動(dòng)最小。這就要求數(shù)據(jù)替換操作是原子性的，或者至少對(duì)每個(gè)廣告主都是原子的。
• 除了日常的離線(xiàn)數(shù)據(jù)更新，在數(shù)據(jù)倉(cāng)庫(kù)數(shù)據(jù)出現(xiàn)偏差遺漏時(shí)，需要支持大范圍的數(shù)據(jù)修正和補(bǔ)償。

作業(yè)調(diào)度要求保證日常工作及時(shí)完成，并盡快完成數(shù)據(jù)修正工作。此外還需要監(jiān)控?cái)?shù)據(jù)更新中的各種指標(biāo)，以應(yīng)對(duì)各種突發(fā)狀況。

Druid 原生支持?jǐn)?shù)據(jù)離線(xiàn)更新服務(wù)，我們與基礎(chǔ)架構(gòu)團(tuán)隊(duì)合作，在 ClickHouse 平臺(tái)實(shí)現(xiàn)了這一功能。

②數(shù)據(jù)架構(gòu)

對(duì)于整合在線(xiàn)數(shù)據(jù)和離線(xiàn)數(shù)據(jù)的大數(shù)據(jù)架構(gòu)，業(yè)界通常的做法是 Lambda 架構(gòu)。即離線(xiàn)層和在線(xiàn)層分別導(dǎo)入數(shù)據(jù)，在展示層進(jìn)行數(shù)據(jù)的合并。

我們也大致上采用了這一架構(gòu)。但具體的做法和經(jīng)典有所不同。

ClickHouse 里數(shù)據(jù)分區(qū)(partition)是一個(gè)獨(dú)立的數(shù)據(jù)存儲(chǔ)單元，每一個(gè)分區(qū)都可以單獨(dú)從現(xiàn)有表里脫離(detach)、引入(attach)和替換(replace)。

分區(qū)的條件可以自定義，一般按照時(shí)間劃分。通過(guò)對(duì)數(shù)據(jù)表內(nèi)數(shù)據(jù)分區(qū)的單個(gè)替換，我們可以做到查詢(xún)層對(duì)底層數(shù)據(jù)更新的透明，也不需要額外的邏輯進(jìn)行數(shù)據(jù)合并。

③Spark 聚合與分片

為了降低 ClickHouse 導(dǎo)入離線(xiàn)數(shù)據(jù)性能壓力，我們引入了 Spark 任務(wù)對(duì)原始離線(xiàn)數(shù)據(jù)進(jìn)行聚合和分片。每個(gè)分片可以分別拉取并導(dǎo)入數(shù)據(jù)文件，節(jié)省了數(shù)據(jù)路由、聚合的開(kāi)銷(xiāo)。

④數(shù)據(jù)更新任務(wù)管理

鎖定分區(qū)拓?fù)浣Y(jié)構(gòu)：在處理數(shù)據(jù)前，離線(xiàn)數(shù)據(jù)更新系統(tǒng)向基礎(chǔ)架構(gòu)團(tuán)隊(duì)提供的服務(wù)請(qǐng)求鎖定 ClickHouse 的分區(qū)拓?fù)浣Y(jié)構(gòu)，在此期間該分區(qū)的拓?fù)浣Y(jié)構(gòu)不會(huì)改變。

服務(wù)端根據(jù)預(yù)先定義好的數(shù)據(jù)表結(jié)構(gòu)與分區(qū)信息返回?cái)?shù)據(jù)的分片邏輯與分片 ID。

離線(xiàn)數(shù)據(jù)更新系統(tǒng)根據(jù)拓?fù)湫畔⑻峤?Spark 任務(wù)。多張表的數(shù)據(jù)處理通過(guò) Spark 并行完成，顯著提升了數(shù)據(jù)更新的速度。

數(shù)據(jù)聚合與分片：對(duì)于每一張需要更新的表，啟動(dòng)一個(gè) Spark 任務(wù)對(duì)數(shù)據(jù)進(jìn)行聚合與分片。

根據(jù) ClickHouse 服務(wù)端返回的表結(jié)構(gòu)與分片拓?fù)鋵?shù)據(jù)寫(xiě)入 Hadoop，同時(shí)輸出數(shù)據(jù)替換階段用于校驗(yàn)一致性的 checksum 與分片行數(shù)。

系統(tǒng)通過(guò) Livy Server API 提交并輪詢(xún)?nèi)蝿?wù)狀態(tài)，在有任務(wù)失敗的情況下進(jìn)行重試，以排除 Spark 集群資源不足導(dǎo)致的任務(wù)失敗。

離線(xiàn)數(shù)據(jù)更新不但要滿(mǎn)足每天的批量數(shù)據(jù)更新需求，還需要支持過(guò)往數(shù)據(jù)的再次更新，以便同步上游數(shù)據(jù)在日常定時(shí)任務(wù)更新之外的數(shù)據(jù)變動(dòng)。

我們利用平臺(tái)團(tuán)隊(duì)封裝的 Spring Batch 管理更新任務(wù)，按照日期將每天的數(shù)據(jù)劃分為一個(gè)子任務(wù)。

通過(guò) Spring Batch 實(shí)現(xiàn)的 Continuously Job 保證在同一時(shí)刻子任務(wù)在運(yùn)行的唯一性，避免產(chǎn)生任務(wù)競(jìng)爭(zhēng)問(wèn)題。

對(duì)于過(guò)往數(shù)據(jù)的更新，我們將 Batch 任務(wù)分類(lèi)，除了日常任務(wù)之外，還可以手動(dòng)觸發(fā)給定時(shí)間范圍內(nèi)的數(shù)據(jù)修正任務(wù)(如圖 2)。

 

圖 2

數(shù)據(jù)替換：在子任務(wù)中的所有 Spark Job 完成后，離線(xiàn)數(shù)據(jù)更新系統(tǒng)會(huì)調(diào)用基礎(chǔ)架構(gòu)團(tuán)隊(duì)提供的數(shù)據(jù)替換接口，發(fā)起數(shù)據(jù)替換請(qǐng)求。

服務(wù)端按照定義好的分區(qū)，將數(shù)據(jù)從 Hadoop 直接寫(xiě)入 ClickHouse，如圖 3 所示。

 

圖 3

離線(xiàn)數(shù)據(jù)更新系統(tǒng)的架構(gòu)如圖 4 所示：

 

圖 4

MySQL 數(shù)據(jù)庫(kù)用于記錄數(shù)據(jù)替換過(guò)程中任務(wù)的狀態(tài)與優(yōu)先級(jí)，當(dāng) Spark Job 失敗或者由于其他原因?qū)е绿鎿Q任務(wù)失敗重啟后，恢復(fù)任務(wù)的進(jìn)度。

⑤原子性與一致性

為了保證數(shù)據(jù)替換的原子性，基礎(chǔ)架構(gòu)團(tuán)隊(duì)提供了分區(qū)替換的方式。在離線(xiàn)數(shù)據(jù)導(dǎo)入的過(guò)程中，首先創(chuàng)建目標(biāo)分區(qū)的臨時(shí)分區(qū)。當(dāng)數(shù)據(jù)替換完畢并且校驗(yàn)完成之后，目標(biāo)分區(qū)會(huì)被臨時(shí)分區(qū)替換。

針對(duì)不同機(jī)器上不同分片的原子性替換問(wèn)題，基礎(chǔ)架構(gòu)團(tuán)隊(duì)為每一條數(shù)據(jù)引入了數(shù)據(jù)版本。

對(duì)于每一個(gè)數(shù)據(jù)分區(qū)，都有對(duì)應(yīng)的活躍版本號(hào)。直到待替換數(shù)據(jù)分區(qū)的所有分片都成功導(dǎo)入之后，分區(qū)的版本號(hào)進(jìn)行更新。

上游應(yīng)用的同一條 SQL 只能讀取同一分區(qū)一個(gè)版本的數(shù)據(jù)，每個(gè)分區(qū)的數(shù)據(jù)替換只感覺(jué)到一次切換，并不會(huì)出現(xiàn)同時(shí)讀取新舊數(shù)據(jù)的問(wèn)題。

廣告平臺(tái)報(bào)表生成應(yīng)用因此在 SQL 層面引入了相應(yīng)的修改，通過(guò)引入固定的 WITH 和 PREWHERE 語(yǔ)句，在字典中查詢(xún)出每個(gè)數(shù)據(jù)分區(qū)對(duì)應(yīng)的版本號(hào)，并在查詢(xún)計(jì)劃中排除掉不需要的數(shù)據(jù)分區(qū)。

為了確保數(shù)據(jù)替換的一致性，在完成 Spark 數(shù)據(jù)處理之后，離線(xiàn)數(shù)據(jù)更新系統(tǒng)會(huì)計(jì)算各數(shù)據(jù)分片的校驗(yàn)碼與數(shù)據(jù)總量。

當(dāng)替換完畢之后，ClickHouse 服務(wù)端會(huì)對(duì)分片數(shù)據(jù)進(jìn)行校驗(yàn)，確保在數(shù)據(jù)搬遷過(guò)程中沒(méi)有數(shù)據(jù)丟失和重復(fù)。

數(shù)據(jù)查詢(xún)

ClickHouse 支持 SQL 查詢(xún)(不完全)，有 HTTP 和 TCP 兩種連接方式，官方和第三方的查詢(xún)工具和庫(kù)豐富。

用戶(hù)可以使用命令行，JDBC 或者可視化工具快速進(jìn)行數(shù)據(jù)查詢(xún)的開(kāi)發(fā)和調(diào)試。

ClickHouse 通過(guò) MPP(Massively Parallel Processing)+SMP(Symmetric Multiprocessing)充分地利用機(jī)器資源，單條查詢(xún)語(yǔ)句默認(rèn)使用機(jī)器核數(shù)一半的 CPU。

因此 ClickHouse 不支持高并發(fā)的應(yīng)用場(chǎng)景。在業(yè)務(wù)使用層面，最核心的問(wèn)題是查詢(xún)校驗(yàn)和并發(fā)控制，單條過(guò)大的查詢(xún)或者過(guò)高的并發(fā)都會(huì)導(dǎo)致集群資源使用率過(guò)高，影響集群穩(wěn)定性。

應(yīng)用架構(gòu)

eBay Seller Hub 通過(guò) Reports Service 接入 ClickHouse 查詢(xún)，Reports Service 提供了 Public 和 Internal 兩套 API。

Internal API 提供給 Seller Hub 以及其他內(nèi)部的已知應(yīng)用使用，Public API 在 eBay Developers Program 開(kāi)放給第三方開(kāi)發(fā)者，詳情見(jiàn)：

https://developer.ebay.com/ 

 

圖 5

Internal API 的查詢(xún)直接提交內(nèi)部線(xiàn)程池執(zhí)行，線(xiàn)程池的大小根據(jù) ClickHouse 的集群機(jī)器數(shù)量設(shè)置。查詢(xún)請(qǐng)求執(zhí)行前會(huì)進(jìn)行校驗(yàn)，過(guò)濾所有非法以及資源不可預(yù)估的請(qǐng)求。

Public API 通過(guò)任務(wù)提交的方式異步執(zhí)行查詢(xún)，用戶(hù)提交的查詢(xún)?nèi)蝿?wù)存入 DB 中，Service 內(nèi)部的 Schedule 定時(shí)掃表，根據(jù)任務(wù)的狀態(tài)串行執(zhí)行查詢(xún)?nèi)蝿?wù)。

執(zhí)行成功的任務(wù)上傳生成 Report 到文件服務(wù)器，用戶(hù)拿到 URL 后自行下載。執(zhí)行失敗的任務(wù)，根據(jù)錯(cuò)誤類(lèi)型(非法的請(qǐng)求，資源不足等)來(lái)選擇是否在下一個(gè)周期再次執(zhí)行。

測(cè)試發(fā)布

在生產(chǎn)環(huán)境部署完成后，我們開(kāi)啟了數(shù)據(jù)雙寫(xiě)，往 ClickHouse 里不斷地插入實(shí)時(shí)數(shù)據(jù)和離線(xiàn)數(shù)據(jù)，直到達(dá)到 Druid 的數(shù)據(jù)水平。

在數(shù)據(jù)一致性驗(yàn)證過(guò)后，我們鏡像了一份生產(chǎn)服務(wù)的查詢(xún)，然后把這些查詢(xún)轉(zhuǎn)發(fā)給 ClickHouse。

通過(guò)收集和對(duì)比 Druid 和 ClickHouse 的響應(yīng)，我們能夠驗(yàn)證 ClickHouse 鏈路的數(shù)據(jù)質(zhì)量和查詢(xún)性能。

之后的灰度階段，我們逐漸提升 ClickHouse 服務(wù)生產(chǎn)系統(tǒng)的比例，并保持 Druid 繼續(xù)運(yùn)行，以保證出現(xiàn)問(wèn)題可以及時(shí)回滾。

查詢(xún) GUI

數(shù)據(jù)可視化方面，我們需要提供類(lèi)似 Turnilo 的可視化工具給開(kāi)發(fā)、測(cè)試和 BI 人員使用。

ClickHouse 支持多種商業(yè)和開(kāi)源的產(chǎn)品接入，我們選用了 Cube.JS，并進(jìn)行了簡(jiǎn)單的二次開(kāi)發(fā)。

 

圖 6

總結(jié)

本文介紹了廣告數(shù)據(jù)平臺(tái)的基本情況，ClickHouse/Druid 的特點(diǎn)對(duì)比和團(tuán)隊(duì)使用 ClickHouse 替換 Druid 的架構(gòu)方案。

ClickHouse 表現(xiàn)出了良好的性能和擴(kuò)展能力，并且還在快速的迭代更新。

目前項(xiàng)目已經(jīng)上線(xiàn)，接下來(lái)我們還會(huì)和大家繼續(xù)分享過(guò)程中的碰到的一些問(wèn)題和解決方法，歡迎大家持續(xù)關(guān)注。

作者：吳寒思、周路、余何

編輯：陶家龍

出處：轉(zhuǎn)載自公眾號(hào)eBay技術(shù)薈(ID：eBayTechRecruiting)