凭据IBM Marketing cloud的最新陈诉，"仅已往两年就建立了当今世界90％的数据，天天建立2.5亿亿字节的数据，而且随着新设备，传感器和技术的泛起， 数据增长率可能会进一步加速"。从技术上讲，这意味着我们的大数据处置惩罚世界将变得越发庞大且更具挑战性。而且，许多用例（例如，移动应用广告，欺诈检测，出租车预订，病人监护等）都需要在数据到达时举行实时数据处置惩罚，以便做出快速可行的决议。
这就是为什么漫衍式流处置惩罚在大数据世界中变得很是盛行的原因。如今，有许多可用的开源流框架。有趣的是，险些所有它们都是相当新的，仅在最近几年才开发出来。因此，对于新手来说，很容易混淆流框架之间的明白和区分。
在本文中，我将首先大致讨论流处置惩罚的类型和方面，然后比力最受接待的开源流框架：Flink，Spark流，Storm，Kafka流。我将实验（简要地）解释它们的事情原理，它们的用例，优势，局限性，异同。
什么是流/流处置惩罚：我发现的最优雅的界说是：一种数据处置惩罚引擎，其设计时思量了无限的数据集。而已。
与批处置惩罚差别，批处置惩罚以事情中的开始和竣事为数据界限，而事情是在处置惩罚有限数据之后完成的，而流处置惩罚则意味着一连不停地处置惩罚无限制的数据，这些数据一连几天，数月，数年甚至是永远。这样一来，流媒体应用法式始终需要启动和运行，因此难以实现且难以维护。
流处置惩罚的重要方面：为了明白任何Streaming框架的优点和局限性，我们应该相识与Stream处置惩罚相关的一些重要特征和术语：· 交付保证：这意味着无论如何，流引擎中的特定传入记载都将获得处置惩罚的保证。可以是Atleast-once（一次，纵然发生故障也将至少处置惩罚一次），Tomost-once（如果发生故障则可能不会被处置惩罚）或Exactly-once（一次处置惩罚，而且纵然是一次也仅处置惩罚一次） 失败）。
显然，只希望一次，可是很难在漫衍式系统中实现，而且需要权衡性能。· 容错：如果发生诸如节点故障，网络故障等故障，框架应该能够恢复并应该从其脱离的位置重新开始处置惩罚。
这是通过不时检查流向某些持久性存储的状态来实现的。例如 从卡夫卡获取记载并对其举行处置惩罚后，将检查点卡夫卡抵消给动物园治理员。· 状态治理：在有状态处置惩罚要求的情况下，我们需要保持某种状态（例如，记载中看到的每个差别单词的计数），框架应该能够提供某种机制来生存和更新状态信息。· 性能：这包罗延迟（可以多久处置惩罚一条记载），吞吐量（每秒处置惩罚的记载数）和可伸缩性。
延迟应尽可能小，而吞吐量应尽可能大。很难同时获得两者。
· 高级功效：事件时间处置惩罚，水印，窗口化这些功效是流处置惩罚要求庞大时所需的功效。例如，凭据在源中生成记载的时间来处置惩罚记载（事件时间处置惩罚）。要相识更多详细信息，请阅读Google家伙Tyler Akidau的必读文章：part1和part2。· 成熟度：从接纳角度来看，重要的是，该框架已经由大公司的验证并经由了大规模的测试。
更有可能获得良好的社区支持并在客栈溢出方面提供资助。流处置惩罚的两种类型：现在相识了我们刚刚讨论的术语，现在很容易明白，有两种方法可以实现Streaming框架：本机流：也称为本机流。这意味着每条到达的记载都市在到达后立刻处置惩罚，而无需等候其他记载。
有一些一连运行的历程（凭据框架，我们称之为操作员/任务/螺栓），这些历程将永远运行，每条记载都将通过这些历程举行处置惩罚。示例：Storm，Flink，Kafka Streams，Samza。微批处置惩罚：也称为快速批处置惩罚。
这意味着每隔几秒钟将传入的记载分批处置惩罚，然后以单个小批处置惩罚的方式处置惩罚，延迟几秒钟。示例：Spark，Storm。
这两种方法都有其优点和缺点。原生流很自然，因为每条记载在到达时都市被处置惩罚，从而使框架实现了尽可能小的延迟。但这也意味着在不影响吞吐量的情况下很难实现容错，因为对于每条记载，一旦处置惩罚，我们就需要跟踪和检查点。而且，状态治理很容易，因为有长时间运行的历程可以轻松维护所需的状态。
另一方面，微批处置惩罚则完全相反。容错是免费提供的，因为它本质上是一个批处置惩罚，吞吐量也很高，因为处置惩罚和检查点将在一组记载中一次性完成。但这会花费一定的等候时间，而且不会感受像是自然的流式传输。
高效的状态治理也将是维持的挑战。流框架一对一：Storm：Storm是流媒体世界的产物。它是最古老的开源流框架，也是最成熟和可靠的框架之一。
这是真正的流传输，适合基于简朴事件的用例。我在以下帖子中详细分享了有关Storm的详细信息：part1和part2。优点：· 极低的延迟，真正的流，成熟和高吞吐量· 很是适合简朴的流媒体用例缺点· 没有状态治理· 没有高级功效，例如事件时间处置惩罚，聚合，开窗，会话，水印等· 一次保证Spark Stream：Spark已成为批处置惩罚中hadoop的真正继任者，而且是第一个完全支持Lambda体系结构的框架（在该框架中，实现了批处置惩罚和流传输；实现了正确性的批处置惩罚；为速度而流化）。
它很是受接待，成熟并被广泛接纳。Spark Streaming是随Spark免费提供的，它使用微批处置惩罚举行流媒体处置惩罚。在2.0版本之前，Spark Streaming有一些严重的性能限制，可是在新版本2.0+中，它被称为结构化流，并具有许多良好的功效，例如称为钨的自界说内存治理（如flink），水印，事件时间处置惩罚支持等。
另外，结构化流更为抽象，在2.3.0版本中，可以选择在微批量和一连流模式之间举行切换。一连流模式有望带来像Storm和Flink这样的子延迟，可是它仍处于起步阶段，操作上有许多限制。优点：· 支持Lambda架构，Spark免费提供· 高吞吐量，适用于不需要亚延迟的许多使用情况· 由于微批量性质，默认情况下具有容错能力· 简朴易用的高级API· 庞大的社区和努力的革新· 恰好一次缺点· 不是真正的流媒体，不适合低延迟要求· 要调整的参数太多。
很难做到正确。在调整Spark Streaming时写了一篇关于我的小我私家履历的文章· 天生无国籍· 在许多高级功效方面落伍于FlinkFlink：Flink也来自类似Spark这样的学术配景。Spark来自加州大学伯克利分校，而Flink来自柏林工业大学。
像Spark一样，它也支持Lambda架构。可是实现与Spark完全相反。虽然Spark本质上是一个批处置惩罚，其中Spark流是微批处置惩罚，而且是Spark Batch的特例，但Flink本质上是一个真正的流引擎，将批处置惩罚视为带界限数据流的特例。
只管两个框架中的API都是相似的，可是它们在实现上没有任何相似之处。在Flink中，诸如map，filter，reduce等的每个函数都实现为长时间运行的运算符（类似于Storm中的Bolt）Flink看起来像是Storm的真正继续者，就像Spark批量继续了hadoop一样。优点：· 开源流媒体领域的创新向导者· 具有所有高级功效（例如事件时间处置惩罚，水印等）的第一个True流框架· 低延迟，高吞吐量，可凭据要求举行设置· 自动调整，无需调整太多参数· 恰好一次· 被Uber，阿里巴巴等大型公司广泛接受。
缺点· 角逐举行得很晚，最初缺乏接纳· 社区不如Spark大，但现在正在快速生长· 停止现在，尚无人接纳Flink Batch，仅盛行于流媒体。Kafka Streams：与其他流框架差别，Kafka Streams是一个轻量级的库。对于从Kafka流式传输数据，举行转换然后发送回kafka很有用。
我们可以将其明白为类似于Java Executor服务线程池的库，但具有对Kafka的内置支持。它可以与任何应用法式很好地集成在一起，而且可以立刻使用。由于其重量轻的特性，可用于微服务类型的体系结构。与Flink在性能方面没有匹配，但不需要运行单独的集群，很是利便且易于部署和开始事情。
内部使用Kafka Consumer组并研究Kafka日志哲学。这篇文章彻底解释了Kafka Streams与Flink Streaming的用例。Kafka Streams的一个主要优点是它的处置惩罚是完全准确的端到端。
可能是因为泉源和目的地都是Kafka以及从2017年6月左右公布的Kafka 0.11版本开始，仅支持一次。要启用此功效，我们只需要启用一个标志即可使用。有关此处和此处共享的更多详细信息。
优点：· 重量很轻的库，适合微服务，IOT应用· 不需要专用集群· 继续卡夫卡的所有优良特性· 支持流毗连，内部使用rocksDb维护状态。· 恰好一次（从Kafka 0.11开始）。缺点· 与卡夫卡精密联合，在没有卡夫卡的情况下无法使用· 婴儿期还很新，尚待大公司测试· 不适用于繁重的事情，例如Spark Streaming，Flink。
Samza：简短先容一下Samza。从100英尺高的萨姆扎（Samza）看上去与卡夫卡Stream（Kafka Streams）相似。有许多相似之处。这两个框架都是由同一位开发人员开发的，这些开发人员在LinkedIn实施了Samza，然后在他们建立Kafka Streams的地方建立了Confluent。
这两种技术都与Kafka精密联合，从Kafka获取原始数据，然后将处置惩罚后的数据放回Kafka。使用相同的Kafka Log哲学。
Samza是Kafka Streams的缩放版本。Kafka Streams是用于微服务的库，而Samza是运行在Yarn.Advantages上的完整框架集群处置惩罚。· 在使用rocksDb和kafka日志维护大型信息状态（适用于毗连流的用例）方面很是好。
· 使用Kafka属性的容错和高性能· 如果已在处置惩罚管道中使用Yarn和Kafka，则要思量的选项之一。· 好纱民· 低延迟，高吞吐量，成熟并经由大规模测试缺点：· 与Kafka和Yarn精密相连。如果这些都不在您的处置惩罚管道中，则不容易使用。
· 至少一次加工保证。我不确定它是否像Kafka 0.11之后的Kafka Streams现在完全支持一次· 缺乏高级流功效，例如水印，会话，触发器等流框架比力：我们只能将技术与类似产物举行比力。只管Storm，Kafka Streams和Samza现在对于更简朴的用例很有用，但具有最新功效的重量级产物之间的真正竞争显而易见：Spark vs Flink当我们谈论比力时，我们通常会问：给我看数字:)基准测试是仅当第三方举行比力时比力的好方法。例如，一个古老的基准标志就是这个。
但这是在Spark Streaming 2.0之前的时候，它受到RDD的限制而且项目钨没有到位。现在在Structured Streaming 2.0版本公布之后，Spark Streaming试图追赶许多工具，而且似乎很难 奋斗。最近，基准测试已成为Spark和Flink之间的一场猛烈争吵。
Spark最近与Flink举行了基准测试比力，Flink开发人员对Flink开发人员举行了另一项基准测试，之后由Spark成员编辑了该帖子。最好不要相信这些天的基准测试，因为纵然很小的调整也可以完全改变数字。
没有什么比决议之前实验和测试自己更好。到现在为止，很显着，Flink在流分析领域处于领先职位，它具有大多数期望的方面，例如准确一次，吞吐量，延迟，状态治理，容错，高级功效等。之所以能够实现这些功效，是因为Flink的一些真正创新，例如轻量级快照和堆外自界说内存治理.Flink的一个重要问题是成熟度和接纳水平，直到一段时间之前，但现在Uber，阿里巴巴，CapitalOne等公司正在使用Flink流 大规模证明Flink Streaming的潜力。
最近，Uber开源了他们最新的称为AthenaX的流分析框架，该框架基于Flink引擎构建。在本文中，他们讨论了如何将流分析从STorm迁移到Apache Samza，再到现在的Flink。
如果您已经注意到，需要注意的重要一点是，所有支持状态治理的本机流框架（例如Flink，Kafka Streams，Samza）在内部都使用RocksDb。RocksDb从某种意义上说是唯一无二的，它在每个节点上当地保持持久状态，而且性能很高。它已成为新流媒体系统的关键部门。我在先前的一篇文章中分享了有关RocksDb的详细信息。
如何选择最佳的流媒体框架：这是最重要的部门。老实的谜底是：这取决于:)重要的是要记着，对于每个用例，没有一个处置惩罚框架可以成为万灵丹。每个框架都有其优点和局限性。
只管如此，凭借一些履历，他仍然会分享一些有助于制定决议的建议：· 取决于用例：如果用例很简朴，那么如果学习和实现起来很庞大，则无需寻求最新，最好的框架。在很大水平上取决于我们愿意为想要的回报投入几多。
例如，如果它是基于事件的简朴IOT事件警报系统，那么Storm或Kafka Streams可以很好地使用。· 现有技术客栈：更重要的一点是思量现有技术客栈。
如果现有客栈的首尾相连是Kafka，则Kafka Streams或Samza可能更容易安装。同样，如果处置惩罚管道基于Lambda架构，而且Spark Batch或Flink Batch已经到位，则思量使用Spark Streaming或Flink Streaming是有意义的。例如，在我以前的项目之一中，我已经在管道中添加了Spark Batch，因此，当流媒体需求到来时，选择需要险些相同的技术和代码库的Spark Streaming相当容易。简而言之，如果我们很好地相识框架的优点和局限性以及用例，那么选择或至少过滤掉可用的选项就越发容易。
最后，一旦选择了两个选项，拥有POC总是一件好事。究竟每小我私家都有差别的味蕾。
结论：Apache Streaming空间的生长速度如此之快，以至于在信息方面，此职位可能在几年后已经由时。现在，Spark和Flink在开发方面是领先的重量级人物，但仍有一些新手可以加入角逐。Apache Apex是其中之一。
另有一些我没有先容的专有流解决方案，例如Google Dataflow。我的这篇文章的目的是资助流媒体新手以最少的术语明白流媒体的一些焦点观点，以及盛行的开源流媒体框架的优点，局限性和用例。
希望该帖子对您有所资助。快乐流！您可以在Linkedin和Quora上关注我(本文翻译自chandan prakash的文章《Spark Streaming vs Flink vs Storm vs Kafka Streams vs Samza : Choose Your Stream Processing Framework》，参考：https://medium.com/@chandanbaranwal/spark-streaming-vs-flink-vs-storm-vs-kafka-streams-vs-samza-choose-your-stream-processing-91ea3f04675b)。
本文关键词：爱,游戏,app,下载,Spark,Streaming,Flink,Storm,Kafka,和,爱游戏下载
本文来源：爱游戏app下载-www.zorgoom.com