一、实时计算架构相关介绍

1. 背景与问题提出

今天要分享的是关于实时计算的相关架构。我们以开放模式的数据服务为核心构建湖仓，整合各类数据统计到湖仓中。在这个过程中，无论是数据流量的管控还是基础构建的选择，都处于开放状态，这样可以支持多种不同的应用场景，用于产品分析。最终，这些数据还能为AI提供进一步分析和报表展示的基础。这种湖仓架构看似完美，但在实际运营中，往往会忽略一些细节，从而产生新的问题。

例如，早上小明到公司后，收到老板的消息，要求统计昨天平台上热销产品的相关统计信息。熟悉业务的小明迅速运用湖仓架构搭建，选择spork作为数据湖，使用datebooks将业务数据导入同步，然后在spork上使用date引擎进行处理，最后用hpi搭建了漂亮的报表给老板。老板很满意，并要求每天更新报表。小明加入dolunfen skidio将其改造成每天调度更新的批链路，但老板又觉得数据更新不够实时，无法支撑业务的实时决策，要求提供实时更新的数据。这让小明犯难了，因为他知道现有的sbook 和spark无法做到实时更新和计算。所以他只能在原有的架构基础上引入新的实时链路，也即flink +kafk链路进行输出实时报表。此时，架构已不再湖仓统一，变成了一种lambda的架构模式。

2.传统架构问题

这种模式在成本、开发运维和效率方面都存在较大成本负担。而且老板还希望看到历史数据和实时数据的对比计算，比如环比和同比计算。这就要求实时和离心的业务口径保持一致，但小明所采用的lanmuda架构存在两套数据存储和计算方式,两套业务的代码，在统计口径上难以对齐，要么只能放弃，要么需要一个全新的架构。

这个新的架构应该是一个统一的湖仓架构，并且能够解决流批一体的问题。今天要介绍的流批一体实时计算湖仓的计算，实时计算UniFlow是一种全新的湖仓架构，它解决上述流批一体的问题。

 

二、实时计算UniFlow架构优势

1.整体架构优势概述

我们先来看左边是传统的lambda架构流程，右边是实时计算UniFlow；流批一体的架构流程。传统架构它为了支撑实时需求，会构建离线链路和实时链路，这两套链路是分离的。比如离线链路可能选用flink +kafka工具，实时链路可能是kafka工具。这种架构存在三个主要问题：一是需要开发两套业务代码，存在大量重复开发建设问题，导致开发效率低下；二是在存储方面，离性数据和实时数据的存储成本较高；三是在同比和环比数据的口径上难以对齐，人工对齐容易出错。

2.各层详细优势

而UniFlow是一种层层递进、每一层都实现了流批一体的架构，能够解决上述三个方面的问题。在业务层，通过flink utaltable统一了用户的流作业和批作业，只需开发一份代码，流作业和批作业会使用流批一体的计算引擎和Flink进行统一计算。使得一套引擎一套代码就可以实现业务的开发。解决了效率的问题。在存储层，使用流批一体的pamo格式进行统一存储，实现了实时数据和离线数据只需存储一份，统一存储解决了成本问题。在摄入层，通过flink ctc工具实现了全中央一体化的数据同步，统一了湖仓内原始数据的一致性，再通过flink SQL系统引擎确保计算逻辑的一致性，解决了数据正确性的问题。

 

三、UnIflow技术细节

1.UniFlow全栈流批一体实时湖仓

UniFlow在架构上的主要优势在于它是一个从数据摄入到存储、计算再到业务逻辑的完整流批一体架构，每一层都是流批一体。缺乏任何一层，都无法使客户达到端到端的留流批体验。即对于用户来说，无需关心流计算和批计算的细节，只需关注业务逻辑，从而提高开发效率和运维效率。

2.Flink cdc无代码实时入湖

接下来详细介绍每一层的产品细节。在数据摄入层，集成了最新的flink cdc yamo能力，用户无需编写SQL代码去做数据的同步，只需开发一个jiamo 配置软件,在这个软件中配置原端和目标端信息，就能将业务数据完整地导入湖仓中，并且在同步过程中，全量和增量数据不间断、不丢失，在此过程中对于加表、密码变更等操作都能实时同步到湖仓当中，做到了完全的自动化。。

3.Paimon 流批一体实时数据湖

同步到湖仓中的数据统一使用paimon 湖仓格式进行存储。这种格式区别于其他数据库格式的主要特点在于它是流批一体的实时数据湖，不仅有完善的批图批写功能，还有强大的流读流写能力，能够将流数据和批数据统一存储，共享存储，这是实现流批一体化存储的基础。这是其他流批一体所不具备的能力。

4.Flink流批一体计算引擎

在计算方面，我们使用流批一体的计算方式和Flink流批一体计算引擎。Flink提供了流批一体的api，使用一份代码就可以以流式的方式执行也可以用p式的方式来执行，并且能保证计算结果的一致性。在UniFlow中，为流计算配备了autparot，能够实时监控业务流量和作业状态，并动态调整作业资源，降低计算成本。在p式执行过程中，内置的调度器会根据数据量选择最优的执行计划和资源进行推进。

5. Flink materialized table声明式ETL统一流批一体作业

然而，即使有了流批一体的计算和存储，在统一用户业务逻辑中的流作业和批作业方面仍存在问题，其本质原因是流计算和批计算的编程模型不同。流计算的编程模型面向无限流，而批计算的作业面向分区进行编程，批作业中存在很多分区管理代码比如into copation,需要将其清理，而这些在流计算中是没有的。编程模型不同导致业务很难统一在一份代码下统一业务逻辑。为了解决这个问题，我们引入 Flink materialized table，创造新的语法。它统一了编程模型从而统一流作业和批作业。右图是materialized table创建的脚本。由三部分组成：一是ctreatal materialized table模型。创建一张特定的物化表，它也属于一种paimon 表，具备其所有的功能；二是按需fresh时间，用于定义业务物化刷新的新鲜度，也就是业务的时效性；三是表的query，也就是业务逻辑部分，这个部分支持除了queyby的任何模型。创建该表后，系统会根据定义的新鲜度选择最优的流或批一体模式自动刷新物化表里的结果。

6.从命令式ETL到声明式ETL

这种表的优势在于简化了开发过程。传统的离线开发面向分区，在业务代码中需要大量分区管理、控制、条件设置和清理等操作，真正代表业务价值和逻辑的部分很少，还需要在分区上配置很多手工调度，在计算机开发过程中称为命令式代码。一步步告诉系统该做什么。这种开发方式成本高、难度大，且让系统失去了很多优化空间。而新的materialized table把etl将命令式开发为声明式。你只需定义业务逻辑和时效性，其他交给系统，系统会根据数据和相关信息推断出最优模型，包括调度和执行时间等。此外，它还具有成本优势，可根据新鲜度选择性价比最高的执行模式。Flink支持3种执行模式，流计算，批计算和分项计算。右图是新鲜度与成本的关系图。在秒和分钟级，流计算成本是比较低的。但是不管客户的新鲜度在秒还是分钟级，流计算成本相对稳定，成本变化不大；因为流计算需要将资源存储，但批计算在小时或天级别的时间尺度下有成本优势，批计算在分钟级别时，由于重复计算和调度成本较高，成本会增加。批计算和流计算之中还有一个是增量计算，增量计算本质也是周期性的批计算，在分钟级别也不太适用，但相对于全量批不需要每次重跑数据，只需要重新跑过增量部分，成本会低一些。Piria table 会根据配置的数据新鲜度和当前数据量，通过成本优化器智能选择成本最低的执行模式，如图中蓝色阴影部分。

在以前流计算总给人一种很昂贵的印象，牺牲了新鲜度的同时并没有换来成本的降低。但是materialized table可以让你按需的设置新鲜度。系统就会按需执行成本最低的模式。也就是提供了新鲜度和成本之间的灵活调整。

 

四、与其他产品比较及行业地位

1.业界流批一体方案对比

在业界流批一体领域有很多相似产品，但Flink在该领域耕耘时间久，产品方案成熟且领先，是业界的流计算实时标准，在批计算领域，在相关性能和稳定性方面处于业界第一梯队，flink社区也孵化了存储paimon，并且发布了流批一体的api materialized table。所以相较于其他产品，Flink在流批一体方向上是最领先的，架构也是最完备的。

实时计算UniFlow是集合了Flink，paimon等相关技术流批一体的产品方案。最近国家标准委员会发布了首个流批一体的目标，实时计算uniFlink是目前业界唯一符合该国标的流批一体分析产品。

 

五、案例演示

1. uniflow天猫流量大屏

为了让大家更直观地感受UniFlow的端到端流批一体能力，我们带来了一个demo。以模拟天猫流量大屏业务构建数仓的deno,会根据flink ctc同步misql到Paimon里，再在里面通过materialized table去构建流批一体分层路数仓。最后通过kbi来展示包庇送。kbi会通过tbox去查询materialized table的数据做实时数据展示。接下来展示uniflow 的demo。

以天猫流批一体大屏建立方案为例：

首先进入MYSQL界面。里面有一个product产品表和userlog业务表。我们模拟真实业务实时灌入数据。我们执行三次的count*可以看到数据在不断的增长，我们的目的是将mysql的三张表数据，我们模同步到pismon DW下，我们可以建立一个数据摄入作业，从MYSQLpipaimon ,他会给我们建立一个真实的模板。这是一个mysql到paimon 的yunmmon脚本，这里的table 同步了mysql里面的所有表格。通过lote功能，重命名表名，加上了ODS的前缀。接着部署上线。

进入到运维页面，点击启动CDC作业，启动完成后可以看到CDC作业统计的信息和状态。然后进入数据管理页面刷新PAIMON 表。可以看到DW已经同步了TABLE 的两张表。同时在stordays中也建立了paimon catelog ，也可以看到两张表的信息。可以去starrocks 查询log表的数据。执行三次，可以看MYSQL里的数据正在源源不断的同步到paimob的ODS中，接下来将致力于PAIMON的ODS数据去构建湖上的流批一体的湖仓，这里会用到flink materialized table 的功能 ，也就是物化表，还是在数据管理页面创建数据表，现在创建物化表的第一个脚本，这是一张ODS user LOG和PRODUCT表去进行关联打宽生成DWD表的脚本，运用该语法后以及根据DSD进行天的分区，定义freshness等于一小时，也就是定义报表义天进行报表，但是数据是以一小时来刷新的。

我们创建一个物化表，同时创建第二个物化表，给予DWD表格进行统计和分析，生成DWDoverall 表格 。同时他和freshness的分区和DWD是一样的，再创建第三章物化表，对商品种类和数据做PV／UV的统计，。三张表格创建完成后进入数据血缘的页面，所以的引擎都能看到，但是还没有开始更新，需要点击更新部署集群，因为定义更新时间为一小时，所以FLINK目前会吧多维批的任务进行一个小时的调度。

进入表的详细页面，可以看到调度的workfraw.因为它会一小时调度一次，但是demon不可以一小时调度一次，随意我们可以手动更新，完成以后我们回到表格页面，可以看到他的信息页面有更新的数据分析，以及可以用过FLINK的数据查询功能对表格进行数据的探查，可以看到当天的点击量是53000多，同时进入sarocks里 执行同样的 query，可以看到它的运维结果是一样的，MT就是一个普通的paimon表，可以支持多引擎的丰富查询的能力。

我们还搭建了一个quick vi 的报表，这个报表会通过starrocks去查询在 DWS创建的两张表的数据生成报表，因为DWS的数据在刚刚还没有进行手动的刷新，我们先进行调度页面进行手动刷新，触发完以后，可以进入WBI页面，可以看到刷新的数据，在第一次的执行过程中，是FLINK会作为全量的批作业进行刷新，当进行第二次调度时，FLin就会识别出每一个部分份量的数据，并进行计算。

接下来我们试验一下他的增量，我们回到DWD的作业部分，进入调度页面，模拟下一次的调度，再进行一次手动作业的触发。进入更新的页面看执行模式。可以看到它的sorce表有一个dmon的属性，dirta的第二次执行是一个增量执行，第一次的执行可以看到TOB图是不一样的，source里的属性并没有dirta，第二次的属性是全链路的属性，现在会带KAKvi的线面，现在他是一个 一小时周期性的调度，用户需要一小时的新鲜度，但老板要求更加实时的数据，传统的方式，你需要端到端搭建实时链路，导致lambda的架构十分复杂，现在基于flink materialized table 你只需要简单的修改数据新鲜度就可以完成工作流程。回到数据血缘页面，修改新鲜度，从一小时改为两秒，同样把下游的两张表进行修改，完整以后FINKL将P5的链路取消，进行实时的数据更新。

进入到详情页面，可以看到流作业的链接，点击可以看到流作业已经启动，所有任务正在进行。然后进去KBI报表页面，可以看到数据报表的结果是实时更行的，每次更新的结果都在不断变化，通过一个简单的新鲜度的修改就可以将批作业的一小时新鲜度更新为两秒，这里还准备了昨天的报表，在数仓里，我们需要对历史的数据进行订正会回装，昨天的数据并没有刷新，所以缺乏报表数据，通过回窗功能刷新出昨天的数据，进入到数据信息的页面点击创建并回刷存取，回刷昨天的数据。数据呈现后，刷新两个表的数据，然后回到昨天的报表页面，当业务完成后，对报表数据页面就能刷新出来，就能完成历史数据回窗的工作。而不需要修改作业SQL的代码，这就是一个端到端在湖上flink+paimon去构建流批一体实时湖仓的演示。谢谢大家。 

2.总结

我们一直致力于引领和推进流批一体的发展方向。希望最终能让用户忘记流计算和批计算的逻辑差异，专注于业务逻辑和业务时效性部分。以上为本场分享的全部内容。