共计 3524 个字符，预计需要花费 9 分钟才能阅读完成。
更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群
随着数据的利用场景越来越丰盛，企业对数据价值反馈到业务中的时效性要求也越来越高，很早就有人提出过一个概念：数据的价值在于数据的在线化。
实时计算起源于对数据加工时效性的严苛需要：数据的业务价值随着工夫的流逝会迅速升高，因而在数据产生后必须尽快对其进行计算和解决，从而最大效率实现数据价值转化，对实时数仓的建设需要自然而然的诞生了。而建设好实时数仓须要解决如下几个问题：
一、稳定性：实时数仓对数据的实时处理必须是牢靠的、稳固的；
二、高效数据集成：流式数据的集成必须不便高效，要求能进行高并发、大数据量的写入；
三、极致性能要求：实时数仓不能仅限于简略查问，须要反对简单计算能力，且计算结果可秒级返回；
四、灵便查问：须要具备自助剖析的能力，为业务剖析提供灵便的、自助式的汇总和明细查问服务；
五、弹性扩缩：须要具备良好的扩展性，必须架构对立具备扩展性，可为 IT 建设提供灵活性。
针对以上问题，火山引擎一直在业务中摸索，总结了基于 ByteHouse 建设实时数仓的教训。
抉择 ByteHouse 构建实时数仓的起因
ByteHouse 是火山引擎在 ClickHouse 的根底上自研并大规模实际的一款高性能、高可用企业级剖析性数据库，反对用户交互式剖析 PB 级别数据。其自研的表引擎，灵便反对各类数据分析和保障实时数据高效落盘，实现了热数据按生命周主动冷存，缓解存储空间压力；同时引擎内置了图形化运维界面，可轻松对集群服务状态进行运维；整体架构采纳多主对等架构设计，架构安全可靠稳固，可确保单点无故障瓶颈。
ByteHouse 的架构简洁，采纳了全面向量化引擎，并装备全新设计的优化器，查问速度有数量级晋升（尤其是多表关联查问）。
用户应用 ByteHouse 能够灵便构建包含大宽表、星型模型、雪花模型在内的各类模型。ByteHouse 能够满足企业级用户的多种剖析需要，包含 OLAP 多维分析、定制报表、实时数据分析和 Ad-hoc 数据分析等各种利用场景。
ByteHouse 劣势一：实时数据高吞吐的接入能力
面对业务大数据量的产生，须要高效牢靠实时数据的接入能力，为此咱们自研了 Kafka 数据源接入表引擎 HaKafka，该表引擎可高效的将 Kafka 的数据接入 ByteHouse，具备有如下个性：
1. 数据接入高吞吐性，反对了多线生产 Kafka topic 对应 Partition 的数据，满足大数据量实时数据接入的需要。
2. 数据接入高可靠性，通过 Zookeeper 来实现主备生产节点治理，比方，当线上呈现某个节点呈现故障或无奈提供服务时，能够通过 Zookeeper 心跳感知机制主动切换到另一个节点提供服务，以此来保障业务的稳定性。
3. 数据接入原子性，引擎自行治理 Kafka offset，将 offset 和 parts 进行绑定在一起，来实现单批次生产写入的原子性，当中途生产写入失败，会主动将绑定的 parts 撤销，从而实现数据生产的稳定性。
具体流程原理如下图所示
ByteHouse 劣势二：基于主键高频数据更新能力
随着实时数据分析场景的倒退，对实时数据更新的剖析需要也越来越多，比方在如下的业务场景就须要实时更新数据能力：
- 第一类是业务须要对它的交易类数据进行实时剖析，须要把数据流同步到 ByteHouse 这类 OLAP 数据库中。大家晓得，业务数据诸如订单数据天生是存在更新的，所以须要 OLAP 数据库去反对实时更新。
- 第二个场景和第一类比拟相似，业务心愿把 TP 数据库的表实时同步到 ByteHouse，而后借助 ByteHouse 弱小的剖析能力进行实时剖析，这就须要反对实时的更新和删除。
- 最初一类场景的数据尽管不存在更新，但须要去重。大家晓得在开发实时数据的时候，很难保障数据流里没有反复数据，因而通常须要存储系统反对数据的幂等写入。
基于以上业务场景的需要，咱们自研了基于主键更新数据的表引擎 HaUniqueMergeTree，该表引擎即满足高效查问性能要求，又反对基于主键更新数据的表引擎，有如下个性：
1. 通过定义 Unique Key 惟一键，来提供数据实时更新的语义，惟一键的抉择反对多字段和表达式的模式；
2. 反对分区级别数据惟一和表级别数据惟一两种模式；
3. 反对多正本高牢靠部署，实测数据去重写入吞吐达每秒 10 万行以上（10w+/s），很好的解决了社区版 ReplacingMergreTree 不能高效更新数据的痛点。
具体流程原理如下图所示
具体的原理细节可查阅之前公布的文章 干货 | ClickHouse 加强打算之“Upsert”
ByteHouse 劣势三：多表 Join 查问能力
在构建实时数据分析的场景中，咱们常在数据加工的过程中，将多张表通过一些关联字段打平成一张宽表，通过一张表对外提供剖析能力，即大宽表模型。其实大宽表仍然有它的局限性，一是，生成每一张大宽表都须要数据开发人员不小的工作量，而且生成过程也须要肯定的工夫；二是，生成宽表会产生大量的数据冗余。
针对宽表模型的局限性，咱们从 0 到 1 自研实现了查问优化器，十分好的反对简单查问的需要，有如下个性：
1. 兼容两种 SQL 语法，反对 ANSI SQL 和原生 CLICKHOUSE SQL ;
2. 反对基于 RBO 优化能力，即反对：列裁剪、分区裁剪、表达式简化、子查问解关联、谓词下推、冗余算子打消、Outer-JOIN 转 INNER-JOIN、算子下推存储、分布式算子拆分等常见的启发式优化能力；
3. 反对基于 CBO 优化能力，基于 Cascade 搜寻框架，实现了高效的 Join 枚举算法，以及基于 Histogram 的代价估算，对 10 表全连贯级别规模的 Join Reorder 问题，可能全量枚举并寻求最优解，同时针对大于 10 表规模的 Join Reorder 反对启发式枚举并寻求最优解。CBO 反对基于规定扩大搜寻空间，除了常见的 Join Reorder 问题以外，还反对 Outer-Join/Join Reorder，Magic Set Placement 等相干优化能力；
4. 分布式打算优化，面向分布式 MPP 数据库，生成分布式查问打算，并且和 CBO 联合在一起。绝对业界支流实现：分为两个阶段，首先寻求最优的单机版打算，而后将其分布式化。咱们的计划则是将这两个阶段交融在一起，在整个 CBO 寻求最优解的过程中，会联合分布式打算的诉求，从代价的角度抉择最优的分布式打算。对于 Join/Aggregate 的还反对 Partition 属性开展。
5. 高阶优化能力，实现了 Dynamic Filter pushdown、单表物化视图改写、基于代价的 CTE（公共表达式共享）。
具体的原理细节可查阅之前公布的文章 干货 | ClickHouse 加强打算之“查问优化器”
实时数仓建设计划
借助 Flink 杰出流批一体的能力，ByteHouse 极致的查问性能，为用户构建实时数仓，满足业务实时剖析需要。
Flink 作为流式数据处理引擎，应用 Flink SQL 为整个实时数仓数据提供数据转化与荡涤；
Kafka 作为流式数据长期存储层，同时为 Flink SQL 数据转化与荡涤提供缓冲作用，进步数据稳定性；
ByteHouse 作为流式数据长久化存储层，应用 ByteHouse HaKafka、HaUniqueMergeTree 表引擎可将 Kafka 长期数据高效稳固接入贮存到 ByteHouse，为后端利用提供极速对立的数据集市查问服务。
具体的数据链路如下图所示
实时数仓各逻辑层性能职责如下：
ODS 层（Operational Data Store）
把生产零碎的数据导入音讯队列，原则上不做任何荡涤操作，字段信息跟数据源保持一致。目标是为了对数据源做收敛治理，数据排查上也好做溯源回查。
DWD 层（Data Warehouse Detail）
DWD 层采纳维度建模实践，针对业务内容梳理业务实体的维表信息和事实表信息，设计 DWD 明细宽表模型，依据设计好的逻辑模型对 ODS 层的数据进行数据荡涤，重定义和整合，整合次要蕴含多流 join 和维度裁减两局部内容，建设能表白该业务主题下具体业务过程的多维明细宽表流。每一份 DWD 表从业务梳理 -> 模型设计 -> 数据流图 -> 工作开发链接 -> 数据校验后果 -> 数据落地信息 -> 罕用应用场景演绎。
DWS 层（Data Warehouse Summary）
该层级次要在 DWD 层明细数据的根底上针对业务实体跨业务主题域建设汇总指标，依据统计场景，设计汇总指标模型。
APP 层（Application）
作为对接具体利用的数仓层级，由 ByteHouse 提供对立的数据服务，是基于 DWD 和 DWS 层对外提供一些定制化实时流。
点击跳转 ByteHouse 云原生数据仓库 理解更多
