Flink/Doris生产环境方案选型的一些思考-技术圈

各位总监，技术负责人，架构师们大家好。今天的文章有点短，是一些个人思考，仅做记录。

以Flink为主的计算组件和以Doris为代表的存储+计算一体的方案选择问题是我们在技术选型过程中最常见的问题之一。也是很多公司和业务支持过程中会遇到的问题。

这个问题非常「实在」也很「接地气」，因为这些技术选型问题在生产环境客观存在，更关系稳定性和成本问题。

如果大家在面试中被问到了，也是一个很好的问题。

目前很多公司的大部分业务完全基于Flink计算引擎来搭建实时数据链路，尤其是在大流量/较为复杂业务背景/强时效性场景中，无论是做关联，还是做指标分析，都有明显优势，Flink在这些场景不可替代。但是在一些场景中，也存在很多问题，我们随便举几个例子：

这个场景相信大家都遇到过，在多源/大数据规模下做实时任务，要考虑的问题太多太多，一不小心就会踩坑，比如大家经常遇到的join key热点问题，TTL问题；维度表本身也会遇到查询瓶颈，所以又会带来缓存和限流问题等；

这个大家应该不陌生，在Flink中直接生产多指标，这个任务会变得非常敏感，因为你大概率会遇到状态不兼容问题、数据回溯问题，主备任务的测试切换问题等等，简直不要太离谱；

在Flink侧做这类任务有点杀鸡用牛刀的意思，成本较高，投入产出比也很低；

所以如果我们的场景是完全基于Flink为主+OLAP查询为辅助的场景，他的优势很明显，劣势也暴露无疑。

所以，在上面的一些场景下，不妨换个思路。我们把计算和存储下移到OLAP侧，利用Doris/StarRocks等数据库的能力，降低数仓链路的开发和维护成本。

我们用Doris作为核心存储和计算介质，主要面向近实时场景。如果建立这样的目标，我能想到的几点要做的：

这个不用详细展开，相当于开发换成了Doris SQL；

例如表元数据、维度指标管理、Doris建模推荐等；

也要做质量检测和准入机制；

例如表的热度、慢sql检测、成本、权限问题。

基于上面两个大的思路，我们都可以基于他们做一体化解决方案平台。当然很多公司多多少少都会这么去做，只是处在的发展阶段不同。

这样的话，我们在综合考虑业务场景、数据规模、开发和迭代成本后，技术方案就可以在两个大方向上做灵活选择。

300万字！全网最全大数据学习面试社区等你来！

如果这个文章对你有帮助，不要忘记 「在看」 「点赞」 「收藏」 三连啊喂！