更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群
近日，《火山引擎云原生数据仓库 ByteHouse 技术白皮书》正式公布。白皮书简述了 ByteHouse 基于 ClickHouse 引擎的倒退历程，首次具体展示 ByteHouse 的整体架构设计及自研核心技术，为云原生数据仓库倒退，及企业数字化转型实战使用提供最新的参考和启迪。
以下为 ByteHouse 技术白皮书前两个版块摘录。
1.ByteHouse 简介
ByteHouse 是字节跳动自主研发的云原生数据仓库产品，在开源 ClickHouse 引擎之上做了技术架构重构，实现了云原生环境的部署和运维治理、存储计算拆散、多租户治理等性能。在可扩展性、稳定性、可运维性、性能以及资源利用率方面都有微小的晋升。
截至 2022 年 2 月，ByteHouse 在字节跳动外部部署规模超过 1 万 8000 台，单集群超过 2400 台。通过外部数百个利用场景和数万用户锻炼，并在多个内部企业客户中失去推广应用。
产品个性
ByteHouse 以提供高性能、高资源利用率、高稳定性、低运维老本为指标，进行了优化设计和工程实现，产品个性和劣势如下：
- 存储计算拆散：解决了全局元数据管理，过多小文件存储性能差等等技术难题。在最小化性能损耗的状况下，实现存储层与计算层的拆散，独立扩缩容。
- 新一代 MPP 架构：联合 Shared-nothing 的计算层以及 Shared-everything 的存储层，无效防止了传统 MPP 架构中的 Re-sharding 问题，同时保留了 MPP 并行处理能力。
- 数据一致性与事务反对。
- 计算资源隔离，读写拆散：通过计算组 (VW) 概念，对宿主机硬件资源进行灵便切割调配，按需扩缩容。资源无效隔离，读写离开资源管理，工作之间互不影响，杜绝了大查问打满所有资源拖垮集群的景象。
- ANSI-SQL：SQL 兼容性全面晋升，反对 ANSI-SQL 2011 规范，TPC-DS 测试集 100% 通过率。
- UDF：反对 Python UDF/UDAF 创立与治理，补足函数的可扩展性。(Java UDF/UDAF 已在开发中)
- 自研优化器：自研 Cost-Based Optimizer，优化多表 JOIN 等简单查问性能，性能晋升若干倍。
产品能力上，在引擎外提供更加丰盛的企业级性能和可视化治理界面：
- 库表资产治理：控制台建库建表，治理元信息。
- 多租户治理：反对多租户模型，租户间相互隔离，独立计费。
- RBAC 权限治理：反对库、表、列级，读、写、资源管理等权限。通过角色进行治理。
- VW 主动启停，弹性扩大：计算资源按需分配，闲时敞开。升高总成本，进步资源使用率。
- 性能诊断：提供 Query History 和 Query Profiler 性能，帮忙用户自助地排查慢查问的起因。
实用场景
ByteHouse 定位为一款数据仓库产品，次要用于 OLAP 查问和计算场景。在实时数据接入、大宽表聚合查问、海量数据下简单剖析计算、多表关联查问场景下有十分好的性能。
次要的的利用场景如下：
2. 技术趋势和挑战
业务需要
企业级数据仓库场景中，须要交融来自多个业务零碎数据库的业务数据，次要是交易记录，例如银行存取记录、用户订单记录等，通常是数千万至数亿条规模；用户行为日志是数据量最大的数据源，包含用户拜访日志、用户操作记录等，这部分数据记录数量通常是业务数据的数百倍。
ByteHouse 须要反对海量数据的实时接入、有限扩大存储、实时合并计算和关联聚合查问。
随着大数据利用的深刻倒退，最外围的业务需要如下：
1）进步剖析的实时性
最近 10 年，以 hadoop 技术体系为代表的大数据平台大规模部署，大大小小的企业和政府部门都搭建了大数据平台和剖析利用，以隔天和小时级数据提早的利用失去了遍及；以 Flink 为代表的实时计算引擎解决了数据统计场景的时效性问题。
随着业务的倒退和技术的提高，业务部门不再满足于 T+1 的剖析需要和固化的实时统计，心愿业务产生后秒级 / 分钟级提早就能看到统计后果；心愿能交互性探查剖析数据，要求毫秒 / 秒级返回后果保持良好的用户体验。
在新的企业级数据架构中，对于曾经构建大数据平台的企业，对时效性要求高的业务，用云原生数据仓库构建实时数据仓库，作为 hadoop 平台的补充；在数据量低于 1PB，没有构建 hadoop 等大数据平台的企业，间接以云原生数据仓库构建轻量级数据仓库。
2）老本可控
大数据利用逐渐从互联网企业和政府部门，并深刻到工业企业，先后进行了业务数据的大集中、用户行为数据和 IOT 数据的宽泛采集存储，企业和政府单位的数据量每年出现 30% 以上的增长速度。
在过来集中式架构的数据仓库计划中，建设老本与数据总量正相干，老本居高不下；采纳基于分布式架构的大数据计划中，因为存储计算耦合，为了满足存储空间收缩，须要洽购越来越多的服务器。
实时的数据采集和存储，导致数据量继续高速增长。
在新的云原生数据仓库计划中，既要解决数据和利用增长带来的扩展性问题，同时要解决老本问题，将数据存储和计算成本处于可控范畴。
3）反对业务上云
依据智库报告的钻研，目前业务上云曾经造成趋势，除游戏视频电商等泛互联网企业之外，在政务、金融、制造业正在以公有云和混合云的形式继续上云，从而实现数据上云。
政务云和金融云是两大次要的行业云，平台建设程度较高，同时制造业、医疗卫生、交通等畛域的行业云也在减速改革和放慢建设行业云平台大规模建设和降级，实现数字化治理和经营。
制造业设施上云和云化革新可能实现制造业企业的数据互通和业务互联，撑持造成以数据驱动的智能化制作、实现供应链和上下游业务的网络化协同，以及实现对业务和设施的数字化治理等制造业倒退新模式，引领制造业数字化转型。
业务上云从而数据上云，也在推动数据处理平台的云原生降级。
技术趋势
近年来，以 Snowflake 为代表的云原生数据仓库失去了客户的认同，市场上获得了微小的胜利。其外围性能和技术点是云原生的架构设计，利用 IAAS 的高可用和资源池化个性，通过存储计算拆散、多租户隔离、容器化技术，提供数据仓库的扩展性、稳定性、可维护性和易用性，整体上进步资源利用率。
国内上，除了 Snowflake 之外，谷歌的 BigQuery、AWS 的 RedShift、Azure 的 Synapse 都实现了云原生的架构降级，实现了存储计算拆散和多租户治理。Databricks、Firebolt 等新生的厂商及产品如雨后春笋一样涌现进去。
在国内，阿里云、华为云、腾讯云都推出了本人的云原生数据仓库产品；PingCap 的 TiDB、鼎石科技的 StarRocks 等独立产品也抉择了云原生路线。
OLAP 产品有如下几个技术趋势：
1）云原生的整体架构
基于公共云、公有云或混合云的架构设计，利用容器化和微服务等云原生技术，实现麻利开发、麻利运维，人造解决扩展性问题。
2）存储服务化
对数据存储层进行对立形象，灵便采纳 HDFS 分布式存储或 S3 等对象存储作为数据存储载体，最终实现存储服务化，便于解决存储扩展性、读写吞吐瓶颈问题、数据一致性问题，同时能大幅升高存储老本。
此外，实现存储服务化后，对于产品的跨云兼容和多云部署带来不便。
3）计算资源池化
因为 OLAP 利用负载的稳定特点，特地在反对多租户的场景下，通过计算资源池化，依据实时负载进行计算资源对立调度治理，实现资源隔离的同时，又能反对资源共享和实时弹性扩缩。从而进步集群整体利用率。
4）反对混合负载
在企业级利用中，OLAP 场景能够细分为交互查问和批量计算，前者要求毫秒 / 秒级响应并反对高并发查问，后者能够承受分钟 / 小时级提早，但要求计算性能的稳定性和较好的 failover 机制。自适应反对多场景的混合负载是 OLAP 产品的外围能力。
5）其余
OLAP 平台中的计算资源、内存、网络带宽是最贵重的资源，系统资源利用率通常围绕这三个资源进行优化。很多产品开始在计算 Serverless 化、分布式内存等方向进行摸索。
技术挑战
ClickHouse 是近几年最热门的开源大数据产品，以其优异的查问性能引人瞩目，在寰球失去了大量的推广和利用。字节跳动从 2017 年开始大规模应用 ClickHouse，总部署规模超过 1 万 8000 台，投入微小的研发团队，对 ClickHouse 进行了大量的优化和改良，积攒了丰盛的利用场景和利用教训。
ByteHouse 的云原生技术计划也遇到了十分多的技术挑战，次要体现在几个方面。
数据实时写入性能
在大批量实时数据写入场景下，须要均衡数据一致性与写入吞量的矛盾，特地在存储计算拆散后，近程数据拜访网络开销加大，写入性能问题会显得更加突出，须要有新的解决方案。
多场景下查问性能
ClickHouse 以单表查问性能好著称，但在多表关联查问方面性能不现实，极大地限度了 ClickHouse 的利用场景。ByteHouse 定位为综合性能强的云原生数仓，须要兼顾多种利用场景下都能把持优异的性能。
资源弹性和隔离
ByteHouse 旨在进步整个集群的资源利用率，从而升高平台建设老本。因为 OLAP 利用的负载通常具备峰谷个性和随机性，要求具备资源弹性共享和资源隔离的能力，在保障性能和 SLA 的状况下升高资源老本。
晋升产品易用性
ByteHouse 须要提供计算资源管理、数据资源管理、数据接入、数据利用的可视化治理性能，升高保护和利用老本，成为真正 SaaS 化的云原生数据仓库产品。
点击链接，立刻下载完整版白皮书👇
https://www.wjx.cn/vm/Ot0YJFq.aspx#
点击跳转 火山引擎云原生数据仓库 ByteHouse 理解更多