Facebook 在2010年4月发表了一篇在Hadoop 里面实现列储存的论文: RCFile: A Fast and Space efficient Data Placement Structure in MapReduce based Warehouse Systems.
CSDN 上面有这篇文章的一部分翻译, 它当时提出这个设想其实就是想做一个列数据库，而实现列数据库的第一步就是实现列储存，本文主要介绍当时Hive 的RCFile 的实现环境与限制，下一代Hadoop的架构对新的RCFile 产生的影响以及将来可能出现的Hadoop 列数据库计算模型的一些相关问题.
RCFile 在实现的时候主要需要满足facebook 在以下4个方面的需求:
Fast data loading、
Fast query processing、
Highly efficient storage space utilization
Strong adaptivity to highly dynamic workload patterns
facebook 团队在参考设计的时候使用的是实验性质的C-store 数据库，而不是像另外一篇非常有名的Hadoop 与DBMS 争论的论文: A Comparison of Approaches to Large-Scale Data Analysis 中使用的是列数据库中非常好的Vertica 数据库做参考. 所以其在上面4点中并没有得到最好的设计，尤其是当时的Hadoop 架构上的限制非常的大，RCFile 的推出算是一种可以接受的能够实现的设计, 毕竟一个不算完美的设计可以慢慢修改，而一个设计非常优秀但是不能实现的设计等于空话.
阅读全文…
这篇文章介绍一下几个数据库的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 并没有大幅减少, 它只是将更多的块放在一起提高了一点压缩率，它并不像其他的混合储存或者列储存得到的好处那么多.
阅读全文…
最早的商业列式数据库是在1995年发布的Sybase IQ , 但是一直到1999年左右才慢慢稳定到能够投入生产环境. 现在的大多数分析型数据库都是在2003-2005年从Postgresql 分支出来的. 其中尤其是Vertica 为代表的列数据库已经在大规模数据仓库环境中证明其特别为数据仓库环境设计的思路在一些领域具有竞争优势. 这篇文章解释介绍列式数据库的几大特点.
- 高效的储存空间利用率 传统的行式数据库由于每个列的长度不一，为了预防更新的时候不至于出现一行数据跳到另一个block 上去, 所以往往会预留一些空间. 而面向列的数据库由于一开始就完全为分析而存在，不需要考虑少量的更新问题，所以数据完全是密集储存的.
行式数据库为了表明行的id 往往会有一个伪列rowid 的存在. 列式数据库一般不会保存rowid.
列式数据库由于其针对不同列的数据特征而发明的不同算法使其往往有比行式数据库高的多的压缩率，普通的行式数据库一般压缩率在3：1 到5：1 左右，而列式数据库的压缩率一般在8：1到30：1 左右. (InfoBright 在特别应用可以达到40:1 , Vertica 在特别应用可以达到60:1 , 一般是这么高的压缩率都是网络流量相关的)
列式数据库由于其特殊的IO 模型所以其数据执行引擎一般不需要索引来完成大量的数据过滤任务(Sybase IQ 除外) . 这又额外的减少了数据储存的空间消耗.
列式数据库不需要物化视图,行式数据库为了减少IO 一般会有两种物化视图，常用列的不聚合物化视图和聚合的物化视图. 列式数据库本身列是分散储存所以不需要第一种，而由于其他特性使其极为适合做普通聚合操作.(另外一种物化视图是不能实时刷新的，比如排名函数,不规则连接connect by 等等，这部分列数据库不包括.)
阅读全文…
IBM Netezza 发表了一篇相对比较中立的文章比较它跟Oracle Exadata 之间的区别 ， 下面摘录一些重要信息:
Oracle 查询性能方面:
oracle exadata 的一个机柜包含一个14个节点组成的服务器储存层 , smart scan 就是在这个储存层优先执行SQL 投影 ( SQL Projection ) , 限制 (restriction), 过滤 （filter) . 但是Oracle 的Smart Scan 有一些明显的限制: 包括表的类型，
Smart Scan 不支持IOT (Index of Table) , 一种用来把相关数据储存一起的表结构，主要用来地理信息空间和OLAP 应用中. 当Oracle 用这种方式组织文本，图像，二进制文件，地理空间信息的时候就不能使用MPP 了.
Oralce 不支持所有的函数MPP . 最新的oracle 提供511 个函数，只有319 个函数可以MPP， 大多数预测，数据挖掘的，数据，财务，高级分析，统计函数都不能MPP. (里面提到的month_between 函数是个bug , 已经被fix 了).
Oracle 对于大表一般使用分区 , 对于两个表的join 会根据各种情况使用分区, 但是当3个表连接的时候, Oracle 的join 就不再是MPP 的了.
Oracle 的UDF 自定义函数 不是MPP 的.
Exadata 的储存层不能处理聚合, 很多高级分析函数都必须要用到这个. 因此Oracle 的in-database analysis 不具备处理大数据的能力.
Exadata 的储存层不能互相通信, 任何中间计算的结果必须先从储存层传递到RAC Node, 然后通过RAC Node 传递到对应的储存层Node, 然后计算. 因此oracle 使用的高端网卡InfiniBand 其实是它架构上的缺陷. 而大量的数据移动又造成了不必要的IO 和网络资源消耗.
Oracle RAC 有一个叫Fusion Cache 的功能用来在多个内存储存同一份数据，这个功能完全面向OLTP 的，在分析型的OLAP 中浪费大量内存，而且如果网络堵塞或者数据更新的时候会造成不必要的节点间的等待.
阅读全文…
数据仓库世界里面的massively parallel processing 大概定义：
MPP 是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果.
首先MPP 必须消除手工切分数据的工作量. 这是MySQL 在互联网应用中的主要局限性
另外MPP 的切分必须在任何时候都是平均的 , 不然某些节点处理的时间就明显多于另外一些节点.
对于工作负载是不是要平均分布有同种和异种之分，同种就是所有节点在数据装载的时候都同时转载，异种就是可以指定部分节点专门用来装载数据(逻辑上的不是物理上) ， 而其他所有节点用来负责查询. Aster Data 和Greenplum 都属于这种. 两者之间并没有明显的优势科研，同种的工作负载情况下，需要软件提供商保证所有节点的负载是平衡的. 而异种的工作负载可以在你觉得数据装载很慢的情况下手工指定更多节点装载数据 . 区别其实就是自动化和手工控制，看个人喜好而已.
另外一个问题是查询如何被初始化的. 比如要查询销售最好的10件商品，每个节点都要先计算出自己的最好的10件商品，然后向上汇总，汇总的过程，肯定有些节点做的工作比其他节点要多.
上面只是一个简单的单表查询，如果是两个表的连接查询，可能还会涉及到节点之间计算的中间过程如何传递的问题. 是将大表和小表都平均分布，然后节点计算的时候将得到的结果汇总（可能要两次汇总），还是将大表平均分布，小表的数据传输给每个节点，这样汇总就只需要一次. （其中一个特例可以参考后面给出的Oracle Partition Wise Join) . 两种执行计划很难说谁好谁坏，数据量的大小可能会产生不同的影响. 有些特定的厂商专门对这种执行计划做过了优化的，比如EMC Greenplum 和 HP Vertica . 这其中涉及到很多取舍问题，比如数据分布模式，数据重新分布的成本，中间交换数据的网卡速度，储存介质读写的速度和数据量大小（计算过程一般都会用临时表储存中间过程）.
一般在设计MPP 数据仓库的时候都会有一个指导原则用来得到比较好的性能，比如数据如何分布，customer 一般按照hash 分布比较好，而sales_order 一般按照时间分布.
所以一般建议在选型做POC 的时候，针对你自己需要的典型查询模式和负载进行测试. 一般优化的时候会考虑如下问题：
阅读全文…
在几年以前，数据库的分类基本就分两种，一种面向OLTP 的，一种面向OLAP 的, 都是关系型数据库, 各种应用的不同决定了他们优化的路线不同 , 现在随着数据量的暴增，两个世界都发生了巨变，兴起了各种面向不同方向优化的noSQL 数据库, 这里介绍的就是主要面向分析型数据库的大概分类.
- 企业级数据仓库 (EDW)
包括的数据： 各种类型但是不包括操作的交易记录
使用类型： 各种
包括的数据： 各种类型但是不包括操作的交易记录
通常例子：集中的EDW 对大企业
鸭梨： 并发，可靠性，负载管理
最原始的美好想法，所有支持决策的数据放一起，主要厂家是Teradata ,DB2 , Oracle Exadata . 现在看来完全不可能，数据量的增长远远超过了硬件, 软件优化和复杂度的能力. 但是在数据量容许的情况下，部分EDW 还是可能的.
-
传统的数据集市 (Data mart)
包括的数据： 各种数据类型，但是一般限于部门级别
通常例子： BI 报表 ， 预算预测， MOLAP 之类的
鸭梨： 性能 , 并发, 成本
BI 最开始的定义, 尤其像是报表这种入门级应用, 一般也是选用关系型数据库， 但是列数据库(Vertica , Sybase IQ ) 可能成本会更有优势
阅读全文…
