作者：陈守元（巴真），阿里巴巴高级产品专家
摘要：本文由阿里巴巴高级产品专家陈守元老师分享，详细讲解实时计算 Flink 的具体业务场景并分享实时计算 Flink 的相关应用案例。
内容分为以下四部分：
● 技术原理
● 技术应用
● 应用场景
● 行业案例
1、技术原理
关于技术原理这部分的介绍，下文主要从通晓原理、容易混淆的四大概念、批处理和流处理的对比、事件触发的流处理四个方面展开介绍。
通晓原理举一反三
从上图所示的关于实时计算 Flink 业务架构图中可以发现，平时在做业务开发或是架构设计的时候，开发人员需要通晓产品背后的技术原理，只有这样做开发的过程中才能避免非必要的失误，从而提高数据开发的效率。对于很多架构师来讲，只有通晓了技术背后的原理，才能养成全局的架构嗅觉。
容易混淆的四大概念
下图所示的数据处理时效性的四大概念是从不同维度描述的，分别代表计算的不同特征，它们分别是：实时计算、离线计算、流计算（或称流处理）和批处理。这四个概念其实是从两个维度来描述的，横坐标轴上面的计算和下面的处理，指代的是业务的特征。
实时计算它描述快速的计算过程和快速的请求响应。实时计算描述的是计算链路的表达，是实时业务实时计算的需求特征。离线计算强调的是它的离线特征，即非实时的，非实时的计算过程和非实时的请求响应。业务特征是，不求特快，只求结果。
所以横向坐标轴上面描述的本质都是业务处理需求，而坐标轴下面描述的是技术需求。
流计算（流处理）强调的技术特征是流式处理。流式处理有有几大特征，包括常驻、事件触发和通常具备实时性。批处理（又称批计算）强调了计算通过批示进行处理。它的特征是，非常驻、外界触发和通常不具备实时性。
批处理和流处理的对比
对于批处理来说，处理分为三步。第一步是数据装载；第二步是批量计算，系统会把这份数据加载到存储里面然后构建相应元数据或者索引等操作；第三步是外界发起数据请求触发计算，计算出结果返回给用户。对于流计算来说，它的方式完全不一样。通常来说用户要把一个流式作业提前写好，然后提交到集群或计算系统里面。（由上图右侧所示）数据写入一条，流式计算就会触发一次并运算一次，然后写出一个结果，整个过程很短。
所以总结而言，对于批处理来说，数据装载、数据计算本身是完全脱节的过程，数据是一批批加载，计算也是一批批请求，这就是批处理（批计算）；同时它也是一个高时延的计算；另外它还是一个主动发起的计算，所谓的主动发起就是用户主动发起计算请求的。对于流式计算来说，它正好与之相反。流计算是持续的，只要有数据输入就会持续的计算；另外它是低时延的；它也是一个事件触发的计算。
事件触发的流处理
关于流处理，从维基百科上可以提炼3个关键词，Event，Stream和Process，本名为事件流处理，日常在工程实践中会被简化称为流处理或流计算。三个关键词准确地描述了流处理的三大特点：
● Event说明了流处理是由事件触发，同时事件又具有极强的时间性，比如事件发生时间、事件处理时间、事件进入时间等等。
● Stream代表的是事件流，也就是上图说明的“无界的事件集合”。意思是对于流计算来说，它的数据是持续的、源源不断地进入流计算系统的。也就是说，只要不人为终止它，数据便会源源不断地进入消息队列，最终进入流式处理系统。所以它本质上是一个无穷无尽的事件流，我们称之为无界的事件集合。
● Process是指流程，流处理作为一个处理系统也是一个计算系统，同样也是一个Process流程系统。对于流计算来说，数据进入一条就会触发一条，然后处理一条再输出，整个过程需要非常快的速度，也就是我们说得实时在线处理。
流式处理的价值
流式处理的价值在于当数据进来产生后，能够被迅速处理计算，然后迅速得到业务结果，这就是流计算的价值。需要流计算的地方，一般是数据价值随着时间流逝而迅速降低的场景。
对于离线计算来说，数据放一小时、一天或一个月，都不会影响计算，但对于实时计算来说，一旦数据没能做到及时流处理并即刻产生结果，那么数据的价值就会随着时间的流逝而逐渐降低。
关于流式处理的业务价值，可以举个例子，相信很多人对一年一度的双11都很熟悉，每年双11显示总交易额的实时大屏就是实时计算的一个最佳应用。另外一个更倍显价值的案例就是关于淘宝或是天猫的卖家通过实时的广告流量数据来调动或指定广告策略并执行，这样对他们的实时业务做到最大的助力。
2、技术场景
在Apache Flink官网有专门描述三大抽象技术场景，它们是：Stream Analytics，Stream Pipelines，Event-Driven Application。这三大抽象技术场景是我们下面展开的所有业务场景的基础，了解了这三大抽象技术场景，对未来推导其他业务场景和应用案例有很大的帮助。
Stream Analytics
目前在中国，最多的使用场景是Stream Analytics，它对应的是流处理；如上图左侧Batch Analytics对应的是批处理。Batch Analytics大家应该很熟悉了，它是传统批量分析，也就是批处理，基于有限的数据集构建应用来完成事件的批查询或计算，这个过程和上文介绍的批处理流程是一样的。
右边的Stream Analytics正好相反。如图所示，数据流是持续不断的进入query或application计算系统， 并持续的计算结果，结果再写入外部的存储，然后再通过Live Report输出给用户。
以上是批处理和流处理在Analytics这个场景下的延伸介绍，它们的原理式完全一样的。
Stream Analytics的核心优势是它规避了批处理周期性数据导入和计算的高延迟过程。相对于批处理，流处理更快更有效率。
Flink 如何支持数据分析类应用
Flink 最大的特点是它内置了一个符合ANSI标准的SQL接口，可以将批量和流式的语义统一起来。无论是在记录事件的静态数据集上，还是实时事件流上，相同SQL查询都会得到一致的结果。这套系统是阿里云贡献给整个社区的，也是从2015年开始就承接了每年双11实时大屏的工作。历经考验，它是一套非常成熟稳定的系统。
Flink内置的符合ANSI标准的SQL接口，成功地把流式处理的技术平民化，赋能给大量的BI工程师或开发人员。他们只需会写SQLC口或稍微通晓一点 Flink 的流处理语言，就能够做相应的开发。 Flink 所支持的数据分析类应用包括：实时数仓，实时数据中台和实时BI。
Stream Pipelines
如上图，左边是批处理Periodic ETL，右边是实时处理Data Pipeline。从整张图的数据管道来看，流处理相对于批处理来讲，更具有流动性，也就是数据的链路更可以实现实时化。
如上图，对于实时的数据管道，最大的优势是，能够明显降低将数据移动到目的端的延迟，也能够持续消费和发送数据，因此用途更广，支持用例更多。
Flink 如何更好的支持数据管道应用呢？ 很多常见的数据转换和增强操作可以利用 Flink 的SQL接口（或Table API）及用户自定义的函数解决。如果数据管道有更高级别的需求，可以选择更通用的DataStream API来实现。
Flink 为多种数据存储系统内置了连接器，如Kafka、Kinesis、Elasticsearch、JDBC数据库等系统。它还提供了文件系统的连续型数据源(Source)及数据汇端(Sink)，可用来监控目录变化和以时间分区的方式写入文件。
Stream Pipeline的应用场景有，实时数据清洗、实时搜索构建和实时告警。
Event Driven Application
希望将 Flink打造成流处理界的翘楚，希望达到更加极致的实时化，也就是提供一些更加定制化或个性化的数据处理。达成这样的效果需要围绕Application做到快速的读取和写入等。从坐标来看，希望把 Flink推向另外一个对处理时间要求更极致化的Event-Driven的Application。所以Event-Driven Application满足的是对更极致流的场景需求。
事件驱动型应用的优势是，无需查询远程数据库，本地数据访问使得它具有更高的吞吐和更低的延迟。而由于定期向远程持久化存储的CheckPoint工作可以异步、增量式完成，因此对于正常事件处理的影响甚微。
事件驱动型应用的优势不仅限于本地数据访问，传统分层架构下，通常多个应用会共享同一个数据库，因而任何对数据库自身的更改都需要谨慎协调。而事件驱动型应用，由于只需考虑自身数据，因此在更改数据表示或服务扩容时，所需的协调工作将大大减少。
事件型应用案例包括，反欺诈、异常检测和复杂规则告警，或是其他比较复杂的非二维关系代数模型分析类的应用。
3、应用场景
基于第二部分的技术场景，在上面做叠加和组合，就是以下几个应用场景的介绍。
实时数仓
实时数仓是在当下比较火、综合了Stream Analytics和Pipeline最终形成了实时数仓。它与传统数仓最大的区别是，它能够把前方的业务数据实时进行清洗、汇聚、加工，最后写入实时服务这一层。实时数仓最核心的是把业务的整个链路实时化了，这就极大的满足了一些需要实时看数据等业务需求。
实时风控
实时风控在很多有资损、监察、安全监控等需求的行业应用场景很多。在互联网时代，对于大量的用户访问、数据请求和业务的需求，造就了实时风控系统架构的极致化应用。在互联网初期，大家对时效性没有那么高的要求，很多离线风控系统就可以满足需求，但是现在实时化需求越来越大了。
借助实时风控，当用户在做一些操作的时候，规则引擎在获取数据后会做规则判断，然后反馈结果用户的操作是否合法。
实时机器学习
实时机器学习是一个更宽泛的概念，传统静态的机器学习主要侧重于静态的模型和历史数据进行训练并提供预测。很多时候用户的短期行为，对模型有修正作用，或者说是对业务判断有预测作用。对系统来说，需要采集用户最近的行为并进行特征工程，然后给到实时机器学习系统进行机器学习。如果动态地实施新规则，或是推出新广告，就会有很大的参考价值。
4、行业案例
以上的业务应用案例是不带行业属性的，那么这一部分将结合一些业务场景来看各个行业的案例。主要围绕每个案例产生的背景、需要使用实时计算的痛点、使用实时计算后解决的问题或产生的价值来展开。
金融行业应用
实时计算在金融行业应用比较多是因为金融行业正在面临数据化的转型。转型和变化表现在，从传统到线上，由传统向云上发展，由人决策向机器决策转换等等。这样会带来几个比较大的变化：
第一是它的业务会越来越复杂，以前只有线下业务，现在有了更多不同类型的业务，比如线上业务，终端业务等等；而且服务链条也越来越长，业务的变化也越来越快。第二是数据需要实行一些决策。以前线下业务在柜台，是点对点的业务沟通和服务，对时效性要求不高。但是新增的线上业务或终端业务，就完全需要一个实时数据监控和实时化的决策，对系统实时化需求更高了。这种实时决策的需求同时对数据质量也会越来越高，这样才能避免决策的失误。
第三是传统风控向实时风控的转型。在金融体系中，像信用违约、账户安全、贷款记账等等，以前的线下业务是靠很多人的参与完成决策的，现在全部数字化后，系统的实时风控就能解决。所以实时计算可以实现对系统整个链路数据的实时采集、实时计算和实时实施，最终实时反馈到业务线上。
在线教育行业应用
由于今年疫情的关系，在线教育行业非常火爆，推动了传统教育向在线教育的转型。在线教育行业面临着很大的实时自动化的需求，因为第一是数据量大，用户量暴增造成数据的暴增；第二是延迟，很多推荐场景或是运营场景，对实时化有强烈的诉求。传统教育的报表是以离线时效性给给到老板查阅分析，但随着行业的数据化转型，数据开始产生价值，实时数据能够为一线运营人员提供决策的依据。
第三是复杂，在线教育行业因疫情而爆发增长，属于比较新的行业，那么他们的业务在快速发展的同时，一些BI场景也是处于快速变化中的，而且也比较复杂，因此急需一套完整的实时解决方案，帮助他们完成业务的数据的实时化和AI化的转型。这就需要用到阿里实时计算 Flink 来解决了，它能帮助客户快速使用 Flink SQL
解决业务问题。
内容资讯行业应用
内容资讯行业本身是数据密集型行业，而且已经实现个性化推荐，例如今日头条、抖音等平台。这种个性化的推荐需要大量的数据做实时决策。所以当一个公司，数据量突然猛增，业务发展迅猛，那么就需要实时计算解决方案。
另外，如果业务形态比较复杂也需要实时计算的帮助。有一些资讯平台，不仅有新闻内容，还有UGC、短视频、直播等内容，各种形态千差万别。这就对实时化计算的诉求很强了。第三就是个性化推荐的实现，更是需要实时化计算来助力。它能够实时的把在线业务系统、用户行为等，实现实时抓取并计算，最终服务用户产生个性化推荐。
电商行业应用
实时计算 Flink在阿里首先落地到了电商上，所以应用到电商行业的实时计算应用场景也很多。首先就是上文提到的每年双11的实时巨屏；双11期间淘宝天猫卖家对渠道出货情况的实时了解，广告投放的实时动态等等，以保证能在双11仅仅24小时的窗口期，及时调整销售策略和广告策略，创造最大价值。
广告行业应用
广告行业从诞生之初，都是一个时效性要求非常高的行业。对广告来说大部分的场景或核心场景都对实时化的要求就比较高。广告数据的真实性对企业来讲是非常重要的，那么能够实时地将因广告产生的用户行为数据、索引数据、广告链接点击和检测等等反馈到系统，借助在线反作弊来反馈真实的流量数据，对企业来讲是有价值的。
实时计算 Flink 可以极大减少业务开发人员和架构人员在面临实时计算的各种各样不确定性情况时，做到非常稳定地实现广告业务并保证企业的广告收益。
