前文对 Spark 和 Flink 的引擎作了对比。对用户来讲引擎并非考虑数据产品的惟一方面。开发和运维相关的工具和环境,技术支持,社区等等,对能不能在引擎上面作出东西来都很重要。这些构成了一个产品的生态。能够说引擎决定了功能和性能的极限,而生态能让这些能力真正发挥出做用。html
Spark 是最活跃的 Apache 项目之一。从 2014 年左右开始获得普遍关注。Spark 的开源社区一度达到上千的活跃贡献者。最主要推进者是 Databricks,由最初的 Spark 创造者们成立的公司。今年 6 月的 Spark+AI 峰会参加人数超过 4000。 Spark 由于在引擎方面比 MapReduce 全面占优,通过几年发展和 Hadoop 生态结合较好,已经被普遍视为 Hadoop MapReduce 引擎的取代者。apache
Flink 也是 Apache 顶级项目,创始者们成立了 Data Artisans。社区规模还没法和 Spark 相比。不过在业界,特别是流处理方面,有不错的口碑。在大规模流处理方面走在最前沿,也是需求最强的几个美国公司,包括 Netflix、 LinkedIn、Uber、Lyft 等,除 LinkedIn 有本身的 Samza 外,都已经采用 Flink 做为流处理引擎或者有了较大投入。安全
阿里集团在 Flink 社区也有较大影响力。最近 Flink 1.3 到 1.5 里都有几个重磅功能是阿里和 Data Artisans 合做或者独立开发的。阿里还有多是世界上最大的流计算集群,也是在 Flink 的基础上开发的。网络
最近的 Spark+AI 峰会上, Databricks 主打的主题是统一分析平台(Unified Analytics Platform)。三大新发布:Databricks delta、Databricks Runtime for ML和 ML flow,都是围绕这一主题。随着近年来机器学习(包括深度学习)在数据处理中占比愈来愈高,能够说 Databricks 又一次把握住了时代的脉搏。架构
统一分析平台回应了 Spark 的初衷。通过几年的探索,对初始问题,即用户能够在一个系统里解决绝大部分大数据的需求,有了一个比较明确具体的解决方案。app
不过有意思的是能够看出 Databricks 在 AI 方面策略的转变。在深度学习流行前,Spark 自带的 MLLib 功能上应该是够用的,可是多是因为兼容性缘由并无取得预期中的普遍采用。框架
对深度学习的新宠 TensorFlow,Spark 曾经推出过 TensorFrames 和 Spark 引擎作了一些集成。结果应该不是很成功,可能尚未 Yahoo 从外面搭建的 TensorFlowOnSpark 影响力大。运维
从此次来看,Spark 转向了集成的策略。Databricks Runtime for ML 实际上就是预装了各个机器学习框架,而后支持在 Spark 任务里启动一个好比 TensorFlow 本身的集群。Spark 引擎方面作的主要改进就是 gang scheduling,即支持一次申请多个 executor 以便 TensorFlow 集群能正常启动。机器学习
MLFlow 更是和 Spark 引擎无关。做为一个工做流工具,MLFlow 的目标是帮助数据科学家提升工做效率。主要功能是以项目为单位记录和管理所作的机器学习试验,并支持分享。设计要点是可重复试验,以及对各类工具的灵活易用的支持。看起来 Spark 暂时在做为 AI 引擎方面可能没什么大动做了。ide
Flink 的目标其实和 Spark 很类似。包含 AI 的统一平台也是 Flink 的发展方向。Flink 从技术上也是能够支持较好的机器学习集成和整条链路的,并且有一些大规模线上学习的使用实例。不过看起来在现阶段 Flink 这方面的平台化尚未 Spark 成熟。值得一提的是 Flink 因为流处理引擎的优点,在线上学习方面可能能支持得更好一些。
产品和生态归根结底是要解决大数据使用者的问题,从数据中产生价值。了解数据的使用者和他们的需求能够帮助咱们在在讨论生态的各方面时有一个比较清晰的脉络。
数据相关的工做者大体能够分为如下角色。实际状况中一个组织里极可能几个角色在人员上是重合的。各个角色也没有公认的定义和明确的界限。
数据采集:在产品和系统中合适的地方产生或收集数据发送到数据平台。
平台:提供数据导入,存储,计算的环境和工具等等。
数据工程师:使用数据平台把原始数据加工成能够供后续高效使用的数据集。把分析师和数据科学家建立的指标和模型等等生产化成为高效可靠的的自动处理。
数据分析师和数据科学家(关于这二者的异同有不少讨论。感兴趣的能够自行搜索。www.jianshu.com/p/cfd94d9e4… 这里的译文能够提供一个视角):为数据赋予意义,发现内含的价值。 下文再不特别区分的地方统称为数据分析。
产品经理,管理和决策层:根据以上产生的数据调整产品和组织行为。
这些构成了一个完整的环。上面的顺序是数据流动的方向,而需求的驱动是反过来的方向。
本文所说的 Spark 和 Flink 的生态主要是对应到数据平台这一层。直接面向的用户主要是数据工程师、数据分析师和数据科学家。好的生态可以大大简化数据平台和数据工程师的工做,并使得数据分析师和数据科学家更加自主化同时提升效率。
从 API 上来看,Spark 和 Flink 提供的功能领域大体至关。固然具体看各个方向支持的程度会有差别。整体来看 Spark 的 API 通过几轮迭代,在易用性,特别是机器学习的集成方面,更强一些。Flink 在流计算方面更成熟一些。
API | Spark | Flink |
---|---|---|
底层 API | RDD | Process Function |
核心 API | DataFrame / Dataset / Structured Streaming | DataStream / Dataset / Table API |
SQL |
![]() |
![]() |
机器学习 |
![]() |
![]() |
图计算 |
![]() |
![]() |
其它 | CEP |
支持的语言也大体至关。Spark 发展的时间长一些仍是有优点,特别是数据分析经常使用的 Python 和 R。
支持语言 | Spark | Flink |
---|---|---|
Java |
![]() |
![]() |
Scala |
![]() |
![]() |
Python |
![]() |
![]() |
R |
![]() |
![]() |
SQL |
![]() |
![]() |
有了 API,再有数据就能够开工了。Spark 和 Flink 都能对接大部分比较经常使用的系统。若是暂时尚未支持的,也都能比较好地支持本身写一个 connector。
www.slideshare.net/chobeat/dat…
这方面数据工程师和数据分析的需求有一些不一样。
数据分析的工做性质比较偏探索性,更强调交互性和分享。Notebook 能比较好地知足这些需求,是比较理想的开发工具,用来作演示效果也至关不错。比较流行的 Notebook 有 Apache Zeppelin,Jupyter 等。Databricks 更是本身开发了 Databricks Notebook 并将之做为服务的主要入口。Zeppelin 支持 Spark 和 Flink,Jupyter 还只支持 Spark。
数据工程师的工做更倾向于把比较肯定的数据处理生产化,能快速把代码写出来是一方面。另外还有项目管理,版本管理,测试,配置,调试,部署,监控等等工做,需求和传统的集成开发工具比较类似。 还常常出现须要复用已有的业务逻辑代码库的状况。Notebook 对其中一些需求并不能很好地知足。比较理想的开发工具多是相似 IntelliJ 加上 Spark/Flink 插件,再加上一些插件能直接提交任务到集群并进行调试,并对接 Apache Oozie 之类的工做流管理等等。在开源社区尚未见到能把这些集成到一块儿的。在商业产品中却是见过一些比较接近的。Spark 和 Flink 在这方面差很少。
应用开发完后要提交到运行环境。Spark 和 Flink 都支持各类主流的部署环境,在这方面都算作得比较好的。
部署环境 | Spark | Flink |
---|---|---|
独立程序 |
![]() |
![]() |
独立集群 |
![]() |
![]() |
Yarn |
![]() |
![]() |
Mesos |
![]() |
![]() |
Kubernetes |
![]() |
![]() |
既然 Spark 和 Flink 都支持各类部署方式,那一个企业是否可使用开源代码快速搭建一个支持 Spark 或者 Flink 的平台呢?
这个要看想要达到什么效果了。最简单的模式多是给每一个任务起一个独占集群,或着给小团队一个独立集群。这个确实能够很快作到,可是用户多了之后,统一运维的成本可能过高,须要用户参与运维。还有一个缺点是资源分配固定,而负载会有变化,致使资源利用率上不去。比较理想的是多租户的共享大集群,能够提升运维效率的同时最大限度地提升资源利用率。而这就须要一系列的工做,好比不一样的做业提交方式,数据安全与隔离等等。对一些企业来讲,可能利用托管服务(包括云服务)是一种值得考虑的开始方式。
Spark 社区在规模和活跃程度上都是领先的,毕竟多了几年发展时间。并且做为一个德国公司,Data Artisans 想在美国扩大影响力要更难一些。不过 Flink 社区也有一批稳定的支持者,达到了可持续发展的规模。
在中国状况可能会不同一些。比起美国公司,中国公司作事情速度更快,更愿意尝试新技术。中国的一些创新场景也对实时性有更高的需求。这些都对 Flink 更友好一些。
近期 Flink 的中国社区有一系列动做,是了解 Flink 的好机会。
Spark 的中文文档在 www.apachecn.org/bigdata/spa…
Flink 的中文社区在 flink-china.org/。
另外,今年年末 Flink 中文社区也会在北京举办 Flink Forward China 大会,感兴趣的朋友能够关注。
近两年一个明显的趋势就是机器学习在数据处理中的比重增加。Spark 和 Flink 都能支持在一个系统中作机器学习和其它数据处理。谁能作得更好就能掌握先机。
另外一个可能没有那么明显的趋势是,随着 IOT 的增加以及计算资源和网络的持续发展,实时处理需求会愈来愈多。如今其实真正对低延迟有很高追求的业务并无那么多,因此每一次流计算新技术的出现都能看到那几家公司的身影。随着新应用场景的出现和竞争环境的发展,实时处理可能会变得愈来愈重要。Flink 如今在这方面是领先的,若是发挥得好能够成为核心优点。
还有一点值得一提的是,由于用户不想锁定供应商,担忧持续的支持等缘由,是否开源已经成为用户选择数据产品的一个重要考量。闭源产品若是没有决定性优点会愈来愈难和基于开源技术的产品竞争。
Spark 和 Flink 都是通用的开源大规模处理引擎,目标是在一个系统中支持全部的数据处理以带来效能的提高。二者都有相对比较成熟的生态系统。是下一代大数据引擎最有力的竞争者。Spark 的生态整体更完善一些,在机器学习的集成和易用性上暂时领先。Flink 在流计算上有明显优点,核心架构和模型也更透彻和灵活一些。在易用性方面二者也都还有一些地方有较大的改进空间。接下来谁能尽快补上短板发挥强项就有更多的机会。
更多资讯请访问 Apache Flink 中文社区网站