01 流之源

以终为始 – 源

了解流计算之源，我们需要看一些自然现象，我们从左往右看，第一个词斗转星移，描述的是地球绕太阳旋转和地球自转的自然现象。后面的改朝换代，生老病死，四季变化，日月交替也是被大家共识的客观事实。这些词语虽然不同，但这些现象都包括了很核心的几个共性：

那就是这里面都是有时间属性，同时伴随时间都会不断的发生具体事件，同时在事件的作用下，整个环境也都发生着必然的变化。现在我们聊一个大家都熟知、但却充满着 事件/计算/预测 等方面要素的事情。

我们在很多文字中都会看到 “一叶知秋”这个词，比如《淮南子·说山训》:“见一叶落而知岁之将暮”。这里是说凭借细微之处可以知道深远的东西，看到一片叶子落下，便知道一年将要到尾声。还有 宋·唐庚《文录》引唐人诗:“山僧不解数甲子，一叶落知天下秋。”是说山里的和尚不知道怎么计算年月，从一片树叶的凋落，就知道了秋天的到来。

这里一叶知秋也比喻通过个别的细微的迹象(事件），可以看到（分析）整个形势的发展趋势与结果。那么，这里叶落是事件，知秋是根据事件进行分析得到的结果。那么我们追溯到这个词语是怎么产生的时候，会自然的思考到底怎样得出树叶落下就要到秋天这个判断的呢？我想那一定不是第一次看见落叶就能得到这个结论，而是有人（大脑）记录了几十次，上百次的现象（事件）观察。因为每次叶落事件发生之后，都会规律的气温下降，进入秋天的客观事实作为依据，进而得到“一叶知秋”的分析结果。这里面善于观察总结的人类就是一台流计算系统，输入是随时间产生的各种事件，这些事件包括叶落是事件，降温入秋也是一个事件，人类的智慧通过分析找到了叶落这个事件和降温入秋这个事件必然关系，这个关系就是分析的结果。就像我们每年进入双11大促，各个商家一定要补充库存一样，就像各个商家补充库存，参加活动时候，每个电商系统背后的工程师就要进行系统的扩容，或者对技术体系进行换代升级一样，但是这里就没有一叶知秋那么简单了，比如要扩容多少，性能提升多少能平稳度过大促，这样的数据可不是一个人脑能解决的，这样就涉及到了计算机（电脑）了，当然这也不是一台计算机能解决的，而是一个计算机集群系统，这个大脑是一个集群，而流计算就是这个集群的思维方式之一。

其实，我们的生活中有很多这样通过人类的智慧，对现实生活中大量的自然现象数据进行分析推理，进而得到的很多规律性认知，比如：在四季分明的北方生活的朋友，一定知道“大雁南飞冬将至”。再比如我们对日月星云的分析总结相关的规律各说一个，如下：

日：红日雨，白日风，明星月朗大晴空。

月：月亮周围有圆圈，刮风就在明后天。

星：久雨见星光，明朝雨更狂

云：乌云接日头，半夜雨不愁

风：久晴西风雨，久雨西风晴

物：蟋蟀上房叫，庄稼挨水泡。

其实，我们生活在一个时间维度的现实世界，流计算只是将现实生活中的人类对自然数据分析能力的高度抽象与规模升级。既然，我们今天探究流计算之源，我们就再多说些和流计算相关的自然现象，供大家思考。

我们人类这台大的流计算系统，对自然界源源不断输入的客观事件进行分析沉淀，形成了很多客观的规律数据，比如今天是2021年12月21日，也就是冬至日，针对冬至日的到来，人类也对冬至日之后的气温变化作出了精准的预测：即，我们熟知的数九歌里面描述的，在冬至日之后的第一个9天和第二个9天，天气变冷，外出必须带上手套保暖。在第三个9天和第四个9天期间北方河流会河水成冰。一直到三个月左右就到了春耕的季节。这些其实都是根据历史数据分析而得到的。

那么，像冬至这样的节气性总结，人类的智慧已经总结出了24个节气，这些都是成百上千年的迭代分析，才形成的分析结果。这些虽然只是人类无限智慧的冰山一角，但这些事实已经证明了人类对自然现象强大的计算能力。

我们由一叶知秋，到冬至数九歌，到人类总结的24节气，我们不难想象出人类本身就是一台庞大的流计算系统，在随着时间推移的历史长河中，万物变化的各类事件，经过人类大脑不断的进行着学习计算，进而人类具备了对万事万物未来发展的预测和判断的能力。而这个过程中万事万物的变化事件就是输入，人类对事件的认知和对规律总结的利用来形成新的规律的过程就是计算分析。借助历史沉淀的经验对新事件进行加工本身就是增量计算的体现，在这过程中，时间就是潜在存在的必要因素，而这些要素正是流计算产品所必备的核心要素。所以任何技术产品的原型都源于自然，流计算产品的源头也是让大家敬畏的宇宙自然。如果我们的技术体系完全能够融合，完全的模拟和虚拟自然宇宙，我想元宇宙也就真的成为完整的现实虚拟了。

但这里我们也不难发现，人类这台流计算系统最大的不足就是计算的周期太长了, 大数据时代我们需要流计算产品有更低的计算周期，更低的计算延迟，进而最大程度的让数据产生价值，为人类决策进行有力支撑。

02 价值空间

以终为始 – 目标（创造价值）

今天和大家分享的整体思维逻辑是“以终为始”，我们先知道我们最终要达成的目标，再反向规划流计算产品所应该具有的未来。第一个点，我们思考流计算产品的最终目标是什么？每个人思考的维度不同，视角不同，回答流计算产品的目标就可能有不同的答案，但不论从哪个视角给出的流计算产品目标，最终在持续挖掘，逐本溯源之后都会回到一个最简单，甚至大家认为是废话的答案：“那就是流计算产品最终的目的是让Data产生价值“。是让Data经过流计算产品的处理最终让Data产生预期的价值。这个目标看起来简单，后面逐层的为大家分析如何才能达成这么一个简单的目标时候，大家就会发现，简单的目标蕴含着巨大的挑战。包括技术层面，产品层面，业务领域等各个维度都充满着不同和挑战。我们继续往下聊...

以终为始 – 空间（1000亿+市场）

这里我们说流计算产品有千亿的价值空间，当然，这个空间不是我个人空想出来的，我们有权威机构统计数据。

这里我们会发现来自权威的市场分析报告，流分析从2020年有125亿的市场空间，到2025年有386亿的潜在市场，我们大概换成人民币是从2020年800亿到2025年2470亿的增长，从这些数字我们看到每年增长率高达每年25.2%。这是一个流计算产品提供商流口水的数字，这是让流计算产品工程师对未来充满希望的数字。流计算产品有这么大的空间，那么在整个公有云的市场空间是怎样的呢？

根据Gartner的最新预测，全球公共云服务的最终用户支出预计将在2021增长23.1%至3323亿美元，远高于2020年的2700亿美元。相对公有云市场空间和全球流计算市场空间来看，这些数字在彰显云计算市场空间之余，也证明着流计算产品在整个云计算产品生态体系里面的重要地位，流计算市场空间是公有云市场空间的近20%。这是我们在流计算产品持续精耕细作的巨大使命动力。那么，我们流计算产品应该长成什么样子呢？

03 核心场景

以终为始 – 场景（Integration + Analytics）

流计算产品长成什么样子，完全取决于流计算产品所要解决的业务场景，不论流计算产品可以解决怎样的业务场景，我们都知道巧女难做无米之炊，那么流计算产品发挥自身价值的前提是什么呢？最简单的表达就是流计算产品首先要有Data作为输入，当然按照这样的思考流计算最终输出也是一系列的Data。那么输入是Data，输出也是Data的流计算产品，可以让输出Data和输入Data有怎样的不同，就是流计算产品所具备的产品能力。我们把这个能力宏观展开一下看，到底流计算产品应该具备支持怎样业务场景的解决能力。

这里被大家熟知的有两个比较宏观的能力需求就是：“数据集成”和“数据分析”。我们将这两种能力稍微展开一点来对每种能力进行描述。

第一个就是数据集成场景能力，该类场景侧重于解决数据到达时不需要立即进行数据分析的业务情况，但这些场景需要在数据到达时立即进行实时的数据接收，并有一定的数据过滤和数据变化需求。比如ETL(Extraction, Transformation, Loading )，CDC（Change data capture)等。最终数据会存储到数据湖或者数据仓/库等存储系统，供以后对静态数据进行分析。也就是说，数据集成能力是要求流计算产品作为大数据产品生态体系的数据连接器，具备外部系统连接和数据输出到外部系统的能力即可，这里强调需要一个实时性的需求。

那么第二个“数据分析”场景需要的能力具体一点如何描述呢？数据分析类场景，核心是对需要在数据到达时候，立即对数据进行连续的动态分析，并需要精准的分析结果供下游业务系统使用。比如对电商数据、传感器数据和服务器日志数据等进行实时性要求很强的聚合分析、数据预测、进而达成监控预警和智能决策等业务目的。数据分析类场景对流计算产品提出更高的能力要求。也就是说，这个场景能力需求，不但要求流计算产品有数据连接能力，还需要有对数据进行复杂的聚合，预测甚至是决策等更高要求的能力满足，并且特别要强调这些分析的能力是要求实时的，对处理的时效有很高的要求，当然这也是流计算产品当仁不让的职责所在。

虽然我们对这两点能力进行了描述，但是对于在流计算产品投入时间较少的朋友来说，还是不清楚流计算产品到底需要进行有怎样的具体功能开发，那么我们再掰碎一点看看。

第一部分我看数据集成部分，顾名思义数据集成是对外部系统的集成能力，那么流计算产品要集成哪些类型的外部系统呢？

我们把外部系统的统称为流数据的制造者，这些制造者包括物，包括人，包括系统，也就是 Things/Persons/Platforms。这些流数据的制造者产生的数据具备很明显的特点，就是种类多，体量大，实效性比较强。那么面对这样的数据特点，流计算产品支持数据集成场景需要怎样的能力呢？

首先在具备连接能力之外还需要对每种连接有丰富的数据format能力，其次对于无用的数据具备简单实用的数据过滤能力，特别强调一点，出于成本和效率的思考，流计算产品针对不同外部链接过滤能力的下沉是非常重要的实现要点。除此之外还需要具备的简单转化能力，比如各种scalar的转换能力等待。在这个场景中，数据的转换能力要不高，但对流计算产品的吞吐能力和实时性有很高的要求。这个要求也充分体现了流计算产品，流本身的自然语义。

当然，数据处理之后最终还是要流入其他下游系统，数据流出就需要对数据质量（对于下游业务系统来说）有很高的要求，这是数据价值的第一层面体现。下游系统我们归类称之为是 流数据的消费者。在数据集成场景中，流数据的消费者往往具备数据分析的能力。如 数据仓库，数据湖等。

那么如果流计算产品不但承担数据集成职责还要具备数据分析能力的话，我们应该在流计算产品上开发怎样的能力呢？

最简单的数据分析，可以进行数据的reduce操作，我们也叫做聚合操作，当然聚合操作面对无限的流数据场景，还会必然的有各种数据分组的能力的要求，也就是数据窗口的抽象能力，面对各种复杂的系统数据，数据之间的各种Join能力也是必不可少的，这里面由于有聚合函数的高度抽象和用户自定义能力开放 ，在框架清晰、能力开放的流计算产品中，流计算产品可以让用户有无限的创作空间。

也正是因为具备数据分析能力的流计算产品可以帮助用户做更多的数据处理，进而下游的业务系统也会相对于只具备数据集成能力的流计算产品有很大的不同，下游系统距离终端用户会越来越近，比如可以直接对BI系统，直接对接监控报警系统。同时，具备数据分析能力的流计算产品除了具备实时性的挑战之外，还需要有数据分析结果高精准的要求。

实时性和数据分析精准性分开来看待时候，相对容易达成，但是如果要求实时性和精准性同时满足的时候，对流计算产品是一个巨大的挑战，后面我会和大家一起分析业界的现有解决手段，以及现有解决方案的不足，甚至和大家一起YY未来的可能的解决方向。

这里我们还要有一点注意那就是闭环问题，整个大数据产品生态体系，不仅仅只有流计算产品这是大家共识的，但流计算产品在整个大数据产品生态体系里面，让数据产生业务价值的过程中，也并不是一条业务数据处理链路中只使用一次流计算产品，更多的可能是流计算产品流出的数据经过其他领域性系统处理之后还会将数据再次流入流计算产品，这一客观事实对流计算产品的数据结构的设计和流计算各种语义设计提出了显而易见的高要求，这里说一个例子，比如：Apache Flink中RowData的数据结构设计和为了在流计算场景下解决数据计算精准性问题撤回机制的设计等，都是需要考虑流计算流出的数据是有可能反复流入到流计算产品的。那么流计算产品面对这样的业务场景和需要的功能抽象中，有哪些具体的技术难点挑战呢？下面我们挑1-2个重点分析一下。

04 技术挑战

以终为始 – 技术(Low-Latency)

对于流计算产品来说，不论是只具备数据集成能力，还是一并具备数据分析能力，实时性都是流计算产品至关重要的技术挑战。那么怎样的计算延时才算是具备实时性呢？是分钟？秒？毫秒还是微妙？那么不论我们在技术上将实时性达到怎样的级别，我们都要考虑哪些设计因素决定了流计算产品的计算实时性呢？

宏观来看，流计算产品实时性有两个非常重要的实时性设计因素，一个是待计算的数据，一个是计算的时钟，我们前面说到流计算产品就是可以处理流事件的产品，流事件的核心是事件和时间，所以实时性设计和时间密不可分。那么这两个核心因素会对计算实时性有怎样的设计影响呢？

由这两个因素激发了两种不同的设计思维，一种是我们可以数据驱动的方式设计流计算产品的实时性机制，也就是我可以单位数据触发计算一次，当然单位数据可以是1条数据。另一种思考方向是我可以是单位时间触发一次计算，比如每秒触发一次，这种设计同样在理论上也可以达到足够的实时性。至于说哪个思维更好？我们需要结合工程实践综合来看。

对于第一种思维的设计模式我们简单描述一下：“流更多的形容数据流，以数据流的自然状态设计触发计算的模型，我们称之为流计算，单位数据为1条数据的时候，计算的触发是最及时的，计算结果的延时也是理论最低的。当数据单位由1条延展到多条时候，多条可以认为是一个批次，进而得到批是流的特例认知。”

对于第二种思维的设计模式我们也文字描述一下：“单位时间所蓄积的数据，我们称之为一批数据，以一批数据作为计算单元触发计算的模型，我们称之为批计算，极端情况下1毫秒积攒一批数据进行触发计算，也是该模型下是最及时的，计算结果的延时也是理论最低的。进而得到流是批的特例认知。”

很幸运这两种思考模式都有对应的开源工程实现，青睐 “批是流的特例“ 的Apache Flink，和认为 “流是批的特例” 的Apache Spark，两个计算框架都是目前最优秀的开源实现，这两种实现，在一定的场景下也都实现了低延时的特定技术指标。

也就是说，流计算模型和批计算模型都能在一定程度上达到了Low-Latency，那么理论指导工程实践，工程实践探知业务疾苦，有的时候我们不走极端，因为此消彼长，物极必反。后面我们会看到为啥在流计算产品的设计中也会有“此消彼长”的影子。

以终为始 – 技术(High-Accuracy)

除了实时性的关键技术指标要求，流计算产品更需要满足计算准确性的现实要求，业务数据的分析计算就是需要有一个准确的计算结果供下游业务使用，比如金融领域，数字准确性至关重要，还有甚至是计算的结果数据可能作为企业重要的决策依据，种种应用场景对数据分析的精准性要求甚高。面对这样的业务场景，流计算产品如何才能保证计算的准确性呢？

我们还是要从关键因素切入思考，第一个很现实的情况是现实生活生产中的流数据由于种种原因会产生延时，数据延时情况也造成计算结果需要进行更新，不但这种数据延时可以造成计算结果需要更新，某些特定的业务逻辑也会造成数据计算结果需要产生更新，简单列举几个场景如下：

比如，物联网领域很多弱网环境导致不同设备上送的数据的顺序和数据在设备端产生的时间顺序是不一致的，现实生活中也有，比如实时统计航班的售卖情况，但是有客户今天购买了机票，明天有取消了机票，那计算结果是不是也涉及到了更新？很多现实业务都对流计算产品提出了要支持数据延时和数据更新的能力。

当然这些实际存在的问题都需要以某种技术手段来解决，当然我们进行技术抽象的目标也是解决业务场景的实际诉求，比如监控预警对实时性要求很高，流计算在处理源源不断的流事件时候，不仅希望计算结果能够快速产生，同时也期望虽然数据延时、数据更新都是一种客观存在，但业务仍然期望延时和更新对后续计算结果的影响面缩小到最小，那么流计算产品如何最大程度达成这一目标呢？

首先我们前面介绍了流计算产品在支撑数据分析场景时候所具备的一些能力，比如 聚合/窗口等等能力。

其中窗口划分解决了数据分组问题，在满足业务本身需要数据分组计算的同时，也能让某条延时数据只影响其对应的窗口计算结果，同时以Apache Flink 为例，对于无窗口聚合计算是每条数据都输出计算结果到下游，达到了低延时的业务要求，同时也依托于retraction机制解决了数据更新带来的计算精准性问题（但这个case如果出现failover的框架级别错误时候，依然无法解决计算精准性问题）。也就是说这些技术点只是在某一个计算分析能力下，某个特定的局部边界线下作出的具体工程实现，解决了局部问题，那么在流计算产品中，有没有更高层面的语义抽象，能够覆盖流计算产品所有场景的支持，也就是在流计算领域有没有关于计算精准性的语义抽象呢？

我们首先要说明一下需要达成的共识，那就是这里我们讨论的数据计算的准确性问题，不是由于业务逻辑bug导致的计算结果不准确，而是流计算框架层面是否能保证预期参与计算的数据都能在任何异常情况下也按预期的要求参与计算。在这个共识下，流计算差评从数据参与计算的次数不同进行了不同计算准确性的语义抽象，那就是：Exactly-once, At-least-once, At-most-once三种核心的语义抽象。

这里我们也会发现，其实产品技术解决业务疾苦，业务疾苦会驱动产品技术发展，流计算的理论和概念的诞生都是为解决业务问题而进行抽象定义的。接下来我们一起看看这个三个不同的语义抽象的含义。

首先我们看一下At-most-once，至多一次的计算语义是参与计算的数据，最多只参与一次计算，在系统异常情况会造成数据丢失。比如，计算SUM值，这种语义模式下计算结果 <= 真实值 （丢数据）

At-least-once，至少一次的计算语义是参与计算的数据，至少参与一次计算，在系统异常情况会造成数据多次参与计算。比如，计算SUM值，这种语义模式下计算结果 >= 真实值（重复计算）

Exactly-once，精准一次的计算语义是参与计算的数据，参与且只参与一次计算，在系统异常情况计算框架保障数据不丢失，不重复，比如，计算SUM值，这种语义模式下计算结果 == 真实值（准确性完美）。

从定义抽象上看，似乎Exactly-once是最好的业务需要，那么为什么不能直接就全部保持Exactly-once呢，也就是为啥还需要 At-least-once和At-most-once的语义抽象呢？这里就是我们之前提到的此消彼长的原因，完美的理论设计往往会对工程实践带来巨大的技术挑战，当然挑战因素往往不在一个单一的产品层面就可以得到完美解决，可能涉及到网络，存储，计算等等各个层面的综合演进才能完成。对于我们目前讨论的流计算数据分析精准性语义抽象的工程实践就涉及到了低延时和高精准同时具备的工程实现的相互影响。以Apache flink为例，这里面涉及到的技术点有很多，包括Checkpoint机制，包括Statebackend技术，包括分布式存储技术，扣到细节也会涉及到Flink内部的网络层面设计等等细分的技术点。这些技术点在Apache Flink知其然，知其所以然的课程里面会分章节进行细致介绍，大家可以看完今天的宏观介绍在去各个章节进行细的知识点的了解，然后再回过头来考虑这些知识点之间的联系。那么我们今天还是从宏观视角继续看流计算领域如何在更高层面解决 低延时和高计算精准性问题。

以终为始 – 技术(流批一体)

低延时要求流计算框架尽可能早的输出计算结果，但是由于存在数据延时和现实业务数据更新的客户情况，就会导致你前一秒计算的结果，因为下一秒来了一个对上一秒已经参与计算的那条数据的更新，进而导致在下一秒时候上一秒的计算结果就是无效的了，那么流计算产品低延时需求导致流计算产品不可能无限制的等待延时数据的到来，这就一定会造成数据计算结果不精准的问题。如果流计算产品想让自己的计算结果更准确，那就需要忍受对延时数据进行更长时间的等待，那就意味着流计算产品的低延时无法达成，所以在流计算产品中鱼和熊掌兼得是不那么容易的。

流计算产品无法达成，这并不代表从业务层面无法达成既要低延时又要计算结果高精准的目标。那就是我们可以跳出流计算单品，以大数据产品生态体系的视角再看看业务层面要求低延时+高精准的目标如何达成。

数据的计算精准性问题是由于数据变化更新导致的，那么如果我们参与计算的数据都是不变化的，那么就意味着我们计算的结果一定是准确的了，所以从业务层面我们可以利用批计算的方式修正流计算的结果。

也就是说，批计算的数据特点首先是没有数据延时，也没有数据更新，因为这里的批计算有一定的业务含义，这里我们说批计算一般是业务层面断定参与计算的数据是不变化的，比如我们熟知的T+1的计算方式。今天只计算昨天的数据，从时间维度看，打上昨天标签的数据都是历史数据，不会改变了。那么分析到这里我们是否可以发现流批计算中有一个本质的数据特征？

从数据特征角度看流批计算的本质区别，流计算所处理的数据是持续变化的，变化是一种常态 - Dynamic Data，批计算所处理的数据保持静止的，静止是一种常态 - Static Data。

这里的批计算和流计算与前面我们讲的流计算模型和批计算模型并不是同一个维度的概念，这里的流计算更多的是说业务维度，使用流计算产品的实时计算模式，以Apache Flink来说就是PIPELINE模式，这里的批计算更强调参与计算的数据是历史不变化的数据，我们可以认为是数据不变的情况下批计算模式是对流计算模式的性能和数据精准性的提升，以Apache Flink为例来说批计算就是就是BLOCK模式。这里分享一个观点，在我看来：“流计算模式是批计算模式的低延时优化，批计算模式是流计算模式的高性能和高精准的优化”。有了这个观点之后，那么企业可以根据自己业务的实际特点判断是低延时对自己业务价值影响更大，还是数据计算精准性对其业务价值影响更大，还是两者都有很大的影响，进而判断自己的业务是选择流计算模式还是选择批计算模式，甚至以增加计算成本搏取业务价值空间，选择批计算模式和流计算模式相结合的计算方案。

以终为始 – 流批一体(Lambda 架构)

那么，目前业界有哪些流计算和批计算相结合的架构可以满足低延时和高精准的既要又要的需求呢？

数据都是伴随着时间产生的，并且抛弃业务赋予的其他属性，只从时间维度去看，每一条数据都是唯一的，也就是在时间线上都是一条条append only的数据。所以对于我们认为历史数据是静态数据，当下数据是动态数据也是因为赋予了数据业务特征之后才成立的说法。比如除了时间属性我们再添加订单号，那么就因为具备了业务属性，才导致不同时间点，相同订单号的数据就具备了关联性，也就是有数据更新的可能，那么在业务维度去划分一定的有效窗口之后，比如1天的订单变化都是影响业务数据统计的，那么1天以前前的数据就可以在这样的业务规则下变成历史数据了，从现在开始源源不断产生的数据就都是动态数据了。这个思考有一点点绕，大家下来静心思考一下是不是这个道理。

基于这样的数据划分思考，我们可以选择处理这两类数据的技术产品。我们将整个架构体系里面既有流计算处理链路，又有批计算处理链路的计算架构叫做流批一体架构。我们当前如图显示的架构就是流批一体的Lambda架构，这个架构流计算和批计算最终是为了服务最终的Serving layer，也即是在查询服务层可以实时的查询当下数据的计算结果。

但随着时间的推移，批计算的精准结果再修正流计算实时产有潜在偏差的结果，进而保证低延时的同时也保证了计算结果的高精准。这个架构很好的一个特点就是，流计算只注重极致的实时性，在计算的优化规则方面也根据流计算的特点进行优化选择。在批计算的时候只注重数据的计算结果精准性，同时优化规则的选择也结合批计算的特点选择性能更好的规则。比如虽然流批都是JOIN的逻辑，但是批可以选择sortedjoin，而流计算模式就不可以选择了。

那么在现实生产系统里面大多的业务数据划分历史数据的方式一般以自然天或者业务天为单位进行划分，也即是我们经常说的T+1.

这样的相同数据分别由批计算模式计算一遍，在用流计算模式跑一遍的Lamdba架构，有哪些不足呢？Lambda架构核心是成本问题：多份数据存储成本，多API开发成本，多引擎运维成本等等。那么我们有没有其他更优化的方案呢？

以终为始 – 流批一体(Kappa 架构)

为了解决Lambda架构多引擎的维护，一套业务多套API开发的不足，Kafka生态体系又提出了Kappa架构，这个架构一个非常大的优点就是用户一套业务只需用一套API开发，用户只维护一份业务代码，运维一个引擎，这在实际的生产开发运维中相比Lamdba有了很大的改善，但是Kappa架构是如何做到实时性和精准性的呢？

其实是利用了存储系统的数据回放能力，也就是如果从流计算产生了计算结果精准性问题，利用同一套只具有流计算模式的计算引擎全量回放一下历史数据，由于是历史数据，数据没有延时，也没有更新，进而即便是流计算模式的计算引擎在进行静态数据计算时候，再加上采用精准一次的计算语义模式下是可以达到数据计算结果的高精准的。

这样的架构特点，大家也不难发现Kappa框架本身也有其潜在的弊端，比如都是流计算模式的引擎在算法优化规则的选择上有很大的局限性，进而也造成资源的浪费。同时以流的模式重放全量数据，在批计算和流计算并行进行时候，会对存储系统产生很大的IO压力。

这里有一篇对Kappa架构有很好的分析的文章推荐大家进行延展阅读。https://www.kai-waehner.de/blog/2021/09/23/real-time-kappa-architecture-mainstream-replacing-batch-lambda/

以终为始 – 流批一体(Enhanced generation)

目前流批一体的架构体系还不够完善，流批一体本身在概念层面业界还存在很大的不同认知，那么从我的角度看流批一体应该具备怎样的特点呢？这里和大家分享几点共同交流。

第一点，流批用户无感，从用户层面去看流批一体，从技术实现上应该流批应该对用户是无感的，流计算和批计算在用户视角看是业务计算的延迟上面有区别，用户本身并不关心是流计算模式还是批计算模式。也就是如果你能达到计算准确并且延时在业务接受的范围内，用户本身不关心计算框架采用怎样的计算模式。

第二点，流批一套API，从开发层面看，用户既不关心引擎的计算模式，更不愿意为了达到计算准确性和计算低延时而利用两套API进行相同业务开发，那么也就是流批一体首先应该确保API层面对用户流批透明，有一套统一的API对用户可见。

第三点，单引擎运维，从运维层面看，用户不想维护多套计算引擎，两套计算引擎的维护，必然也会造成第二点提及的开发困扰，同时增加更多的运维成本。

第四点，流批自动切换，技术角度去看，流批一体的计算引擎，流计算和批计算的模式，不是在作业启动的时候进行二选一的配置，而是根据作业算子的特点，业务延时要求的配置等等综合因素进行引擎内部的自动选择。也就是说，我更认为批计算是流计算在性能和计算精准性方面的优化选择，流计算是批计算在延时性方面的优化选择。流批一体的计算引擎应该对用户来说是黑盒子，有能力具备按照用户的业务目标自动化选择流批计算模式。

第五点，客户第一，其实不是技术特点，而是流计算产品必须要担负的职责，为用户节约成本，为用户创造价值。这虽然是一句愿景的话，但这对流计算产品提出了巨大的挑战，流批一体本身也是为了完成这一职责所产生的技术架构。

那么，就流批一体的技术体系而言，在现有的架构方案中，我们接下来从哪些维度可以在为用户创造更大价值的同时，还能为用户节约更多的成本呢？

这里抛砖引玉，我们是否可以在计算和存储层面有更多的思考，让存储加速计算，并节约用户成本，为用户创造更大的价值呢？

以终为始 – 流批一体(存储+计算)

其实以存储换取计算速度的技术在传统的数据库里面已经有了很好的技术抽象和落地实现了，比如，物化视图，一般物化视图有2种方式，一是ON DEMAND，一是ON COMMIT，其中ON COMMIT的方式有更好的实时性体体现。那么在流计算产品里面我们有哪些存储加速计算的场景呢，其实在Apache Flink里面也有这样的影子，比如试图和SQL复用的技术实现都是将一部分公用的数据计算出来之后进行局部存储，然后供其他复杂的计算进行计算结果的复用，进而依托于存储加速计算，也为用户节约了计算成本。那么在流批一体层面上看，我们可以用怎样的技术手段，优化现有流批一体架构呢？

首先计算实时性是业务价值最大化的强需求，那么在不损失业务实时性的前提下，如何改进批计算环节的技术实现来完成计算成本优化的目标呢？

这里简单假设一下，流计算产品一般都是有状态的计算引擎，在持续计算的过程中我们都会将中间计算结果进行持久化处理，以Apache Flink为例，在持续查询的算子实现层面，会将中间计算结果进行statebackend的持久化处理，当然这些持久化处理是为了作业的恢复使用。但如果这些持久化数据除了用于作业恢复之外，再延伸思考一下，我们是否有契机将持久化数据应用在高精准批量计算的过程当中呢？

我们知道流计算模式的计算结果之所以有失精准性，那是因为有小部分的数据延时和更新造成的。比如我们在窗口计算中，延时的数据只会影响数据对应的窗口计算结果，那么在精准性批量计算中只需要对有问题的窗口数据进行计算，并且我们即便是对有问题的窗口数据进行计算，也没有必要把整体窗口的所有数据都重新计算一遍，而是利用流计算的中间结果和出现问题的延时数据进行修复计算即可。

如果这些构想能够细化落地，会涉及到statebackend能力延展，以及流计算中间计算结果的通用数据结构抽象，并结合GAP数据和数据源建立血缘关系的方式，减少GAP数据在statebackend的存储，进而即便是GAP数据我们也可以从数据源拉取，而不进行多余的持久化处理，这样就可以极大程度的优化流批一体化架构实现。

如果再进一步延展，也许我们可以将Statebackend独立成StateDB子产品，这样在 checkpoint/failover等机制中也可以得到优化可能，比如在在Fast failover中将StateDB作为远程分布式的状态数据库，作业算子的状态可以mappping到StateDB中的状态记录，进而提速作业恢复。

上面的简单构思其实核心是想让批计算可以复用流计算的计算状态，那么其实在流批一体化技术体系和实际的业务场景中，也存在流计算复用批计算计算状态的需求，我举一个例子，我们在追数据的场景，我们可能利用批计算模式进行历史数据的追溯计算，在追上之后切换到流计算模式，那么批计算的计算结果如何在切换到流计算模式时候被新流入的数据计算过程进行复用呢？这里面也是前面我们提到流批一体化技术体系需要解决流批系统自动切换的前提能力之一。

总之，在我看来，延展计算存储，利用存储加速计算是后续我们需要持续研究和不断技术演进的重点方向之一。

不论如何，这些方向的思考和技术的研究在默默的发生着，我们静观其变，其实，除了流批一体之外流计算产品还有很多重要的技术挑战需要持续投入，比如，秒级收缩容，状态数据的冷热分层，云原生的迈进，流计算产品的低代码化等等。今天内容主题是流计算产品的综合洞察，所以不针对每一个技术细节进行展开，后续课程我们慢慢再聊。

05 用户取向

以终为始 – 用户视角（商业价值）

OK，现在我们换个思维方向，我们说流计算产品的核心目标是让数据产生价值。

首先我们的目标是让企业适用商业趋势进而助力企业创造最大业务价值，那么企业是以这样的方式达成适应商业趋势呢？当然依靠的是企业管理层一个又一个的企业决策。再去思考，这些决策的依据又是什么呢？当然是靠精准的数据作为决策支撑。那么精准的数据又是从哪里来的呢？不能排除有一部分实时精准的数据就来自于我们的流计算产品。那么这些精准有效的数据又来自于哪里呢？其实原始数据还是来源于商业本身。

那么在这样的数据和数据利用闭环体系中，怎样的计算产品才是对用户是最有效的呢？这个问题是流计算产品需要持续思考的问题。

以终为始 – 用户视角（做我所长）

怎样的流计算产品才是对用户最有效的？这个问题，如果我们从用户视角去思考的话，我想，如果一个流计算产品可以为用户创造一个用户可以只 “做其所长”的平台环境，那么将是对用户最有效的流计算产品。

那么怎样衡量一个流计算产品是否做到了可以让用户能够精力集中到“做其所长”呢？我们可以从产品能力和产品形态两个维度进行思考。

首先从产品能力上看，流计算产品首先需要具备数据集成能力，然后是数据分析能力，在具备了集成分析能力之后，我们更需要在领域上深耕，增加更多的行业分析能力，比如物联网领域，金融风控领域等领域性较强的分析能力。

不论我们进行什么行业的分析，用户最终还是期望依托于数据进行商业决策的，那么如果流计算产品本身囊括了商业决策所需平台能力，那么将会极大的减轻用户的决策成本。

最后，如果我们的流计算产品可以智能的学习企业商业决策所需要的决策模型，并自动化的助力企业进行商业决策，那么用户就真的是只思考商业模式和做自己最擅长的业务工作去了，那么也必然能达成了”做其所长“的最佳状态。但是我们知道，流计算产品能力不仅仅是技术层面的功能性，还需要有交付到用户手里的产品形态，那么怎样的产品形态才是最便利用户的呢？

第一种，我们可以将产品能力齐全的项目发布代码交付给客户，客户自己本地部署，也就是On-premise交付形态。这种本地部署其实对用户提出了很高的要求，包机房，网络环境等等都需要用户自己准备

第二种，半托管模式，也就是基于IaaS交付模式，用户可以托管服务器，网络环境等基础设置，用户只是依赖的中间件产品和流计算产品自己部署到安全的基础设施里面，但是这里面用户仍然要维护流计算产品的应用

第三种，全托管模式，也就是PaaS交付模式，为用户提供一个流计算产品平台，比如：用户只需通过web 浏览器就可以进行业务开发，用户只关心自己的业务应用代码维护

第四种，是更便利的服务模式，SaaS交付模式，用户只需要进行服务直接调用或者简单的业务流程编排就完成了自己的业务需要。

第五种，其实这一种更多的是云原生架构的体现形式，一切皆服务，数据库可以是服务，人工智能可以服务，业务流程也可以是服务，XaaS交付模式会对服务直接的依赖复用提出更多的技术挑战。

那么不论产品具备怎样的产品能力，以怎样的产品形态进行交付，流计算产品都需要考虑用户数据处理的实时性要求。

最后，要时刻意识到流计算产品需要解决以数据处理的实时性，以达到将业务数据的价值最大化的目标。

06 产品能力

以终为始 – 产品能力（数据集成） 

那么用户要达成自己的商业决策需求，根据流计算产品提供的不同层面的产品能力，可以解决怎样的业务问题，都适用怎样的业务场景呢？

首先我们看看具备数据集成能力的流计算产品在用户整个业务处理链条中的位置。

流计算产品具备数据集成能力是最基础的能力，核心解决企业各个业务系统由于数据分散存储而造成的数据价值碎片问题。数据集成可以将分散数据进行汇聚，供后续业务进行综合分析。

如图，只具备数据集成能力的流计算产品将多数据源数据汇聚集成，但不进行聚合加工，集成后的数据直接输出到其他的具备分析能力的数据产品。

从用户视角看，用户只能通过具备数据集成能力的流计算产品完成业务数据的实时集成需求，要完成全部的商业决策还需要面对其他大数据生态产品，比如数据湖，数据仓库等。

以终为始 – 产品能力（数据分析） 

那么具备数据分析能力的流计算产品应该增加怎样的功能和解决怎样的业务问题呢？

首先流计算产品具备数据分析能力是在数据集成能力基础之上的能力增强，核心会增加满足基础的分析算子能力，如：数据窗口划分，通用聚合函数，各种数据流的JOIN等，对数据进行通用分析。

从用户视角来看，用户可以通过具备数据分析能力的流计算产品可以满足常见的业务端到端需求，比如实时监控等业务需求。但是复杂的领域性复杂分析，还需要借助其他大数据生态产品，比如数据湖，数据仓库等。这里我们注意，分析后的数据除了流入其他具备领域性分析能力的产品外，也可以直接提供给监控预警场景的终端用户，也意味着具备数据分析能力的流计算产品可以端到端的独立解决某些业务场景了。

以终为始 – 产品能力（行业分析）

流计算产品发展到第三个能力层次就是具备行业分析能力，行业分析能力可以横向拓展，就像在坚实的地基上高楼林立，每一座高楼都代表一个行业，而你可以不断的新建新的、各具特色的大楼。

流计算产品增加行业分析能力，是根据不同行业的领域问题来增加领域性较强的垂直功能，比如电商行业需要的机器学习能力，进而完成搜索推荐，游戏行业需要对玩家各种游戏打斗和道具应用进行复杂的事件分析，进而需要增加CEP能力，或者IoT领域需要对设备实时管理，就有可能需要增加位置数据处理能力和时序数据处理能力等等。

用户视角：用户可以通过具备行业分析能力的流计算产品，开发满足特定行业属性的端到端需求，比如电商的商品推荐，IoT领域的设备管理和控制，游戏行业的复杂事件分析等，没有被流计算产品覆盖的行业需求，还是需要借助其他大数据生态产品，比如数据湖，数据仓库等。

以终为始 – 产品能力（商业决策）

流计算产品发展到具备了商业决策能力，那么从用户视角看，流计算产品基本完成了除了企业自身业务工作之外的所有工作了，流计算产品就可以做企业的军师了，不用给流计算产品太多输入，流计算产品就可以告诉企业如何进业务拓展，如何进行客户拓展。

流计算产品具备商业决策能力，需要增加对商业决策模型进行配置的能力，并具备根据决策流程配置生成商业决策的能力。同时此时的流计算产品应该囊括了其他分析类产品的能力，即，比如流程定制，湖仓分析等等都是对用户透明的。

从用户视角看，用户可以通过具备商业决策能力的流计算产品进行商业方面的实时决策，用户只需要对企业决策规则进行配置，对决策流程进行配置，并配置决策方案的打分机制，进而通过流计算产品完成端到端的全链路的商业决策。

具备这样能力的流计算产品已经是广义的流计算概念了，这样的流计算产品可以端到端的处理现实世界中随时间而产生的任何数据，真正达成全面的实时化分析决策。具备这个能力的流计算产品已经是一个现实事件实时化分析处理的流计算产品套件了。

以终为始 – 产品能力（智能学习）

最后，如果让这个流计算产品更智能化，如果产品具备智能学习的能力，那就是最完美的流计算产品了。

流计算产品具备智能学习能力，是在具备商业决策能力的基础上对决策的规则，决策模型等人工配置部分自动化掉，就是依托于内置的数据分析，行业分析，机器学习，模型训练和数据预测等能力进行智能的自动更新。

从用户视角来看，用户可以利用具备智能学习能力的流计算产品，只需要进行商业目标的设定和用户增长所需的业务参数配置，即可完成商业价值的缔造。

这里也做一个简单的说明，前面和大家分享的流计算产品这五个层面的产品能力，是从达成用户利用数据创造价值的目标过程中，如何简化用户非擅长的工作的视角进行思考的，流计算产品的发展可以从不同的视角进行切入规划，如有不妥的认知，欢迎大家指正，也期待听到你的思考分享！

那么接下来让我们来看看当前行业中的流计算产品有哪些？

07 业界产品

以终为始 – 开源产品

首先我们看看开源领域的流计算项目。

第一个[Apache Flink](https://flink.apache.org/zh/flink-architecture.html)是一个分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。Flink 能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。

第二个[Apache Spark](https://spark.apache.org/) 是一个多语言引擎，用于在单节点机器或集群上执行数据工程、数据科学和机器学习。

第三个[Apache Storm](https://storm.apache.org/) 可以轻松可靠地处理无限的数据流，实现Hadoop对批处理的实时处理。

第四个[Esper](https://www.espertech.com/) 是一种用于复杂事件处理（CEP）和流式分析的产品

第五个[Hazelcast](https://hazelcast.com/)是一个流式和内存优先的应用平台，用于在本地、边缘或作为完全管理的云服务实现快速、有状态、数据密集型的工作负载。

第六个[Apache Samza](https://samza.apache.org/) 允许您构建有状态应用程序，实时处理来自多个源的数据。

第七/八两个都是基于[Kafka](https://kafka.apache.org/documentation/streams/)的延展流计算产品,其中[ksqlDB](https://ksqldb.io/)是为流处理应用程序专门构建的数据库。

第九个[MegFlow](https://github.com/MegEngine/MegFlow) 提供快速视觉应用落地流程，最快 15 分钟搭建起视频分析服务,虽然和流计算产品有一定的差异，但是也很值得我们感兴趣的同学去体验一下。

第十个[Apache Heron](https://heron.apache.org/)是一种实时、分布式、容错的流处理引擎

这些开源流计算引擎大家都可以作业流计算理论学习的实现工程参考。如果大家对哪一个特别感兴趣，我们也可线下聚焦讨论，一起学习。

以终为始 – 商业产品（基于开源）

除了前面的开源产品还有一些大家熟知的基于开源打造的商业化平台产品，简单了解如下几个：

第一个是阿里巴巴旗下实时计算商业品牌

[Ververica](https://www.aliyun.com/product/bigdata/sc)，是阿里云基于 Apache Flink 构建的企业级、高性能实时大数据处理系统，由 Apache Flink 创始团队官方出品，拥有全球统一商业化品牌，完全兼容开源 Flink API，提供丰富的企业级增值功能。

第二个是腾讯云的流计算品牌

[流计算Oceanus](https://cloud.tencent.com/product/oceanus)，是大数据产品生态体系的实时化分析利器，是基于 Apache Flink 构建的企业级实时大数据分析平台，具备一站开发、无缝连接、亚秒延时、低廉成本、安全稳定等特点。流计算 Oceanus 以实现企业数据价值最大化为目标，加速企业实时化数字化的建设进程。

第三个是 AWS的流计算品牌

[Kinesis](https://aws.amazon.com/cn/kinesis/data-analytics/)，使用无服务器的完全托管式 Apache Flink 从串流数据中获得可行建议。

第四个是Confluent产品

[Confluent](https://www.confluent.io/)的KsqlDB是专门为流处理应用程序构建的数据库，能够利用它进行流处理使您能够从数据流中获得即时见解。

第五个Esper产品

[Esper](https://www.espertech.com/)企业版是一种用于复杂事件处理（CEP）和流式分析的产品

第六个是谷歌产品

[Dataflow](https://cloud.google.com/dataflow)，无服务器、快速且经济高效的统一流式数据处理和批量数据处理。

最后两个大家感兴趣也可以到其官网进行简单了解。

以终为始 – 商业产品（完全自研）

对于流计算产品提供商而言，一种是基于开源进行商业化，一种是完全自研进行商业化，自研产品对企业研发力量的要求还是很高的，但是投入产出比也是也是不错的，我们看到如图的这些自研产品，不论是Oracle，SAS，还是TIBCO，IBM他们自研的流计算产品都是在Forrester测评的领导者象限的。所以在目前业界拥抱开源的大环境下，自研产品的生命力并不会减弱，因为这些自研产品的东家都具备一流的产研能力，都舍得在研发上长期投入，这是很多处于探寻商业生存空间的中小企业无法比拟的。

以终为始 – 商业产品（组合套件）

跳出流计算产品的单品，在整个大数据产品体系中，要端到端的解决企业业务问题，仅仅一个流计算核心产品是远远不够的，所以很多企业打造了大数据流计算体系的产品套件，企业在这个套件中可以闭环的完成所有的企业大数据流计算需求，大家如果感兴趣可以对如图产品进行逐一了解，比如第一个九很有意思，低代码的流计算分析产品。坦白说我也非常赞同流计算产品都尽可能的走到低代码行列。

08 交付模式

以终为始 – 价值空间

OK，到这里我们简单了解了从纯开源，到基于开源的商业化产品，到完全自研的产品，再到流计算体系的产品套件等业界现有的流计算产品。那么这些产品在交付选择上有怎样的区别，这些不同的交互模式下有怎样的本质区别呢？我们这里可以有一个共识，这些产品都是toB的产品，不同的交付模式完全是流计算产品提供商和B端企业的分工问题。

但这些分工有一个本质的内因，就是不同的交付模式决定了彼此的价值空间。但这里一方价值空间的增加并不是以牺牲对方的价值空间为基础的，而是一种因地制宜，按需索取的双赢模式。为什么要这么说呢？我们可以根据不同的交付模式简单分析一下。

以终为始 – 交付模式（toB）

其实流计算产品面向B端企业，B端产品最终也是面向C端用户的，那么云上流计算产品的交付模式对于C端用户有什么影响吗？这一点我们是确认的，就是不论流计算产品怎么交付到B端用户，C端用户都是不受影响的。那么B端用户就需要根据自己的企业特点选择不同的流计算产品交付模式。

那么，到底有几种流计算产品交付模式，可以供B端企业进行选择呢？常见的有4种可选的交付模式，即：On-premise，IaaS，PaaS和SaaS。

那么这几种交付模式的不同完全是在产品在面向C端用户之前所需要的工作分工进行区别的，那么我们要想一个产品最终面向用户，我们有很多工作要做，比如：网络环境，存储介质，服务器，虚拟化资源，操作系统，各种中间件，流计算产品运行时的维护，业务数据和服务抽象，还有业务应用逻辑开发等等工作。那么这些工作在不同的交付模式下就会涉及到不同的分工，我具体看一下。

比如On-premise交付模式，流计算产品提供商之需要软件交付，B端企业需要对如上列出的工作全部自己承担，这种交付模式是需要企业有很强的团队支撑的。那么后面IaaS/PassS/SaaS模式的的交付，流计算产品提供商会逐步负责更多的工作，最后的SaaS模式B端企业之需要负责自己的业务编排部分，当然B端企业做的越少，相对于流计算产品提供商而言其价值空间越大。当然这并没有挤压B端企业的价值空间，这是一种双赢的交付模式，因为B端企业可以将精力等多的用在自身业务发展上。后面我们也会介绍，什么样的企业需要选择怎样的流计算产品交付模式。

当然这里在延展一点，目前在云的大环境下，越来越多的服务化发展，一切皆为服务，就变成了XaaS的交付模式了。所以不同的交付模式的本质，就是流计算产品提供商的价值空间获取，当然这也是需要雄厚的技术实力支撑的。下面我们再具体介绍一下，每种交付模式的细节内容。

以终为始 – 交付模式（On-premise）

首先我们来看一下，On-Premise的交付模式，与这种交付模式相关的概念有什么呢？

首先就是公有云和私有云的概念，公有云通常指第三方提供商为用户提供的能够使用的云，公有云一般可通过Web直接使用，比如阿里云，腾讯云，华为云等等。

私有云则是将云基础设施与软硬件资源建立在防火墙内，完全为特定组织而运作的云端基础设施，管理者可能是组织本身，也可能是第三方；位置可能在组织内部，也可能在组织外部。

基于私有云的概念，我们会发现其实私有云根据其基础设施位置不同有两种细分的方式，一种就是On-Premise，准确的说是基于本地部署的私有云，就是基础设施是用户自己维护的。第二种就是托管的模式，也就是基础设施是在云上的，虽然也是专门服务这个企业，但是基础设施是有云提供商进行运维的。因为Hosted方式和IaaS有很多共性，所以我也将Hosted的部分跨过私有云和公有云的分割线。那么这两种私有云的分类方式有比较清晰的概念吗？当然是有的，我们也看一眼：

第一种，On-Premise Private Cloud, often called Internal Cloud, is hosted within an organizations own offices, or data center, and provides an internal solution for hosting needs. (组织自己的数据中心，组织自有)

第二种，A hosted Private Cloud solution is owned and operated by third-party service providers.（公有云提供商提供的专门服务该组织的服务设施，从服务提供商视角更愿意叫 “专有云”）

根据概念的定义我们会发现，其实最核心的部分就是基础设施对于企业而言，是否是自有的区别。关于Hosted托管的私有云模式，云服务提供商更多的叫做专有云。

以终为始 – 交付模式（Public Cloud）

那么一个比较容易想到的问题就是，大家公有云和私有云选择一般从哪些维度进行思考呢？其实前面提到过，如果用一句话来说，就是大多数用户选择公有云还是私有云是根据能否达成“做其所长，赢其所需”的目标来进行选择的。

但这个选择的过程考虑的因素也是比较多，但是最核心的因素可能包括： 

第一：开发成本问题，企业希望快速迭代，依托公有云，组织可以消除购买和配置计算基础设施的资本支出，以及维护本地数据中心的人员成本。

第二：任意扩展，企业需要不断发展，更需要具备技术保障产品支撑后续业务的发展，公有云平台提供按需服务，应用程序可以方便的获取企业生产规模所需的各种资源。

第三：极致性能，企业期望通过云计算享受具备极致性能的流计算产品，比如超低延时的技术支撑，进而赢取业务上的市场竞争。

第四：安全可靠，企业数据的安全是重中之重，云计算简化了数据备份和灾难恢复，从而确保了业务连续性和安全性。

当然考虑因素可能不限于这四点，但这四点已经足够让某些发展阶段的企业选择公有云的流计算产品了。

以终为始 – 交付模式（IaaS）

IaaS(Infrastructure as a Service)基础设施即服务。IaaS通过虚拟化技术提供高度自动化可扩展的硬件资源，包括服务器、网络、操作系统和存储。企业使用IaaS客户端能够完全控制整个基础设施。IaaS提供了与传统数据中心相同的技术和功能，而无需企业对所有数据中心进行物理维护。

那么IaaS适用于怎样的企业进行选择呢？ 

第一种：技术型的初创公司和小公司，这类技术型小公司，具备较好的技术实力，但是在硬件运维方面投入有限，进而使用IaaS可以避免在硬件运维上花费时间和金钱。

第二种：技术和人力资源充沛的中型公司，这类公司在可接受的人力投入下，更愿意对基础设施有完全的控制权，但只想购买与其实际需要迫切相关的资源。

当然，这里提一下，IaaS交付模式的选择可能存在供应商锁定和各种定制问题。所以很多企业在制定自己的云战略时候，会选择混合云，甚至多云部署。

以终为始 – 交付模式（PaaS）

PaaS(Platform as a Service)平台即服务。PaaS为开发人员提供了一个框架，通过web交付，开发人员可以集中精力构建与企业业务相关的应用程序，而无需担心操作系统、软件更新、存储或基础设施的资源配备和运维监控。

那么PaaS交付模式又适合怎样的企业进行选择呢？因为PaaS交付模式具备简单、高效的应用程序开发和部署特点，同时在平台层面具备可伸缩、高可用、屏蔽技术细节等重要特征，所以PaaS适用技术力量有限，企业人力资源全部投入到业务开发的企业，这些企业可以是初创的业务型企业，也可以是中大型的业务领域性非常强的大型企业，比如传统的工业领域，能源领域，电子政务，金融领域等不关心技术细节，只注重领域性业务发展的特定企业。

目前大多数云服务提供商也都是提供的PaaS模式进行流计算产品的交付，比如前面提到的阿里云，腾讯云，AWS，谷歌等，更多情况，云提供商将IaaS交付模式叫做半托管模式，将PaaS交付模式叫全托管模式。

以终为始 – 交付模式（SaaS）

SaaS(Software as a Service)软件应用即服务。SaaS利用互联网向用户交付由云供应商管理的应用服务。大多数SaaS应用程序直接通过web浏览器运行，这意味着SaaS交付模式无需下载和安装应用程序。使用SaaS，供应商可以管理所有潜在的技术问题，如中间件、服务器，存储和网络等等，从而减轻企业技术类的维护和支持负担。比如：我们常见的天气服务，在线翻译，文档服务，各种云盘等等都属于SaaS模式的交付方式。

因为SaaS交付模式将各类通用服务进行了高度抽象，用户只需要知道服务的功能，不用关心服务的内部逻辑和服务正常服役所需要的各种软硬件保障，使用门槛超低，所以SaaS交付模式更适合于标准化程度较高的业务领域，比如财税，教育等。或者SaaS还适合期望以快速的业务迭代促进企业快速发展的小型创业企业，人力少，变化快，同时具备一定的业务流程编排开发能力，所以在SaaS最上层除了Services层外还增加了Business层，Business层面是指在已有细粒度服务的基础上进行业务编排，形成新的、业务相关的粗粒度服务。

以终为始 – 交付模式（XaaS）

XaaS(Everything as a Service)一切皆服务。XaaS是指高度个性化、响应迅速、数据驱动的产品和服务，完全由客户控制，通过使用云计算产生的数据，企业可以更快地创新，更准确的进行商业决策，在某种程度上XaaS是数字企业的自主化发展的关键促成因素。

因XaaS的概念还在持续丰富中，比如：DBaaS，AIaaS，FaaS，BPMaaS等等，面对这些服务的个性化交付，我们也会迎来服务粒度划分的标准化问题，服务间依赖性问题，XaaS在技术层面的挑战，进而也会促进相关技术的蓬勃发展，如云原生架构体系，这这一体系里面最核心的内容涉及到 DevOps、持续交付、微服务、容器化等关键技术，但不论技术如何演进，标准如何抽象，最根本的目标还是只有一个：“最大程度的让用户做其所长，赢其所愿”。

所以不论是公有云还是私有云在接下来的发展过程中都会朝着云原生的架构模式发展，并且云原生距离我们并不遥远，云原生和流计算产品也息息相关，比如Apache Flink on K8S就是Apache Flink 迈向云原生的重要一步。当然Apache Flink 迈向云原生的体现不仅仅是这点，稍后我们会稍微扩展一点进行介绍。

以终为始 – 交付模式（市场预测）

我们聊了这么多的交付模式，尤其是公有云提供的IaaS/PaaS/SaaS等交付模式，那么这些交付模式的市场份额是怎样的呢？不论采用怎样的流计算产品交付模式，云提供商最终的目的还是实现企业价值，为企业盈利，所以每种交付模式在全球市场上的份额还是有必要大家了解一下的。

如图是Gartner在2021年4月份的市场调研报告，我们会发现在目前市场上XaaS的份额还不大，比如BPaaS，DaaS只有百亿和十几亿的份额，IaaS/PaaS/SaaS交付模式还是占全球市场的80%以上的空间。在这三种交付模式中SaaS的交付模式还是有明显的优势所在，占全部市场份额的36%以上。

当然这是全球范围的宏观数据，那么具体到每个云产品提供商需要将自己的产品进行怎样的云上交付，还有很多其他综合因素的考虑，包括企业技术能力，包括企业当前发展阶段，包括云产品提供商当前大数据产品生态体系的健全性等等因素。总之，没有最好的，只有最合适的。

09 云战略

以终为始 – 你是谁决定你选择谁

刚才我们说了企业对自己流计算产品的交付模式因企业自身综合因素，所以选择的交付模式各不相同，同样对于B端客户企业也是一样，选择怎样交付模式的云产品也是需要结合自身的综合因素来决定的，其实对于B端企业而言可选择的空间不仅仅是上面提到的产品交付模式，面对复杂的市场环境和自身业务对云产品的服务质量要求的不同，可能每一个B端企业都需要对自己的业务云化进行云战略布局。

以终为始 – 你强弱？谁说了算？

不论流计算产品的云提供商提供了怎样的流计算产品能力，提供商都需要解决怎么证明自己的产品是世界一流的的问题？同样不论企业怎么选择流计算产品提供商，企业拿到怎样的信息才能让企业内心笃定自己的选择是正确的呢？面对百花齐放的流计算产品，谁是最公正，最权威的流计算产品评论员呢？

根据这份权威数据统计，全球权威的评测机构，TOP3是Gartner，IDC和Forrester，根据如图的可信指数，Gartner的可信度已经超过了第二名Forrester和第三名IDC的可信度之和，Gartner是全球最全面，最可信的科技决策者。IDC更侧重数据领域，Forrester则更侧重于洞察全球的技术趋势。Gartner则可以在客户、竞争者、市场空间和技术趋势这四个核心维度为企业决策保驾护航。参阅：https://www.slideshare.net/HernanCampero/gartner-overview

所以不论是云提供商自信于自己的流计算产品，还是B端企业要笃定的选择自己的流计算产品，都可以关注Gartner的权威测评数据。当然在现实选择中，没有所谓的最好、最强，因为最强的虽然是把牛刀，但你目前只想吃鸡肉，没有最好只有最适合。这里祝流计算产品提供商都能荣登Gartner魔力象限，祝福B端企业都能选择到自己合适的流计算产品。当然，对于B端企业而言，不仅仅是对流计算产品的选择，更多的是需要考虑，自己企业的云战略选择。

以终为始 – 你是谁决定你选择谁（B端 Cloud Strategy）

一个企业的云战略是关乎企业生存发展的重要战略决定，这个决定不仅仅是企业IT部门的事情，也和企业人力资源/法务部门/采购部门/业务部门等等都息息相关。企业需要组建云战略委员会进行非常细腻的分析才能最终作出决策，这个决策是一个非常复杂的过程，在决策过程中切忌不是一刀切的方式，上云和不上云，不是非此即彼的选择，很可能根据企业的不同发展阶段有不同的云战略选择，整体来看企业有大概五种云战略选择。

这五种云战略方式的选择分别是：私有云（自建数据中心）/专有云（数据中心托管）/混合云（私有云+公有云）/多云（私有云&公有云1&2）。这里我也很想知道，收看视频或者阅读文章的您所在的企业，采用了怎样的云战略呢？欢迎大家留言反馈。

以终为始 – 你是谁决定你选择谁（Flink 步入Cloud Native ）

不论企业如何选择云战略，也不论云产品如何发展和如何选择产品交付模式。在完成Apache Flink 知其然，知其所以然的系列课程后，我们应该清楚的知道Apache Flink最终要走向哪里，这里和大家同步，Apache Flink将向着Cloud Native不断演进着。为什说Apache Flink在不断的向云原生演进着呢？我们需要结合元云生的12因素进行判断，当然云原生的12因素中有4个非常重要的点，那就是 开发运维/持续交付/微服务化/容器化，在这非常重要的4个维度中，Apache Flink有哪些符合的关键点呢？我简单列出如下几点：

- 基于K8S的弹性容器化（Re-active Scaling）

- 大状态的快速恢复增强（Remote Database）

- 服务依赖配置化

- 计算性能的持续增强（CP时间精准控制)

- 无状态部署模式

- 无状态HTTP/REST接口设计 

Apache Flink是有状态的计算框架，但是在部署，服务设计等维度都不断的追求无状态化，同时在可配置性上不断增强，包括服务依赖配置化设计，在流计算领域性上也不断的进行技术突破，包括CP的持续优化，作业失败恢复的持续提速，当然在容器化上也不断的迭代演进。

好，那我们选择其中一个小点的细节介绍，作为今天和大家分享的结束内容，我们选择Apache Flink 如何精准的控制CP时间这一点进行一些细节介绍。

10 文末彩蛋

以终为始 – Apache Flink 渐近步入 Cloud Native 

那么CP的精准时间控制是在讨论哪些技术点呢？这个技术点就是Apache Flink 里面的CheckPoint机制，那么CP机制相关的FLIP有好几个，这些内容我们在课程的流计算容错小节中做了细致的介绍，我们简单回忆一下，然后在进行CP时间精准控制的一个小的改进细节介绍。

在FLIP-76中提出了对CP进行的一个改进，具体涉及到什么问题呢？

当 Flink 发起一次 Checkpoint 时， Checkpoint Barrier 会从整个拓扑的 Source 出发一直流动到 Sink。对于超过一个输入的算子，来自各个输入的 Barrier 首先需要对齐，然后这个算子才能进行 state 的快照操作以及将 Barrier 发布给后续的算子。一般情况下对齐可以在几毫秒内完成，但是当反压时，对齐可能成为一个瓶颈：Checkpoint Barrier 在有反压的输入通道中传播的速度非常慢（需要等待前面的数据处理完成），这将会阻塞对其它输入通道的数据处理并最终进一步反压上游的算子。Checkpoint Barrier 传播慢还会导致 Checkpoint 时间过长甚至超时，在最坏的情况下，这可能导致整个作业进度无法更新。

大家观察当前的gif动图，算子有多个输入的时候，快的一边要等待慢的一边的Barrier到来，这时候如果出现反压，上面的Barrier很久都不能到来就影响了CP，导致业务中很多CP失败，最后成功的CP的状态也是超大的，进而引发很多业务问题。所以FLIP-76就提出了优化办法，就是Unaligned CP机制。也就是不用等等Barrier的对齐就可以进行CP操作。但是这样的优化由于buffer中的数据必须作为快照的一部分被持久化，非对齐的 Checkpoint 机制会增加 Checkpoint 产生状态的大小.那么我们有没有办法避免buffer的数据膨胀呢？如果我们可以通过技术手段解决，在反压的情况下也确保buffer的数据不会太大的话，那么就在一定程度上缓解了CP压力，当然也加速了作业恢复速度。基于这样的一个初心FLIP-183就出现了。

FLIP-183中提出了可以避免buffer数据膨胀的办法，那就是根据当前算子的处理吞吐来动态的告知上游算子当前buffer有多少可用的空间。为啥这样就能控制积压的数据大小了呢？我们列举一个例子，比如Flink内部计算出来当前节点处理的速度是5条数据每秒，同时根据业务的需求我期望buffer里面的数据处理时间不能超过2秒，那么就得出buffer的逻辑大小是10，将这个10的容量告知上游，确保上游发过来的数据不过超过10条，进而保证了不论何时做CP，系统都能保证进行状态持久化的数据不会超过10条，进而有效的解决了buffer数据不可控的问题，综合优化了Flink的CP性能。

如果我们尝试用一句话来说FLIP-183做了什么优化？我们可以认为FLIP-183只是为buffer size可配置的基础上，增加了一个可以根据作业处理吞吐来动态的计算buffer的逻辑大小的能力。所以大家可以消除对社区每一个FLIP都是大怪兽的恐惧心理，尝试去参与，书越看越薄，Apache Flink的知识体系也是一样，大家后续一起加油。

11 开放问题

以终为始 – 概念（实时计算 vs 流计算）

好，今天聊的时间不短了，最后再抛出一个问题，你认为 “实时计算” 和 “流计算” 在概念和含义上有什么区别吗？实时计算 强调业务延时，流计算 强调计算模型 （既可以完成低延时的 实时计算，又可以完成高精准的批量计算），你有怎样的认知和观点呢？

这里也说明一下，今天的内容应该算是一个补课内容，这些内容应该在Apache Flink 知其然，知其所以然的开课之初就先为大家介绍。所以这节课内容我会放到整个课程系列的第一节位置。欢迎大家在B站或者在我的公众号中持续关注本系列课程。先行谢谢大家。

作者介绍

孙金城，51CTO社区编辑，Apache Flink PMC 成员，Apache Beam Committer，Apache IoTDB PMC 成员，ALC Beijing 成员，Apache ShenYu 导师，Apache 软件基金会成员。关注技术领域流计算和时序数据存储。