既然Python的库能对大数据进行分析，那为何还要用Hadoop和Spark?

再者，机器学习和spark,hadoop有关系吗？

一般 Python 的库不是为大数据设计的。pandas 诞生于 2009 年，它把 DataFrame 的概念带到了 Python 语言。而要说 DataFrame 的历史，甚至可以追溯到上个世纪90年代的 S 语言，R 语言作为 S 语言的开源版本，在 2000 年发布第一个稳定版本。这些 DataFrame 是同宗同源的。

他们的 DataFrame 数据模型相同，在行和列上存在著标签，且数据保证顺序。他们都要求数据能 fit 进内存，大部分操作也并没有考虑到多核。这主要还是时代局限，在他们诞生的年代，大数据还不是主流。

关于 MapReduce 和 Hadoop 诞生的历史就不多说了，网上一搜很多。MapReduce 就是简单把数据处理抽象成 map 和 reduce 两个运算元（函数式编程的概念），map 和 reduce 数据都需要落盘。MapReduce 的好处是特别简单，反正就两个运算元，基本上所有操作都能用这两个运算元组合出来，而且因为数据落盘，任何计算失败都可以 failover 出来，因此 Hadoop 特别稳定。缺点也很容易想到，就是更高阶的运算元的表达得写大量代码。所以 Hadoop 诞生之后，工程师特别满足，因为很多东西都要重新实现啊。Hadoop 是 Java 写的，因此奠定了 Java 在大数据领域的黄金地位。

那时候反正大数据基本都是日志，大家写一堆 mapper 逻辑来抽取日志信息，然后在 reducer 里聚合啊等等算一些统计数据。

很快人们就发现不对，这么搞下去药丸，每次一个任务就要写一大堆代码，亟需一个更高层的语言，不用每次写这么多重复代码。有一个前提，这个高层语言，底层要能用 MapReduce 实现。大家都知道了，这个语言就是 SQL，SQL 的强大在于简单，基本上没学过编程的人也会使。SQL 是一种 declarative 的语言，也就是说，人们只要告诉它我要算某个栏位的 AVG，咋算的我不管，那就太适合架在 Hadoop 上面作为一种更高阶的语言。大家的开发效率也提高了，因为不用再写很多重复的 Java 代码了。声明式语言的好处是，可以优化啊，SQL 发展了几十年的关系代数优化也可以逐步采用。

后来随著时间发展，人们发现 Hadoop 也太慢了，什么东西都要落盘这怎么吃得消。因此，spark 诞生了，spark 也受了函数式编程的影响，把 Scala 语言上的介面全部带到 Spark 里，什么 map、flatmap 等等。然后把运算元归为两类，一种要 shuffle 的（就是我这个分区的数据依赖前面所有的数据），一种不需要 shuffle 的，不需要 shuffle 的数据就可以做更多管线优化，数据在内存里流动就行了。再者，除了 Scala 和 Java，Spark 还支持了 Python、R 来编程，一下让其他编程语言的用户有了幸福感。

然而好景不长，这种方式虽然各种语言都能写了，然而不同语言性能不同，虽然都写著类似的代码，但性能天差地别。于是怎么办呢？SQL 啊，再把 SQL 架上去，这次不是架在 MapReduce 上，而是架在 RDD 编程介面上，这样 spark 带来的性能优势都还在。Spark 的开发者们阅历也特丰富，R 和 pandas 的 DataFrame 看上去不错，毕竟不是每个人都想写 SQL 的，于是又在和 SQL 同等级别上又搞出来了 DataFrame，以及后来的 Dataset 介面，写 DataFrame 就不是 SQL Monkey 了。（没有冒犯的意思：））

时过境迁，属于大数据的时代很快就被人工智慧给取代了，人工智慧时代，演算法工程师们都是写 Python 的，Python 语言特别适合用来作为深度学习框架的前端，因为他简单、优雅，再加上人们对人工智慧的过度吹捧，很快 Python 一跃成为最受瞩目的语言。毕竟这个时候不会 Python，意味著不懂人工智慧，和文盲没区别啊（再次没有冒犯的意思:)），看人家潘石屹都在学 Python。

但其实传统的大数据离人工智慧的 gap 确实比较远，演算法工程师一个 pip install tensorflow，网上翻个经典模型就开干了，大数据的那套环境玩不转。

于是，我们看深度学习的前序数据处理又回到了 pandas 这套，甚至用 Python 的循环。反正是相当原始。天道好轮回啊。

这里观众可能要问，不是有 spark DataFrame 么？甚至后来砖厂还搞了个号称完全兼容 pandas 的 Koalas，它看上去不是和 pandas 挺像么。对，看上去确实像，但是底层仍然是 spark，所以其实内在有很多不同。如果拿 pandas 这套来写，经常会如鲠在喉。最集中的两点是，报错经常来个 Java 异常栈，让人不知所云；spark 本身数据并不保证顺序，所以人们做分析的时候常常得到错误的结果。关于这点可以看我的文章：https://zhuanlan.zhihu.com/p/135329592。

所以，到这里回到题目，pandas 这些库不能处理超过内存大小的数据，这就是为什么还需要 hadoop 和 spark 的原因，因为只有人家能干大数据的活啊。

那么，为什么 Python 不能处理大数据呢？数据从 Python 流到深度学习一气呵成，不是很好么？

这就是我们做 Mars 项目的原因（抱歉啊，广告来的太突然），保证和 pandas 兼容，但能处理大规模的数据，能用 GPU 加速数据处理，还能和 tensorflow 等深度学习框架集成。关于这点，我觉得他和天下大事，分久必合，合久必分一个理，你看人家资料库那边，有了轰轰烈烈的 NoSQL（Not only SQL），现在也都改叫 NewSQL 了。我觉得 Mars 也可以说是 new pandas:) pandas 很好，我们没有必要取代他，我们要做的只是让他能处理更多数据、能并行和分散式起来。

所以啊，使用 Mars，你可能不需要 Hadoop 和 Spark。

Mars 文档：https://docs.pymars.org/zh_CN/latest/

Mars 开源地址：https://github.com/mars-project/mars

因为python库并不是为分散式设计的，实际业务中数据量并不是一部高性能计算机就能handle得来的。下面听我细细道来。

打个比喻：

有个年轻人，他参加了蓝翔烹饪学校的课程，立志成为一名厨师。

毕业后，他开了一家小餐馆。在他看来，他每天的任务就是早上把食材准备好，放在厨房的一个冰箱里，他开工时，按照客户的点单，从冰箱取出相应食材进行烹饪。

这种日子也挺惬意，厨师度过了开店前六个月安稳的小日子。

有一天，顾客A对他说：你的菜很棒，我想请你为我们工厂提供工作餐，你看可以吗？

厨师立马就答应下来了。但是他坐下来一想，可能要准备很多食材，现在的冰箱恐怕是放不下了。

有两个选择：1.买多几个冰箱 2.换更大的冰箱。

厨师选择了1。他认为，现在有顾客在这里大量订餐，以后也会有顾客大量订餐，生意一定是蒸蒸日上的。如果现在买了大冰箱，可能过两个月，又得买更大的。

买了冰箱，食材的放置就要有一定的规划了。这样会使得工作效率最大化。例如肉类放冰箱A，蔬菜放冰箱B，这样就不用为了准备一个菜，要去翻来覆去的把每个冰箱找一次。

当然有了冰箱，他一个人也不够人手来准备这么多菜。他请了几个伙计，一个负责做水煮鱼、一个负责做沙拉。

这个餐厅倍受好评。在当地三个镇都有订单。为了减少来回成本，这个厨师决定在三个镇都开分店，按照统一的标准进行管理。当某地食材不足时，可以从其他地区补充。

就这样，这个餐厅一直扩张，这位蓝翔毕业的厨师，终于在2019年最后一个月，实现了小康生活。

把上面文章用大数据的语言翻译下：

毕业后，他开了一家小餐馆。（一个数据节点，一个处理单元）

这种日子也挺惬意，厨师度过了开店前六个月安稳的小日子。（业务不多，数据量不大，一台伺服器处理得来）

有两个选择：1.买多几个冰箱（买多几个伺服器） 2.换更大的冰箱（更高性能伺服器）。

厨师选择了1。（几个伺服器搭建分散式数据系统，扩展业务只需添加新伺服器）

他认为，现在有顾客在这里大量订餐，以后也会有顾客大量订餐，生意一定是蒸蒸日上的。如果现在买了大冰箱，可能过两个月，又得买更大的。（扩展数据系统只需要添加）

买了冰箱，食材的放置就要有一定的规划了。这样会使得工作效率最大化。例如肉类放冰箱A，蔬菜放冰箱B，这样就不用为了准备一个菜，要去翻来覆去的把每个冰箱找一次。（数据的indexing）

当然有了冰箱，他一个人也不够人手来准备这么多菜。他请了几个伙计(worker node)，一个负责做水煮鱼(task1)，红烧牛肉（task2）、一个负责做沙拉(task3),意面(task4)。

这个餐厅倍受好评。在当地三个镇的工厂都来订餐。为了减少来回成本，这个厨师决定在三个镇都开分店，按照统一的标准进行管理(cluster manager)。当某地食材不足时，可以从其他地区补充(data shuffle)。

就这样，这个餐厅一直扩张，这位蓝翔毕业的厨师，成为了镇上的小康之家(建立了稳定的大数据系统），在2019年最后一个月，完全脱贫。

为了再加深理解，我在Spark结构图上面标注了餐厅的一些「术语」。

看完这个图，你对我们蓝翔的厨师专业，啊不，你对spark还有什么想了解的吗。

其他答案回答的非常全面了，我想谈谈为什么会产生题主的这个问题，其实就是近几年乱七八糟的概念乱炒作，「大数据」和「机器学习（人工智慧）」首当其冲。

先来谈学术界，学术界很多传统的实证研究和统计方法加上大数据的特点和技术（就是指hadoop生态代表的一系列技术）后说自己创新了方法，也有很多根本谈不上是大数据，就是数据量变多了而已，这样水的文章不在其数。

机器学习就更泛滥了，在各个领域遍地开花地写文章......

大数据技术和机器学习有关系吗？

我感觉在科研届后者不在乎前者的关系，工业界是肯定要考虑的，因为要实实在在地落地。为什么学术界不是很在乎数据这块呢？（这也是为什么机器学习的学者拿著pandas和for循环就开干的原因），首先要明确大数据和大数据技术是两个不同的概念，前者是理论性的，类似4v理论什么的，后者很早就出现了，源头在「分散式数据应用」、「数据密集型应用」的解决方案上，更早更早就是谷歌的三家数据方解决的三家马车：GFS, MR，Bigtables （这些技术上的在科研界可能就只听个名字，没有真正会用的。）

所以科研界用大数据方法来搞实证的，我真的怀疑是否真的进行的整套的数据流处理，分散式部署和处理，因为数据处理的是否高效对你的论文结论来看没有必然从影响（换言之用串列或传统的方法处理你所谓的大数据是不是不影响结论？可能我的想法略天真，也希望有从事大数据作为研究方法的朋友批评指正）.....

上述原因导致hadoop生态这些东西对使用机器学习作为研究方法的科研人员来说根本用不到。毕竟对科研来讲方法创新是主要的，你的实验历程和实现根本看不到，你数据分散式不分布或者大数据处理与否不重要（或者说没必要，因为数据量不够）. 因此python针对科研的模块，numpy，pandas自然不考虑这些。

那么完整的落地方案必要要考虑数据密集这一重要问题，系统的可用、可靠、可维护都需要hadoop生态为代表的大数据技术的基本支持，所以工业界和学术界思考问题的侧重点是不一样的。两者合作才是硬道理。

那么整个流程的统一，有些回答也提供了相关方案了，总而言之，技术选型是次要的，搞清楚各个环节的职责才是首要的学习任务。

问得好。事实上，我们不仅需要基于Hadoop、Spark的大数据平台，还需要更加强大的数据中台。

不管企业还是个人，做数据分析/挖掘的目的，不外乎发现问题，总结知识，降低成本，提高效率，只有Python库本身，并不等于可以无视性能、规模之类的挑战，并不等于高效了。

而数据中台，更是解决成本和效率问题的「大杀器」，网易数据中台负责人郭忆的精彩分享如下：

如果我们把数据中台看作是一个汽车工厂，那大数据平台就是工厂中的设备，Hadoop 集群则是工厂运作所必须的水、电、煤。Hadoop 提供的是大数据生产所必须的计算和存储资源，大数据平台使得数据开发人员具备了对数据的加工和处理能力，类比设备使得工人具备了对原材料的加工能力，但是大数据平台还不能提供产品，这么多的原始数据，要按照一定的方法论，进行良好的组织，加工，才能生成最终的指标，就如只有切割机、油漆机还不能生产汽车，各个零部件要按照一定的规则，通过设备组装在一起，才是一辆完整的汽车。