共计 1239 个字符，预计需要花费 4 分钟才能阅读完成。
更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群
近日，《火山引擎云原生数据仓库 ByteHouse 技术白皮书》正式公布。白皮书简述了 ByteHouse 基于 ClickHouse 引擎的倒退历程，首次具体展示 ByteHouse 的整体架构设计及自研核心技术，为云原生数据仓库倒退，及企业数字化转型实战使用提供最新的参考和启迪。
以下为 ByteHouse 技术白皮书【核心技术解析——元数据】版块摘录。
技术白皮书（Ⅰ）(Ⅱ)（Ⅲ）（Ⅳ）（Ⅴ）精彩回顾：
https://xie.infoq.cn/article/5c9471c7adb58e4bb43b69c4d
https://xie.infoq.cn/article/086b4e706965a6bd81f6a6ff2
https://xie.infoq.cn/article/a0dceef1588fe6c58247d3b37
https://xie.infoq.cn/article/9802a36beb0e82fd989991011
https://xie.infoq.cn/article/af5fc530f0d2ce7cbb8cefe5f
核心技术解析
元数据管理
元数据管理（Catalog Service）的性能次要是对读写申请的元数据进行读写操作。元数据服务是一个十分要害的服务，须要保障其本身的高可用和元数据的一致性，元数据服务的扩展性影响整个平台的扩展性，此外元数据读写的性能也影响整个读写过程的性能。
元数据管理须要重点思考上面几个方面的问题，元数据的长久化，和利用缓存对元数据层的减速。
元数据长久化
元数据的长久化，能够有很多不同的存储后端可供选择，例如 KV 型数据库，传统数据库，New SQL。通过综合思考，最初决定抉择 KV 数据库，目前采纳字节外部产品 ByteKV，内部开源的 FoundationDB 也是其余产品常见抉择。
对于 KV 数据库外面须要存储的元数据信息次要有版本、统计信息、事务信息、数据的 Schema、Partition 信息、Part 的信息等。
元数据缓存
因为咱们将 Part 级元数据存储在 ByteKV 中，因而在查问大数据范畴时，是 KV 数据库的 Scan 操作，获取 Part 元数据的工夫较长，且给 ByteKV 带来很重的累赘。因而通过减少一个缓存层进步性能、升高负载。
因为 Insert/Select 语句会在任意的 Coordinator 节点上执行，为保障 Read-Commited 语义，须要确保不同 Coordinator 过程间统一的 元数据读取，采纳
1.Leader Selection 机制保障惟一的 Master
2.Master 保护全局统一的拓扑图
3. 所有 Coordinator 采纳雷同的选主机制保障每一张表有惟一的主节点
4. 表的主节点维持 Cache 的有效性
点击链接，立刻下载完整版白皮书👇
https://www.wjx.cn/vm/Ot0YJFq.aspx#
点击跳转 云原生数据仓库 ByteHouse 理解更多
