|
HadoopDB 是一个 Mapreduce 和传统关系型数据库的结合方案，以充分利用 RDBMS 的性能和 Hadoop 的容错、分布特性。2009 年被 Yale 大学教授 Abadi 提出，继而商业化为 Hadapt，据称从 VC 那儿拉到了 10M 刀投资。
本文是对 HadoopDB 论文的总结。其中不免掺杂些自己的不成熟想法，更详细的内容，还请参见原论文 HadoopDB: An Architectural Hybrid of MapReduce and DBMS Technologies for Analytical Workloads
背景
PB 级数据分析系统的能力要求
1.性能：节省开销（时间、资金）。
2.容错：数据分析系统（即使有故障节点也能顺利工作） 不同于 事务型的系统的容错（从故障中无损的恢复）。节点故障时，原来的查询操作不需要重启。
3.在异构型环境中运行的能力。即使所有机器硬件一样，但某些机器在某些时候可能因为软件原因、网络原因也会性能降低。分布式操作时，要防止木桶效应。
4.活的查询接口：商业化的数据分析一般建立在 SQL 查询上，UDF 等 non-SQL 也是需要的。
并行数据库
满足 1,4：利用分表的方式，扩散到多个节点。一般情况下节点最多为几十个，原因：1.每增加一个节点，失败率增加；2.并行数据库假设各个机器都是同质化的，但这往往不太可能
MapReduce
满足 2,3,4：Map - repartition - Reduce 原为非结构化数据，但也可以适用结构化数据。
2：（错误节点）动态的规划节点执行任务，将错误节点任务发放给新节点。并在本地磁盘做 checkpoint 存储。
3：（拖后腿的节点）节点间冗余的执行。执行慢的节点的任务交付给速度快的节点执行
4：Hive 的 HQL
HadoopDB
融合了之前两者，做出系统层面的改进，而不仅仅是语言和接口层面。
这三个解决方案对 4 个指标的关系如下图：
alt compare
架构
如图 alt framework
组件介绍
Databse Connector:
作用
hadoopTask <-通信-> Database on Node。节点上的 DB 类似于 Hadoop 中的数据源 HDFS
实现
扩展了 Hadoop 的 InputFormat
Catalog：
作用
1.链接参数如数据库位置，驱动类和证书； 2.一些元数据如数据簇中的数据集，副本的位置，数据的划分。
实现
HDFS 上的 XML。希望做成类似于 Hadoop 的 namenode。
Data Loader
作用
将数据合理划分，从 HDFS 转移到节点中的本地文件系统
实现
global hasher：分配到不同节点 local hasher：继续划分为不同 chunks
SQL to MapReduce to SQL (SMS) Planner
作用
将 HiveQL 转化为特定执行计划，在 hadoopDB 中执行。原则是尽可能的讲操作推向节点上的 RDBMS 上执行，以此提高执行效率。
实现
扩展 Hive： 1.执行查找前，用 catolog 的信息更新 Hive 的 metastore，定向到节点数据库的表 2.执行前，决定划分的键；将部分查询语句推到节点的数据库中执行。
示例
示例参见下文的 slides
总结
对 hadoopDB 的一些看法：
其数据预处理代价过高：数据需要进行两次分解和一次数据库加载操作后才能使用；
将查询推向数据库层只是少数情况，大多数情况下，查询仍由Ｈive 完成．因为数据仓库查询往往涉及多表连接，由于连接的复杂性，难以做到在保持连接数据局部性的前提下将参与连接的多张表按照某种模式划分；
维护代价过高．不仅要维护Ｈadoop 系统，还要维护每个数据库节点；
目前尚不支持数据的动态划分，需要手工一次划分好
(责任编辑：IT) |