实时数仓构建：Flink+OLAP查询的一些实践与思考

今天是一篇架构分享内容。

1.概述

以Flink为主的计算引擎配合OLAP查询分析引擎组合进而构建实时数仓，其技术方案的选择是我们在技术选型过程中最常见的问题之一。也是很多公司和业务支持过程中会实实在在遇到的问题。

很多人一提起实时数仓，就直接大谈特谈Hudi，Flink的流批一体等，但实际上，实时数仓包括任何架构体系的构建如果我们抛开成本和稳定性谈技术，那都是有耍流氓的嫌疑。

本文主要给大家进行实时数仓构建的技术选型提供一些经验与思考，面试中如果被问及，也可以谈谈。

2.实时数仓的现状

目前大多数公司的实时数仓业务完全基于Flink计算引擎来搭建实时数据链路，尤其是大多数具有中大流量，或者业务背景较为复杂以及对数据要求强时效性的场景中，无论是做数据关联，还是做业务指标分析，都具有明显的优势，Flink在这些场景中不可或缺。

但是在一些场景中，实时数仓也存在很多问题：

2.1复杂的多表关联分析

在Flink中实现较为完美的多源关联或者说多维度关联比较困难，在多源或者说大规模数据情况下做实时任务，要考虑的问题很多：比如大家经常遇到的join key热点问题，TTL问题，维表本身也会遇到查询的瓶颈，所以又会带来缓存解决方案以及限流问题等。

2.2指标口径的频繁变更

相信大家都遇到过类似的问题，不管是在离线场景还是在实时场景，都会面临频繁的指标口径变更。而在Flink中直接生产多个指标，那么这个任务会变得尤为敏感。每一次的口径变更都会让你痛不欲生。例如状态不兼容的问题，数据需要回溯，主备任务的测试切换问题等等，这个时候可能会想，我为什么要用Flink做实时开发。

2.3小规模非核心场景

Flink本身是需要通过代码开发平台来实现数据处理，这样其整个开发流程就会变得比较重。而在Flink侧做一些小规模非核心场景的任务，开发，测试，预上线，上线。开发耗时长，计算成本高。整个投入产出比很低。而且后期维护也需要耗费大量人力，且运维要求高，需要Flink代码能力。

3.Flink+OLAP查询分析优劣势

所以如果公司的业务场景是完全基于Flink为主+OLAP查询分析为辅助的场景，这种架构在数据处理和分析领域具有显著的优势，但同时也存在一些劣势。

3.1优势：

• 实时处理能力：Flink作为一个流处理框架，具有强大的实时数据处理能力。它能够实时摄入数据流，并进行近实时的计算和分析，满足对数据时效性要求较高的场景。

• 低延迟：Flink能够保证数据的低延迟处理，快速响应业务需求，这对于需要快速决策的场景非常重要。

• 灵活的窗口机制：Flink支持各种窗口机制，可以根据业务需求灵活定义时间窗口，实现对历史数据的聚合和分析。

• 批流统一：Flink支持批处理和流处理的统一，可以方便地处理批量数据和实时数据，提高数据处理效率。

• OLAP查询辅助：结合OLAP查询，Flink可以处理复杂的数据分析需求。OLAP查询具有强大的多维分析能力和快速的数据查询速度，能够为决策提供有力支持。

• 容错性：Flink提供了精确一次的处理语义，保证了数据处理的可靠性。即使在系统故障的情况下，也能够保证数据的一致性。

3.2劣势：

• 复杂性：Flink作为一个通用的流处理框架，其使用和维护具有一定的复杂性。需要具备一定的编程和数据处理解能力才能有效地使用Flink。

• 硬件资源要求较高：为了支持实时数据处理和复杂分析，需要较高的硬件资源，包括计算资源、存储资源和网络资源等。这会增加系统的建设和维护成本。

• 数据一致性挑战：在实时数据处理场景中，如何保证数据的一致性是一个挑战。虽然Flink提供了精确一次的处理语义，但在某些复杂场景下，仍然需要额外的机制来保证数据的一致性。

• 生态系统不够完善：虽然Flink是一个成熟的流处理框架，但其生态系统相比一些其他大数据处理框架可能还不够完善。可能需要依赖其他工具和组件来完善功能。

• 对历史数据支持不足：相比传统的OLAP系统，Flink在处理历史数据方面可能存在不足。虽然可以通过存储历史数据来解决这个问题，但会增加系统的复杂性和成本。

综上所述，Flink为主+OLAP查询为辅助的场景具有实时处理能力、低延迟、灵活的窗口机制等优势，但也存在复杂性、硬件资源要求较高、数据一致性挑战等劣势。

4.解决思路构想

在上面的一系列问题中，我们提出的解决方案必然是要避免其缺点，发扬其优点。可以换个思路，我们将计算和存储完全下移到OLAP引擎侧，利用Clickhouse/Doris等数据库的能力，降低数仓链路的开发和维护成本。

事实上，目前各大公司都有或多或少这方面的尝试与应用。

我们以Clickhouse作为核心存储和计算平台，主要是面向近实时的场景。

那么基于这个平台，我们需要做哪些功能来完善它呢？

4.1.开发和测试平台

需要实现一个可以写Clickhouse Sql任务的平台，能够提供从表到表的数据转化链路。包括但不限于提供接入数据，开发SQL，测试任务，提供查询，导出数据的功能。

4.2.数据建模工具

基于Clickhouse Sql构建一个表元数据管理，数据仓库管理，集市管理，以及任务管理的功能。

4.3.数据质量

需要提供数据质量监测能力。

4.4.数据治理

提供完整的血缘上报，进行全链路追踪。

表的热度分析，慢SQL的监测，结合表热度进行存储分层处理，以及权限和成本问题等。

5.方案总结

基于上面解决思路，可以想象，我们的解决方案已经很清晰了，主要有两大模块。

1.一个实时性支持良好的数据传输通道

2.一个OLAP分析引擎。

例如

可以开发Flink生成自动化模板化的接入数据任务，包括但不限于客户端日志，服务端日志，数据库日志等。解析完成写入kafka.

通过Clickhouse物化视图的方案读取kafka数据，进而构建出近实时的数仓。

以上两个步骤我们完全可以灵活选择，例如第一步我可以通过模板化的FlinkSql来实现。或者使用FlinkCDC功能等。

而Clickhouse还可以用市面上相近的数据库来替代，如Doris或者StarRocks等。

以上，为本次分享内容。

感谢阅读。

按例，欢迎点击此处关注我的个人公众号，交流更多知识。