Flink原理与实践全套教学课件.pptx

第一章大数据技术概述;大数据的5个V Volume：数据量大 Velocity：数据产生速度快 Variety：数据类型繁多 Veracity：数据真实性 Value：数据价值;单台计算机无法处理所有数据，使用多台计算机组成集群，进行分布式计算。 分而治之： 将原始问题分解为多个子问题 多个子问题分别在多台计算机上求解 将子结果汇总 比较经典的模式和框架： MPI MapReduce;MPI：Message Passing Interface消息传递接口 使用分治法将问题分解成子问题，在不同节点上分而治之地求解。 MPI提供数据发送和数据接收操作： 将本进程中某些数据发送给其他进程 接收其他进程的数据 自行设计分治算法，将复杂问题分解为子问题 优势：以很细的粒度控制数据的通信 劣势：难度大，开发调试时间成本高;程序员只需要定义两个操作：Map和Reduce 案例：三明治制作 Map阶段将原材料在不同的节点上分别进行处理 Shuffle/Group阶段将不同的中间食材进行组合 Reduce阶段最终将一组中间食材组合成三明治成品 学习门槛比MPI低;单条数据被称为事件（Event）或者被称为一条数据或一个元素。 事件按照时序排列会形成一个数据流（Data Stream）。 数据流一般是无界（Unbounded）的，某段有界数据流（Bounded Data Stream）可以组成一个数据集。 ;批处理（Batch Processing）：对一批数据进行处理 案例：微信运动统计步数，银行信用卡账单统计… 数据总量大，计算非常耗时 流处理 数据本质上是流，流处理（Stream Processing）对数据流进行处理 案例：查看电商实时销售业绩、股票交易…;流处理一般使用生产者-消费者模型 股票交易案例：辅助人工决策 实现消费者侧代码，以10秒为一个时间窗口，统计窗口内的交易情况 可扩展性：随着数据不断增多，能否保证我们的程序能够快速扩展到更多的节点上。 数据倾斜：数据没有均匀分布到分布式系统各个节点上。 容错性：系统崩溃重启后，之前的那些计算如何恢复。 时序错乱：数据到达的时间和实际发生的时间是不一致的，有一定的延迟，需要设计等待策略。 Flink：为流处理而生。 ;MapReduce编程模型的一种实现，逐渐形成了一整套生态圈。 主要组件： Hadoop MapReduce：数??处理模型，面向批处理。 HDFS： 分布式文件系统，提供存储支持。 YARN：资源调度器，分配计算资源。 其他著名组件： Hive：SQL-on-Hadoop Hbase：基于HDFS的分布式数据库，毫秒级实时查询 Kafka：消息队列 ZooKeeper：分布式环境的协调;Spark初衷：改良Hadoop MapReduce的编程模型，提高运行速度，优化机器学习性能。 易用性：比MapReduce更好用，提供了多种编程语言API，支持SQL、机器学习和图计算。 速度快：尽量将计算放在内存中。 完美融入进Hadoop生态圈。 流处理：Spark Streaming，mini-batch思想，将输入数据流拆分成多个批次。 Spark是一个批流一体的计算框架。 ;消息队列：数据集成和系统解耦，某个应用系统专注于一个目标。 企业将各个子系统独立出来，子系统之间通过消息队列来发送数据。;主要面向流处理 流处理框架经历了三代演进 Storm Spark Streaming Flink 事件投递保障：Exactly-Once：一条数据只影响一次最终结果 毫秒级的延迟;Lambda架构：批处理层、流处理层、在线服务层 批处理层：等待一个批次数据，使用批处理框架计算，得到一个非实时的结果。比如，凌晨0点开始统计前一天所有商品的计算次数，计算需要几个小时。 流处理层：使用流处理框架生层结果。早期的流处理框架不成熟，结果近似准确。 在线服务层：将来自批处理层准确但有延迟的预处理结果和流处理层实时但不够准确的预处理结果做融合。 程序员需要维护批处理和流处理两套业务逻辑。 ;Kafka等消息队列可以保存更长时间的历史数据，它不仅起到消息队列的作用，也可以存储数据，替代数据仓库。 Flink流处理框架解决了事件乱序下计算结果的准确性问题。 程序员只维护一套流处理层，维护成本低。;延迟：一个事件被系统处理的总时间。 案例：自助食堂，一位用餐者从进入食堂到离开食堂的总耗时。高峰时，总耗时会增加。 分位延迟更能反映系统的性能。 吞吐：系统最大能处理多少事件。与系统本身设计有关，也与数据源的数据量有关。 延迟与吞吐相互影响，一起反映了系统的性能。 优化方式：优化单节点内的计算速度，使用并行策略，分而治之地处理数据。 ;滚动窗口（Tumbling Window）：定义一个固定的窗口长