火山引擎云原生数据仓库 ByteHouse 技术白皮书 V1.0 （Ⅵ）
Posted 字节跳动数据平台
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了火山引擎云原生数据仓库 ByteHouse 技术白皮书 V1.0 （Ⅵ）相关的知识，希望对你有一定的参考价值。
更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【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 进程间一致的 元数据读取，采用
-
Leader Selection 机制保证唯一的 Master
-
Master 维护全局一致的拓扑图
-
所有 Coordinator 采用相同的选主机制保证每一张表有唯一的主节点
-
表的主节点维持 Cache 的有效性
点击链接，立即下载完整版白皮书
云化生长，火山引擎的“云原生”在讲些什么？
我们正处在一个云原生的时代，阿里巴巴、华为、腾讯...... 你叫得上名字的大厂，几乎都和云原生难舍难分。
很多人对云原生的认知停留在“上云”，即“将机房服务搬到云上”。云原生真正的意义还要更深一层，即应用程序从诞生之初就根植于云上，能在云平台之间迁移。落到具体的实践层面，不同的人对云原生的理解也不尽相同。
首次系统提出云原生概念的是 Pivotal 公司的技术大拿 Matt Stine，他将云原生归纳为模块化、可观察、可部署、可测试、可替换、可处理 6 个特质，不过，将云原生概念随着云原生应用推广开的 Pivotal，目前在官网上概括云原生为：DevOps+ 持续交付 + 微服务 + 容器。业内如今普遍采用的是 CNCF 的说法：云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。
虽然对云原生的理解不尽相同，但每个说法都表达了云原生应用“云生云长”的意思。日前，火山引擎作为字节跳动战略层面面向 B 端市场的“三驾马车”之一，聚合了字节跳动的技术能力、实用工具和增长方法，也展示了在云原生上的理解和实践。就此，InfoQ 采访了火山引擎副总经理张鑫，聊了聊他眼中的云原生。
企业构建云原生并非易事。对于企业而言，做云原生首先面临的就是对技术本身的驾驭挑战，需要专业的技术人员和专项的投入；其次将会面临技术和业务目标断层的问题。
张鑫分享了他看到的真实情况：很多企业看到了云原生的技术趋势，在内部推广的时候，面临包括自身技术开发团队在内的很多阻力。“技术层面新老技术需要融合，上层业务和应用需要原生适配，这些不能实现，就不能算是实现了云原生化。”
一项技术的成熟标志是能够广泛地商业化应用。能够广泛地商业化应用的前提，是技术已经有过真实测试，能够适应的业务规模和实现的响应速度，有例可循。
veCompass 是火山引擎的一项重要技术产品，张鑫告诉 InfoQ：“veCompass 在抖音等 App 数亿日活的大体量下，锤炼了很多深度的技术能力，比如超大规模集群的管理和调度。”
据悉，某金融企业为了替代传统 IaaS，实现与云资源管理平台 SDN 网络和存储的无缝集成，利用 veCompass 打造了新型的容器云平台，使开发部署效率提升 500%，资源利用率提升 200%，采购成本也节省了 1500 万。在新零售领域，veCompass 帮助某国内零售企业搭建本地与公有云混合架构，实现微服务改造、多个软件供应商标准化协同交付和线上业务的弹性运营管理，帮助其业务负载值提升 1000%，业务上线耗时缩短 50%，采购成本也节省了 3000 万。veCompass 的这两个案例就是火山引擎云原生能力对外服务的典型。
“技术”和“业务”两个词的无缝衔接，在采访中多次出现。与火山引擎因客户需求诞生的故事一样，“以终为始”的沟通理念，源自于业务层，也深入影响到了火山引擎对底层技术走向的理解。如今，火山引擎提供的服务包括创意内容的生产制作、千人千面的个性化匹配和精细化的用户运营增长方法，高度智能和流程化的工具，以及统一基础服务、个性化推荐和音视频处理等技术。
“火山引擎提供的服务主要在 PaaS 层。”张鑫强调，通过统一的云原生操作系统，屏蔽底层 IT 的差异性，支持研发敏捷的迭代，提供弹性、稳定的算力支持。在统一的基础服务之上，是技术中台，包括研发中台，AI 中台、视频中台和数据中台。技术中台是面向企业研发体系中的人员。面向非研发体系中的人员，火山引擎提供了智能应用层的产品，包括智能营销、智能体验内容和算法等。最上层的是行业解决方案，目前包括互联网、零售、汽车、文旅等行业。
在火山引擎内部，不仅提到云原生，还会提到“原生云”。“原生云”和“云原生”并非对立的关系，前者是在后者更深层次的应用和组合。张鑫告诉 InfoQ，有人觉得云原生是容器，或者扩展到几个经典技术如容器、微服务等的集合，但从他的角度，理解云原生首先要明确主语。
“在我看来，这个主语其实应该是企业的业务和应用架构。上层的应用架构和整个业务系统，能够充分利用云的这种弹性、敏捷和高性能，才是云原生最本质的东西。云原生应该是一种应用的新的架构，这是最核心的一个点。为了实现这种新的应用的架构，我们可以采取不同的技术手段，比如容器、DevOps 等，未来我们可能还会有新的一些技术实现。”
换句话说，相较一提到“云原生”大家讨论的各项技术，火山引擎“原生云”更突出关注如何构建应用架构，将最佳实践固化在平台上，帮助企业实现业务增长。“原生云不给客户出选择题，而是把我们（字节跳动）自身过去的面向互联网原生的应用、背后的最佳实践，固化在我们平台上，让企业能够更轻松地使用这种轻服务的方式。”
据悉在容器的发源地谷歌，彼时绝大多数的应用、业务甚至是应用开发人员，根本不知道底下是容器，也不需要关注，只是知道写出来的代码会被打包到容器里，被类似 Kubernetes 这样的系统去调度。
技术的发展不断演化。仅就容器技术来看，经过了数十年的发展，才在 Docker 上发扬光大，如今在 Kubernetes 上广被使用。技术要解决的是什么问题？不仅要解决速度的问题，还要解决规模的问题。“原生云”是业务视角下对“云原生”的一种解读和应用。
从诞生至今，云原生在技术层面已经相对成熟。从容器和 Kubernetes 角度来看，云原生不仅在重塑上层应用架构和应用开发部署的方式，也在拉动 itstack 改变。比如容器的出现，使容器之间的通信模式也在发生改变；在应用安全层面，以前只需要考虑代码安全，现在因为多了一层容器，所以还要考虑容器本身是否有安全漏洞，很多安全领域的产品需要重新设计；在存储方面，云原生可以做到计算和存储分离，让资源利用率更高，更加有弹性；在数据的领域，出现了基于云原生的数仓；在运维方面，以前基于虚拟机，现在必须要基于容器。
张鑫认为，目前云原生的发展还有四个方面需要攻坚：
第一是性能。从技术的角度来看，容器往往要结合微服务使用。但是当微服务多了以后，就会产生业务以外的损耗，涉及到很多额外的跨主机的通讯成本。如何提升整个微服务体系或者说服务网格的性能还需要做很多工作。
第二是安全。近期就出现了容器安全逃逸事件，有人利用容器的漏洞，去做一些挖矿的事情。
第三是可观测性。容器微服务化以后，给运维和管理带来了很大的复杂度的，怎么样让新的容器体系更好地管理，也是目前比较热的一个方向，即通过可观测性，能够溯源、去做全链路的追踪和多维度数据的融合。
第四是实现智能化的运维。Kubernetes 只是实现了自动化，并没有完全实现智能化。自动化做好参数的调配设置就可以真正达到智能化，是可以通过系统自己去观测，基于数据驱动不断地进行自配置、自适应，从而达到调优。
“从上层的业务视角，是不是有一个足够好的 PaaS 层产品后者 SaaS 层产品，让大家不知道底下跑的是这么多的容器或者其他技术，反而达到一个无声胜有声。”
武功的至高境界是化有形于无形，张鑫认为，云原生的最高境界，就是“没有”云原生。
相较于其他大厂，2020 年才开始对外开放云原生能力的字节跳动，看起来像是云原生“后浪”。不过据 InfoQ 了解，字节跳动内部的云原生实践早在 2016 年就开始了。当被问到“后浪”是否有机会超越“前浪”时，张鑫表示，最关键是看技术是否处于变革期，是否处于换代的关键点上。
“如果是处于技术变革期，等于是把所有人又再次拉到了同一个起跑线上。‘前浪’由于历史包袱，反而不一定能起跑的快，而‘后浪’由于没有退出成本，反而能更好地运用新技术、新理念、新架构、新硬件，实现超越。”
字节跳动没有很多存量的历史包袱，对新技术、创新架构的拥抱会比较积极，投入力度也会更大，比如如何在网络上如何基于 RDMA 做高性能传输，基于智能网卡做硬件卸载等。张鑫说：“也正是因此，字节跳动在新技术上有很多沉淀。这里拿 Kubernetes 举例，虽然它现在非常成熟，但本质上还是一个技术，而企业在技术驾驭上还有挑战。典型的问题是，容器的部署和应用需要分配 CPU 和内存，到底应该给 CPU 和内存分别分配多少？Kubernetes 可以做很多调度，但在线的业务和离线的业务如何做配置？对于这些，火山引擎都可以把字节的经验对外开放服务。”
在外界看来，成为企业服务的第一梯队收入肯定是重要的一个指标，但在火山引擎看来，实现了差异化和特色，其他的事情水到渠成。目前，火山引擎最关注的事情是能否真正原生的面向现代化应用的架构，帮助企业实现业务的增长，而不仅仅是解决 IT 问题或者架构问题。
以上是关于火山引擎云原生数据仓库 ByteHouse 技术白皮书 V1.0 （Ⅵ）的主要内容，如果未能解决你的问题，请参考以下文章
火山引擎云原生数据仓库 ByteHouse 技术白皮书 V1.0 （Ⅴ）
火山引擎云原生数据仓库 ByteHouse 技术白皮书 V1.0（中）
助力企业数据飞轮转起来！火山引擎云原生数仓ByteHouse全面大促中
ByteHouse技术白皮书正式发布，云数仓核心技术能力首次全面解读（内附下载链接）