并行数据库 VS. Hadoop Map/Reduce

并行数据库与Hadoop Map/Reduce是目前流行的两种规模数据处理的系统。知名数据库学者Stonebraker在论文[1]中对两种系统进行了比较。笔者根据自己的理解与体会，总结两种系统的差异如下：

1. 着重处理的数据类型不同
传统的数据库技术着重处理的是结构型的数据（关系表）。设计良好的关系模式（比如3范式）对一个数据库应用相当重要。而Map/Reduce更多处理的是无结构的数据（比如文本数据），数据被映射成<key, value>的二元结构，不存在模式需要根据应用而改变的问题。
注意：虽然数据库也可以用Blob字段存取无结构化数据，但归根到底数据是以表的形式进行存储的。

2. 用户的接口不同
SQL语言是数据库给用户提供的主要接口，SQL语言是一种阐述型（Declarative）语言，而不是一种过程型语言。用户只通过SQL描述关系表之间的逻辑操作，而由查询优化器产生最终的物理存取路径。Map/Reduce与之相反，程序员需要编写相应的Mapper实现类和Reducer实现类，用程序实现相应的应用逻辑。
注意：基于Hadoop实现类似SQL的高级语言是Hadoop社区正在进行的项目，比如Pig和Hive.

3. 存储模型的不同
数据库的储存对象是关系表（或者是列，如果是Columnar数据库），为了加速查找，表上可以建各种索引，如B+树，Hash索引，Bitmap索引，R树索引等。Map/Reduce的存储基于HDFS，以文件为接口，在Name节点上保存文件的元数据信息，文件分块存储在不同的数据节点上。

4. 数据分布（Data Distribution）不同
并行数据库的数据分布一般有Hash和Duplication两种方式。Hash分布就是根据关系表指定的Distribution Key为分一个元组计算一个Hash值，然后在将Hash值映射到某一个执行节点进行存储，系统中常常需要维护一个HashMap来记录Hash值与节点之间的映射关系。Duplication分布就是复制元组到每一个执行节点。HDFS的数据分布主要由Name节点进行分配，在Name节点保存有文件如何分布于各个数据节点的信息。Name节点相当于系统中的中心控制节点。比较而言，并行数据库不存在单点失败的问题，但系统在线增加和删除节点也变得复杂，需要做数据的重新分布（Redistribution），可能影响到系统中许多执行节点；而Hadoop存在单点失败的问题，但系统增加和删除节点比较容易，如果将源数据组织成一个类似B+树的节点，相当于只需要做节点的分裂或者合并，而且系统的负载均衡也比较容易做。

5. 执行方式不同
并行数据库采取的执行方式是推（Push）的方式，由查询引擎生成查询计划，然后将查询计划分步分发到各个执行节点进行执行。采用这种执行方式的假设是认为传输代码总比传输数据有效，将代码传输到数据所在的节点进行执行。而Map/Reduce采取的执行方式是托(Pull）的方式，由执行节点主动向JobTracker申请Task，如果数据不在执行节点，需要同时传输数据。这样的做法看起来似乎低效，但Hadoop假设系统中的节点的不稳定的，如果节点失败，Hadoop可以很容易地实现Fail over，由于各个执行节点根据自己当前的负载申请Task，因此系统的负载更为均衡，不会出现由于数据skew造成的负载不均衡。

6. 故障恢复不同
在分布式系统中预防节点失败的方式是数据复制（Replication)。并行数据库可以复制原始表数据于多个节点上，但不会复制中间结果，而且Pipeline的执行方式试图减少中间结果的产生，因此如果一个在运行时间很长的Query中间出现节点失败，并行数据库的做法基本需要重新执行这个Query。而在Map/Reduce中，输入数据被切割成多个splits，每个splits对应一个Mapper task，因此如果在Map节点出现故障，只需要重做相应那个Splits的Mapper Task就可以；如果在Reducer阶段出现故障，由于Mapping和Data Resuffling中间结果都被存储下来，因此也可以只重做相应的Reducer Task就可以了。从这个意义上，Hadoop提供了更高的故障恢复机制。

7. 事务支持
数据库对事务的支持无疑的比较复杂以及完整的。比较而言，Hadoop对事务的支持是比较有限的，文件的操作也以Append为主，Hadoop的主要应用场景还是分析型的应用，并不支持以更新为主的操作。

综上所述，并行数据库与Hadoop各有所长，各有所短。许多数据库厂商都在研究如何将Hadoop集成到并行数据库中（笔者将在今后的Blog讨论这一主题），而Hadoop社区也在研究如何基于Hadoop开发类似SQL的高级语言，使Hadoop不光面向程序言，而面向用户。两大阵营将来如何结合，让我们拭目以待。

参考文献:
[1] A Comparison of Approaches to Large-Scale Data Analysis. Michael Stonebraker etc. SIGMOD 2009.

数据挖掘项目实施方法论

数据挖掘是指从大量数据中揭示出隐含的、先前未知的并有潜在价值的信息的非平凡过程。实际应用中，一个数据挖掘项目是一个过程，而不仅仅是一个算法，一般分为六个阶段，包括定义业务问题范围、数据选取与预处理、探索型数据分析、建模，实施以及结果反馈修正模型，如下图所示：

1. 定义业务问题范围

在这个数据挖掘的初始阶段，需明确阐述项目目标和客户业务需求，目的是明确包括客户响应的数据挖掘问题。具体任务包括：

• 明确业务目标
•  定义响应变量
•  项目计划必要的调整

2. 数据选取和预处理

在这一阶段，建模小组要搜寻并检查客户数据，做为未来的分析定义属性的简略一览表。创建一个数据映射概念图以对应客户数据与建模相关的各个数据属性名。将数据整合到一个适当的程度，省略不适当的记录（如商务客户，非居民客户，如果分析仅针对居民客户）、不完整的数据记录、训练数据、试验数据，等等。具体任务包括：

• 数据来源
• 数据映射
•  准备数据评估
•  数据的必要聚合
•  数据抽样

3. 数据分析与数据探索

在这个阶段中，建模小组核查目前的数据源并且努力去发现在每个待选的预测变量和响应变量之间是否有任何关系。数据转换通常在更进一步的范围中探察数据关系。通常，数值分析是为了全面理解数据的第一步，跟着进行的统计分析是为了得到有关数据分配的更好知识。如频率图、柱状图、条线图，散点图、框图和许多其他方式是典型的且很好的数据的图形化呈现工具，使为下一步建立模型准备数据来源变得容易很多。在数据挖掘过程中这是一个关键的阶段，通常随伴着由正式的数据探索报告来记录和呈现发现。具体任务包括：

•  数据质量检查
•  数据的必要整理
• 通过图形化呈现工具和其他的统计方法理解数据
• 分析待选预测变量和响应变量之间的关系
•  数据转换以辅助数据的分析
•  数据派生为建立模型做准备
• 整理和呈现数据探索的发现

4. 建模

在这一阶段，建模小组建立并确认分析模型。建模小组通常尝试不同的建模技术（数据挖掘算法），结合不同数据集，衡量模型性能的不同，选出最好的。来自最终用户的业务领域知识在这个阶段是非常关键的，因为他们可以评价和确认模型的结果、理解发现并付诸实际行动，即证明这些模型并在实际环境中实施。具体任务包括：

• 为模型的训练和验证准备数据集
• 在模型的建立中使用适当的建模技术
• 针对不同的建模技术测试模型性能
• 必要地精炼分析模型
• 和主题专家一起的检验分析模型
• 记录分析模型和结果

5. 实施

在这一阶段，需要用模型的结果帮助客户作出业务决定、战略设计和战术实施。将模型产生的结果输入到客户的业务系统中，触发相应的业务行动是数据挖掘项目实施的关键一环。例如：利用客户流失分析模型（如决策树）预测下月将要离网的客户名单，并将客户名单输入客服系统，根据这些客户的消费行为特性，针对性地制定客户挽留方案，由客服人员对可能离网的客户进行挽留。具体任务包括：

• 模型评分和存储模型
• 利用模型产生结果
• 数据挖掘自动化，整合其它业务系统，如客户接触渠道系统或更完整的CRM系统

6. 结果反馈修正模型

这一阶段是比较容易忽视的阶段。收集实施结果反馈，为模型的退化进行侦测，更进一步改善模型性能，从而形成业务闭环。例如，通过分析模型实施结果的准确率和召回率，对模型的预测变量进行调整，提升模型的性能。另外，模型也需要定期更新，以保证模型的性能。具体任务包括：

• 模型结果反馈收集
• 模型修正
• 数据挖掘自动化，整合其它业务系统

前言

转眼工作很多年了，一直从事数据库方面的开发，包括数据挖掘，数据库内核以及并行计算。本博客用以记录本人平时工作学习的心得体会。