更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【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 的执行过程：
1. 用户提交 Query 到服务节点
2. 从元数据服务获取须要的元数据信息，对 Query 进行 Parse，Planning，Optimize，生成执行打算
3. 服务节点对 Query 进行调度
4. 计算节点接管到 Query 子查问
5.Query 从近程文件系统获取原始数据，并依据 Query 的执行打算在计算节点上执行，并发回计算结果给服务节点汇总。
数据写入流程
ByteHouse 实现了读写拆散，有独自写入节点来执行写入申请，写入申请分为几类：insert values, insert infile, insert select，insert values 可能蕴含大量数据集，为防止网络传输开销间接由服务节点本地执行 insert 而无需转发给写入节点来执行。
Write Query 模块交互图
Query 的执行过程：
1. 用户提交 Write Query 到服务节点
2. 服务节点从元数据服务获取须要的元数据信息，对 Query 进行 parse，planning，optimize，生成执行打算，依据写入类型分为以下两种模式来执行：
- Local 模式：insert values 操作间接由服务节点跳转到步骤四间接执行
- 分布式模式：对于 insert infile/select 模式间接将执行打算信息分发给一个写入节点执行
3. 服务节点对写入申请依据调度策略抉择适合的写入节点执行
4. 写入节点从读取节点(insert select) 或者内部存储 (insert infile hdfs) 读取数据流写入节点写入数据到本地盘
5. 写入节点 导出 本地盘到云存储
6. 写入节点 更新元数据
后台任务
为了更好的查问性能，会有一些作业在后盾对写入的数据进行更进一步的解决。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、内存、存储资源使用量指标、技术组件衰弱度指标、计算工作状态指标、集群负载和性能指标进行监控，并通过短信、电话等形式告诉值班员。
点击链接，立刻下载完整版白皮书👇
https://www.wjx.cn/vm/Ot0YJFq.aspx#
点击跳转火山引擎云原生数据仓库 ByteHouse 理解更多