Facebook数据仓库揭秘：RCFile高效存储结构

本文介绍了Facebook公司数据分析系统中的RCFile存储结构，该结构集行存储和列存储的优点于一身，在MapReduce环境下的大规模数据分析中扮演重要角色。
Facebook曾在2010 ICDE（IEEE International Conference on Data Engineering）会议上介绍了数据仓库Hive。Hive存储海量数据在Hadoop系统中，提供了一套类数据库的数据存储和处理机制。它采用类SQL语言对数据进行自动化管理和处理，经过语句解析和转换，最终生成基于Hadoop的MapReduce任务，通过执行这些任务完成数据处理。图1显示了Hive数据仓库的系统结构。

图1 Hive数据仓库的系统结构

基于MapReduce的数据仓库在超大规模数据分析中扮演了重要角色，对于典型的Web服务供应商，这些分析有助于它们快速理解动态的用户行为及变化的用户需求。数据存储结构是影响数据仓库性能的关键因素之一。Hadoop系统中常用的文件存储格式有支持文本的TextFile和支持二进制的SequenceFile等，它们都属于行存储方式。Facebook工程师发表的RCFile: A Fast and Spaceefficient Data Placement Structure in MapReducebased Warehouse Systems一文，介绍了一种高效的数据存储结构——RCFile（Record Columnar File），并将其应用于Facebook的数据仓库Hive中。与传统数据库的数据存储结构相比，RCFile更有效地满足了基于MapReduce的数据仓库的四个关键需求，即Fast data loading、Fast query processing、Highly efficient storage space utilization和Strong adaptivity to highly dynamic workload patterns。

数据仓库的需求
基于Facebook系统特征和用户数据的分析，在MapReduce计算环境下，数据仓库对于数据存储结构有四个关键需求。
Fast data loading
对于Facebook的产品数据仓库而言，快速加载数据（写数据）是非常关键的。每天大约有超过20TB的数据上传到Facebook的数据仓库，由于数据加载期间网络和磁盘流量会干扰正常的查询执行，因此缩短数据加载时间是非常必要的。
Fast query processing
为了满足实时性的网站请求和支持高并发用户提交查询的大量读负载，查询响应时间是非常关键的，这要求底层存储结构能够随着查询数量的增加而保持高速的查询处理。
Highly efficient storage space utilization
高速增长的用户活动总是需要可扩展的存储容量和计算能力，有限的磁盘空间需要合理管理海量数据的存储。实际上，该问题的解决方案就是最大化磁盘空间利用率。
Strong adaptivity to highly dynamic workload patterns
同一份数据集会供给不同应用的用户，通过各种方式来分析。某些数据分析是例行过程，按照某种固定模式周期性执行；而另一些则是从中间平台发起的查询。大多数负载不遵循任何规则模式，这需要底层系统在存储空间有限的前提下，对数据处理中不可预知的动态数据具备高度的适应性，而不是专注于某种特殊的负载模式。
MapReduce存储策略
要想设计并实现一种基于MapReduce数据仓库的高效数据存储结构，关键挑战是在MapReduce计算环境中满足上述四个需求。在传统数据库系统中，三种数据存储结构被广泛研究，分别是行存储结构、列存储结构和PAX混合存储结构。上面这三种结构都有其自身特点，不过简单移植这些数据库导向的存储结构到基于MapReduce的数据仓库系统并不能很好地满足所有需求。
行存储
如图2所示，基于Hadoop系统行存储结构的优点在于快速数据加载和动态负载的高适应能力，这是因为行存储保证了相同记录的所有域都在同一个集群节点，即同一个HDFS块。不过，行存储的缺点也是显而易见的，例如它不能支持快速查询处理，因为当查询仅仅针对多列表中的少数几列时，它不能跳过不必要的列读取；此外，由于混合着不同数据值的列，行存储不易获得一个极高的压缩比，即空间利用率不易大幅提高。尽管通过熵编码和利用列相关性能够获得一个较好的压缩比，但是复杂数据存储实现会导致解压开销增大。

图2 HDFS块内行存储的例子

列存储

图3显示了在HDFS上按照列组存储表格的例子。在这个例子中，列A和列B存储在同一列组，而列C和列D分别存储在单独的列组。查询时列存储能够避免读不必要的列，并且压缩一个列中的相似数据能够达到较高的压缩比。然而，由于元组重构的较高开销，它并不能提供基于Hadoop系统的快速查询处理。列存储不能保证同一记录的所有域都存储在同一集群节点，例如图2的例子中，记录的4个域存储在位于不同节点的3个HDFS块中。因此，记录的重构将导致通过集群节点网络的大量数据传输。尽管预先分组后，多个列在一起能够减少开销，但是对于高度动态的负载模式，它并不具备很好的适应性。除非所有列组根据可能的查询预先创建，否则对于一个查询需要一个不可预知的列组合，一个记录的重构或许需要2个或多个列组。再者由于多个组之间的列交叠，列组可能会创建多余的列数据存储，这导致存储利用率的降低。