批处理
数据处理一般意义而言，具有三种不同的风格：
- 第一种，也是最为常见的一种，提供线上服务的online system。它往往会在应用的后端静静的等待使用者的request的到来，而且当收到request之后，便会立马返回response。对于online system，可用性和response time是the first。
- 第二种，便是这篇文章要聊的批处理(Batchprocessing system)，正常情况而言，这也是离线系统。对于批处理而言，它要运行job处理大量的数据，然后输出数据。
- 第三种，和第一种类似，但是介于批处理和线上处理之间，称为streaming processing。流处理的核心是event，而且类似于批处理，也是消费输入再输出结果数据。不过延迟要比批处理小很多。
今天要聊的批处理，在前些年，有个忽悠人的外号，就是所谓的大数据。最经典的处理模式就是MapReduce，它起源于谷歌的《MapReduce:Simplified DataProcessing on Large Cluster》，初起风光，花式刷论文灌水，但是MapReduce饱受诟病，因为这是一个相当低层次的编程模型，类似于sql语句的group by。Hadoop的MapReduce作为一个逐渐走向没落的编程模型，我们学习更应该是其体现的理念，比如和Unix一样的，采用了统一的接口，对logic和wiring的分离。
让我们来简单看看Hadoop及其分布式文件系统，可以这么说，谷歌在04年发的那三篇论文最为核心的就是GFS，开源版本HDFS。HDFS的核心就是shared-nothing架构，通过网络来交流，使用NameNode作为leader，为了防止宕机，使用了block块存储在多个机器之上。更具体的细节，可以参考谷歌的那篇论文。说完了HDFS，我们再简单看看Map Reduce的执行模式：
- 读入数据，将其分解为对应的record
- 调用Mapper函数抽取Key和Value值
- 根据Key值排序键值对
- 最后再调用Reducer函数迭代处理排好序的键值对。
整个的处理模型是相当简单的，值得注意的点可能就是是将运算移动到对应的机器上，而不是移动数据。这也是所有分布式计算应该遵守的原则。
现在再来看看更值得注意的join。Join是再数据处理当中最常见的运算符，可以将两张表根据相同的键将数据聚合起来。那么Map Reduce的实现呢？可以大致的分为在Reduce端join，Map端聚合。
- 通过上面的分析，我们可以发现join在Reduce端是比较好聚合的，也就是Sort-Merge Join。在map端将数据处理为Key-Value，sort之后，两张表的key值就被处理在一起了。
- Map端的，可以分为表小和表大。表小的话，可以把小表处理成hash值，在map端进行匹配。这被称为Broadcasthash join
- 对于表大的，可以使用Partitioned hash join。对大表将数据拆分一个个小块，再进行broadcast hash join。
说了这么多，最后再看看HDFS和分布式数据库的区别。
- 数据存储
Hadoop的数据存储只需要byte sequence，可以使用任何数据模型和编码，而分布式数据库，则是针对特定数据模型的结构化的数据。
2.数据处理模型
Hadoop给与了工程师更大的权力选择独有的程序处理数据，但是分布式数据库则是独揽一切，只对外提供SQL接口。
其实Map Reduce不是很完美的模型，每个的Map Reduce都是独立的程序，中间的工作流需要自己组织，但是到后来，为了更适应迭代，spark之类的相对比较新的框架提出了dataflow的概念，将一系列的程序组织起来优化，为了解决fault的问题，使用的是重新计算而不是retry的方式。
这篇文章其实写的并不怎么好，因为这个话题更多的是工程的问题，数据模型其实是相当老的，所以值得讨论的点并不多。
