二蛋的博客

有的技术尽管在初期发挥了重要作用，但因为时代的发展以及新技术的诞生已经边缘化（例如MapReduce、Storm）。例如，使用 Hive、Spark或Flink对数据进行分析，然后将结果存储到HBase中实现实时查询，再例如 Spark on Hive 或者 Hive on Spark等等，再例如 MapReduce、Spark、Storm、Flink这些计算任务都可以通过 Yarn 进行调度。例如，在应用开发中涉及到的高可用、高并发、微服务等技术都有分布式的影子，都是分而治之的思想。

在学习过程中可能会发现 MapReduce、Spark 和 Flink 也有自己的资源管理器，随之产生疑问：“各计算引擎知道自己的数据在哪，可以进行任务调度，Yarn 是怎么知道数据在哪？作为 Hadoop2.0从 MapReduce 中分离出来的组件，Yarn 已经是一个通用的资源调度管理平台，MapReduce 也可以专注于计算任务的调度工作。像 Yarn、K8s这样的资源调度平台，都是把资源的管理、分配以及计算任务调度、容错做到了自动化，可以提高资源的利用率，也可以减少开发运维人员的工作量。

传统的关系型数据库是单机的，通常一个表的数据在一个文件中，想要做到实时的增删改查是比较容易的。但是 HDFS 中的一个文件是要分布在不同的节点上，实时添加一条数据相对容易，直接在文件末尾追加数据即可。初学者在接触HBase的时候，可能会产生一个疑问：“既然有支持SQL的Hive，为什么又有HBase，这两个有什么区别 ”。没错，HBase 就是一个支持增删改查操作的“大”数据库，只不过 HBase 是基于 HDFS 实现的。提到数据库大家应该就有概念了，所有业务系统都离不开的增删改查操作都需要数据库。

因为是间隔一段时间再去计算，所以在实时性方面，Spark Streaming 就不如 Flink，现在说起流计算基本上就是在讨论 Flink 了。不过两者的架构和概念有很多相似的地方，也都是函数式编程。批计算和流计算整体工作流程大体一致，都有任务调度、计算结果聚合等过程。随着移动互联网、物联网的兴起，每分每秒都在产生大量的数据，例如传感器产生的数据、订单交易数据、用户行为记录等。，所以任务执行还是 Spark 的逻辑，所以 Spark Streaming 算是一个“伪”流计算系统，属于批计算这一波。

由于 MapReduce 的计算模型只有 Map 和 Reduce 两个阶段，在实现复杂计算需求时就要编写多个 Mapper 和 Reducer 的实现。以上面800个数据块为例子，MapReduce 会有800次的 Map 计算结果落盘以及多个 Reduce 计算结果聚合（这个行为有一个专业的术语： Shuffle，这里不具体说明）。但这并不影响 MapReduce 的地位，毕竟它的设计思想影响了很多技术，例如Spark。由于文章篇幅的原因，如果你和我一样有同样的疑问，请关注我，欢迎大家一起交流。

虽说 MapReduce 简化了大数据编程的难度，但是如果每来一个需求都要写一个 MapReduce 代码，那岂不是太麻烦了。**尤其是在全民“CRM”的2000年代，对于像数据分析师已经习惯使用SQL进行分析和统计的工程师，让他们去 MapReduce 编程还是有一定的难度**。

不关注大数据的可能对这两个名词比较陌生，但是Hadoop大家一定都听说过吧。HDFS 和 MapReduce 就是 Hadoop 项目中的两个核心组件，。

第一次听说大数据是在18年左右，那个时候也才刚入行还在CRUD，对大数据这么高端的技术没有什么概念，只知道很牛逼，就买了一本《Hadoop 权威指南》。至今已经6、7年了，也只看了第一章的第一节《数据！数据！》，现在还陈列在我的书架上的第一排。虽然这期间再也没有进行学习，但毕竟是程序员嘛，多少会接触到大数据相关的一些边缘工作，说起大数据的一些技术也都不陌生，比如Hadoop、Spark、Flink什么的，但总归是没有深入了解。

在古时候，人们用牛来拉重物，当一头牛拉不动一根圆木时，人们从来没有考虑过要想方设法培育出一种更强壮的牛。同理，我们也不该想方设法打造什么超级计算机，而应该千方百计综合利用更多计算机来解决问题。