大数据十年回顾（3）： 区技术

在这篇文章里，我们沿大数据发展时间线，从产品、行业、技术多角度讨论其发展脉络，究其发展承其脉络大家可以学习、借鉴、并最终推测未来大致走向。

Hadoop 技术相比于 Google 原作并无新意，甚至在 GFS 系统细节方面折扣实现不少。但笔者在此并无讨论技术差异点的打算，我仍然回到老本行，从产品或者市场角度去探讨 Hadoop 成功因素以及给我们的启示。

在笔者看来，Hadoop 体系能够成功，并在数据处理市场占据一席之地，其初期核心因素就在于以下几点：

时机。彼时互联 Web 2.0 风头正紧，大量用户与 站交互行为爆炸式增长，如何使用廉价的服务器(大量互联 创业公司就是穷鬼，买不起大小型机)去分析各类 站数据的业务需求已经迫在眉睫。此时，大量 Top 互联 公司有数据、有需求、有硬件，就缺一个廉价的数据分析系统。于是乎，开源、免费的 Hadoop 工具正好钻入此类大数据市场空档，迅速占领了核心种子客户群体，并为后续市场推广奠定了群众基础。

开源。开源在开发者 区感染力不容小觑。Cutting 和 Cafarella 通过开源(以及 HDFS 的源代码)确保 Hadoop 的源代码与世界各地可以共享，最终成为 Apache Hadoop 项目的一部分。Google 此时并未意识到开放论文仅仅自我精神爽了一次：让尔等看看我等技术影响力;实际上并未从长远去思考大数据技术影响力构建以及更加长远的云计算商业生态构建。互联 时代下，大量软件被开发者以及背后的互联 商业公司作为开源系统贡献出来，整个互联 开发者行业已经被开源 区完全洗脑，仿佛开源就是人类灯塔，闭源就是万恶不赦。于是，此时，一个开源的、免费的、感觉挺符合互联 精髓的大数据处理软件出现在各大互联 公司圈中，迅速在互联 大数据处理领域触达了这部分市场群体。

商业。早年开源软件皆靠诸位开源运动人士在业界做 区用户推广，这波人本身毫无金钱汇 全靠一腔精神热血。但本质上来说，人类以及人类 会都是趋利性的，没有利益驱动的市场行为终究无法持续。因此，早期没有找到合适盈利模式的开源软件一直发展缓慢，靠类似 Richard Stallman 类似开源***斗士去做市场推广，市场效率之低下。后期，在 Linux 商业公司红帽逐步摸索出开源软件变现模式后，其他开源软件也纷纷仿效。Hadoop 一时间背后迅速成立三家公司，包括 Cloudera、HotonWorks、MapR，这些公司盈利潜力完全都依赖于 Hadoop 开源生态的规模，因此，三家公司都会尽不遗余力地推进 Hadoop 生态发展，反过来促进了 Hadoop 整个生态用户的部署采用率。到大数据市场更后期的时代，其商业竞争更趋激烈。以 Kafka、Spark、Flink 等开源大数据软件为例，在各自软件提交到 Apache 基金会之时创始人立刻创办商业公司，依靠商业推进开源生态建设，同时通过收割生态最终反哺商业营收。

最终 Hadoop 在生态建设上获得了巨大的成功，其影响力在开源业界开创了一个崭新领域：大数据处理可见一斑。我们从如下几个维度来看看 Hadoop 生态成功的各类体现：

这些数据处理 Pipeline 在作业启动时将通过优化器生成，优化器将以最佳效率生成 MapReduce 作业，然后交由框架编排执行。整个编译执行原理图如下图。

大数据开发技术群：957205962

对于 Hive 而言，其官 特性说明充分阐释了 Hive 的作为一套 Hadoop MapReduce 之上的 DSL 抽象之价值和特性：

Hive 是基于 Hadoop 的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的 sql 查询功能，可以将 sql 语句转换为 MapReduce 任务进行运行。其优点是学习成本低，可以通过类 SQL 语句快速实现简单的 MapReduce 统计，不必开发专门的 MapReduce 应用，十分适合数据仓库的统计分析。

于笔者这样的产品经理而言，其重要意义是将 MapReduce 进一步进行抽象为业务高阶语言，让更多不善于 Java/C++ 编码的数据工程师能够快速上手使用大数据工具进行数据分析，让大数据业务开发成本更低、使用门槛更低、维护成本更低，让传统的、使用数据库的数据分析师能够基本无缝迁移到基于 Hadoop 的大数据平台，从而极大扩展了大数据用户群体，进一步拉动 Hadoop 区的用户生态以及商业生态。

从另外一个方面，Hive 作为一个 SQL-On-Hadoop 工具，为后续诸多大数据处理软件提供了很好的表率：即越高阶的业务抽象 API 能够极大降低用户开发门槛，拉动使用者基数。后续大量的开源闭源大数据系统都或多或少、有模有样地提供了各自 SQL 方言，方便用户更加快速、简单地上手各自的大数据软件。开源 区来看，从 Hive 开始，Presto、Impala、Spark、或者当前风头正紧的 Flink，无不提供 SQL 作为高阶数据分析语言。从闭源产品而言，阿里云的 MaxCompute、AWS 的 Redshift、Google 的 BigQuery，均提供各自 SQL 抽象以争取更多云上开发人员的使用。据阿里对外宣传的文章来看，基于 MaxCompute 的离线数仓体系服务了整个阿里集团数万名员工之众、每日运行作业达数百万至多，以至于集团内部包括数据工程师、产品经理、运营人员、财务人员人人可以分析数据，人人可以提取数据，人人皆为数据分析师。可以想像，若非 SQL 这类高阶业务表达语言助力，阿里集团大数据体系绝无可能有如此规模的受众群体，亦不可能产生巨大业务价值。

上述将 Storm 类比为流式的 MapReduce 框架，我自认为特别贴切，因为这个概念类比更好向各位看官传达了 Storm API 的 low-level 以及开发效率低下，这类基础大数据的 API 让业务人员参与编写业务逻辑好比登天。同时，Storm 的设计原则和其他系统大相径庭，Storm 更多考虑到实时流计算的处理时延而非数据的一致性保证。后者是其他大数据系统必备基础产品特征之一。Storm 针对每条流式数据进行计算处理，并提供至多一次或者至少一次的语义保证。我们可以理解为 Storm 不保证处理结果的正确性。

第二代：Spark

Spark 在 2009 年左右诞生于加州大学伯克利分校的著名 AMPLab。最初推动 Spark 成名的原因是它能够经常在内存执行大量的计算工作，直到作业的最后一步才写入磁盘。工程师通过弹性分布式数据集(RDD)理念实现了这一目标，在底层 Pipeline 中能够获取每个阶段数据结果的所有派生关系，并且允许在机器故障时根据需要重新计算中间结果，当然，这些都基于一些假设 a)输入是总是可重放的，b)计算是确定性的。对于许多案例来说，这些先决条件是真实的，或者看上去足够真实，至少用户确实在 Spark 享受到了巨大的性能提升。从那时起，Spark 逐渐建立起其作为 Hadoop 事实上的继任产品定位。

在 Spark 创建几年后，当时 AMPLab 的研究生 Tathagata Das 开始意识到：嘿，我们有这个快速的批处理引擎，如果我们将多个批次的任务串接起来，用它能否来处理流数据乎，Spark Streaming 就此诞生。相比于 Storm 的低阶 API 以及无法正确性语义保证，Spark 是流处理的分水岭：第一个广泛使用的大规模流处理引擎，既提供较为高阶的 API 抽象，同时提供流式处理正确性保证。 有关更多 Spark 的信息，笔者推荐 Matei Zaharia 关于该主题的论文《 An Architecture for Fast and General Data Processing on Large Clusters》:

全家桶：一套引擎解决“所有”大数据问题

Flink 和 Spark：All-In-One

大数据全家桶其实是一个实打实的产品问题：从大数据 区反馈的情况来看，对于大部分大数据处理用户，实际上的大数据处理诉求分类有限，基本上在 Batch(60%+)、Stream(10%+)、Adhoc(10%+)、其他(包括 ML、Graph 等等)。对于任何一个大数据处理引擎深入做透一个领域后，势必会考虑下一步发展，是继续做深做专，抑或还是横向扩展。做又红又专业来看，这个领域的市场规模增长可能有限，眼瞅着都到天花板了;但从横向角度来看，周边大数据引擎虎视眈眈，随时都有杀入我们现有市场之中。面对市场，各色需求可穷举;面对技术，引擎基础业已夯实，为何不周边突破扩展，开拓新的大数据领域。Spark 从批入手，针对 Hadoop 处理性能较差的问题，将 Spark 的 Batch 功能做成一个“爆款应用”，同时提供 Spark Streaming、Spark ML，前期靠 Spark Batch 为整个 Spark 区用户倒流，并吸收为 Spark Streaming、Spark ML 的客户。而通过 Spark 大数据全家桶功能，Spark 产品构建一个粘性的护城河。大量中小用户一旦全功能上了 Spark，大家理解后续很难因为 Spark 某个功能点不太满足需求而抛弃使用 Spark。

Spark 从批入手，尝试在一个技术栈体系内统一基础的大数据处理;在另外一个方向，Flink 从 Stream 入手，在构建出 Flink Stream 强大生态后，也在考虑布局 Flink Batch，从 Stream 切入 Batch 战场。

下图是 Spark 的软件栈体系：

Beam: One-Fits-All

前文已述，早期 Google 在大数据领域纯粹扮演了一个活雷锋的角色，以至于整个开源大数据生态蓬勃发展起来，并最终形成完整的大数据商业生态之时，Google 基本门外一看客，眼瞅着自己的技术理论在开源 区发扬光大，自己没捞半点好处。适时，Google 云业已发展起来，并拉起诸多祖师爷级别的产品技术服务客户，例如 BigTable。常理而言，BigTable 开创 NoSQL 大数据之先河，其 Paper 位列 Google 大数据三驾马车之中，技术地位可见一斑。再看 区 HBase，乃直接“抄袭”Google BigTable 论文理论，实乃徒子徒孙之技术。但最终，Google 云发布 BigTable 产品之时，为了考虑 区产品兼容性以及用户上云迁移成本，竟然不得不兼容 HBase 1.0 的 API 接口。可以想象，BigTable 项目组成员当时内心感觉只能是：简直日了狗!但一切为了云计算营收，BigTable 产品放下技术执念选择兼容 HBase 接口，实属难得!我们为 Google 尊重市场而放下身段的行为点赞!

Google 受此大辱，吃此大亏，当然会痛定思痛，考虑建设开源 区并尝试力图控制 区。于是在此背景之下，Apache Beam“粉墨登场”。Google 考虑问题之核心不在于是否要开源一个大数据处理系统(当时 区 Spark 已经蔚然成风，Flink 的发展同样亦是扶摇直上，似乎 区并无缺少一个好的大数据引擎)，而仅仅缺乏开源 区大数据处理接口之统一，包括将核心的批处理以及流处理接口统一。而之前 Google 内部的 FlumeJava 一直承担大数据 Data Pipeline 之 API 定义角色，于是想当然地从内部将之前的 FlumeJava 接口进行抽象改进，提供统一的批流处理 API 后在 2016 年贡献提交给 Apache 基金会。试图通过定义一套统一的 API 抽象层，说服各个厂商实现该套抽象，即可完成 API 统一的千秋大业，并为用户迁移 Google 云上埋下最大伏笔。

结语

大数据开发技术群：957205962

-！

相关资源：内窥镜影像软件宫腔镜腹腔镜耳鼻喉镜软件win10.rar-医疗文档类…