基于Doris实时数据开发的一些注意事项

Doris的发展大家有目共睹。例如冷热分离等新特性的持续增加。使得Doris在易用和成本上都有大幅提升。

基于Doris的一些存储实时数仓在越来越多的场景中开始有一些实践。大家也看到了这种方案频繁出现在社区分享中。但是我们得客观看待这种方案，基于存储的实时数仓有优势也有他的劣势，生产环境中我们要谨慎评估个人的业务场景。这篇文章我结合个人的实践和思考简单说说这个问题。。

为什么有这样的方案？

基于Doris等OLAP实现实时计算的业务很多情况下是基于以下考虑。

在更多的情况下，基于Flink的实时数据开发难度要显著高于离线任务(二者根本不在一个数量级)，基于Doris的存储实时数据开发可以显著降低开发门槛，但是存在滥用的可能。

其次，Flink在大窗口、大状态、灵活计算的场景下并不擅长(注意这里是不擅长，不是不能)，例如在多流Join、维表变更频繁、口径多变的场景下，开发成本极高，但是Doris可以显著降低这一点。

最后，基于Flink的计算数据可观测性差，例如状态数据是不可见的，排查问题，Debug都存在显著门槛，修复历史数据也非常困难。

所以大家可以看到，上述基于Flink为主的实时数据开发存在不小的门槛。所以我们有一个定性的结论，在亿级(或者数千万)数据规模以下，可以使用类似Doris这种的分析引擎，仿照离线数据一样进行分层和定时调度，处理大窗口数据(一般时间跨度超过30天)，在保证性能的前提下，降低实时数据的开发成本，并且提高了数据的可观测性，开发运维效率也有一定提升。

和基于Flink的一些方案对比

门槛低，开发简单

所有人都可以开发这样的任务；

运维简单

因为不像Flink一样考虑状态兼容，不需要大量的资源长期占用。只在运行SQL时需要调度资源；

开发效率提升

不需要对Flink有很深入的理解(当然这不是好事),几乎不存在参数条有，测试简单，无需启动调度容器(例如TaskManager和Task的调度)；

数据调试方便，中间结果落地可见

没有Flink的状态数据，所有数据都在表中可查。

上面几点是一些优势，但是基于Doris的这种方案也存在明显的短板，需要大家特别注意！

延迟明显

如果你采用了Doris，那么我们大概率是配合定时调度进行的，一般调度周期在30秒级以上，意味着数据实时性大幅降低，一些实时观测的指标例如实时GMV、在线人数等场景不适用；

数据规模限制

如果你采用了Doris，那么意味着，你的TPS不能过高，这不是Doris擅长的领域，需要大家特别注意。另外单次扫描的数据不能过大，正如我们前面所说，亿级(或者数千万)数据规模以下才有比较好的性能保证。

最后，如果你真的选择以Doris为主的实时数据开发，那么意味着Doris会成为你的成本、运维中心。要有非常严格的配套工具，例如报警、任务运行监控、任务规范性、调度和血缘能力。要特别注意资源和SQL性能问题，一旦他们成为瓶颈，会影响所有基于Doris的任务运行。