开发者学堂课程【实时计算 Flink 实战课程：实时计算 Flink 训练营场景与应用】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/762/detail/13352
实时计算 Flink 训练营场景与应用
2、Stream Analytics
// 三大场景的第一个，同时也是Flink 在目前在中国来说，包括在阿里看到最多的一个使用产品为Stream Analytics ，对于它来说，对应的就是批处理与流处理。这里与之对应就是左边的Batch analytics 以及右边的Streaming analytics 。
// 对于左边的Batch analytics 来说，大部分人比较熟悉，因为举了Flink 的例子，但是实际上之前用的好多其实都是一个典型的Batch analytics 场景，有时会有传统的一个交互式分析，其实就是一个批处理或者批查询，把基于有限的一个数据集进行加工、计算。此时用户先将数据装载到存储系统，包括演算存储系统或者数据活动程序系统，之后进行批处理引擎及计算，过程就是如此，与刚才描述批处理的三步应该是完全一致的。
// 对于右边的Streaming analytics 来说，它与左边的Batch analytics 正好相反，但是在之前的技术原理图里面已经讲解了这一部分内容，对于Streaming analytics 来说，数据流是持续不断的进入计算系统。再看到图中右边中间小松鼠那块Continuous Ouery / Application ，数据持续的进入我们的application或者是Ouery所代表的进程或者程序里面会持续的消费和计算结果，同时结果会写入外部的存储，例如Database或者 K-V Store，可以将数据通过我们的lashbored 或者livereport对终端的用户数据进行保存。其实对于Batch analytics 以及Streaming analytics 来说，是批处理和流处理在analytics 场景下的延伸，原理是完全一致的，与之前讲解的内容是完全一致的。故如果对前面那些图（批处理与流处理对比）比较熟悉的话，对其也应该不会感到陌生。
对于Streaming analytics 进行展开讲解，Streaming analytics 主要讲解的知识产品为流计算。用实时的流计算分析，Streaming analytics 应用的优势为规避了批处理部分的周期性数据的导入以及计算整个高延迟的过程，把它完全替换成数据产生、传输，进入到流式处理系统进行加工处理。整个的链条十分短，时效性高。这是对于流式分析应用的一个优势。实时计算产品Flink 支持数据分析的应用，其实最大的一个特点就是Flink 相比于之前的 stop 或者 stap来说非常大的一个优点在于内置的一套 ANSI 的系统，其实是阿里巴巴、阿里云贡献给整个 Flink 社区的，ANSI标准的 SQL 接口 是在集团内部2015年开始承接天猫双十一的大屏。一套SQL的视线十分成熟稳定，因为其实对于大量数据的工程师或者数据开发工程之后的 BI 分析是擅长二维的关系代数模型，或者用程序员表达就是 SQL 接口，这套接口其实是完全几乎是整个工业界的一种规范，而对于流处理来说，其实都没有一个符合或者近似符合标准的一个接口，而Flink 在这部分有重大的突破，同时得到了许多人的认可，Flink 提供了一个 NOSI标准的 SQL 接口，将流式处理的技术民主化，将这套技术赋能给了大量的 BI 的工程师或者储藏开发人员等，他们只要会一些 SICO 稍微或者通晓一些 Flink 流式处理的原理。就能够做相应的优势开发，这比之前的有更大优势。Streaming analytics 应用场景目前能看到的是不全的，都是用点状法举例。实时数仓在空间比较广阔，包括实时数据中台的概念之前是阿里的数据中台的部门提供的，但实际上对于整个数据中台来说，其实以下还会细分，包括离线数据中台与实时数据中台。整个实时数据中台在集团内部也是通过 Flink 构建的一个实时的数据中台。第三点是实时 BI ，其实与之前 analytics 相呼应匹配，做完 analytics 之后一般是BI 。
3、Stream Pipelines
// Stream Pipelines可能受到文化差异的影响，如图所示，左边为批处理periodic ETL ，右边为实时处理Data Pipelines ，其实中国人一般会将数据的处理，比如周边有时也会叫作 Pipelines ，当然有时也会叫作 ETL 。
// 而对于右边来说，有时叫作 Pipelines ，有时也会叫作 Stream Pipelines 。文化的一个差异，国外特别是欧美，会强调实时化，所以从字面意思上理解，其实并没有看到实时这个点，但其实好像对于欧美这边这个单词隐藏的含义就是数据的实时化，然后对于离线来说会叫作 ETL 。实际上在本质上说右边的批处理是偏实时的 ETL ，这是按照中国人自己的一个叫法，故整个的数据管的可以看到 ETL ，在整个过程对 Flink 来说，或者对流处理来说，是一个有持续流模型来运行的，不像批处理是触发一下、运行一下、数据导入一下，然后结束。流处理是持续的导入相应问题。如此能将数据的利用变得实时化。
（1） Data Pipeline
// Data Pipeline 直译数据管道，实际上更要强调实时或者Streamming 的ETL，对于Streamming ETL 来说，最大的特点在于有效的降低了数据从源端移动到目的端中间的延迟，将时效性有效的提升，将延迟有效的降低，能够持续消费及发送数据，相对于离线处理来说，这就是不一样的特点。而对于 Flink 来说，除去刚才讲解的 SQL 接口 ，其实 Table API 也能进行表达。同时提供了一个字典函数，若做列扩展、一系列相关的裁剪或者做一些变化，可以提供一些资源。但是对于有非常低底层硬创的一些需求，Flink 还提供了Table API 作特殊化的响应处理，其中有Kafka 、Kinesis、 Elasticsearch等，越往底层越灵活，但是用户需要操心的事务越来越多。对于 Stream Pipelines来说，能看到其他场景实时的数据信息，往往是构建实时数据市场或者实时数据中台非常重要的一个前置步骤。实时索引构建其实对于 Stream Pipelines 及Flink 在阿里巴巴落地来说，第一个是实时搜索，搜索部门做实时的索引的构建。第三个是实时的告警，当Flink 计算完成后的结果，需要实时的写入告急系统，这就是实时告警的一个特点。
（2）Event-Driven Application
// 最后一点是Event-Driven Application，其实对于Flink 来说，希望定义为流式处理的一个翘楚，想将指示技术在实时计算一个实时化的分析及处理，想做到更加极致实时化。就是当进入一条数据的时，会更加自定化或者个性化的处理，处理完成的结果同时会提供支持，此时围绕着application，读取、写入等能够做到快速的状态。若是一个坐标轴的话，希望 Flink 能够也能涉足到近实时处理，甚至完全实时化处理，同时将Flink 推想做更加极致化的一个流。极致化的Event-Driven Application的架构，其实满足的是一部分的需求，希望能够处理的更加极致的、非流式分析的一个场景。
// 对于这种场景来说，Flink 的核心的优势特点就是状态，因为相比普通的一些事件触发的引擎或者框架来说，其实在里面最大的一个特点是会在意stage。可以保证运行即使出现问题时，也能够做到快速运行，同时这份检查还是存在本地的，所谓存在本地就在于流式处理或者Event-Driven Application的进程，可以直接访问本地的存储，而不需要访问远端的数据库，能够极大的减少时间。实际上目前在中国这边用的不算多，下面会举一些案例进行分析，若有感兴趣，欢迎之后再进行探讨。Event-Driven Application暴露了非常底层的API Profunction，它非常灵活，非常灵活，能够做一些比较复杂的非二维的关系代数模型的非分析类的问题。比如异常检测、复杂的规则引擎的告警等，都是比较复杂的、非二维的关系代数模型描述的应用。
// 第二章总结：技术场景是一个高度通用的抽象化的产品。这些场景是线下的一些场景，可以理解为一个基石，希望通过这些场景，未来在遇到其他场景的时候都能够收敛、归纳，能够运用到这些场景里面的技术场景来帮助识别。
三、应用场景
// 接下来内容为几个应用场景，就是在之前场景上做叠加、组合，最后形成的新的与行业无关的应用场景。最后一章举行业相关的一些案例，就会更加的具体，所以是从技术到抽象的场景，到案例，到应用场景，最后的行业案例的过程。
1、实时数仓
// 实时数仓目前来说，实际上他综合了Pipelines 及Event-Driven Application两个接触器，最后形成的实时数仓。与传统的实时数仓最大不同的点就在于能够将业务的数据进行识别、汇聚、加工，最后写入实时的服务层，交互式分析作为一个查询层对外提供服务，但其实满足同样的结果。最核心就在于将业务的整个需求及整个链路实时化。其实是能够极大的去满足一些需要实时探索、实时聚合数与实时业务价值的场景。例如客户需要实时巡查。
2、实时风控
