随着实时分析需求的不断增加,数据的时效性对于企业的精细化运营越来越重要。借助海量数据,实时数仓在有效挖掘有价值信息、快速获取数据反馈、帮助企业更快决策、更好的产品迭代等方面发挥着不可替代的作用。
在这种情况下,Apache Doris 作为一个实时 MPP 分析数据库脱颖而出,它具有高性能和易用性,并且支持多种数据导入方式。结合 Apache Flink,用户可以从 MySQL 等上游数据库快速导入来自 Kafka 和 CDC(Change Data Capture) 的非结构化数据。 Apache Doris 还提供了亚秒级的分析查询能力,可以有效满足多维分析、仪表盘、数据服务等多种实时场景的需求。
挑战
通常,实时数据仓库要保证端到端的高并发和低延迟存在很多挑战,例如:
-
如何保证秒级的端到端数据同步?
-
如何快速保证数据可见性?
-
高并发情况下小文件写入问题如何解决?
-
如何保证端到端的Exactly-Once?
在上述挑战中,我们对用户使用 Flink 和 Doris 构建实时数仓的业务场景进行了深入研究。在抓住用户痛点后,我们在Doris 1.1版本中进行了针对性的优化,大大提升了用户体验,提高了稳定性。 Doris的资源消耗也得到了极大的优化。
优化
流式写入
Flink Doris Connector 最初的做法是在接收到数据后将数据缓存到内存批处理中。数据写入的方法是保存批处理,同时使用batch.size和batch.interval等参数来控制 Stream Load 写入的时机。
通常在参数合理的情况下运行稳定。无论参数不合理,都会导致频繁的Stream Load和不及时的compaction,导致版本错误过多(-235)。另一方面,当数据过多时,为了降低 Stream Load 的写入频率,将batch.size设置过大也可能导致 OOM。
为了解决这个问题,我们引入流式写入:
-
Flink任务启动后,会异步发起Stream Load Http请求。
-
收到数据后,会通过Http的Chunked传输编码,不断的传输给Doris。
-
Http 请求将在 Checkpoint 结束并完成 Stream Load 写入。下一个 Stream Load 请求将同时异步发起。
-
继续接收数据,后续流程同上。
由于采用 Chunked 机制传输数据,因此避免了批处理的内存压力。并且写入的时间与Checkpoint绑定,使得Stream Load的时间可控,为后面的Exactly-Once语义提供了基础。
恰好一次
Exactly-Once 意味着数据不会被重新处理或丢失,甚至不会出现机器或应用程序故障。 Flink 很早就支持 End-to-End 的 Exactly-Once 场景,主要是通过两阶段提交协议来实现 Sink 算子的 Exactly-Once 语义。
在 Flink 两阶段提交的基础上,借助 Doris 1.0 的 Stream Load 两阶段提交,Flink Doris Connector 实现了 Exactly Once 语义。具体原则如下:
- Flink任务启动时,会发起Stream Load PreCommit请求。这时候会先开启一个事务,通过Http的Chunked机制不断向Doris发送数据。
- 数据写入在 Checkpoint 结束时完成 Http 请求,并将事务状态设置为 preCommitted。数据已写入 BE,此时用户不可见。
- Checkpoint之后会发起一个Commit请求,事务状态会设置为Committed。数据将在请求后对用户可见。
- Flink 应用程序意外结束并从 Checkpoint 重启后,如果最后一个事务处于 preCommitted 状态,则会发起回滚请求,并将事务状态设置为 Aborted。
基于以上,可以使用 Flink Doris Connector 实现数据的实时存储,不丢不重。
秒级数据同步
高并发写入场景下端到端的秒级数据同步和数据的实时可见性,需要Doris具备以下能力:
- 交易处理能力
Flink 实时写入与 Doris 以 Stream Load 2pc 的形式进行交互,这需要 Doris 具备相应的事务处理能力来保证基本的 ACID 特性,并支持 Flink 在高并发场景下的秒级数据同步。
- 数据版本的快速聚合能力
Doris 中的一次导入将生成一个数据版本。在高并发写入场景下,不可避免的影响是数据版本过多,单次导入的数据量不会太大。持续的高并发小文件写入场景对实时性和Doris的数据合并性能非常考验,对Doris不友好,进而影响查询的性能。 Doris 在 1.1 版本中大幅增强了数据压缩能力,可以快速完成新数据的聚合,避免分片数据版本过多导致的 -235 错误和查询效率问题。
首先在Doris 1.1版本中引入了QuickCompaction,可以在数据版本增加时主动触发Compaction。同时,通过提高扫描分片元信息的能力,可以快速发现需要compact的分片并触发Compaction。通过主动触发和被动扫描,彻底解决了数据合并的实时性问题。
针对高频小文件Cumulative Compaction,实现Compaction任务的调度和隔离,防止重量级Base Compaction影响新数据的合并。
最后,采用梯度合并的方法对合并小文件的策略进行了优化。每次参与合并的文件属于同一数据量级,可以防止大小差异较大的版本合并,并逐步分层合并,减少单个文件参与合并的次数,可以大大节省系统的 CPU 消耗。
Doris 1.1 版本针对高并发导入、秒级数据同步、数据实时可见等场景进行了针对性的优化,极大的增加了 Flink 系统和 Doris 系统的易用性和稳定性,节省了整体资源集群。
效果
一般Flink高并发场景
在调查的一般场景中,使用 Flink 来同步上游 Kafka 中的非结构化数据。数据通过 ETL 后由 Flink Doris Connector 实时写入 Doris。
这里的客户场景非常严格。上游保持每秒10w的高频率,数据需要能够在5s内完成上下游同步,实现秒级数据可见性。 Flink 配置 20 并发,Checkpoint 间隔为 5s。 Doris 1.1 版本的性能相当出色。
具体体现在以下几个方面:
- 实时压缩
数据可以快速合并,tablet数据版本数保持在50以下,compaction分数稳定。与之前高并发导入场景下的-235问题相比,compaction效率提升了10倍以上。
){kind=link}