更多技术交流、求职时机，欢迎关注字节跳动数据渠道微信公众号，回复【1】进入官方交流群
跟着数据的运用场景越来越丰厚，企业对数据价值反应到事务中的时效性要求也越来越高，很早就有人提出过一个概念：
数据的价值在于数据的在线化。实时核算起源于对数据加工时效性的苛刻需求：数据的事务价值跟着时刻的消逝会迅速下降，因此在数据产生后有必要尽快对其进行核算和处理，然后最大效率完成数据价值转化，对实时数仓的建造需求自然而然的诞生了。而建造好实时数仓需求处理如下几个问题：
一、安稳性：实时数仓对数据的实时处理有必要是牢靠的、安稳的；
二、高效数据集成：流式数据的集成有必要便利高效，要求能进行高并发、大数据量的写入；
三、极致功能要求：实时数仓不能仅限于简单查询，需求支撑复杂核算才能，且核算成果可秒级回来；
四、灵敏查询：需求具有自助剖析的才能，为事务剖析供给灵敏的、自助式的汇总和明细查询服务；
五、弹性扩缩：需求具有杰出的扩展性， 有必要架构一致具有扩展性，可为 IT 建造供给灵敏性。
针对以上问题，火山引擎不断在事务中探索，总结了根据 ByteHouse 建造实时数仓的经历。
挑选 ByteHouse 构建实时数仓的原因
ByteHouse 是火山引擎在 ClickHouse 的基础上自研并大规划实践的一款高功能、高可用企业级剖析性数据库，支撑用户交互式剖析 PB 等级数据。其自研的表引擎，灵敏支撑各类数据剖析和确保实时数据高效落盘，完成了热数据按生命周主动冷存，缓解存储空间压力；一起引擎内置了图形化运维界面，可轻松对集群服务状态进行运维；全体架构选用多主对等架构规划，架构安全牢靠安稳，可确保单点无故障瓶颈。
ByteHouse 的架构简练，选用了全面向量化引擎，并配备全新规划的优化器，查询速度稀有量级进步（尤其是多表相关查询）。
用户运用 ByteHouse 可以灵敏构建包括大宽表、星型模型、雪花模型在内的各类模型。
ByteHouse 可以满意企业级用户的多种剖析需求，包括 OLAP 多维剖析、定制报表、实时数据剖析和 Ad-hoc 数据剖析等各种运用场景。
ByteHouse 优势一：实时数据高吞吐的接入才能
面对事务大数据量的产生，需求高效牢靠实时数据的接入才能，为此咱们自研了 Kafka 数据源接入表引擎 HaKafka ，该表引擎可高效的将 Kafka 的数据接入 ByteHouse ，具有有如下特性：
- 数据接入高吞吐性，支撑了多线消费 Kafka topic 对应 Partition 的数据，满意大数据量实时数据接入的需求。
- 数据接入高牢靠性，通过 Zookeeper 来完成主备消费节点办理，比如，当线上出现某个节点出现故障或无法供给服务时，可以通过 Zookeeper 心跳感知机制主动切换到另一个节点供给服务，以此来确保事务的安稳性。
- 数据接入原子性，引擎自行办理 Kafka offset ，将 offset 和 parts 进行绑定在一起，来完成单批次消费写入的原子性，当中途消费写入失败，会主动将绑定的 parts 撤销，然后完成数据消费的安稳性。
详细流程原理如下图所示
ByteHouse 优势二：根据主键高频数据更新才能
跟着实时数据剖析场景的发展，对实时数据更新的剖析需求也越来越多，比如在如下的事务场景就需求实时更新数据才能：
- 第一类是事务需求对它的买卖类数据进行实时剖析，需求把数据流同步到 ByteHouse 这类 OLAP 数据库中。咱们知道，事务数据比如订单数据天生是存在更新的，所以需求 OLAP 数据库去支撑实时更新。
- 第二个场景和第一类比较类似，事务希望把 TP 数据库的表实时同步到 ByteHouse，然后凭借 ByteHouse 强大的剖析才能进行实时剖析，这就需求支撑实时的更新和删去。
- 最后一类场景的数据虽然不存在更新，但需求去重。咱们知道在开发实时数据的时分，很难确保数据流里没有重复数据，因此一般需求存储系统支撑数据的幂等写入。
根据以上事务场景的需求，咱们自研了根据主键更新数据的表引擎 HaUniqueMergeTree，该表引擎即满意高效查询功能要求，又支撑根据主键更新数据的表引擎，有如下特性：
- 通过定义 Unique Key 仅有键，来供给数据实时更新的语义，仅有键的挑选支撑多字段和表达式的模式；
- 支撑分区等级数据仅有和表等级数据仅有两种模式；
- 支撑多副本高牢靠部署，实测数据去重写入吞吐达每秒 10 万行以上（10w+/s），很好的处理了社区版 ReplacingMergreTree 不能高效更新数据的痛点。
详细流程原理如下图所示
详细的原理细节可查阅之前发布的文章干货 | ClickHouse增强方案之“Upsert”
ByteHouse 优势三：多表 Join 查询才能
在构建实时数据剖析的场景中，咱们常在数据加工的过程中，将多张表通过一些相关字段打平成一张宽表，通过一张表对外供给剖析才能，即大宽表模型。其实大宽表仍然有它的局限性，一是，生成每一张大宽表都需求数据开发人员不小的工作量，并且生成过程也需求必定的时刻；二是，生成宽表会产生大量的数据冗余。
针对宽表模型的局限性，咱们从 0 到 1 自研完成了查询优化器，非常好的支撑复杂查询的需求，有如下特性：
- 兼容两种 SQL 语法，支撑 ANSI SQL 和原生 CLICKHOUSE SQL ;
- 支撑根据 RBO 优化才能，即支撑：列裁剪、分区裁剪、表达式简化、子查询解相关、谓词下推、冗余算子消除、Outer-JOIN 转 INNER-JOIN、算子下推存储、分布式算子拆分等常见的启发式优化才能；
- 支撑根据 CBO 优化才能，根据 Cascade 查找框架，完成了高效的 Join 枚举算法，以及根据 Histogram 的价值预算，对 10 表全连接等级规划的 Join Reorder 问题，可以全量枚举并寻求最优解，一起针对大于 10 表规划的 Join Reorder 支撑启发式枚举并寻求最优解。CBO 支撑根据规矩扩展查找空间，除了常见的 Join Reorder 问题以外，还支撑 Outer-Join/Join Reorder，Magic Set Placement 等相关优化才能；
- 分布式方案优化，面向分布式 MPP 数据库，生成分布式查询方案，并且和 CBO 结合在一起。相对业界干流完成：分为两个阶段，首要寻求最优的单机版方案，然后将其分布式化。咱们的方案则是将这两个阶段融合在一起，在整个 CBO 寻求最优解的过程中，会结合分布式方案的诉求，从价值的视点挑选最优的分布式方案。对于 Join/Aggregate 的还支撑 Partition 属性展开。
- 高阶优化才能，完成了 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云原生数据仓库了解更多
