背景

这段时间因为工作上的原因需要认识下实时计算，这段时间集中看了些材料和书籍，算是积累起了一点点认知，还是本着用写作记录反哺学习的遵旨，把学习过程和心得结构化的记录下来。本文将粗劣的介绍下实时计算平台的搭建，如果你是一枚数据产品经理，且工作过程中有涉及过实时计算相关的内容，希望本文能为你在实时计算上拓展一点点的认知边界，了解如果要做一个最简单的实时计算平台应该怎么去思考。

认识 Flink

如果你是技术同学，那么本节甚至本章可以接忽略和跳过，让我一个数据产品半吊子技术讲 Flink 其实是有点搞笑了。尝试尽可能把 Flink 这块内容给各位产品经理大概说清楚，目的了解它是什么，能做什么，怎么用，以及在这个过程中有什么可以产品化的工作可以做。

首先为什么是 Flink？因为 Flink 本身就非常热门，实时计算认准 Flink 框架，现在业内也都是这么玩的。近年的谷歌热度趋势就可见一斑。

然后 Flink 它是什么？它是一个框架，它不是一个组件。Apache Flink 是一个在有界数据流和无界数据流上进行有状态计算分布式处理引擎和框架。你可以理解框架就是制定一套规范或者规则（思想），大家（程序员）在该规范或者规则（思想）下工作，或者说使用别人搭好的舞台来做编剧和表演。对应在 Flink 这里更加纯粹一点看，当你完全忽略掉 Flink 内部的实现把它当成黑箱，只需要在 Flink 的约束下对它根据它的标准接口规范提交任务，Flink 内部会进行处理就会按照实际的需求进行下游输出。

Flink 好在哪里？从产品经理的角度来看，能解决真实的用户痛点需求而不是痒点需求，同时各个方面的成本足够低就能迅速把市场打下来。简单来说：

• 速度快：作为干实时计算的 Flink 能够提供毫秒级别的验证，时效性足够强

• 高吞吐：能保证了数据处理的低延迟、高吞吐和结果的正确性

• 门槛低：因为框架本身支持丰富的时间类型和窗口计算、以及 Exactly-once 语义支持，使得通过操作 Flink Sql 的形式就进行对数据流进行操作

• 易兼容：能对现有 hadoop 体系架构进行兼容和快速适应，不会像 storm 特别独立

具体 Flink 更多的技术层面介绍可参考 Flink官方文档

基于 Flink 的数据流

上图是一个简单的数据需求实现的数据流过程，可以看到 Flink 在整个业务实践中怎么发挥作用的，图中标示个各类算子在数据流中的生成关系，从左往右看，其中：

数据采集端：Mysql 开启 binlog 日志以后，通过 Flink CDC（Change Data Capture）捕捉 mysql 里的增量变更数据，实时增量变更到 Hudi 中。Flink CDC 现阶段用的比较多，之前阿里的 canal 较为常见，同样用以监听 binglog 日志，同时在监听完以后也会放在 kafka 做一层削峰解耦。

数据存储端：Hudi（数据湖框架，本身也是依托 HDFS 之上封装了更多结构化数据变更能力，包含更新数据，删除数据的能力以及消费变化数据的能力）这里可以理解为就是数仓，同样的位置也可以换成 Hive

数据消费端：这里共计分为两条数据流，一条走流式查询和计算，直接通过 Flink SQL 去查询 hudi 表的方式为前端的帆软 BI 做展示层表达；一条是走 Presto 离线计算，即席查询的形式为帆软 BI 做展示层表达，Presto 这里业内也常用于 Spark，Presto 查询性能足够优秀但是语法变化较大，自己曾亲身体会一个 hive/spark sql 要换成 Presto 要花费大量时间改语法特别麻烦，个人感觉 Presto 比较适合数据探索，但是涉及到业务逻辑复杂的还是用 spark 顺手一点。上图是从网上截的一张图，仅做参考意义。

在这个标准的数据流搭起来以后，新增的业务需求主要将会围绕着后续提交数据任务为主，就是数据开发工程师不断的开发，提交，测试流式计算的 Flink 任务和批处理的 Presto/Hive/spark 任务。其中批处理任务和实时计算分别有各自的开发平台，这里重点学习学习实时计算平台。

实时计算平台

如上面所说，实时计算平台依托于 Flink 来构建，整个实现过程是写 java，Scale 代码打包成 jar 提交到平台运行，这样对技术人员还是有一定要求，一是 Flink 对底层实现和各类 Api 调用逻辑要很了解，二是任务调试和调优比较麻烦，业务应用不断增多的同时开发效率提不上来就很被动。

因为 Flink 本身提供的最高层级的抽象是 SQL 。可以理解 Flink 自己可以通过对 SQL 的转译，最终执行到它流批一体的有界与无界数据流中做数据转换或计算，一定程度上就降低了代码量和使用门槛。那么实时计算平台就可以通过产品化的形式，以交互式开发页面为导向，面向具备数据工程能力的人员（包括算法人员，数据开发人员），提供了一站式的 SQL IDE，通过 SQL 可以完成作业开发和提交作业，实现开箱即用的效果，最终实现提高人效，降低框架学习成本和开发门槛的作用。

整个实时计算任务的生产过程可以分为以下几个步骤：

作业开发：指的就是在 IDE 窗口里面做相关的开发，最基本的从任务创建，版本的选择，yjmytm 参数等相关的配置，可以直接写 sql，可以上传 jar 包，就是基本的开发的窗口，包括支持 table api 的 Pyflink 等切换，

作业调试：通过平台交互提供更多易用功能，调试、语义检测，自动提示补全、语法高亮、调试执行、语法校验、语句美化、全局变量，以及记录任务的版本历史支持方便的上线及回滚操作。这些都能提高任务测试的人效。

作业提交：支持全面的多版本的 FlinkSQL 作业提交方式，诸如 Local、Standalone、Yarn Session、Yarn Per-Job、Yarn Application、Kubernetes Session、Kubernetes Application 等等、以及统一不同云厂商不同的集群环境、提交方式等，将散落在用户各个提交机上的 hadoop 客户端入口进行统一。

作业维护：作业上线下线、作业信息、集群信息、作业快照、异常信息、作业日志、数据地图、即席查询、历史版本、报警记录等

学习过程中也发现了很多简单的开源计算平台：

1、StreamX：https://github.com/search?q=streamX

2、Flink-streaming-platform-web：https://github.com/zhp8341/flink-streaming-platform-web

3、Dlinky：http://www.dlink.top/docs/next/overview

其中 Flink-streaming-platform-web 最简单，可以迅速拉起一套版本出来，能支持提交 jar 包和 sql 的形式；其次是 StreamX，在原来的基础上可以直接构建 git 代码，不需要本地打包，也可以线上编写 Flink 程序运行；最后是 Dlinky，Dlinky 主要是以支持 Flink SQL 为主，调试、语义检测，自动提示补全、语法高亮功能比较全。

总结

其实自己在看的时候发现很多大数据组件无论离线计算还是实时计算，都支持 SQL 的任务提交，虽然 Flink 的 SQL 方式也并不是完全纯 SQL，也有一定的代码，但都还是在做 SQL 化的演进。

自己虽然当时做数据开发时候很短，对这整个实现不了解。但从产品设计的角度来看：数据开发 SQL 化的演进实际上实在降低整个数据流的开发开发门槛，门槛越是降低越是能形成规模化，维度更高一点来看，在各个算子的开发和运维工作门槛降低的过程中，也是在降低整个数据流的信息熵，熵越低，越强调规模化的分工，但也随之带来的是信息量的下降。

具体来说，SQL 确实简化了开发，但是同时也屏蔽了更多的技术细节。实时作业运维工具的需求比如 Trace，或者任务的规范这些并没有发生变化，甚至对这些的要求反而更加严格。因为屏蔽细节的同时，一旦出了问题，用户越不知道如何处理。就好像冰山一角，漏出来的越少，沉在水底的越多，就越需要做好周边体系的建设。