首页 > 其他分享 >ByteHouse:基于 ClickHouse 的实时计算能力升级

ByteHouse:基于 ClickHouse 的实时计算能力升级

时间:2023-03-21 15:23:23浏览次数:55  
标签:场景 字节 优化 实时 ByteHouse 计算能力 ClickHouse

更多技术交流、求职机会,欢迎关注字节跳动数据平台微信公众号,回复【1】进入官方交流群

 ByteHouse 是火山引擎数智平台旗下云原生数据分析平台,为用户带来极速分析体验,能够支撑实时数据分析和海量离线数据分析;便捷的弹性扩缩容能力,极致的分析性能和丰富的企业级特性,助力客户数字化转型。

ByteHouse 在字节跳动的发展历程

从 2017 年开始,字节内部的整体数据量不断上涨,为了支撑实时分析的业务,字节内部开始了对各种数据库的选型。经过多次实验,在实时分析版块,字节内部决定开始试水 ClickHouse。

2018 年到 2019 年,字节内部的 ClickHouse 业务从单一业务,逐步发展到了多个不同业务,适用到更多的场景,包括 BI 分析、A/B 测试、模型预估等。

在上述这些业务场景的不断实践之下,研发团队基于原生 ClickHouse 做了大量的改造,同时又开发了大量的优化特性。

2020 年, ByteHouse 正式在字节跳动内部立项,2021 年通过火山引擎对外服务。

截止 2022 年 3 月,ByteHouse 在字节内部总节点数达到 18000 个,而单一集群的最大规模是 2400 个节点。

可以想象,2400 台服务器同时堆在一起是怎样一副壮观的景象。ByteHouse 支撑的最大数据量可达 700 个 PB,自上线以来,支持了 80%大家非常耳熟能详的字节跳动业务。

选择 ClickHouse 作为实时分析的基建

选择原因

那么,字节为什么会选择 ClickHouse 作为内部分析型数据库的基础呢?

2017 年,基于众多的业务场景以及海量分析数据,字节内部对于实时数仓的要求也越来越高。

 

事实上,要同时满足图上所示的这些要求有着相当大的难度。

首先,要解决数据量大的问题,同时这个数据量还会不断地增长,2019 年,字节内部每天新增的数据量就达到了 100 个 TB。

其次,在数据量大的基础上,仍要保有包含以下三个方向非常强的灵活性:

  • 数据源头的灵活性。也同时去支持批示数据和流式数据的导入,实现批流一体。

  • 查询性能的多样性。希望同时能够支持到明细数据和聚合查询,不希望在数据库当中只存聚合的数据。

  • 交互式分析需求的灵活性。数千个维度都要能够达到秒级的快速响应。

最后,在满足前述两点基础上,还要做到成本可控。最开始,团队内部其实也列出了很多开源解决方案,例如 Redis、Apache 等等,这些方案其实都可以实现上述要求的一点到两点。但如果要去维护不同的开源数据库,成本就会变得非常高,团队希望尽量选择一款可以避免成本无限扩展的计算引擎。与此同时,团队也希望数据整体成本可控的,服务器成本的增加是线性的,而不是指数的。

  • 线性:数据存储都通过磁盘来进行

  • 指数:指数通过内存来进行(快但贵)

 

 

最后,团队发现作为开源产品的 ClickHouse,竟然能够同时满足所有的要求——性能强劲,灵活支持,主要依赖磁盘,成本相对可控,真正做到了 All In One。

多快好省——ClickHouse 基础能力介绍

ClickHouse 是一个用于联机分析处理(OLAP)的列式数据库管理系统,源自俄罗斯的搜索引擎 Yandex。它的最大特点可以概括为”多快好省“。

  • “多”——指集群规模多。在字节内部最大的集群规模是 2400 台,ClickHouse 可以完全支持。

  • “快”——在大数据规模下,ClickHouse 也能提供秒级的单表查询性能,性能强。

  • “好”——指无入侵式架构,可以轻松集成到现有的系统,可复用性好。

  • “省”——ClickHouse 使用磁盘作为性能的基准,不使用内存,成本随着规模的扩展,可控性强。

开源 ClickHouse 的瓶颈

当字节内部的整体使用规模到了 18000 台服务器之后,其实也发现 ClickHouse 一些瓶颈,比如

  1. OLAP 能力不够好用。在一些特定的场景下,如 upset 场景,实时数据更新场景……原生 ClickHouse 能力难以支持。

  2. ClickHouse 在单表性能上非常的强劲,但多表能力非常局限,且对标准 SQL 兼容性低。

  3. 缺乏成熟运维管理工具,运维复杂程度高,需要投入极大的人力,这是一个很大的缺陷。

  4. ClickHouse 是 MPP 架构(存算一体架构),性能和扩展性极强,但缺陷也很明显:

    横向扩容成本非常高,增加一个节点要进行数据重新定位。

    隔离性差,单一用户的查询会非常容易打满整个集群,导致 ClickHouse 并发度不高。

ByteHouse:实时场景全面进化

字节内部针对 ClickHouse 的很多特性进行了全新的研发,推出了 ByteHouse 产品,在实时场景上全面实现了进化。

OLAP 能力进化:丰富的自研表引擎

 

ClicHouse 本身就可以支持非常丰富的表引擎,但 ByteHouse 在此基础上逐渐弥补了各种表引擎的不足,衍生出更多全新的表引擎,使 ByteHouse 能够做很多开源 ClickHouse 做不到的场景。

  • 高可用表引擎。相比社区的 ReplicatedMergeTree,高可用表引擎支持的整体表数量更多,支持的集群规模更大,稳定性更高。

  • 实时数据引擎。 ByteHouse 的实时数据引擎相比起社区所支持的数据实时数据引擎,消费能力更强,并且能够支持 At—Least once 语义,能够解决社区版 Kafka 单点写入的性能瓶颈问题。

  • Unique 引擎。这是最关键的一点,它解决了社区版 Replacing Merge 实时更新延迟问题,真正能够做到实时 upset。

  • Bitmap 引擎。它可以在特定的场景(如用户圈选)当中,支持大量的“交并补”,做到 10 倍到 50 倍的性能提升。

相比 ClickHouse,ByteHouse 在这四个引擎加持下,整体使用场景做到了大幅的增强。

比如在有一些场景下面,实时消费的性能是不够的,需要做到 At—least once 或者 Exactly once 语义,社区版的 ClickHouse 是做不到的,而 ByteHouse 可以;又比如用户希望导入之后能做到实时地去重,而不希望等到 Merge 之后才能去重,ClickHouse 同样做不到,而 ByteHouse 可以做到。

性能优化:优化器、字典、索引支持

ClickHouse 最大的特点是单表性能强劲,但多表性能存在极大的缺陷。

 

优化器

主要的问题在于 ClickHouse 不支持优化器。众所周知,在 MySQL、PGSQL、 Oracle 这类传统数据库当中,优化器对于多表的性能优化起到了非常大的作用。此外,优化器还有一个非常关键的作用,就是它能改写 SQL。在不支持优化器的前提下,产生了两个比较大的缺陷。

  • 多表性能差。

  • 从 MySQL 或者很多传统数据库迁移到开源 ClickHouse 之后,要做很多 SQL 的改写。

而 ByteHouse 自研了基于 CBO 和 RBO(基于代价和基于规则的优化器),同时支持了很多优化器的多如牛毛的特性,包括多层嵌套的下推、Join 子查询的下推、Join-Reorder、Bucket Join、Runtime Filter 等。

在做到整体优化器的支持之后,ByteHouse 它能够做到 TPC-DS 的性能,在覆盖率层面, 可以达到 99 条 sql100%覆盖,每一条的查询都比社区版 ClickHouse 要更快。

全局字典、索引支持

参考大量不同的 OLAP 或者 OLTP 数据库,ByteHouse 还做了很多的优化。比如支持了全局字典,支持了更多的索引,如 Bitmap index,可以让查询效率更快。开源 ClickHouse 所具备的“多快好省”,在 ByteHouse 的优化之下,让快更快,以快至快。

运维进化:集群运维能力 & 稳定性优化

第一是集群运维能力优化。之前提到,在更多的服务器场景下面,急需运维工具,使得 SRE 或者 Devops 运维人员的人效更高。为了解决这些问题,ByteHouse 提供了以下工具。

  • 标准化运维工具。比如像在白屏上自动下发配置的工具,在白屏上进行版本自助升级的工具,节点重启、替换等等标准化运维工具。

  • 集群健康度的检测工具。相当于集群的实时巡检,可以报告当前集群是健康状态还是有问题的状态,这些问题是什么?这些问题怎么解决?更大程度地把问题前置化,避免在紧急的时刻要去处理大量的问题。

  • 当问题发生时的诊断工具。比如大查询的诊断,和集群当时负载的诊断。

通过这三个方向的工具,能够让整体的运维效率达到非常高的程度,并且达到可复制化。(在字节跳动内部,总共 18000 个节点,只有不到 10 个运维人员的支持。通过 ByteHouse 这些工具,能够做到自动化、高效化、可复制化)

第二方面是稳定性优化。在长达 6 年多的 ByteHouse 集群运营当中,研发团队发现 ClickHouse 存在大量的稳定性痛点。而 ByteHouse 优化到了代码根本层面的修复,包括云数据的持久化,包括主备同步查询,包括慢节点模式, Zookeeper 的自动的清理和修复等等。当这些问题不再发生后,运维同学可以节省出大量的人力用于工具的开发,最终能够形成一个完整的产品、非常高的人效以及整体非常好的终端用户查询性能的正向循环。

架构进化:存算分离

在 MPP 1. 0 存算一体的模式下面,有着隔离比较困难以及扩容比较困难的瓶颈。ByteHouse 基于这些痛点做了非常大的投入,直接研发出了 MPP 2. 0 的架构,也就是存算分离架构。

简单来说,存算分离架构——就是计算层 Shared Nothing,存储层 Shared Everything。这样做的好处可以分成两个层次。

  • 第一层:更好地做到资源隔离。每一个计算任务都会提交到不同的计算资源上面去,不同用户之间不会有影响的。随时能够扩容计算资源和存储资源,也能够缩容计算资源。结合云计算一些按秒计费的策略,最终能做到用户的成本进一步的降低。

  • 第二层:真正做到云原生(Cloud native),ByteHouse 的存储层既支持 HDFS,也支持 S3 对象或者其他的对象存储,比如火山的 TOS。这样可以支持 MPP2. 0 架构下的 ByteHouse,真正能够实现云原生的部署。

ByteHouse 多场景实践

场景一:实时监控

 ByteHouse 在实时场景上最典型的应用就是实时监控业务。

比如在抖音的线上活动当中,经常会有数据实时监控需求,从生产到数据展现在大屏上,往往达到分钟级甚至秒级的数据延迟。而 ByteHouse 加入其中,带来了以下价值。

  1. 非常高的吞吐性能。实时的线上数据都能够被 ByteHouse 的计算引擎所接收到,而最终能够达到 250W/写入 TPS 的性能指标。

  2. 非常高的查询性能。ByteHouse 可以使数据从输入端到输出端的流程达到秒级。

  3. 数据保障。ByteHouse 能够最终保障到 Exactly Once 的语义,保证数据不丢失,也不会重复。最终达到数据是高效存储的,准确的,可以在秒级被查询到的。

场景二:行为分析

 

在行为分析的场景下,可以结合到运维同学非常熟悉的一些产品,类似一些事件分析、留存分析、转化分析、各种漏斗图表等等产品功能的底层,其实都非常适合 ByteHouse 作为支撑的。

事实上, 在 2017 年,ByteHouse 最早支撑的内部场景也是行为分析场景。行为分析场景需要非常大数据量的存储、非常高的数据读取、响应的要求,以及非常大的成本诉求。 ByteHouse 的优势价值有以下三点。

  1. 支撑大集群。ByteHouse 通过 HaMergeTree 引擎的支持,通过集群扩容能力的研发,最终才能够让个场景能够支撑到 2400 台集群的极大规模。

  2. 秒级响应。想做到秒级响应,就需要做到不断地优化支持——通过字典编码来进行减少序列化和反序列化的开销,查询性能才能得到提升。最终达到的效果是 90% 的查询场景能够在 5 秒钟~ 7 秒钟之间得到返回。在这么大一个量级下面,ByteHouse 仍然能够达到 10 秒钟之内的响应,是一个非常了不起的成果。

  3. 降本增效。数据量级怎样能够做到进一步的降低成本?事实上,用户每天访问一定是有热数据的,也有着一些长期需要被查询的冷数据。在 ClickHouse 的基础上面, ByteHouse 做了二次迭代开发——在 HDFS 上面进行冷热的分存。热数据存储在本地,在 SSD 磁盘上加快响应;冷数据放在 HDFS 上来进行存储成本的降低。不仅可以做到大集群规模响应很快,它的成本仍然能够保持,非常具有性价比。

场景三:精准营销

最后是精准营销场景。这个场景其实在生产场景下面非常的普遍,每一个产品都需要精准营销,每个产品都需要画大量的漏斗图。在精准营销的背后,如果使用 ByteHouse 来进行数据支撑,会有三个非常重要的优化节点。

  1. 秒级响应。ByteHouse 的优化器支持对于秒级响应做到了很大的优化。在优化器的加持下面,能够做到 P95 的整个时长响应能够在一秒之内,甚至能够在半秒钟之内,满足了用户实时看数,实时分析市场行情的需求。

  2. 交并补计算。因为人群的圈选,事实上在用户打了大量的标签,这些标签就是 0 和 1。这些 0 和 1 在进行交并补的计算之后,最终效果可以达到 10 倍到 50 倍的性能提升。

  3. 激发效应。因为 ByteHouse 有更多维度的查询能力和非常快的响应能力,所以用户的每一条查询链路,从输入到输出,都能在一秒钟之内得到响应。所以用户的思维是可以不断地去激发,不断地去创造,不断地去迭代的,这条数据链路精准营销的价值得到不断地提升,最终能够带来生产上的真实产品价值和真实业务价值。

 

为了助力企业抓稳数字化发展机遇,加速企业数智能力升级,自 2023 年 2 月 1 日开始,火山引擎 ByteHouse 特别推出为期一年的企业级特惠活动。

企业通过本次活动购买 ByteHouse 服务,包年 1 年可享 8.3 折,包年 2 年可享 7 折,包年 3 年可享 5 折。除基础优惠之外,企业包年购买后,还可获得大量额外资源免费赠送,买二送一, 买三送二,买五送三(赠送资源与包年使用期限一致),且以上两项优惠可叠加享受!

 

点击跳转 ByteHouse云原生数据仓库 了解更多

标签:场景,字节,优化,实时,ByteHouse,计算能力,ClickHouse
From: https://www.cnblogs.com/bytedata/p/17240123.html

相关文章

  • clickhouse的数据存储原理
    ClickHouse是一个列式存储数据库,它的数据存储原理与传统的行式存储数据库有很大不同。以下是ClickHouse数据存储原理的一些关键点:列式存储:与行式存储数据库将数据按行存......
  • Clickhouse集群扩容和收缩
    集群节点信息节点IPClickhousenode121.198.165.19Clickhousenode221.198.165.20Clickhousenode321.198.165.21集群配置信息......
  • 限时促销,火山引擎 ByteHouse 为企业带来一波数智升级福利!
    更多技术交流、求职机会,欢迎关注字节跳动数据平台微信公众号,回复【1】进入官方交流群 面对庞杂的海量数据,稳定高速的实时数据处理能力,成为了当下企业数智升级过程中备......
  • centos 安装clickhouse 并导入mysql数据
    一.安装clickhouse1.系统要求 ClickHouse可以在任何具有x86_64,AArch64或PowerPC64LECPU架构的Linux,FreeBSD或MacOSX上运行。 官方预构建的二进制文件通常针对x86_......
  • Clickhouse实现累计求和cumulative sum
    源表数据如下:timeprovinceorder_cnt20200601shandong10020200601jiangsu20020200601zhejiang30020200602shandong20020200602jiangsu30020200602zhejiang40020200603shandon......
  • clickhouse高级功能之MaterializeMySQL详解
    clickhouse20.8将新增MaterializeMySQL引擎,可通过binlog日志实时物化mysql数据,极大提升了数仓的查询性能和数据同步的时效性;原有mysql中承担的数据分析工作可交由click......
  • Clickhouse单机部署
    1.下载安装clickhousesudoyuminstall-yyum-utilssudoyum-config-manager--add-repohttps://packages.clickhouse.com/rpm/clickhouse.reposudoyuminsta......
  • springboot jpa hibernate mysql clickhouse 多数据源
    ClickhouseConfig.java@Configuration@EntityScan(basePackages="test.entity.clickhouse")@EnableJpaRepositories(basePackages="test.repository.clic......
  • golang 连接clickhouse
    1.驱动:"github.com/ClickHouse/clickhouse-go/v2"2.连接代码:packagemodelimport("database/sql""fmt"_"github.com/ClickHouse/clickhouse-go/v......
  • ClickHouse(13)ClickHouse合并树MergeTree家族表引擎之CollapsingMergeTree详细解析
    目录建表折叠数据算法资料分享参考文章该引擎继承于MergeTree,并在数据块合并算法中添加了折叠行的逻辑。CollapsingMergeTree会异步的删除(折叠)这些除了特定列Sign有1和-1......