【Flink】-总结

【Flink】-总结

                                      
                                                                            不善于总结，就是在浪费时间

一、技术背景

        Apache Flink（下简称Flink）项目是大数据处理领域最近冉冉升起的一颗新星，其不同于其他大数据项目的诸多特性吸引了越来越多人的关注。
         这几年大数据的飞速发展，出现了很多热门的开源社区，其中著名的有 Hadoop、Storm，以及后来的 Spark，他们都有着各自专注的应用场景。Spark 掀开了内存计算的先河，也以内存为赌注，赢得了内存计算的飞速发展。Spark 的火热或多或少的掩盖了其他分布式计算的系统身影。就像 Flink，也就在这个时候默默的发展着。
        在国外一些社区，有很多人将大数据的计算引擎分成了 4 代，当然，也有很多人不会认同。我们先姑且这么认为和讨论。
首先第一代的计算引擎，无疑就是 Hadoop 承载的 MapReduce。这里大家应该都不会对 MapReduce 陌生，它将计算分为两个阶段，分别为 Map 和 Reduce。对于上层应用来说，就不得不想方设法去拆分算法，甚至于不得不在上层应用实现多个 Job 的串联，以完成一个完整的算法，例如迭代计算。
        由于这样的弊端，催生了支持 DAG 框架的产生。因此，支持 DAG 的框架被划分为第二代计算引擎。如 Tez 以及更上层的 Oozie。这里我们不去细究各种 DAG 实现之间的区别，不过对于当时的 Tez 和 Oozie 来说，大多还是批处理的任务。接下来就是以 Spark 为代表的第三代的计算引擎。第三代计算引擎的特点主要是 Job 内部的 DAG 支持（不跨越 Job），以及强调的实时计算。在这里，很多人也会认为第三代计算引擎也能够很好的运行批处理的 Job。随着第三代计算引擎的出现，促进了上层应用快速发展，例如各种迭代计算的性能以及对流计算和 SQL 等的支持。Flink 的诞生就被归在了第四代。这应该主要表现在 Flink 对流计算的支持，以及更一步的实时性上面。当然 Flink 也可以支持 Batch 的任务，以及 DAG 的运算。首先，我们可以通过下面的性能测试初步了解两个框架的性能区别，它们都可以基于内存计算框架进行实时计算，所以都拥有非常好的计算性能。经过测试Flink计算性能上略好。
测试环境：
1.CPU：7000个；
2.内存：单机128GB；
3.版本：Hadoop 2.3.0，Spark 1.4，Flink 0.9
4.数据：800MB，8GB，8TB；
5.算法：K-means：以空间中K个点为中心进行聚类，对最靠近它们的对象归类。通过迭代的方法，逐次更新各聚类中心的值，直至得到最好的聚类结果。
6.迭代：K=10，3组数据
迭代次数（纵坐标是秒，横坐标是次数）
Spark和Flink全部都运行在Hadoop YARN上，性能为Flink > Spark > Hadoop(MR)，迭代次数越多越明显，性能上，Flink优于Spark和Hadoop最主要的原因是Flink支持增量迭代，具有对迭代自动优化的功能
迭代次数（纵坐标是秒，横坐标是次数）
Spark和Flink全部都运行在Hadoop YARN上，性能为Flink > Spark > Hadoop(MR)，迭代次数越多越明显，性能上，Flink优于Spark和Hadoop最主要的原因是Flink支持增量迭代，具有对迭代自动优化的功能
Flink和spark的差异
 
技术
Spark
Flink
定义
弹性的分布式数据集，并非真正的实时计算
真正的流计算，就像storm一样但flink同时支持有限的数据流计算（批处理）
高容错  
沉重    
非常轻量级
内存管理
JVM相关操作暴露给用户
Flink在JVM中实现的是自己的内存管理
程序调优
只有SQL有自动优化机制
自动地优化一些场景，比如避免一些昂贵的操作（如shuffle和sorts），还有一些中间缓存
 

二、技术简介

          很多人可能都是在 2015 年才听到 Flink 这个词，其实早在 2008 年，Flink 的前身已经是柏林理工大学一个研究性项目， 在 2014 被 Apache 孵化器所接受，然后迅速地成为了 ASF（Apache Software Foundation）的顶级项目之一。Flink 的最新版本目前已经更新到了 1.6了，在很多人感慨 Spark 的快速发展的同时，或许我们也该为 Flink 的发展速度点个赞。Flink 是一个针对流数据和批数据的分布式处理引擎。它主要是由 Java 代码实现。目前主要还是依靠开源社区的贡献而发展。对 Flink 而言，其所要处理的主要场景就是流数据，批数据只是流数据的一个极限特例而已。再换句话说，Flink 会把所有任务当成流来处理，这也是其最大的特点。
          Flink 可以支持本地的快速迭代，以及一些环形的迭代任务。并且 Flink 可以定制化内存管理。在这点，如果要对比 Flink 和 Spark 的话，Flink 并没有将内存完全交给应用层。这也是为什么 Spark 相对于 Flink，更容易出现 OOM 的原因（out of memory）。就框架本身与应用场景来说，Flink 更相似与 Storm。如果之前了解过 Storm 或者 Flume 的读者，可能会更容易理解 Flink 的架构和很多概念。
           Flink核心是一个流式的数据流执行引擎，其针对数据流的分布式计算提供了数据分布、数据通信以及容错机制等功能。基于流执行引擎，Flink提供了诸多更高抽象层的API以便用户编写分布式任务：
  • DataSet API， 对静态数据进行批处理操作，将静态数据抽象成分布式的数据集，用户可以方便地使用Flink提供的各种操作符对分布式数据集进行处理，支持Java、Scala和Python。
  • DataStream API，对数据流进行流处理操作，将流式的数据抽象成分布式的数据流，用户可以方便地对分布式数据流进行各种操作，支持Java和Scala。
  • Table API，对结构化数据进行查询操作，将结构化数据抽象成关系表，并通过类SQL的DSL对关系表进行各种查询操作，支持Java和Scala。
  • 此外，Flink还针对特定的应用领域提供了领域库，例如：
    • Flink ML，Flink的机器学习库，提供了机器学习Pipelines API并实现了多种机器学习算法。
    • Gelly，Flink的图计算库，提供了图计算的相关API及多种图计算算法实现。
 

三、应用领域

  • 优化电子商务的实时搜索结果：阿里巴巴的所有基础设施团队使用flink实时更新产品细节和库存信息，为用户提供更高的关联性。针对数据分析团队提供实时流处理服务：king通过flink-powered数据分析平台提供实时数据分析，从游戏数据中大幅缩短了观察时间。
  • 网络/传感器检测和错误检测：Bouygues电信公司，是法国最大的电信供应商之一，使用flin监控其有线和无线网络，实现快速故障响应。
  • 商业智能分析ETL：Zalando使用flink转换数据以便于加载到数据仓库，将复杂的转换操作转化为相对简单的并确保分析终端用户可以更快的访问数据。
  • 多种数据源(有时不可靠)：当数据是由数以百万计的不同用户或设备产生的，它是安全的假设数据会按照事件产生的顺序到达，和在上游数据失败的情况下，一些事件可能会比他们晚几个小时，迟到的数据也需要计算，这样的结果是准确的。
  • 应用程序状态管理：当程序变得更加的复杂，比简单的过滤或者增强的数据结构，这个时候管理这些应用的状态将会变得比较难(例如：计数器，过去数据的窗口，状态机，内置数据库)。flink提供了工具，这些状态是有效的，容错的，和可控的，所以你不需要自己构建这些功能。
  • 数据的快速处理：有一个焦点在实时或近实时用例场景中，从数据生成的那个时刻，数据就应该是可达的。在必要的时候，flink完全有能力满足这些延迟。
  • 海量数据处理：这些程序需要分布在很多节点运行来支持所需的规模。flink可以在大型的集群中无缝运行，就像是在一个小集群一样。

四、实现架构

Flink基本架构：
        从上图可知，Flink从另一个角度看待流处理和批处理，将2者统一起来。Flink是完全支持流处理，也就是说流处理看待数据是无界限的，批处理作为流处理的一种特殊情况，数据只是被定义为有界的。
  Flink可以与Hadoop集成，可以方便读取Hadoop项目中的组件数据，如hive,hdfs及Hbase等。以kafka作为流式的数据源，直接可以重用storm代码
DataStream API 可以流畅地分析无限数据流，并且可以用Java 或者Scala 来实现。开发人员需要基于一个叫DataStream 的数据结构来开发，这个数据结构用于表示永不停止的分布式数据流。Flink 的分布式特点体现在它能够在成百上千台机器上运行，它将大型的计算任务分成许多小的部分，每个机器执行一个部分。Flink 能够自动地确保在发生机器故障或者其他错误时计算能持续进行，或者在修复bug 或进行版本升级后有计划地再执行一次。这种能力使得开发人员不需要担心失败。Flink 本质上使用容错性数据流，这使得开发人员可以分析持续生成且永远不结束的数据（即流处理）。

五、应用案例

 

六、优化方案

 

七、运行维护

 
 
 
 
posted @ 2019-05-31 12:37  DayetCH  阅读(299)  评论(0)    收藏  举报