共计 5570 个字符，预计需要花费 14 分钟才能阅读完成。
更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【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。
其次，在数据量大的根底上，仍要保有蕴含以下三个方向十分强的灵活性：
1. 数据源头的灵活性。 也同时去反对批示数据和流式数据的导入，实现批流一体。
2. 查问性能的多样性。 心愿同时可能反对到明细数据和聚合查问，不心愿在数据库当中只存聚合的数据。
3. 交互式剖析需要的灵活性。 数千个维度都要可能达到秒级的疾速响应。
最初，在满足前述两点根底上，还要做到老本可控。最开始，团队外部其实也列出了很多开源解决方案，例如 Redis、Apache 等等，这些计划其实都能够实现上述要求的一点到两点。
但如果要去保护不同的开源数据库，老本就会变得十分高，团队心愿尽量抉择一款能够防止老本有限扩大的计算引擎。与此同时，团队也心愿数据整体老本可控的，服务器老本的减少是线性的，而不是指数的。
- 线性： 数据存储都通过磁盘来进行
- 指数： 指数通过内存来进行（快但贵）
最初，团队发现作为开源产品的 ClickHouse，居然可能同时满足所有的要求—— 性能强劲，灵便反对，次要依赖磁盘，老本绝对可控，真正做到了 All In One。
多快好省——ClickHouse 根底能力介绍
ClickHouse 是一个用于联机剖析解决（OLAP）的列式数据库管理系统，源自俄罗斯的搜索引擎 Yandex。它的最大特点能够概括为”多快好省“。
“多”——指集群规模多。在字节外部最大的集群规模是 2400 台，ClickHouse 能够齐全反对。
“快”——在大数据规模下，ClickHouse 也能提供秒级的单表查问性能，性能强。
“好”——指无入侵式架构，能够轻松集成到现有的零碎，可复用性好。
“省”——ClickHouse 应用磁盘作为性能的基准，不应用内存，老本随着规模的扩大，可控性强。
开源 ClickHouse 的瓶颈
当字节外部的整体应用规模到了 18000 台服务器之后，其实也发现 ClickHouse 一些瓶颈，比方
OLAP 能力不够好用。在一些特定的场景下，如 upset 场景，实时数据更新场景……原生 ClickHouse 能力难以反对。
ClickHouse 在单表性能上十分的强劲，但多表能力十分局限，且对规范 SQL 兼容性低。
不足成熟运维管理工具，运维复杂程度高，须要投入极大的人力，这是一个很大的缺点。
ClickHouse 是 MPP 架构（存算一体架构），性能和扩展性极强，但缺点也很显著：
- 横向扩容老本十分高，减少一个节点要进行数据从新定位。
- 隔离性差，繁多用户的查问会非常容易打满整个集群，导致 ClickHouse 并发度不高。
ByteHouse：实时场景全面进化
字节外部针对 ClickHouse 的很多个性进行了全新的研发，推出了 ByteHouse 产品，在实时场景上全面实现了进化。
OLAP 能力进化：丰盛的自研表引擎
ClicHouse 自身就能够反对十分丰盛的表引擎，但 ByteHouse 在此基础上逐步补救了各种表引擎的有余，衍生出更多全新的表引擎，使 ByteHouse 可能做很多开源 ClickHouse 做不到的场景。
1. 高可用表引擎。 相比社区的 ReplicatedMergeTree，高可用表引擎反对的整体表数量更多，反对的集群规模更大，稳定性更高。
2. 实时数据引擎。 ByteHouse 的实时数据引擎相比起社区所反对的数据实时数据引擎，生产能力更强，并且可能反对 At—Least once 语义，可能解决社区版 Kafka 单点写入的性能瓶颈问题。
3.Unique 引擎。 这是最要害的一点，它解决了社区版 Replacing Merge 实时更新提早问题，真正可能做到实时 upset。
4.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 退出其中，带来了以下价值。
- 十分高的吞吐性能。 实时的线上数据都可能被 ByteHouse 的计算引擎所接管到，而最终可能达到 250W/ 写入 TPS 的性能指标。
- 十分高的查问性能。 ByteHouse 能够使数据从输出端到输入端的流程达到秒级。
- 数据保障。 ByteHouse 可能最终保障到 Exactly Once 的语义，保证数据不失落，也不会反复。最终达到数据是高效存储的，精确的，能够在秒级被查问到的。
场景二：行为剖析
在行为剖析的场景下，能够联合到运维同学十分相熟的一些产品，相似一些事件剖析、留存剖析、转化剖析、各种漏斗图表等等产品性能的底层，其实都非常适合 ByteHouse 作为撑持的。
事实上，在 2017 年，ByteHouse 最早撑持的外部场景也是行为剖析场景。行为剖析场景须要十分大数据量的存储、十分高的数据读取、响应的要求，以及十分大的老本诉求。ByteHouse 的劣势价值有以下三点。
- 撑持大集群。 ByteHouse 通过 HaMergeTree 引擎的反对，通过集群扩容能力的研发，最终才可能让个场景可能撑持到 2400 台集群的极大规模。
- 秒级响应。 想做到秒级响应，就须要做到一直地优化反对——通过字典编码来进行缩小序列化和反序列化的开销，查问性能能力失去晋升。最终达到的成果是 90% 的查问场景可能在 5 秒钟~ 7 秒钟之间失去返回。在这么大一个量级上面，ByteHouse 依然可能达到 10 秒钟之内的响应，是一个十分了不起的成绩。
- 降本增效。 数据量级怎么可能做到进一步的降低成本？事实上，用户每天拜访肯定是有热数据的，也有着一些长期须要被查问的冷数据。在 ClickHouse 的根底下面，ByteHouse 做了二次迭代开发——在 HDFS 下面进行冷热的分存。热数据存储在本地，在 SSD 磁盘上放慢响应；冷数据放在 HDFS 上来进行存储老本的升高。不仅能够做到大集群规模响应很快，它的老本依然可能放弃，十分具备性价比。
场景三：精准营销
最初是精准营销场景。这个场景其实在生产场景上面十分的广泛，每一个产品都须要精准营销，每个产品都须要画大量的漏斗图。在精准营销的背地，如果应用 ByteHouse 来进行数据撑持，会有三个十分重要的优化节点。
- 秒级响应。 ByteHouse 的优化器反对对于秒级响应做到了很大的优化。在优化器的加持上面，可能做到 P95 的整个时长响应可能在一秒之内，甚至可能在半秒钟之内，满足了用户实时看数，实时剖析市场行情的需要。
- 交并补计算。 因为人群的圈选，事实上在用户打了大量的标签，这些标签就是 0 和 1。这些 0 和 1 在进行交并补的计算之后，最终成果能够达到 10 倍到 50 倍的性能晋升。
- 激发效应。 因为 ByteHouse 有更多维度的查问能力和十分快的响应能力，所以用户的每一条查问链路，从输出到输入，都能在一秒钟之内失去响应。所以用户的思维是能够一直地去激发，一直地去发明，一直地去迭代的，这条数据链路精准营销的价值失去一直地晋升，最终可能带来生产上的实在产品价值和实在业务价值。
为了助力企业抓稳数字化倒退时机，减速企业数智能力降级，自 2023 年 2 月 1 日开始，火山引擎 ByteHouse 特地推出为期一年的企业级特惠流动。
企业通过本次流动购买 ByteHouse 服务，包年 1 年可享 8.3 折，包年 2 年可享 7 折，包年 3 年可享 5 折。除根底优惠之外，企业包年购买后，还可取得大量额定资源收费赠送，买二送一，买三送二，买五送三（赠送资源与包年应用期限统一），且以上两项优惠可叠加享受！
点击跳转 ByteHouse 云原生数据仓库 理解更多
