2019年ClickHouse在頭條內部技術演進.pdf

《2019年ClickHouse在頭條內部技術演進.pdf》由會員分享，可在線閱讀，更多相關《2019年ClickHouse在頭條內部技術演進.pdf（33頁珍藏版）》請在三個皮匠報告上搜索。

1、ClickHouse 在頭條內部技術演化目錄1.ClickHouse 簡介 2.Bytedance 如何使用ClickHouse 3.問題與解決方案 4.Q&A1.Developed by Yandex,and open source since 2016 2.查詢性能優越的分析型引擎 3.主要特點（not new)-Column oriented+vector execution -Local attached storage(not Hadoop ecosystem)-Linear scalable&Reliable(shard+replication)-SQL interface -Fa

2、stClickHouse 簡介1.Data Skipping -分區以及分區剪枝-數據局部有序（LSM-like engine,zone map)2.資源的垂直整合-并發 MPP+SMP（plan level)-Tuned執行層實現（multi-variant agg implementation,SIMD)3.C+Template CodeClickHouse 簡介-性能優越的因素1.適用場景-單表分析 或 colocate join case-distributed join 性能并不出色 2.不足 -no transaction -batch data ingest -weak upda

3、te/delete support -weak optimizer&query rewriteClickHouse 簡介-適用場景與不足1.選擇ClickHouse的原因 產品需求 -交互式分析能力(in seconds)-查詢模式多變 -以大寬表為主 -數據量大 Open sourced MPP OLAP engine-(performance,feature,quality)Bytedance 如何使用ClickHouse1.幾千個節點,最大集群1200個節點 2.數據總量 幾十PB 3.日增數據 100TB 4.查詢響應時間(mostly)ms-30s 5.覆蓋下列用戶-產品運營，分析師

4、-開發人員-少量廣告類用戶-openapiBytedance 如何使用ClickHouseBytedance 如何使用ClickHouse產品運營研發人員用戶行為分析平臺自研BI系統SQL 網關其他ClickHouse集群數據倉庫（HIVE)Kafka RDBMS(MYSQL)數據ETL服務Mini batch Data-多種數據源（離線+實時+)-交互式分析-數據處理鏈路對業務方透明 滿足數據中臺對數據查詢需求。Bytedance 如何使用ClickHouse問題與解決方案數據源-ClickHouse 服務化數據就緒？ETLCH NodeCH NodeCH NodeHDFS消息中間件其他服務

5、化與自動化中的問題 1.HDFS 數據訪問 2.數據導入過程中Fail over 3.CH數據就緒速度(Part生成）1.增加 HDFS 數據訪問能力（HDFS client porting from HAWQ)2.ETL服務維護外部事務保障數據一致性（fail over)3.INSERT INTO LOCAL TABLE 4.數據構建與查詢分離(experimental feature)數據源-ClickHouse 服務化1.客戶端上報字段多變(自定義參數）2.數據產品需要相對固定schema Engine fix this Gap by Map type 性能需求：訪問MAP 鍵值需要與訪

6、問POD 類型的列速度一致 實現方式：LOB？Two-implicit column?Other Map 數據類型-動態Schema 1.數據特征：#keys 總量可控，局部有限 2.局部（PART level)展平模型(自描述）Map 數據類型-動態Schema 1.MAP鍵訪問自動改寫 e.g.“select c_mapa from table”will be rewrote to“select c_map_a from table”2.MAP列訪問(代價較大)e.g.select c_map from table 3.Merge階段優化（無需重構MAP column)4.收益：-自動化接

7、入-Table schema 簡化-極大簡化數據構建(ETL)邏輯Map 數據類型-動態Schema語法：Create table t(c1 UInt64,c2 Map(String,UInt8)ENGINE=MergeTree.insert into t values(1,abc:1,bcd:2)Select c2abc from tMap 數據類型-動態Schema1.兩副本保障數據/服務 2.ReplicatedMergeTree in ClickHouse（Issue)-Async Master-Master replication-High Volume Data&High Avai

8、lability(zookeeper 使用問題)1.ReplicatedMergeTree的問題 -ZooKeeper壓力大，znode太多 -400 Nodes 集群，半年數據，800萬znodes 2.ReplicatedMergeTree use ZK to store:-Table schema-副本狀態（part info&log info)-分片（shard)狀態 Catalog service+mini log service+coordinate service High Volume Data&High Availability(zookeeper 使用問題)1.數據繼續增長

9、會導致ZK無法服務 2.社區mini checksum in zk能緩解內存使用，但不能解決問題 3.基于MergeTree開發HA 方案High Volume Data&High Availability(Zookeeper問題)1.ZooKeeper只用作coordinate-Log Sequence Number(LSN)分配-數據Block ID 分配-元數據管理 2.節點維護local log service(action log)3.Log 在分片內部節點間通過Gossip協議交互 4.數據信息（parts)按需交互 5.外部接口與社區兼容（例如：multi-master寫入）Hi

10、gh Volume Data&High Availability-HaMergeTreeZK（LSN/ID alloc,metadata)ReplicaReplicaPart/Log INFOHigh Volume Data&High Availability-HaMergeTreeZK（LSN/ID alloc,metadata)Replica AReplica BInsert12231.A 獲取LSN和Block ID 2.A Push log to active replica B 2.B get its log lags from ZK and pull logs from A 3.B

11、 redo the log and get Block from AHigh Volume Data&High Availability-HaMergeTree1.ZooKeeper壓力不會隨著數據量增長 2.3M znodes in ZK 3.保障數據&服務高可用1.String 類型的濫用（from HIVE),處理低效 2.Why not LowCardinalityColumn？3.算子盡量在壓縮域上執行（actionable compression)-pure dictionary compression-predication(equality family)-group by(s

12、ingle/composite keys)String 類型處理效率-Global Dictionary1.Per replica字典(異步)構建-why not cluster level/shard level?2.Support xxMergeTree onlyString 類型處理效率-Global DictionaryINSERTPART ROLLINMERGEAsync check&recodeWriteData&Dict(MergedBlockOutPutStream)1.壓縮域執行String 類型處理效率-Global DictionarySelectDecompress(o

13、ptional)Execute actions on codeAnalyze and RewriteRead compressed string as code1.分布式表字典（per shard,per replica)2.分布式表壓縮域執行 3.性能提升約 20%30%String 類型處理效率-Global Dictionary1.Query：60天內用戶轉化率/行為路徑，以及對應每天轉化率 2.內存使用量大，OOM對服務穩定性影響 3.Aggregator無法感知底層數據特性 特定場景內存OOM-Step-ed Aggregation1.Aggregator 由執行HINT控制 2.H

14、INT 感知數據分區/指標語義 3.Blocked Aggregator 按partition pipeline計算指標。收益：內存使用比默認方式降低約五倍特定場景內存OOM-Step-ed Aggregation1.Array類型用來表示實驗ID 2.Query：命中某些實驗的用戶指標 3.單條記錄Array（實驗）幾百 or 上千 Array類型處理-BloomFilter&BitMap indexArray col.binArray col in BlockArray hasAny1.需要輔助信息減少 Array column materialize -Two scale BloomFi

15、lter(Part level,MRK range level)2.減少Long Array column in Runtime Block -Transform hasAny into BitMap index OR-ing Array Column value+BitMap 集合 has(array,value)get BitMap(執行層自動改寫）Array類型處理-BloomFilter&BitMap index1.HaKafka engine(主備容錯的kafka engine)2.輕量級update/delete支持（基于delta表的方案)3.多尺度分區（小文件讀取問題）.其他問題與改進1.控制面開發，簡化運維 2.Query cache支持 3.數據導入原子性支持 4.物化視圖增強 5.分布式Join Bytedance ClickHouse TODO