谈到大数据框架,不得不提Hadoop和 Spark,今天我们进行历史溯源,帮助大家了解Hadoop和Spark的过去,感应未来。

在Hadoop这个模型出现之前,人们是如何做计算的呢?下图是一个典型的HPC(高性能计算) workflow。它有专门负责计算的Compute cluster,它的Memory不大,所以计算产生的任何数据会存储在Storage中,最后在Tape里进行备份,这种Workflow主要适用高速大规模复杂计算,像核物理模拟中会用到。

 

 

HPC workflow在实际应用中存在一些问题,这些问题促进了Hadoop的出现。

首先,如果想对大量进行简单计算,比如对Search logs进行“What are the popular keywords”计算,这时是否可以用HPC workflow?当然可以,但却并不适合,因为需要做的计算非常简单,并不需要在 HPC Cluster中进行。

其次,由于数据量大,HPC workflow是I/O Bound,计算时间只有1个微秒,但剩下的100个微秒可能都需要等数据,这时候Compute cluster就会非常空闲,因此HPC同样不适用于Specific use。

 

另外HPC主要在政府部门、科研等领域使用,成本高昂,不适合广泛推广。

如果不能把数据移到计算的地方,那为什么不转换思维,把计算移到数据里呢?

所以Google在2003至2006年发表了著名的三大论文——GFS、BigTable、MapReduce,解决怎么样让Framework挪到有数据的地方去做,解决了数据怎么存储,计算及访问的问题。

在Google 发出三大论文后,Yahoo用相同的框架开发出JAVA语言的项目,这就是Hadoop。Hadoop Ecosystem在十年多时间发展的如火如荼,其核心就是HDFS,Mapreduce和Hbase。

 

 

HDFS很好地实现了数据存储的以下特性要求:

  • Cheap
  • High availability
  • High throughput
  • High scalability
  • Failure detection and recovery

 

 

大家从图中可以看到HDFS数据读取和写入的过程,这个Architecture非常稳定,当数据量越来越大时Namenode从一个发展为多个,使内存增大,产生了Namenode Federation。

 

 

数据存储已经实现,那如何进行计算呢?

如果有1PB size log,当需要计数时, 一个Machine肯定无法计算海量数据,这时候可能需要写Multi-threads code,但也会存在进程坏了,性能不稳定等问题。如果Data Scientist要写Multi-threats code,是非常浪费时间的,这时候Mapreduce就应运而生,目的是让Framework代替人来处理复杂问题,使人集中精力到重要的数据分析过程中,只需要通过Code Map和Reduce就可以实现数据运算。

 

 

让我们来思考下:在一次Mapreduce中至少需写硬盘几次?

至少3次!

开始从HDFS中读取数据,在Mapreduce中计算,再写回HDFS作为 Intermediate data,继续把数据读出来做Reduce,最后再写回HDFS,很多时候做Machine learning需要不断迭代,一次程序无法算出最终结果,需要不断循环。

循环过程一直往硬盘里写,效率非常低,如果把中间数据写入内存,可以极大提高性能。于是Spark出现了。

 

 

当把数据从HDFS中读出来到内存中,通过Spark分析,Intermediate data再存到内存,继续用Spark进行分析,不断进行循环,这样Spark会很大地提高计算速度。

 

Spark在2009年由AMPLab开发,吸取了很多Hadoop发展的经验教训,比如Hadoop对其他语言支持不够,Spark提供了Java,Scala,Python,R这些广泛受到Data Scientist欢迎的语言。

 

 

那Spark与Hadoop的区别有什么?

  • Spark比Hadoop使用更简单
  • Spark对Data Scientist更友好(Interactive shell)
  • Spark有更多的API/language支持(Java, Python, Scala)