建站
咨詢
售后
建站咨詢
新聞中心
圖片來自 Pexels
10年積累的成都網(wǎng)站設(shè)計、成都做網(wǎng)站經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先制作網(wǎng)站后付款的網(wǎng)站建設(shè)流程，更有嫩江免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
eBay 廣告數(shù)據(jù)平臺為 eBay 第一方廣告主(使用 Promoted Listing 服務(wù)的賣家)提供了廣告流量、用戶行為和效果數(shù)據(jù)分析功能。
廣告賣家通過賣家中心(Seller Hub)的營銷標(biāo)簽頁、效果標(biāo)簽頁和公開API，有效掌控和對比店鋪的營銷活動和推廣商品的流量、銷量的實時和歷史數(shù)據(jù)，并通過網(wǎng)頁或者 API 下載數(shù)據(jù)分析報告。
這一系統(tǒng)上線之初使用了自研的分布式 SQL 引擎，構(gòu)建在對象存儲系統(tǒng)之上。3 年前隨著廣告流量增加，我們把數(shù)據(jù)引擎切換到 Druid 上。
這一平臺的主要挑戰(zhàn)如下：
- 數(shù)據(jù)量大：每日的插入數(shù)據(jù)記錄有數(shù)百億條，每秒的插入峰值接近一百萬條。
- 離線數(shù)據(jù)攝入：在不影響實時數(shù)據(jù)攝入的情況下，每天需要對前 1-2 天的數(shù)據(jù)進行在線替換。
根據(jù)上游數(shù)據(jù)團隊發(fā)布清洗過的每日數(shù)據(jù)，廣告數(shù)據(jù)平臺需要在不影響查詢的情況下每日替換實時數(shù)據(jù)，數(shù)據(jù)切換要求實現(xiàn)跨節(jié)點的全局原子操作。
- 完整性和一致性：面向賣家的財務(wù)數(shù)據(jù)，離線更新后的數(shù)據(jù)要求不能有遺漏和重復(fù);實時數(shù)據(jù)要求端對端的延遲在十秒內(nèi)。
Druid vs ClickHouse
Druid 于 2011 年由 Metamarkets 開發(fā)，是一款高性能列式在線分析和存儲引擎。它于 2012 年開源，2015 年成為 Apache 基金會旗下項目。
Druid 在業(yè)界使用廣泛，為千億級數(shù)據(jù)提供亞秒級的查詢延遲，擅長高可用、水平擴展。
另外為數(shù)據(jù)攝入提供了很多非常方便的聚合、轉(zhuǎn)換模版，內(nèi)建支持多種數(shù)據(jù)源，最快可以在幾十分鐘內(nèi)配置好新的數(shù)據(jù)表，包括數(shù)據(jù)定義和數(shù)據(jù)攝入鏈路(Lambda 架構(gòu))，大大提高了開發(fā)效率。
ClickHouse 由俄羅斯最大的搜索引擎公司 Yandex 研發(fā)，設(shè)計目標(biāo)是支持 Yandex.Metrica(世界第二大 Web 分析平臺)生成用戶分析報表等核心功能。
ClickHouse 是一個數(shù)據(jù)庫管理系統(tǒng)(DBMS)，有數(shù)據(jù)庫、表、視圖、DDL、DML 等概念，并提供了較為完整的 SQL 支持。
其核心特性有如下幾點：
- 高效的數(shù)據(jù)存儲：通過數(shù)據(jù)壓縮和列式存儲，可以達到最高 10 倍的數(shù)據(jù)壓縮率。
- 高效的數(shù)據(jù)查詢：通過主鍵索引、向量化引擎處理、多處理器并發(fā)和分布式查詢，最大壓榨 CPU 的所有能力，在中小規(guī)模的數(shù)據(jù)量上尤為突出。
- 靈活的數(shù)據(jù)定義和接入：通過支持 SQL 語言、JDBC 和關(guān)系模型，降低學(xué)習(xí)和遷移成本，可以和其他現(xiàn)有數(shù)據(jù)的產(chǎn)品無縫集成。
為什么遷移?
運維
Druid 雖然提供了很多非常方便的數(shù)據(jù)攝入功能，但它的組件構(gòu)成也較為復(fù)雜，節(jié)點類型有 6 種(Overload，Coordinator，Middle Manager，Indexer，Broker 和 Historical)。
除了自身的節(jié)點，Druid 還依賴于 MySQL 存儲元數(shù)據(jù)信息、Zookeeper 選舉 Coordinator 和 Overlord、HDFS 備份歷史數(shù)據(jù)。
ClickHouse 的架構(gòu)采用了對等節(jié)點的設(shè)計，節(jié)點只有一種類型，沒有主從節(jié)點。如果使用了副本功能，則依賴于 Zookeeper 保存數(shù)據(jù)段的同步進度。
與此同時，eBay 的基礎(chǔ)架構(gòu)團隊提出在定制 ClickHouse 的基礎(chǔ)上，向產(chǎn)品團隊提供列式數(shù)據(jù)庫存儲的服務(wù)。
除了運維和生命周期管理，基礎(chǔ)架構(gòu)團隊對 ClickHouse 進行改造和二次開發(fā)，進一步提高了數(shù)據(jù)攝入和存儲的效率，并在離線攝入方面彌補了和 Druid 的功能差距。
延時數(shù)據(jù)插入
Druid 通過引入實時數(shù)據(jù)的索引任務(wù)，把實時數(shù)據(jù)處理成一個個分段數(shù)據(jù)(segment)，并歸檔成歷史數(shù)據(jù)。成為分段數(shù)據(jù)之后，該時段數(shù)據(jù)即不可寫入。
由于并發(fā)實時索引任務(wù)數(shù)的限制，我們設(shè)置了 3 個小時的窗口長度(每個小時一個任務(wù))，因此超過 3 個小時的數(shù)據(jù)就無法寫入。
在某些極端情況下，例如上游數(shù)據(jù)延遲或者實時數(shù)據(jù)消費過于滯后，就會導(dǎo)致離線數(shù)據(jù)替換前這部分?jǐn)?shù)據(jù)的缺失。ClickHouse 則沒有這個限制，任意分區(qū)都可以隨時寫入。
主鍵優(yōu)化
ClickHouse 支持的主鍵并不是傳統(tǒng)意義下關(guān)系型數(shù)據(jù)庫的主鍵。傳統(tǒng)的主鍵要求每條表記錄都有唯一的鍵值，通過查詢主鍵可以唯一地查詢到一條表記錄。
而在 ClickHouse 中，主鍵定義了記錄在存儲中排序的順序，允許重復(fù)，所以稱之為排序鍵似乎更加合理。
事實上在 ClickHouse 里的主鍵定義通過 ORDER BY 聲明，僅在個別場景中允許和排序鍵不一致(但必須是排序鍵的前綴)。
由于我們的產(chǎn)品是給賣家提供分析功能，幾乎所有的查詢限定在了單一賣家維度，因此通過主鍵按照賣家排序，可以極大地提高查詢效率以及數(shù)據(jù)壓縮率。
系統(tǒng)架構(gòu)
圖 1
如圖 1 所示，系統(tǒng)由 4 個部分組成：
- 實時數(shù)據(jù)獲取模塊，接入 eBay 的行為和交易實時消息平臺。
- 離線數(shù)據(jù)替換模塊，接入 eBay 內(nèi)部的數(shù)據(jù)倉庫平臺。
- ClickHouse 部署和外圍數(shù)據(jù)服務(wù)。
- 報表服務(wù)，支撐廣告主、商家后臺和 eBay 公開 API。
實戰(zhàn)經(jīng)歷
Schema 設(shè)計
ClickHouse 提供了豐富的 Schema 配置。這方面需要根據(jù)業(yè)務(wù)場景和數(shù)據(jù)模式反復(fù)斟酌和多次試驗，因為不同的選擇會對存儲和性能有數(shù)量級的影響，一個錯誤的選擇會導(dǎo)致后期巨大的調(diào)優(yōu)和變更成本。
①表引擎
ClickHouse 的存儲引擎的核心是合并樹(MergeTree)，以此為基礎(chǔ)衍生出：
- 匯總合并樹(SummingMergeTree)
- 聚合合并樹(AggregationMergeTree)
- 版本折疊樹(VersionCollapsingTree)等常用的表引擎
另外上述所有的合并樹引擎都有復(fù)制功能(ReplicatedXXXMergeTree)的對應(yīng)版本。
我們的廣告數(shù)據(jù)平臺的展示和點擊數(shù)據(jù)選擇了復(fù)制匯總合并樹。這兩類用戶行為數(shù)據(jù)量極大，減小數(shù)據(jù)量節(jié)省存儲開銷并提升查詢效率是模式設(shè)計的主要目標(biāo)。
ClickHouse 在后臺按照給定的維度匯總數(shù)據(jù)，降低了 60% 的數(shù)據(jù)量。
銷售數(shù)據(jù)選擇了普通的復(fù)制合并樹，一方面由于銷售數(shù)據(jù)對某些指標(biāo)有除匯總以外的聚合需求，另一方面由于本身數(shù)據(jù)量不大，合并數(shù)據(jù)的需求并不迫切。
②主鍵
一般情況下，ClickHouse 表的主鍵(Primary Key)和排序鍵(Order By Key)相同，但是采用了匯總合并樹引擎(SummingMergeTree)的表可以單獨指定主鍵。
把一些不需要排序或者索引功能的維度字段從主鍵里排除出去，可以減小主鍵的大小(主鍵運行時需要全部加載到內(nèi)存中)，提高查詢效率。
③壓縮
ClickHouse支持列級別的數(shù)據(jù)壓縮，顯著地減少原始數(shù)據(jù)的存儲量，這也是列存儲引擎的巨大優(yōu)勢。查詢階段，較小的存儲占用也可以減少 IO 量。
對不同列選擇一種合適的壓縮算法和等級，能把壓縮和查詢的平衡做到性價比最優(yōu)。
ClickHouse 的所有列默認(rèn)使用 LZ4 壓縮。除此以外，一般的數(shù)據(jù)列可以選擇更高壓縮率的算法如 LZ4HC，ZSTD。
而對于類似時間序列的單調(diào)增長數(shù)據(jù)可以選擇 DoubleDelta，Gorilla 等特殊壓縮算法。
LZ4HC 和 ZSTD 等高壓縮率的算法還可以自己選擇壓縮級別。在我們的生產(chǎn)數(shù)據(jù)集上，ZSTD 算法對 String 類型字段壓縮效果較為顯著。LZ4HC 是 LZ4 的高壓縮比改進版，更適用于非字符串類型。
更高的壓縮率意味著更少的存儲空間，同時由于降低了查詢的 IO 量，可以間接提升查詢性能。
不過 CPU 也不是大風(fēng)刮來的，數(shù)據(jù)的插入性能就成了犧牲品。根據(jù)我們內(nèi)部測試的數(shù)據(jù)，在我們的生產(chǎn)數(shù)據(jù)集上使用 LZ4HC(6) 相比 LZ4 可以節(jié)省 30% 的數(shù)據(jù)，但實時數(shù)據(jù)攝取性能下降了 60%。
④低基
值得一提的是，對于基數(shù)較低的列(即列值多樣性低)，可以使用 LowCardinality 來降低原始存儲空間(從而降低最終存儲空間)。
如果在使用壓縮算法的情況下對一字符串類型的列使用 LowCardinality，還能再縮小 25% 的空間量。
在我們的測試數(shù)據(jù)集上，如果整表組合使用 LowCardinality、LZ4HC(6) 和 ZSTD(15)，整體壓縮比大約在原來的 13% 左右。
離線數(shù)據(jù)替換
①挑戰(zhàn)
針對廣告主的數(shù)據(jù)報表要求數(shù)據(jù)準(zhǔn)確、一致。實時的行為數(shù)據(jù)存在少量的 bot 數(shù)據(jù)(需要離線清除)，另外廣告的歸因也需要在離線階段重新調(diào)整。
因此我們引入了離線數(shù)據(jù)鏈路，在實時數(shù)據(jù)寫入 24-72 小時之后，用離線數(shù)據(jù)替換實時數(shù)據(jù)。
其中的挑戰(zhàn)如下：
- 廣告系統(tǒng)每天需要處理的用戶離線數(shù)據(jù)量近 1TB，在此之前，需要耗費大量時間將數(shù)據(jù)從 Hadoop 導(dǎo)入 Druid。
另外，導(dǎo)入期間的 I/O、CPU 和內(nèi)存的開銷對查詢的壓力不小。如何在保證數(shù)據(jù)一致性的同時，亦確保數(shù)據(jù)遷移的效率，是問題的關(guān)鍵。
- 如何在數(shù)據(jù)替換期間，確保用戶可見的數(shù)據(jù)波動最小。這就要求數(shù)據(jù)替換操作是原子性的，或者至少對每個廣告主都是原子的。
- 除了日常的離線數(shù)據(jù)更新，在數(shù)據(jù)倉庫數(shù)據(jù)出現(xiàn)偏差遺漏時，需要支持大范圍的數(shù)據(jù)修正和補償。
作業(yè)調(diào)度要求保證日常工作及時完成，并盡快完成數(shù)據(jù)修正工作。此外還需要監(jiān)控數(shù)據(jù)更新中的各種指標(biāo)，以應(yīng)對各種突發(fā)狀況。
Druid 原生支持?jǐn)?shù)據(jù)離線更新服務(wù)，我們與基礎(chǔ)架構(gòu)團隊合作，在 ClickHouse 平臺實現(xiàn)了這一功能。
②數(shù)據(jù)架構(gòu)
對于整合在線數(shù)據(jù)和離線數(shù)據(jù)的大數(shù)據(jù)架構(gòu)，業(yè)界通常的做法是 Lambda 架構(gòu)。即離線層和在線層分別導(dǎo)入數(shù)據(jù)，在展示層進行數(shù)據(jù)的合并。
我們也大致上采用了這一架構(gòu)。但具體的做法和經(jīng)典有所不同。
ClickHouse 里數(shù)據(jù)分區(qū)(partition)是一個獨立的數(shù)據(jù)存儲單元，每一個分區(qū)都可以單獨從現(xiàn)有表里脫離(detach)、引入(attach)和替換(replace)。
分區(qū)的條件可以自定義，一般按照時間劃分。通過對數(shù)據(jù)表內(nèi)數(shù)據(jù)分區(qū)的單個替換，我們可以做到查詢層對底層數(shù)據(jù)更新的透明，也不需要額外的邏輯進行數(shù)據(jù)合并。
③Spark 聚合與分片
為了降低 ClickHouse 導(dǎo)入離線數(shù)據(jù)性能壓力，我們引入了 Spark 任務(wù)對原始離線數(shù)據(jù)進行聚合和分片。每個分片可以分別拉取并導(dǎo)入數(shù)據(jù)文件，節(jié)省了數(shù)據(jù)路由、聚合的開銷。
④數(shù)據(jù)更新任務(wù)管理
鎖定分區(qū)拓撲結(jié)構(gòu)：在處理數(shù)據(jù)前，離線數(shù)據(jù)更新系統(tǒng)向基礎(chǔ)架構(gòu)團隊提供的服務(wù)請求鎖定 ClickHouse 的分區(qū)拓撲結(jié)構(gòu)，在此期間該分區(qū)的拓撲結(jié)構(gòu)不會改變。
服務(wù)端根據(jù)預(yù)先定義好的數(shù)據(jù)表結(jié)構(gòu)與分區(qū)信息返回數(shù)據(jù)的分片邏輯與分片 ID。
離線數(shù)據(jù)更新系統(tǒng)根據(jù)拓撲信息提交 Spark 任務(wù)。多張表的數(shù)據(jù)處理通過 Spark 并行完成，顯著提升了數(shù)據(jù)更新的速度。
數(shù)據(jù)聚合與分片：對于每一張需要更新的表，啟動一個 Spark 任務(wù)對數(shù)據(jù)進行聚合與分片。
根據(jù) ClickHouse 服務(wù)端返回的表結(jié)構(gòu)與分片拓撲將數(shù)據(jù)寫入 Hadoop，同時輸出數(shù)據(jù)替換階段用于校驗一致性的 checksum 與分片行數(shù)。
系統(tǒng)通過 Livy Server API 提交并輪詢?nèi)蝿?wù)狀態(tài)，在有任務(wù)失敗的情況下進行重試，以排除 Spark 集群資源不足導(dǎo)致的任務(wù)失敗。
離線數(shù)據(jù)更新不但要滿足每天的批量數(shù)據(jù)更新需求，還需要支持過往數(shù)據(jù)的再次更新，以便同步上游數(shù)據(jù)在日常定時任務(wù)更新之外的數(shù)據(jù)變動。
我們利用平臺團隊封裝的 Spring Batch 管理更新任務(wù)，按照日期將每天的數(shù)據(jù)劃分為一個子任務(wù)。
通過 Spring Batch 實現(xiàn)的 Continuously Job 保證在同一時刻子任務(wù)在運行的唯一性，避免產(chǎn)生任務(wù)競爭問題。
對于過往數(shù)據(jù)的更新，我們將 Batch 任務(wù)分類，除了日常任務(wù)之外，還可以手動觸發(fā)給定時間范圍內(nèi)的數(shù)據(jù)修正任務(wù)(如圖 2)。
圖 2
數(shù)據(jù)替換：在子任務(wù)中的所有 Spark Job 完成后，離線數(shù)據(jù)更新系統(tǒng)會調(diào)用基礎(chǔ)架構(gòu)團隊提供的數(shù)據(jù)替換接口，發(fā)起數(shù)據(jù)替換請求。
服務(wù)端按照定義好的分區(qū)，將數(shù)據(jù)從 Hadoop 直接寫入 ClickHouse，如圖 3 所示。
圖 3
離線數(shù)據(jù)更新系統(tǒng)的架構(gòu)如圖 4 所示：
圖 4
MySQL 數(shù)據(jù)庫用于記錄數(shù)據(jù)替換過程中任務(wù)的狀態(tài)與優(yōu)先級，當(dāng) Spark Job 失敗或者由于其他原因?qū)е绿鎿Q任務(wù)失敗重啟后，恢復(fù)任務(wù)的進度。
⑤原子性與一致性
為了保證數(shù)據(jù)替換的原子性，基礎(chǔ)架構(gòu)團隊提供了分區(qū)替換的方式。在離線數(shù)據(jù)導(dǎo)入的過程中，首先創(chuàng)建目標(biāo)分區(qū)的臨時分區(qū)。當(dāng)數(shù)據(jù)替換完畢并且校驗完成之后，目標(biāo)分區(qū)會被臨時分區(qū)替換。
針對不同機器上不同分片的原子性替換問題，基礎(chǔ)架構(gòu)團隊為每一條數(shù)據(jù)引入了數(shù)據(jù)版本。
對于每一個數(shù)據(jù)分區(qū)，都有對應(yīng)的活躍版本號。直到待替換數(shù)據(jù)分區(qū)的所有分片都成功導(dǎo)入之后，分區(qū)的版本號進行更新。
上游應(yīng)用的同一條 SQL 只能讀取同一分區(qū)一個版本的數(shù)據(jù)，每個分區(qū)的數(shù)據(jù)替換只感覺到一次切換，并不會出現(xiàn)同時讀取新舊數(shù)據(jù)的問題。
廣告平臺報表生成應(yīng)用因此在 SQL 層面引入了相應(yīng)的修改，通過引入固定的 WITH 和 PREWHERE 語句，在字典中查詢出每個數(shù)據(jù)分區(qū)對應(yīng)的版本號，并在查詢計劃中排除掉不需要的數(shù)據(jù)分區(qū)。
為了確保數(shù)據(jù)替換的一致性，在完成 Spark 數(shù)據(jù)處理之后，離線數(shù)據(jù)更新系統(tǒng)會計算各數(shù)據(jù)分片的校驗碼與數(shù)據(jù)總量。
當(dāng)替換完畢之后，ClickHouse 服務(wù)端會對分片數(shù)據(jù)進行校驗，確保在數(shù)據(jù)搬遷過程中沒有數(shù)據(jù)丟失和重復(fù)。
數(shù)據(jù)查詢
ClickHouse 支持 SQL 查詢(不完全)，有 HTTP 和 TCP 兩種連接方式，官方和第三方的查詢工具和庫豐富。
用戶可以使用命令行，JDBC 或者可視化工具快速進行數(shù)據(jù)查詢的開發(fā)和調(diào)試。
ClickHouse 通過 MPP(Massively Parallel Processing)+SMP(Symmetric Multiprocessing)充分地利用機器資源，單條查詢語句默認(rèn)使用機器核數(shù)一半的 CPU。
因此 ClickHouse 不支持高并發(fā)的應(yīng)用場景。在業(yè)務(wù)使用層面，最核心的問題是查詢校驗和并發(fā)控制，單條過大的查詢或者過高的并發(fā)都會導(dǎo)致集群資源使用率過高，影響集群穩(wěn)定性。
應(yīng)用架構(gòu)
eBay Seller Hub 通過 Reports Service 接入 ClickHouse 查詢，Reports Service 提供了 Public 和 Internal 兩套 API。
Internal API 提供給 Seller Hub 以及其他內(nèi)部的已知應(yīng)用使用，Public API 在 eBay Developers Program 開放給第三方開發(fā)者，詳情見：
- https://developer.ebay.com/
圖 5
Internal API 的查詢直接提交內(nèi)部線程池執(zhí)行，線程池的大小根據(jù) ClickHouse 的集群機器數(shù)量設(shè)置。查詢請求執(zhí)行前會進行校驗，過濾所有非法以及資源不可預(yù)估的請求。
Public API 通過任務(wù)提交的方式異步執(zhí)行查詢，用戶提交的查詢?nèi)蝿?wù)存入 DB 中，Service 內(nèi)部的 Schedule 定時掃表，根據(jù)任務(wù)的狀態(tài)串行執(zhí)行查詢?nèi)蝿?wù)。
執(zhí)行成功的任務(wù)上傳生成 Report 到文件服務(wù)器，用戶拿到 URL 后自行下載。執(zhí)行失敗的任務(wù)，根據(jù)錯誤類型(非法的請求，資源不足等)來選擇是否在下一個周期再次執(zhí)行。
測試發(fā)布
在生產(chǎn)環(huán)境部署完成后，我們開啟了數(shù)據(jù)雙寫，往 ClickHouse 里不斷地插入實時數(shù)據(jù)和離線數(shù)據(jù)，直到達到 Druid 的數(shù)據(jù)水平。
在數(shù)據(jù)一致性驗證過后，我們鏡像了一份生產(chǎn)服務(wù)的查詢，然后把這些查詢轉(zhuǎn)發(fā)給 ClickHouse。
通過收集和對比 Druid 和 ClickHouse 的響應(yīng)，我們能夠驗證 ClickHouse 鏈路的數(shù)據(jù)質(zhì)量和查詢性能。
之后的灰度階段，我們逐漸提升 ClickHouse 服務(wù)生產(chǎn)系統(tǒng)的比例，并保持 Druid 繼續(xù)運行，以保證出現(xiàn)問題可以及時回滾。
查詢 GUI
數(shù)據(jù)可視化方面，我們需要提供類似 Turnilo 的可視化工具給開發(fā)、測試和 BI 人員使用。
ClickHouse 支持多種商業(yè)和開源的產(chǎn)品接入，我們選用了 Cube.JS，并進行了簡單的二次開發(fā)。
圖 6
總結(jié)
本文介紹了廣告數(shù)據(jù)平臺的基本情況，ClickHouse/Druid 的特點對比和團隊使用 ClickHouse 替換 Druid 的架構(gòu)方案。
ClickHouse 表現(xiàn)出了良好的性能和擴展能力，并且還在快速的迭代更新。
目前項目已經(jīng)上線，接下來我們還會和大家繼續(xù)分享過程中的碰到的一些問題和解決方法，歡迎大家持續(xù)關(guān)注。
作者：吳寒思、周路、余何
編輯：陶家龍
出處：轉(zhuǎn)載自公眾號eBay技術(shù)薈(ID：eBayTechRecruiting)
當(dāng)前文章：為什么要從Druid遷移到ClickHouse？
文章地址：http://m.5511xx.com/article/cccdihs.html
