实时数仓的流批一体

一直没时间来写一下关于实时数仓建设的情况，简单先记录一下。

我们在2021年Q1对产品进行了实时能力的构建。主要架构是kafka+flink计算引擎的方式。我们公司的实时计算能力其实已经做了蛮长时间了，之前数据中心的研发同学使用的是rddm框架的实时模型，此次，我们产品化，是希望能够转变为采用FlinkSql的方式。但如实来讲，当前产品支持的FlinkSql的方式，还没有覆盖到实时模型的全部场景，有一部分开发依然采用了jar包的方式这实时计算平台上运行。

产品化的思路，是通过对实时模型构建，将topic模型化，在Flink上进行逻辑的开发，实现减少重复解析topic字段的工作，也使得实时开发具备像离线开发一样的便捷性，同时降低实时开发的难度。将Flink的Source、Core、Sink产品化，在后台进行FlinkSql的代码优化同时进行物理化剪枝，最大程度节约资源。

以下是我们实时模型构建的过程：

1. 将kafka消息解析，进行Source化，从topic中解析出来字段，构建逻辑模型，同时对逻辑模型进行业务属性的归类，后续可对此进行实时元数据的统一管理。该步骤，可以理解为对现存高频消费的topic进行一次初始化，这些初始化后的实时模型，作为源头表，是可以被所有用户所查看表结构、进行逻辑编写的；此处我们的用户大致分为2类，一种是我们的专业数据研发，另一种是业务侧有实时需求、具备实时基础知识的数据分析师；

在这一步中，我们完成了批量topic的解析，初步形成了业务属性完备的实时模型。这些模型，都是可以在元数据管理中查看到的。

2. 在源头表的基础上，研发同学，可以像访问离线模型一样，对已有的实时模型进行FlinkSql的窗口开发，生成的逻辑模型，首先是需要填写相应的业务属性，其次，逻辑模型的开发脚本是有相应的脚本版本的，第三，由于我们产品本身是具备离线开发能力的，有离线的基础，所以对照当前lamda架构，是可以实现口径对齐。

这一步中，加工实现的逻辑表，也进行了统一元数据管理，同时对生成的脚本进行脚本管理，这里的脚本管理，会涉及到后续用户Sink的代码升级的情况。如果用户Sink所引用的逻辑模型，进行了脚本的升级，后台会判断用户是否有必要进行相应的升级，如果是，则会提醒用户进行升级，如果否，则该模型的脚本升版本，对用户是无感知的。

另外，这里生成和引用的逻辑模型，我们依据一定的策略，进行是否进行Sink物理化的判断。如果是被高频或者性能要求高的逻辑模型，同样会将该逻辑模型进行物理化。

3. 在业务侧实时需求的用户看来，实质上是没有源头表和加工表的区别的，用户无需去思考该实时模型的来源，只需要查看已有的模型，是否可以满足当前的需求即可。如果经过加工，该实时需求可以被满足，则可以将该模型Sink到不同的olap库中，进行应用。

在这一步中，这用户sink的时候，系统会进行物理剪枝以及代码优化的功能，实现节约资源的目的。在用户提交后，系统会自动获取用户当前的消费者权限，对所需的权限进行申请，这审批流程结束后，可直接在实时计算平台上调度该任务。实时计算平台，当前是Data Lake+Flink。

这一步中，由于涉及消费者权限的申请，系统多处做了判断和校验，确保数据的安全性。

以上，大概是产品设计的思路。介于客观原因，产品页面不能在此做记录。后续如有变动，再进行更新。