Question

3讨论flink、storm和spark的特点和适用场景以此讨论为起点能否同时明确

Answer 1

问：3讨论flink、storm和spark的特点和适用场景以此讨论为起点能否同时明确

答：亲，您好，很高兴为您解答，请稍等，正在解答中

问：3.讨论Flink、Storm和Spark的特 点和适用场景?以此讨论为起点，能否同时明确例如Kafaka等其他工具的大数据生态位?

答：您好，Spark使用弹性分布式数据集(Resilient Distributed Dataset,RDD)，RDD比MapReduce的文件模型更抽象，依赖于运算关系以确保可恢复性。RDD通常用于分布式共享内存或完全虚拟化，也就是说，当下游处理完全在本地时，可以对一些中间结果进行优化和省略。这节省了大量不必要的输入和输出，是Spark早期性能优势的主要基础。Spark还使用RDD上的转换(操作符)来描述数据处理，每个操作符(如map、filter、join)生成一个新的RDD，所有的操作符形成一个有向无环图(Directed Acvclic Graph，DAG)。Spark简单地将图的边划分为2类:宽依赖和窄依赖，当上下游数据不需要混洗时，边是一个窄依赖，在这种情况下，上下游操作可以在同一个staae中进行木地外理，并且可以忽略上游结果RDD的物化，下图呈现了这里涉及的基本概念。相比之下，Flink的基本数据模型由数据流组成，例如事件序列。数据流作为数据的基本模型，可能不如表或数据块那样直观和熟悉，但仍然可以提供一组完全等效的特性。人们普遍认为数据流是没有边界的，但它也可以是一个有边界的有限流，处理这些流相当于批处理。为了描述数据处理过程，Flink在数据流上使用操作符，每个操作符生成一个新的数据流。从操作符、DAG和上下游操作符的链接来看，整体模型和Spark大体相同。Flink的定点相当于Spark中的阶段，将操作符划分为定点的过程和上图中在 Spark DAG中划分为stage的过程基本相同。相比之下，Flink的基本数据模型由数据流组成，例如事件序列。数据流作为数据的基本模型，可能不如表或数据块那样直观和熟悉，但仍然可以提供一组完全等效的特性。人们普遍认为数据流是没有边界的，但它也可以是一个有边界的有限流，外理这些流相当干批外理。为了描述数据处理过程，Flink在数据流上使用操作符，每个操作符生成一个新的数据流。从操作符、DAG和上下游操作符的链接来看，整体模型和Spark大体相同。Flink的定点相当于Spark中的阶段，将操作符划分为定点的过程和上图中在 Spark DAG中划分为stage的过程基本相同。

答：您好，如果Hadoop项目继续发展，且没有Spark项目 出现，那么Hadoop项目会演进出类似优秀的统- -性的内存计算引擎。taz计算引擎也是基于内存计算

问：3.讨论Flink、Storm和Spark的特 点和适用场景?以此讨论为起点，能否同时明确例如Kafaka等其他工具的大数据生态位?

问：这个问题呢？

答：您好。请稍等，正在整理资料

答：spark是一个执行引擎，本身不保存数据，所以需要外部的文件系统来保存数据，很多时候会基于hadoop来保存数据。spark计算时尽可能把数据放到内存中（基于内存），还提供了很好的上层用户使用的接口，包括spl语句（spark sql），处理数据十分方便。它比map-reduce处理框架（基于磁盘）要快很多倍。现在基本上用它来做离线数据处理。storm是一个实时数据处理框架，只提供最基本的数据流传输框架元素和基本的数据流接口，用户需要自己编写处理过程和处理逻辑。flink是实时数据处理系统，自己有一套完整的生态。上层提供了很多数据处理算子（接口函数）供用户使用，对用户更加友好，方便使用。现在很多公司都用它来进行实时数据处理。

答：，Spark 提出了内存计算的概念，核心思想就是中间结果尽量不落盘。依靠这样的基础思想，Spark 相对 Hadoop MapReduce 获得了千百倍的性能提升，代价是更高的内存开销以及 OOM 风险。经历过 Spark 1.x 年代的研发和运维应该都对此深有体会。Storm 和 Flink 完全是另一个路数。我们这里讨论 Flink 的流计算部分，而不讨论它早年被 Spark 全方位吊打的 DataSet 批计算部分。前面讨论的批计算，其特点是输入数据集是事先知晓且有限的，而流计算的世界观认为输入数据集是无限的消息流。因此，它们的计算逻辑处理的不是一批一批的数据，而是一条一条连绵不断的消息。Storm 通过产生数据流的源头和消费数据流的管道来抽象流计算的世界，Flink 的流计算部分其实大同小异。两者最大的区别或者说 Flink 最大的优势是它拥有内置的状态管理和精确一次送达语义的容错机制。Flink 的官方标语就是状态化的流计算，因此这才是它的核心竞争力。有了内置的状态管理，Flink 相比 Storm 就少了对接外部状态存储的负担。要知道，每次手动对接外部存储，重复开发量是巨大的，而且涉及两个分布式项目的端到端一致性保证，将变得非常复杂。以上就是对这四个项目口水化的介绍，其使用场景大抵如下。Spark 作为批计算的王者存在，基本处理所有分布式批处理的场景。有的时候会使用 Hadoop MapReduce 是因为存量业务没有明显的性能瓶颈，不需要故意开发迁移。另一种情况是在没有严格性能要求的情况下，减少 Spark 的部署运维成本，简单使用 HDFS 集群直接支持的 MapReduce 计算任务。还有一种情况是早年某些 MapReduce 作业的 DSL 的存量，传递依赖 MapReduce 且同样没有升级的强需求，例如 Pig 程序。Flink 作为流计算的标杆，基本覆盖了阿里巴巴内部的流计算场景。但是，在阿里强推之前，或者从技术上说被双十一磨砺之前，大部分公司的伪实时需求可以通过 Spark Streaming 或者 Storm 乃至订阅 Kafka 加消费者任务来解决。因此市面上非 Flink 的流计算大抵是过时或者有局限性技术的存量。

问：可以了吗

问：1.学习Spark用那种语言好?是Scala还是Python?理由是什么?

问：4.结合教材、理论课件和你自己的感受，谈谈Spark的学 习路线应该是怎样的?