Alex的个人Blog

这篇文章介绍一下几个数据库的Hadoop 适配器的资料：

AsterData 和 Greenplum 虽然在2008年8月期间都宣布自己是第一个在数据库层面实现MapReduce 的厂商，但是之后双方走的路线却不尽相同. AsterData 之后走的路线还是将MapReduce层面的东西交给Hadoop 来做，并在一年之后的2009年10月宣布跟Cloudera 合作推出了第一个Hadoop 连接器. 这个连接器主要有如下特点：

• 双向连接：Hadoop 和 AsterData 互相能够保持数据的同步传输.
• SQL-MapReduce : 通过sql 可以直接调用后面的手写的mapreduce 端代码
• MapReduce 执行的时候会占用尽可能多的内存，尤其是保证中间结果尽量不写入到磁盘.

Greenplum 在今年9月的时候完成了它的第一个Hadoop 适配器，也是和Cloudera 合作开发, 不过它是单向的从HDFS 往Greenplum 导数据，仍然是通过所有集群节点并行加载. 它主要利用了机器的优势装载, 本身技术上并没有优化太多, 速度还算可以. 另外一个特点是它的适配器集成了它的Chorus , 作为数据生命周期管理的一个重要特性.

Vertica 在2009年10月与Cloudera  合作开发出了Vertica-Hadoop 集成适配器，它当时只实现了从Vertica 往Hadoop 导入数据的功能，一年之后它增强了从Hadoop 的HDFS 往Vertica 导数据的功能，从而实现了Vertica 与 Hadoop 的双向连接功能，值得一提的是，Vertica 的适配器有两个很变态的功能，一个是能从在vertica 的客户端通过sql 直接指定sql运行在hadoop 集群上, 这个跟AsterData 的SQL-MapReduce 差不多，这个过程是透明的, 他后台的适配器能自动把SQL 翻译成HiveQL 然后执行返回. 另外一个特性是它的Hadoop 连接器是直接读Vertica 的文件格式和元数据，对，数据只存储一份，不像其他的连接器实际上是数据存两份要你自己确保两份数据是同步的. (更准确的说法应该是Vertica 里面的数据是可以配置mirror的，用来提高IO并行能力和数据高可用性，Hadoop 的HDFS 的其中1到2个复制备份是直接依赖与Vertica 文件系统的, 而不像行数据库Greenplum,AsterData 那样数据在DBMS 里面和Hadoop 里面是完全不同的备份)

阅读全文…

由于列数据库在IO 读取和磁盘利用率上有优势，所以各个行数据库也纷纷提出了自己的向列数据库过度的中间储存模型，即混合储存(Hybrid Column).

在商用的混合储存出现之前，就已经有论文说明了三种不同的储存方式, 行储存，列储存，混合PAX储存.

本文将介绍三种混合存储的方式: Oracle 的混合储存，Greenplum,AsterData,Teradata的混合储存, Vertica 的混合储存.

Oracle 11g Hybrid

Oracle 在09年7月左右推出Exadata 的时候推出的新压缩模式, 也是唯一一个最接近PAX 的压缩模式. 它将数据分为Compression Unit (简写CU）, 一个CU 一般是一个Oracle 里面的extend 区块. 由16个Block 组成（可以配置大小), 然后在每个CU 的第一个Block 的头部放入压缩数值, 将所有的列中出现频率最高的数值放入Block 头部, 默认好像是只有在Oracle 自己的Exadata 里面才能用(为了赚钱嘛), 有两种压缩级别，压缩级别高的收益更小，压缩时间更长, 解压缩无影响. 如下图:

oracle 的混合压缩并不算是真正意义上的混合储存，它在读取数据的时候IO 并没有大幅减少, 它只是将更多的块放在一起提高了一点压缩率，它并不像其他的混合储存或者列储存得到的好处那么多.

阅读全文…

在08年底的时候vertica 宣布了它的ETL世界纪录，在57分21.51秒时间内装载了5.4TB 的记录，这项记录由Syncsort（一个DI 供应商）和Vertica 共同发布. 最近Greenplum 在mysql/fox interactive media 的应用也发布了一个ETL装载记录4TB/h.
vertica 的记录由16 two quad-core server blades and 16 storage blades in HP BladeSystem c-Class enclosures ， 运行在Red hat Linux operation system 上.
Greenplum 则是在一小时装载4TB , 由40台Sun fire 4500 运行的greenplum 集群组成,Sun fire 4500 有2 dual-core AMD .

两个声明都是由供应商自己发出，取自客户的实例，只不过greenplum 的应用是在myspace/fox 上. 更加实际,Vertica 更像是一种实验性质的测试.
阅读全文…

在 dbms2 看到两篇文章分别介绍Myspace 使用Aster Data 做分析型数据仓库和myspace 的父公司Fox Interactive Media 使用Greenplum 做分析数据仓库, Aster Data 和 Greenplum 作为两个都实现了数据库级别的MapReduce 的data warehosue数据库(先有这些大客户，后才有mapreduce 技术的)，其案例还是非常值得关注的.

Fox 的greenplum 数据库有几百T ，它目前是在慢慢的使用greenplum 数据库慢慢的替换之前的Aster Data ，Fox/Greenplum 在自己的优势项方面非常满意，并且也比Myspace 的Aster Data 数据库要大，不过显然在使用次数跟并发上比myspace 少的多, 不过Aster Data 数据库似乎有数据输入也会删除一些数据, 不过Greenplum 数据库一直在不停的增加数据(这根myspace 应用有关，后面会提到). 另外一方面，Fox 使用了一种sandbox 的数据库架构，无论分析员怎么创建和删除表，底层的数据都不会受到影响，eBay 也在其Teredata 应用上使用了同样的方式.Dell 的DATALLegro 数据仓库也是一样的.

Myspace 使用Aster Data 构建了一个200+ 普通服务器的集群，管理200+T 的数据，每天以2-3 TB 增加. Aster 支持一个data warehouse 和若干个data marts , 并且myspace 使用其做myspace music 项目，这是一个面向最终用户的分析型数据库，(每个用户都可以在上面分析歌曲的各种数据，这种面向最终用户的分析型数据库不知道全世界还有没有第二个案例，技术太牛了) , 以myspace 的超海量用户，并发性和高可用性都是其特色之一，它可以无缝的支持失效转移，服务器一运行就是几个星期.

两个都有视频展示和案例介绍, 建议大家去看看

Fox 使用greenplum 那个没什么好看的，速度很慢，而且里面都是男的.

Myspace 使用Aster Data 那个真的建议大家去看看，里面有美女，真的!!! 绝对没拿恐龙骗你,

myspace 的data service vice president 是个短发，属于很精明能干类型的美女，很有个性的女生，事业型男士最爱.

Chief Data Architect 则是标准长发美女，黑色头发（外国美女中还是黑发比较接受，金发就……）, 有一点邻家女孩的味道，很标致的美女，我觉得是里面最漂亮的一个.

Data Warehouse Architect 是…… , 嗯… , 属于熟女，30岁以上家庭型男士最爱(这样应该比较合适)

Data Warehouse Manager 好像有一点拉丁血统，嘴唇比较厚，不知道该跟舒淇比还是朱莉娅罗伯茨比, 头发是褐黄相间，有点混血的味道,标准的轻熟女.  三个女人一台戏，myspace 这四个女人那哪能让男性员工好好工作呀.

……嗯，我还准备说什么的呀，咦？我现在讲到哪了，我怎么会扯到这里来的，算了，突然发现自己有其他重要事情去做了, 就到这里吧.

参考资料:

http://www.asterdata.com/blog/index.php/2009/03/04/myspace-expands-usage-of-aster-data-systems-%E2%80%93-check-out-the-video/

myspace 的视频地址, 有美女哦

http://www.dbms2.com/2009/03/05/myspaces-multi-hundred-terabyte-database-running-on-aster-data/

dbms2 介绍myspace 的

http://www.dbms2.com/2009/03/05/fox-interactive-medias-multi-hundred-terabyte-database-running-on-greenplum/

dbms2 介绍fox 的.