讓快更快,火山引擎ByteHouse為ClickHouse提速
近日,火山引擎數智平臺VeDI與DataFun聯合舉辦以“OLAP計算引擎”為主題的直播活動,來自火山引擎數智平臺VeDI的產品專家從技術選型、能力分析、性能優化以及應用場景落地多個角度,介紹火山引擎ByteHouse如何基于ClickHouse實現實時計算能力升級。
(資料圖片)
據介紹,火山引擎ByteHouse來源于字節跳動多年內部沉淀。由于場景越來越豐富以及數據分析需求增長,業務對于實時數倉的要求也越來越高。首先是數據體量大以及不斷增長的問題。早在2019 年,字節內部每天新增的數據量就達到了100TB。其次,在海量數據基礎上,由于數據類型多樣(包括批式數據和流式數據)、查詢需求多樣、交互式分析復雜,數據引擎需要具備靈活性。目前,行業Redis、 SparkSQL 等開源方案可以從不同角度滿足上述兩個需求,但是維護多個開源數據庫將導致成本高,選擇一款可以避免成本無限擴展的計算引擎成為字節數據研發首要考慮的問題。
ClickHouse性能高、靈活性強,且主要依賴磁盤、成本相對可控,成為字節跳動內部計算引擎的首選。但原生 ClickHouse 能力難以支持 upset 、實時數據更新等一些場景,在很多層面有局限性,例如:
· 單表性能強勁,但多表能力局限,且對標準 SQL 兼容性低。
· 缺乏成熟運維管理工具,運維復雜程度高。
· ClickHouse 為 MPP 架構(存算一體架構),性能強,但橫向擴容成本非常高、數據隔離性差。
ByteHouse產品專家在直播中介紹到,“為了解決以上問題,我們主要從4個方向進行優化,讓OLAP引擎能力、性能、運維、架構進一步升級。”
第一,豐富的自研表引擎,實現OLAP引擎能力進化。 ByteHouse 彌補了ClickHouse表引擎的不足,并衍生出全新的表引擎,包括使高可用表引擎、實時數據引擎、Unique 引擎、Bitmap 引擎。以Unique 引擎為例,它解決了社區版 ReplacingMergeTree 實時更新延遲問題,真正做到實時 upset。
第二,新增優化器、字典、索引支持能力,實現OLAP引擎性能進化。ClickHouse在多表場景中性能存在缺陷,而ByteHouse 通過自研CBO 和 RBO(基于代價和基于規則的優化器),支持了多層嵌套的下推、Join 子查詢的下推、Join-Reorder、Bucket Join、Runtime Filter 等優化器特性,做到 TPC-DS 的性能可以達到 99 條sql100%覆蓋,極大提升多表場景下的性能。另外,ByteHouse還支持了全局字典以及更多索引,如 Bitmap index,讓查詢效率更快。
第三, 自動化、可視化,實現OLAP引擎運維進化。ByteHouse 提供標準化運維、集群健康度檢測、問題發生時的診斷工具,幫助運維人員提高效率。例如,集群健康度的檢測工具,類似于集群的實時巡檢,能夠報告當前集群狀態、出現了什么問題、問題如何解決,最大程度把問題前置化,降低運維風險。從效果上看, 18000 個節點只需要不到 10 個運維人員來支持。
第四, 存算分離,實現OLAP引擎架構進化。ByteHouse推出了 MPP 2. 0 即存算分離架構。一方面, 存算分離可以更好實現資源隔離,每一個計算任務都會提交到不同的計算資源中,做到用戶之間互不影響,還能靈活擴容、縮容存儲計算資源;另一方面,存算分離能做到真正云原生(Cloud native),ByteHouse 存儲層既支持 HDFS,也支持 S3 對象或者其他的對象存儲,實現云原生部署。
目前,ByteHouse已經在行為分析、精準營銷、實時監控等業務場景中落地。以實時監控為例,很多互聯網APP有線上運營活動、直播電商等業務,數據實時性格外重要。數據從生產到展現在大屏上,延遲往往要控制在分鐘級甚至秒級以內。而ByteHouse高吞吐性能、查詢性能,使數據從輸入端到輸出端的流程達到秒級。在數據保障層面,ByteHouse 也能精細到Exactly Once 的語義,保證數據不丟失、不重復,最終達到數據高效存儲、準確查詢。(作者:吳卓港)
關鍵詞:
2023-08-29 18:06:50
2023-08-29 17:53:55
2023-08-29 17:53:33
2023-08-29 17:37:20
2023-08-29 17:37:14
2023-08-29 17:04:07
2023-08-29 17:00:22
2023-08-29 16:53:59
2023-08-29 16:53:58
2023-08-29 16:07:41
2023-08-29 16:06:06
2023-08-29 16:03:56
2023-08-29 16:01:32
2023-08-29 15:57:07
2023-08-29 15:53:29
2023-08-29 15:02:38
2023-08-29 15:02:21
2023-08-29 15:00:49
2023-08-29 14:57:51
2023-08-29 14:57:28
2023-08-29 14:55:59
2023-08-29 14:02:12
2023-08-29 13:57:58
2023-08-29 13:09:01
2023-08-29 13:03:55
2023-08-29 11:59:55
2023-08-29 11:57:35
2023-08-29 11:54:36
2023-08-29 11:37:07
2023-08-29 11:34:59
2023-08-29 11:07:11
2023-08-29 11:04:13
2023-08-29 11:04:09
2023-08-29 11:01:32
2023-08-29 10:58:33
2023-08-29 10:56:52
2023-08-29 10:56:40
2023-08-29 10:08:48
2023-08-29 10:08:03
2023-08-29 10:08:02
2023-08-29 10:07:02
2023-08-29 10:06:19
2023-08-29 10:03:19
2023-08-29 10:00:32
2023-08-29 09:59:19
2023-08-29 09:53:40
2023-08-29 09:37:53
2023-08-29 08:33:42
2023-08-29 06:59:25
2023-08-29 06:52:01
2023-08-29 05:54:36
2023-08-29 03:14:52
2023-08-28 23:02:50
2023-08-28 22:34:21
2023-08-28 21:12:03
2023-08-28 20:10:18
2023-08-28 20:08:13
2023-08-28 20:01:17
2023-08-28 19:59:37
2023-08-28 19:59:00
2023-08-28 19:56:01
2023-08-28 19:27:55
2023-08-28 19:06:19
2023-08-28 19:04:26
2023-08-28 18:08:33
2023-08-28 18:03:10
2023-08-28 17:03:10
2023-08-28 16:55:50
2023-08-28 16:54:31
2023-08-28 16:38:54
2023-08-28 16:07:06
2023-08-28 16:05:01
2023-08-28 16:03:46
2023-08-28 16:00:26
2023-08-28 15:56:32
2023-08-28 15:54:58
2023-08-28 15:11:54
2023-08-28 14:04:09
2023-08-28 14:00:44
2023-08-28 13:53:21
2023-08-28 13:05:19
2023-08-28 12:58:52
2023-08-28 12:54:48
2023-08-28 12:54:23
2023-08-28 12:14:24
2023-08-28 12:07:57
2023-08-28 12:04:49
2023-08-28 12:04:28
2023-08-28 12:01:24
2023-08-28 12:01:17
2023-08-28 12:00:02
2023-08-28 11:56:37
2023-08-28 11:56:08
2023-08-28 11:53:21
2023-08-28 10:29:57
2023-08-28 09:08:54
2023-08-28 09:07:19
2023-08-28 09:05:44
2023-08-28 09:04:49
相關新聞