火山引擎云原生数据仓库 ByteHouse 技术白皮书 V1.0（中）

Posted 2023-04-14 字节跳动数据平台

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了火山引擎云原生数据仓库 ByteHouse 技术白皮书 V1.0（中）相关的知识，希望对你有一定的参考价值。

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

近日，《火山引擎云原生数据仓库 ByteHouse 技术白皮书》正式发布。白皮书简述了 ByteHouse 基于 ClickHouse 引擎的发展历程，首次详细展现 ByteHouse 的整体架构设计及自研核心技术，为云原生数据仓库发展，及企业数字化转型实战运用提供最新的参考和启迪。

以下为 ByteHouse 技术白皮书整体架构设计版块摘录。

点此查看ByteHouse技术白皮书（上）

ByteHouse 整体架构设计

ByteHouse 整体架构图

云原生数据仓库 ByteHouse 总体架构图如上图所示，设计目标是实现高扩展性、高性能、高可靠性、高易用性。从下往上，总体上分服务层、计算层和存储层。

服务层

服务层包括了所有与用户交互的内容，包括用户管理、身份验证、查询优化器，事务管理、安全管理、元数据管理，以及运维监控、数据查询等可视化操作功能。

服务层主要包括如下组件：

资源管理器

资源管理器（Resource Manager）负责对计算资源进行统一的管理和调度，能够收集各个计算组的性能数据，为查询、写入和后台任务动态分配资源。同时支持计算资源隔离和共享，资源池化和弹性扩缩等功能。资源管理器是提高集群整体利用率的核心组件。

服务节点

服务节点（CNCH Server）可以看成是 Query 执行的 master 或者是 coordinator。每一个计算组有 1 个或者多个 CNCH Server，负责接受用户的 query 请求，解析 query，生成逻辑执行计划，优化执行计划，调度和执行 query，并将最终结果返回给用户。

服务节点是无状态的，意味着用户可以接入任意一个服务节点（当然如果有需要，也可以隔离开），并且可以水平扩展，意味着平台具备支持高并发查询的能力。

元数据服务

元数据服务（Catalog Service）提供对查询相关元数据信息的读写。Metadata 主要包括 2 部分：Table 的元数据和 Part 的元数据。表的元数据信息主要包括表的 Schema，partitioning schema，primary key，ordering key。Part 的元数据信息记录表所对应的所有 data file 的元数据，主要包括文件名，文件路径，partition, schema，statistics，数据的索引等信息。

元数据信息会持久化保存在状态存储池里面，为了降低对元数据库的访问压力，对于访问频度高的元数据会进行缓存。

元数据服务自身只负责处理对元数据的请求，自身是无状态的，可以水平扩展。

安全管理

权限控制和安全管理，包括入侵检测、用户角色管理、授权管理、访问白名单管理、安全审计等功能。

计算层

通过容器编排平台（如 Kubernetes）来实现计算资源管理，所有计算资源都放在容器中。

计算组是计算资源的组织单位，可以将计算资源按需划分为多个虚拟集群。每个虚拟集群里包含 0 到多台计算节点，可按照实际资源需求量动态的扩缩容。

一个租户内可以创建 1 个或多个计算组，计算资源扩缩容的方式有两种，一种是调整计算组的 CPU 核数和内存大小实现快速的纵向扩缩容，另一种方式是增减计算组的数量实现水平扩容，在存储计算分离的架构下，计算资源与存储资源是解耦的且无状态的，扩缩容过程不需要迁移和平衡数据，因而可以实现快速弹性扩缩容。

计算节点主要承担的是计算任务，这些任务可以是数据写入、用户查询，也可以是一些后台任务。用户查询和后台任务，可以共享相同的计算节点以提高利用率，也可以使用独立的计算节点以保证严格的资源隔离。用户可以根据计算任务的特性、优先级和业务类别不同，构建多个计算组，并设置不同的资源弹性策略，提高计算效率降低成本。

存储层

采用 HDFS 或 S3 等云存储服务作为数据存储层，用来存储实际数据、索引等内容。

数据表的数据文件存储在远端的统一分布式存储系统中，与计算节点分离开来。底层存储系统可能会对应不同类型的分布式系统。例如 HDFS，Amazon S3, Google cloud storage，Azure blob storage，阿里云对象存储等等。

不同的分布式存储系统，例如 S3 和 HDFS 有很多不同的功能和不一样的性能，会影响到功能的设计和实现。例如 hdfs 不支持文件的 update, S3 object move 操作时重操作需要复制数据等。

通过存储的服务化，对计算层提供统一的抽象文件系统接口，存储层采用 S3 还是 HDFS 对计算层透明；计算层可以支持 ByteHouse 自身的计算引擎之外，将来还可以便捷地对接其他计算引擎，例如 Presto、Spark 等。

采用块存储或对象存储作为共享的存储层，带来的好处是多方面的：

首先底层存储是天然支持高可用
存储容量可以无限扩缩
扩容时无需做数据均衡

作业执行流程

ByteHouse 中的作业按照响应优先级分为 3 大类：Read query、Write query 和 Background 的作业。不同类型的作业，按照前面所述，可以运行同一个工作节点上，也可以分离开来。

数据查询流程

服务节点负责响应和接受用户查询请求，并调度到相应的计算组中去执行，并回传结果给服务节点。各个计算节点执行完子查询之后，很多时候会有相应计算结果要集中处理，如果希望这一层有计算组的隔离，务节点的部分功能例如聚合最终结果需要下放到计算组中的计算节点中去。

Read Query 模块交互图

Query 的执行过程：

用户提交 Query 到服务节点
从元数据服务获取需要的元数据信息，对 Query 进行 Parse，Planning，Optimize，生成执行计划
服务节点对 Query 进行调度
计算节点接收到 Query 子查询
Query 从远程文件系统获取原始数据，并根据 Query 的执行计划在计算节点上执行，并发回计算结果给服务节点汇总。

数据写入流程

ByteHouse 实现了读写分离，有单独写入节点来执行写入请求，写入请求分为几类：insert values, insert infile, insert select，insert values 可能包含大量数据集，为避免网络传输开销直接由服务节点本地执行 insert 而无需转发给写入节点来执行。

Write Query 模块交互图

Query 的执行过程：

用户提交 Write Query 到服务节点
服务节点从元数据服务获取需要的元数据信息，对 Query 进行 parse，planning，optimize，生成执行计划，根据写入类型分为以下两种模式来执行：

Local 模式：insert values 操作直接由服务节点跳转到步骤四直接执行

分布式模式：对于 insert infile/select 模式直接将执行计划信息分发给一个写入节点执行
服务节点对写入请求根据调度策略选择合适的写入节点执行
写入节点从读取节点(insert select)或者外部存储(insert infile hdfs)读取数据流
写入节点写入数据到本地盘
写入节点导出本地盘到云存储
写入节点更新元数据

后台任务

为了更好的查询性能，会有一些作业在后台对写入的数据进行更进一步的处理。ByteHouse 中主要包括如下 3 种后台任务。

Merge：将不同的 parts 文件按 Primary Key 做排序合并成一个大的 part 文件。
Checkpoint：对表的任意更新，例如元数据的改变，数据字典等异步构建操作会产生新的增量数据文件，这部分新产生的增量和原有的数据文件会在后台合并成一个新的数据文件。
GC：空间回收，当数据文件中的垃圾空间超过一定阈值后，会触发后台作业回收空间.

数据导入导出

ByteHouse 包括一个数据导入导出（Data Express）模块，负责数据的导入导出工作。

Data Express 模块架构图

Data Express 为数据导入/导出作业提供工作流服务和快速配置模板，用户可以从提供的快速模板创建数据加载作业。

DataExpress 利用 Spark 来执行数据迁移任务。

主要模块：

- JobServer

- 导入模板

- 导出模板

JobServer 管理所有用户创建的数据迁移作业，同时运行外部事件触发数据迁移任务。

启动任务时，JobServer 将相应的作业提交给 Spark 集群，并监控其执行情况。作业执行状态将保存在我们的元存储中，以供 Bytehouse 进一步分析。

ByteHouse 支持离线数据导入和实时数据导入。

离线导入

离线导入数据源:

Object Storage：S3、OSS、Minio
Hive (1.0+)
Apache Kafka /Confluent Cloud/AWS Kinesis
本地文件
RDS

离线导入适用于希望将已准备好的数据一次性加载到 ByteHouse 的场景，根据是否对目标数据表进行分区，ByteHouse 提供了不同的加载模式：

全量加载：全量将用最新的数据替换全表数据。
增量加载：增量加载将根据其分区将新的数据添加到现有的目标数据表。ByteHouse 将替换现有分区，而非进行合并。

支持的文件类型

ByteHouse 的离线导入支持以下文件格式：

Delimited files (CSV, TSV, etc.)
Json (multiline)
Avro
Parquet
Excel (xls)

实时导入

ByteHouse 能够连接到 Kafka，并将数据持续传输到目标数据表中。与离线导入不同，Kafka 任务一旦启动将持续运行。ByteHouse 的 Kafka 导入任务能够提供 exactly-once 语义。您可以停止/恢复消费任务，ByteHouse 将记录 offset 信息，确保数据不会丢失。

支持的消息格式

ByteHouse 在流式导入中支持以下消息格式：

Protobuf
JSON

更多的导入数据源以及导出功能正在不断完善中。

多租户管理

多租户管理架构图

ByteHouse 的计算资源、数据资源、作业任务和用户权限都用租户进行隔离，所有的数据对象和资源都在一个租户内部进行管理。

不同的业务团队可以建立各自的租户，按额度申请所需的计算资源，便于进行资源管理和结算。计算资源隔离在租户内部，屏蔽租户之间的资源争抢。

数据库、数据表、视图等对象都在租户内部进行管理和授权，数据安全限制在租户内部。数据查询、数据导入任务也在各自租户中，增加了任务代码安全性。

多租户管理功能适应了整个企业资源集中统一管理、按需按份额使用、兼顾资源共享和数据安全要求，同时可以为 SaaS 应用提供支撑，能按需为新用户申请资源，做到即开即用，又能满足不同用户资源和数据隔离性需求，实现一套系统服务所有用户。

运维监控管理

ByteHouse 的私有化部署版本包含一个可视化的资源监控和管理平台，提供资源、负载监控仪表盘，直观地展现集群整体状况，同时提供租户管理、报警监控、审计日志、扩缩容、系统升级、故障节点替换等核心功能，让运维人员通过白屏化操作，降低运维成本和操作风险。

集群管理维护模块包括对物理资源的配置、节点重启、故障节点一键替换、滚动升级、滚动重启等功能，实现可视化运维管理。

通过仪表板对集群健康度进行宏观监控，集群资源饱和度监控能实时查看存储计算的当前应用情况和增长趋势，方便进行扩缩容；节点健康度监控能实时监控节点实时的响应情况；集群负载监控能实时反应集群总体负载水位；提供 Grafana 对各个组件运行状态进行细粒度监控。

运维监控模块示意图

监控报警模块提供与第三方报警平台对接能力，支持对 CPU、内存、存储资源使用量指标、技术组件健康度指标、计算任务状态指标、集群负载和性能指标进行监控，并通过短信、电话等方式通知值班员。

点击链接，立即下载完整版白皮书

云原生操作系统创造新可能性！「火山引擎」于鸿磊：多云环境下的云原生操作系统

摘要

2020全球分布式云大会于12月17日-18日召开，火山引擎产品总监于鸿磊出席大会并发表精彩演讲。

“

“分布式云”启动新商业引擎，“云原生”引爆亿万级苍穹，“分布式数据及存储”开创未来新篇。

2020年12月17日至18日， “Distributed Cloud|2020全球分布式云大会”在深圳正式拉开帷幕。大会邀请到华为云、腾讯云、阿里云、金山云、火山引擎、浪潮云、蚂蚁集团、政府主管部门、标准制订方、以及深圳TOP200流量主级运营商等云原生、边缘云开发者相关企业共同参与，以推动技术变革，适应时代发展。

”

在12月17日下午举办的“云原生领导力”论坛上，火山引擎产品总监于鸿磊带来了《多云环境下的云原生操作系统》的主题演讲。演讲中，于鸿磊从介绍产品云原生操作系统出发，分享了火山引擎敏捷高效的基础设施与技术，为企业追求业务持续增长的提供了一种创新技术思路。

于鸿磊首先对火山引擎及其产品做了简单的介绍。火山引擎是字节跳动旗下的数字服务与智能科技品牌。依托字节跳动长期沉淀的、服务于数亿用户的大数据技术、云原生等基础技术服务能力，及成熟的增长理念和方法论，为企业级客户提供稳定成熟的技术产品与解决方案。

火山引擎一直秉承的使命与愿景是将字节跳动经过验证的技术积累和成功实践孵化成提升业务价值的技术红利，释放企业持续增长的潜能。除此之外，火山引擎的产品凭借强大的内容制作的能力、多触点的交互体验、敏捷高效的技术体系、智能算法和智能推荐引擎、独有的增长方法论以及高价值的数据洞察等特点，如今成长为全球领先的智能技术引擎服务商。

在云原生领导力论坛上，于鸿磊就火山引擎敏捷高效的云原生技术进行了分享，希望能够为更多企业实现数字化转型提供赋能。

从企业的角度，于鸿磊认为当前企业面临三个挑战。一是对自身多样的基础设施、多种边缘模式，要形成统一的平台去管理。二是对于不同业务的不同应用架构，要在一个平台进行规模化、标准化的管理。三是对于开发者，要追求开发过程、开发流程朝着更敏感、更高效、更安全的方向前进。对于以上三点，于鸿磊给出了火山引擎的解决方案：毋庸置疑是容器技术。

于鸿磊说：“在内部，我们已经把90%以上的无状态服务，还有70%以上的有状态服务全部都容器化了，如今，我们的在线环境里有6万多微服务、数百万Pod，每周会有差不多几万次的变更，峰值请求高达数亿，所以我们提出并实现了一个概念——云原生操作系统，整体支撑我们产品的海量服务的工程实践。”

火山引擎提出的云原生操作系统，从硬件层、内核态和用户态三个层次实现多云、异构、海量和极致体验的效果。其中，硬件层即底层极致高效的基础设施，包括计算和存储构成云原生硬件底层；内核态是容器化与大规模调度空间，可联动基础设施与应用场景，起到了承上启下的作用；用户态则是一条工具链，为开发者提供开发、测试、运维、服务治理的一套平台。这三层支撑着用户业务应用的高可用、高性能和高效能。

详细来说，火山引擎背靠丰富落地实践，其云原生操作系统的三层架构有着以下显著优势：

由于需要支撑丰富多元的业务形态和海量服务，火山引擎云原生操作系统的硬件层有着极致优化、超大规模、自主可控、云原生、高效管理五大特点，可为前线业务提供云算力、海存储保障。

云原生操作系统的内核态基于火山引擎丰富的客户服务实践经验，具备容器大规模智能调度能力和强大的服务化支撑能力。当客户需要应对在线和离线状态下的高低峰流量时，内核态能通过超售、弹性伸缩和混部控制优化资源配置，保障业务的高稳定性，同时提升资源的利用率。

而用户态的架构与治理则主要体现在微服务和Service Mesh上。一言以蔽之，就是实现了一个高性能多协议的代理和一个灵活可扩展的控制服务，将它们与云平台原生集成，最终通过轻量级RPC框架来输出能力，实现无感知切换。当前企业业务应用的数量正呈现快速增长态势，复杂的调用关系对业务稳定性和底层系统的容灾、单元化、容量规划提出了挑战。火山引擎云原生操作系统通过优化全局工程、多点联动，可以帮助企业解决服务治理难题。

综上所述，火山引擎云原生操作系统脱胎于字节跳动内部的技术能力、增长理念与工具，旨在帮助各行业企业的技术体系转向云原生化，从而在整体上帮助企业应对底层基础架构革新难题，推进企业实现数字化增长。

而除了产品领域的创新，在开源领域，火山引擎也是社区积极参与者。2020 年 11 月 18 日，火山引擎在北美举办的 KubeCon + CloudNativeCon 上宣布正式加入 CNCF，将携数十万级容器集群规模应用实践，全面融入全球云原生技术生态，为云原生的落地应用以及开源生态建设做出持续贡献。

未来，火山引擎会给云原生的落地应用和最佳实践创造更多可能性！