近期，ByteHouse与某数字娱乐公司达成合作，双方聚焦高性能离/在线一体化数仓展开合作。随着自身领域迅速发展的同时，该数字娱乐公司需要更稳定、易用的数据基础服务，但该方面遇到多种挑战，如数据融合与整合、实时数据分析、可扩展性和灵活性、多源数据入仓以及复杂的离线加工任务等。
作为一款云原生数据仓库，ByteHouse基于ClickHouse技术路线进行优化和升级，不仅拥有极致的分析性能、良好的扩展能力，而且有丰富的能力支撑ELT作业，支持fault tolerance、任务拆分等。
2023年该数字娱乐公司就引入 ByteHouse 构建实时数仓服务，2024年又将离线数仓迁移至 ByteHouse 上，至此完成了统一的离线/实时一体化数仓建设。通过数仓一体化升级，大幅提高数据分析的实时性 （天级->分钟级） ，保证了大数据量级下数据处理的稳定性。
背景和挑战
*数据流向图*
如上图所示，在一体化数仓改造前，该数字娱乐公司 的业务数据库在 Oracle 和 TiDB 上，使用 Flink 通过 CDC 方案将数据同步到数据仓库。导入后会经过一系列的离线加工任务，生成供业务读取的表，最终以报表、看板等形式展示到前端。
原架构中离线加工任务是由 Hive 和 Spark SQL 完成的，只有最终加工得到的数据才会存储在 ByteHouse 中，由 ByteHouse 提供实时查询能力。该方案有以下弊端：
- 架构复杂。用户需要维护多套引擎，无论是底层架构、运维方式、SQL语法还是参数调优，多套引擎都截然不同。这造成了额外的维护成本。
- 数据冗余。 从 Hive/Spark SQL 到 ByteHouse 的数据同步链路需要额外开发，且数据是冗余存储了多份。无论从计算，还是存储方面，都造成了浪费。
- 效率瓶颈。当前资源下，该架构已经达到了每日多源数据融合的瓶颈，很难超过日增10亿这个量级。制约了公司业务的发展。
在这种情况下，客户选择使用 ByteHouse 构建一体化数仓，无论是 Adhoc 的报表查询、还是复杂的离线加工任务，都在一个系统中完成，减少运维、计算、存储方面的成本。
技术挑战
该数字娱乐公司 的离线加工场景对 ByteHouse 的能力提出了更高的要求，具体表现在：
-
数据量大。 数据增量每天10亿级别，最大的表10TiB+，数据量1000亿+。
-
加工链路长。 一共200+表，多层加工，任务依赖比较复杂，重试成本高。日常加工任务4-5千个，高峰时每天超过1万。
-
查询复杂。 查询通常涉及大数据量 aggregate、多表 join，容易挤压资源，造成 OOM、超时等报错。
解决方案和收益
提升任务并行度，保障业务平稳运行
传统架构中，之所以要分别建设离线数仓和实时数仓，是因为常见的 OLAP 产品不擅长处理大量的复杂查询，很容易把内容打满任务中断，甚至造成宕机。
ByteHouse 具备 BSP 模式，支持将查询切分为不同的 stage，每个 stage 独立运行。在此基础上，stage 内的数据也可以进行切分，并行化不再受节点数量限制，理论上可以无限扩展，从而大幅度降低峰值内存。
在实际应用中，通过对关键的大表增加并行度，该数字娱乐公司 的离线任务整体内存峰值降低了40% 左右。有效减少了内存溢出的概率，保障任务平稳运行。
任务级重试，减少重试成本
离线加工任务的另外一个特点就是链路比较长，并且任务间有依赖关系。如下图所示，
如上图所示，task4 依赖 task1、task2 的完成。如果 task1 失败发起重试，会显示为整个链路执行失败。
ByteHouse 增加了任务级重试能力，在 ByteHouse 中只有运行失败的 task 需要重试。以10月15日到10月17日为例：
*总数及发生重试的任务数以***脱敏展示*
可以看到，任务的成功率在这三天内分别提高了6.6%、4.4%和2.9%，整体成功率为100% 。除提高任务执行的成功率外，还能显著减少重试时间，体现为降低整体的离线任务执行时间。
大批量并行写入，稳且快
该数字娱乐公司 的业务数据存在频繁更新的特点，使用重叠窗口进行批量 ETL 操作时，会带来大量的数据更新。在这种场景下，ByteHouse 做了大量的优化。
*写入优化示意图*
经过持续优化，将最耗时的数据写入部分单独并行化，并且在写入 part 文件时标记是否需要进行后续的 dedup 作业。在所有数据写入完毕后，由 server 指定一个 worker 进行 dedup 和最后的事务提交（如上图最右）。
经过优化，在保持稳定的前提下，用户十亿表的 insert 作业运行时间从48分钟降低到13分钟，提速73% 。其他相对较小的表插入效率也提高了26%-44%左右。
简化数据链路，提高健壮性
ByteHouse 在传统的 MPP 链路基础上增加了对复杂查询的支持，这使得 join 等操作可以有效地得到执行。在数据交换方面，要求所有 stage 之间的依赖必须在查询执行之前以网络连接的形式体现。离线加工场景下，这种方式有着天然的劣势：
- stage 较多、并行度较大时，每一个 task 出现的抖动都会影响整体链路，叠加的抖动增加任务失败的概率；
- task 同时拉起会进一步对资源进行挤占。
BSP 模式使用 barrier 将各个 stage 进行隔离，每个 stage 独立运行，stage 之内的 task 也相互独立。即便机器环境发生变化，对查询的影响被限定在 task 级别。且每个 task 运行完毕后会及时释放计算资源，对资源的使用更加充分。
在这个基础上，BSP 的这种设计更利于重试的设计。任务失败后，只需要重新拉起时读取它所依赖的任务的 shuffle 数据即可，而无需考虑任务状态。
总结
所有以上提到的这些优化，均建立在ByteHouse提供极速分析性能的基础上。在实时数仓的能力上，通过叠加对离线数仓能力的支持，ByteHouse通过将查询切分为独立的阶段、阶段内进行并行度的拓展，对大查询的内存降低、任务的失败降低、写入效率和整体鲁棒性来说，都有明显的效果。这在最终促成了该数字娱乐公司可以使用ByteHouse一个引擎同时完成数据加工和数据分析，减少了组件冗余，节省了人力成本，大大提高了数据实时性、优化了运营效率。