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

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

2、务完成数据处理。图1显 示了Hive数据仓库的系统结构。图1 Hive数据仓库的系统结构基于MapReduce的数据仓库在超大规模数据分析中扮演了重要角色，对于典型的Web服 务供应商，这些分析有助于它们快速理解动态的用户行为及变化的用户需求。数据存储结构是影响数据仓库性能的关键因素之一。Hadoop系统中常用的文件存 储格式有支持文本的TextFile和支持二进制的SequenceFile等，它们都属于行存储方式。Facebook工程师发表的RCFile: A Fast and Spaceefficient Data Placement Structure in MapReducebased

3、 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系统

4、特征和用户数据的分析，在MapReduce计算环境下，数据仓库对于数据存储结构有四个关键需求。Fast data loading对于Facebook的产品数据仓库而言，快速加载数据（写数据）是非常关键的。每天大约有超过20TB的数据上传到Facebook的数据仓库，由于数据加载期间网络和磁盘流量会干扰正常的查询执行，因此缩短数据加载时间是非常必要的。Fast query processing为了满足实时性的网站请求和支持高并发用户提交查询的大量读负载，查询响应时间是非常关键的，这要求底层存储结构能够随着查询数量的增加而保持高速的查询处理。Highly efficient storage spa

5、ce utilization高速增长的用户活动总是需要可扩展的存储容量和计算能力，有限的磁盘空间需要合理管理海量数据的存储。实际上，该问题的解决方案就是最大化磁盘空间利用率。Strong adaptivity to highly dynamic workload patterns同一份数据集会供给不同应用的用户，通过各种方式来分析。某些数据分析是例行过程，按照某种固定模式周期性执行；而另一些则是从中间平台发起的查 询。大多数负载不遵循任何规则模式，这需要底层系统在存储空间有限的前提下，对数据处理中不可预知的动态数据具备高度的适应性，而不是专注于某种特殊的负 载模式。MapReduce存储策略要

6、想设计并实现一种基于MapReduce数据仓库的高效数据存储结构，关键挑战是在MapReduce计算环境中满足上述四个需求。在传统数据库 系统中，三种数据存储结构被广泛研究，分别是行存储结构、列存储结构和PAX混合存储结构。上面这三种结构都有其自身特点，不过简单移植这些数据库导向的 存储结构到基于MapReduce的数据仓库系统并不能很好地满足所有需求。行存储如图2所示，基于Hadoop系统行存储结构的优点在于快速数据加载和动态负载的高适应能力，这是因为行存储保证了相同记录的所有域都在同一个集群 节点，即同一个HDFS块。不过，行存储的缺点也是显而易见的，例如它不能支持快速查询处理，因为当查询

7、仅仅针对多列表中的少数几列时，它不能跳过不必要 的列读取；此外，由于混合着不同数据值的列，行存储不易获得一个极高的压缩比，即空间利用率不易大幅提高。尽管通过熵编码和利用列相关性能够获得一个较好 的压缩比，但是复杂数据存储实现会导致解压开销增大。图2 HDFS块内行存储的例子列存储图3显示了在HDFS上按照列组存储表格的例子。在这个例子中，列A和列B存储在同一列组，而列C和列D分别存储在单独的列组。查询时列存储能够避 免读不必要的列，并且压缩一个列中的相似数据能够达到较高的压缩比。然而，由于元组重构的较高开销，它并不能提供基于Hadoop系统的快速查询处理。列 存储不能保证同一记录的所有域都存储

8、在同一集群节点，例如图2的例子中，记录的4个域存储在位于不同节点的3个HDFS块中。因此，记录的重构将导致通过 集群节点网络的大量数据传输。尽管预先分组后，多个列在一起能够减少开销，但是对于高度动态的负载模式，它并不具备很好的适应性。除非所有列组根据可能的 查询预先创建，否则对于一个查询需要一个不可预知的列组合，一个记录的重构或许需要2个或多个列组。再者由于多个组之间的列交叠，列组可能会创建多余的列 数据存储，这导致存储利用率的降低。图3 HDFS块内列存储的例子PAX混合存储PAX存储模型（用于Data Morphing存储技术）使用混合存储方式，目的在于提升CPU Cache性能。对于记录

9、中来自不同列的多个域，PAX将它们放在一个磁盘页中。在每个磁盘页中，PAX使用一个迷你页来存储属于每个列的所有域，并使用 一个页头来存储迷你页的指针。类似于行存储，PAX对多种动态查询有很强的适应能力。然而，它并不能满足大型分布式系统对于高存储空间利用率和快速查询处 理的需求，原因在于：首先，PAX没有数据压缩的相关工作，这部分与Cache优化关系不大，但对于大规模数据处理系统是非常关键的，它提供了列维度数据 压缩的可能性；其次，PAX不能提升I/O性能，因为它不能改变实际的页内容，该限制使得大规模数据扫描时不易实现快速查询处理；再次，PAX用固定的页 作为数据组织的基本单位，按照这个大小，在

10、海量数据处理系统中，PAX将不会有效存储不同大小类型的数据域。本文介绍的是RCF i l e 数据存储结构在Hadoop系统上的实现。该结构强调：第一，RCFile存储的表是水平划分的，分为多个行组， 每个行组再被垂直划分， 以便每列单独存储；第二，RCFile在每个行组中利用一个列维度的数据压缩，并提供一种Lazy解压（decompression）技术来在查询执行时 避免不必要的列解压；第三，RCFile支持弹性的行组大小，行组大小需要权衡数据压缩性能和查询性能两方面。RCFile的设计与实现RCFile（Record Columnar File）存储结构遵循的是“先水平划分，再垂直划分”的

11、设计理念，这个想法来源于PAX。它结合了行存储和列存储的优点：首先，RCFile保证同一行 的数据位于同一节点，因此元组重构的开销很低；其次，像列存储一样，RCFile能够利用列维度的数据压缩，并且能跳过不必要的列读取。图4是一个 HDFS块内RCFile方式存储的例子。图4 HDFS块内RCFile方式存储的例子数据格式RCFile在HDFS分布式文件系统之上设计并实现，如图4所示，RCFile按照下面的数据格式来存储一张表。RCFile基于HDFS架构，表格占用多个HDFS块。每个HDFS块中，RCFile以行组为基本单位来组织记录。也就是说，存储在一个HDFS块中的所有记录被划分为多个行

12、组。对于一张表，所有行组大小都相同。一个HDFS块会有一个或多个行组。一个行组包括三个部分。第一部分是行组头部的同步标识，主要用于分隔HDFS块中的两个连续行组；第二部分是行组的元数据头部，用于存储行组单元的 信息，包括行组中的记录数、每个列的字节数、列中每个域的字节数；第三部分是表格数据段，即实际的列存储数据。在该部分中，同一列的所有域顺序存储。从图 4可以看出，首先存储了列A的所有域，然后存储列B的所有域等。压缩方式RCFile的每个行组中，元数据头部和表格数据段分别进行压缩。对于所有元数据头部，RCFile使用RLE（Run Length Encoding）算法来压缩数据。由于同一列中所

13、有域的长度值都顺序存储在该部分，RLE算法能够找到重复值的长序列，尤其对于固定的域长度。表格数据段不会作为整个单元来压缩；相反每个列被独立压缩，使用Gzip压缩算法。RCFile使用重量级的Gzip压缩算法，是为了获得较好的压 缩比，而不使用RLE算法的原因在于此时列数据非排序。此外，由于Lazy压缩策略，当处理一个行组时，RCFile不需要解压所有列。因此，相对较高的 Gzip解压开销可以减少。尽管RCFile对表格数据的所有列使用同样的压缩算法，不过如果使用不同的算法来压缩不同列或许效果会更好。RCFile将来的工作之一可能就是根据每列的数据类型和数据分布来自适应选择最好的压缩算法。数据追

14、加RCFile不支持任意方式的数据写操作，仅提供一种追加接口，这是因为底层的HDFS当前仅仅支持数据追加写文件尾部。数据追加方法描述如下。RCFile为每列创建并维护一个内存column holder，当记录追加时，所有域被分发，每个域追加到其对应的column holder。此外，RCFile在元数据头部中记录每个域对应的元数据。RCFile提供两个参数来控制在刷写到磁盘之前，内存中缓存多少个记录。一个参数是记录数的限制，另一个是内存缓存的大小限制。RCFile首先压缩元数据头部并写到磁盘，然后分别压缩每个column holder，并将压缩后的column holder刷写到底层文件系统中

15、的一个行组中。数据读取和Lazy解压在MapReduce框架中，mapper将顺序处理HDFS块中的每个行组。当处理一个行组时，RCFile无需全部读取行组的全部内容到内存。相反，它仅仅读元数据头部和给定查询需要的列。因此，它可以跳过不必要的列以获得列存储的I/O优势。例如，表tbl(c1, c2, c3, c4)有4个列，做一次查询“SELECT c1 FROM tbl WHERE c4 = 1”，对每个行组，RCFile仅仅读取c1和c4列的内容。在元数据头部和需要的列数据加载到内存中后，它们需要解压。元数据头部总会解压并在内存中维 护直到RCFile处理下一个行组。然而，RCFile不会

16、解压所有加载的列，相反，它使用一种Lazy解压技术。Lazy解压意味着列将不会在内存解压，直到RCFile决定列中数据真正对查询执行有用。由于查询使用各种WHERE条件，Lazy解压非常有 用。如果一个WHERE条件不能被行组中的所有记录满足，那么RCFile将不会解压WHERE条件中不满足的列。例如，在上述查询中，所有行组中的列 c4都解压了。然而，对于一个行组，如果列c4中没有值为1的域，那么就无需解压列c1。行组大小I/O性能是RCFile关注的重点，因此RCFile需要行组够大并且大小可变。行组大小和下面几个因素相关。行组大的话，数据压缩效率会比行组小时更有效。根据对Facebook日

17、常应用的观察，当行组大小达到一个阈值后，增加行组大小并不能进一步增加Gzip算法下的压缩比。行组变大能够提升数据压缩效率并减少存储量。因此，如果对缩减存储空间方面有强烈需求，则不建议选择使用小行组。需要注意的是，当行组的大小超过4MB，数据的压缩比将趋于一致。尽管行组变大有助于减少表格的存储规模，但是可能会损害数据的读性能，因为这样减少了Lazy解压带来的性能提升。而且行组变大会占用更多的内存， 这会影响并发执行的其他MapReduce作业。考虑到存储空间和查询效率两个方面，Facebook选择4MB作为默认的行组大小，当然也允许用户自行 选择参数进行配置。小结本文简单介绍了RCFile存储结

18、构，其广泛应用于Facebook公司的数据分析系统Hive中。首先，RCFile具备相当于行存储的数据加载 速度和负载适应能力；其次，RCFile的读优化可以在扫描表格时避免不必要的列读取，测试显示在多数情况下，它比其他结构拥有更好的性能；再 次，RCFile使用列维度的压缩，因此能够有效提升存储空间利用率。为了提高存储空间利用率，Facebook各产品线应用产生的数据从2010年起均采用RCFile结构存储，按行存储 （SequenceFile/TextFile）结构保存的数据集也转存为RCFile格式。此外，Yahoo公司也在Pig数据分析系统中集成了 RCFile，RCFile正在用于另

19、一个基于Hadoop的数据管理系统Howl（/pig /Howl）。而且，根据Hive开发社区的交流，RCFile也成功整合加入其他基于MapReduce的数据分析平台。有理由相信，作为数据存储标准 的RCFile，将继续在MapReduce环境下的大规模数据分析中扮演重要角色。附录资料：不需要的可以自行删除如何构建银行数据仓库数据仓库技术作为一项数据管理领域的新技术，其精髓在于针对联机分析处理(OLAP)提出了一种综合的解决方案，与以往很多技术不同的是，它主要是一种概念，在此概念指导下完成系统的构造。既没有可以直接购买到的现成产品，也没有具体的分析规范和实现方法，也就是说没有成熟、可靠且被广

20、泛接受的数据仓库标准。在以往关系数据库的设计和实现中，不仅有详细的理论推导，还有无数的设计实例，无论你使用的是什么公司的数据库产品、开发工具，只要按照规范做，那么实现同一业务需求的方案都会很相似。而现有数据仓库的实现中，出现了MOLAP方案和ROLAP方案的区别，出现了形形色色的数据仓库建模工具、表现工具，而设计人员的个人经验和素质也会在其中扮演很重要的角色。 数据仓库技术的实现方式 目前在数据仓库技术的实际应用中主要包括如下几种具体实现方式。 1、在关系数据库上建立数据仓库(ROLAP) 2、在多维数据库上建立数据仓库(MOLAP) MOLAP方案是以多维方式来组织数据，以多维方式来存储数据

21、；ROLAP方案则以二维关系表为核心表达多维概念，通过将多维结构划分为两类表:维表和事实表，使关系型结构能较好地适应多维数据的表示和存储。在多维数据模型的表达方面，多维矩阵比关系表更清晰且占用的存储更少，而通过关系表间的连接来查询数据的ROLAP系统，系统性能成为最大问题。MOLAP方案比ROLAP方案要简明，索引及数据聚合可以自动进行并自动管理，但同时丧失了一定的灵活性。ROLAP方案的实现较为复杂，但灵活性较好，用户可以动态定义统计和计算方式，另外能保护在已有关系数据库上的投资。 由于两种方案各有优劣，因此在实际应用中，往往将MOLAP和ROLAP结合使用，即所谓的混合模型。利用关系数据库

22、存储历史数据、细节数据或非数值型数据，发挥关系数据库技术成熟的优势，减少花费，而在多维数据库中存储当前数据和常用统计数据，以提高操作性能。 3、在原有关系库上建立逻辑上的数据仓库 由于目前正在运行的OLTP系统中已经积累了海量数据，如何从中提取出决策所需的有用信息就成为用户最迫切的需要。新建数据仓库固然能从功能、性能各方面给出一个完整的解决方案，但需要投入大量的人力、物力，并且数据仓库的建设和分析数据的积累需要一段时间，无法及时满足用户对信息分析的迫切需要。因此在筹建数据仓库的前期，可以采用一些合适的表现工具，在原有OLTP系统上建立起一个逻辑的数据仓库系统。尽管由于原有OLTP系统设计上的局

23、限性，这样的系统可能无法实现很多分析功能，但这样一个系统中数据结构固定、信息分析需求相对稳定成熟，因此数据仓库的建模、实现过程会相对容易、便捷；同时，这样的系统也会成为将来真正数据仓库建设的原型。 信息系统与数据仓库的关系 由于数据量大、数据来源多样化，在商业银行构建管理信息系统时，不可避免地会遇上如何管理这些浩如烟海的数据，以及如何从中提取有用的信息的问题；而数据仓库的最大优点在于它能把企业网络中不同信息岛上的商业数据集中到一起，存储在一个单一的集成的数据库中，并提供各种手段对数据进行统计、分析。因此可以说，在银行使用数据仓库构建管理信息系统，既有压力，又有数据基础，它们之间的联系是必然的，

24、难以割舍的。 数据仓库在商业银行的应用范围包括存款分析、贷款分析、客户市场分析、相关金融业分析决策(证券、外汇买卖)、风险预测、效益分析等。 在银行信息系统构建时，由于历史情况和现实需求的不同，存在两种途径: 1、建设新系统 由于目前国内商业银行对银行内部运营的监管，缺乏很好的数据搜集机制，因此可以在构建管理信息系统时，分数据收集录入和数据汇总分析两部分来考虑。这样的系统中由于不需考虑大量历史数据的处理问题，同时考虑到搜集过程中可能存在多个数据来源，因此可以在系统建设的同时构建数据仓库，将搜集来的各种数据通过数据抽取整合到数据仓库中。 2、完善原有系统 而对于已经存在OLTP系统，其中沉淀了大

25、量历史数据，则可以先在原有系统上建立逻辑数据仓库，即使用数据分析的表现工具，在关系模型上构建一个虚拟的多维模型。当系统需求稳定后，再建立物理数据仓库，这样既节省投资，又缩短开发工期。 实现中需要注意的问题 一、模型设计中的问题 模型设计(包括逻辑模型设计和物理模型设计)是系统的基础和成败的关键，在实际操作中，视实现技术的不同应分别对下列问题引起注意。 1、直接构建数据仓库 直接构建数据仓库时，必须按业务分析的要求重组OLTP系统中的数据，并要按不同侧重点分别组织，使之便于使用。 *主题的确定 主题是一个逻辑概念，它应该能够完整、统一地刻画出分析对象所涉及的各项数据以及相互联系。划分主题的根据主

26、要来源于两方面:对原有固定报表的分析和对业务人员的访谈。原有固定报表能较好地反映出以往工作对数据分析的需求，而且数据含义和格式相对成熟、稳定，在模型设计中需要大量借鉴。但仅仅满足于替代目前的手工报表还远远不应是构建管理信息系统的目标，还应该通过业务访谈，进一步挖掘出日常工作中潜在的更广、更深的分析需求。只有这样，才能真正了解构建数据仓库模型所需的主题划分。 *分析内容的细化 主题的划分实际上是与分析内容的范围直接相关的，一旦主题划分清楚了，下一步就是细化分析的具体内容以及根据分析内容的性质确定它在数据仓库中的位置。通常维元素对应的是分析角度，而度量对应的是分析关心的具体指标。一个指标究竟是作为

27、维元素、度量还是维属性，取决于具体的业务需求，但从实际操作中可以总结出如下的概念性经验:作为维元素或维属性的通常是离散型的数据，只允许有限的取值；作为度量的是连续型数据，取值无限。如果一定要用连续型数据作为维元素，则必须对其按取值进行分段，以分段值作为实际的维元素。判断分析指标是作为维元素还是维属性时，则需要综合考虑这个指标占用的存储空间与相关查询的使用频度。 需要特别强调的是，在细化分析内容的过程中，务必解决指标的歧义问题。在不同报表中以及在业务访谈中同一名称的指标，是否是在同样条件限定下，通过同样方法提取或计算得到的，它们之间的相互关系是什么，这些问题都必须从熟悉业务的分析人员那里得到准确

28、、清晰的答案，否则将会影响到模型设计、数据提取、数据展现等多个方面。 *粒度的设计 数据仓库模型中所存储的数据的粒度将对信息系统的多方面产生影响。事实表中以各种维度的什么层次作为最细粒度，将决定存储的数据能否满足信息分析的功能需求，而粒度的层次划分、以及聚合表中粒度的选择将直接影响查询的响应时间。 如果同一个信息系统要在大范围、多层次上同时运行，如部门级和企业级，还应考虑不同层次的数据仓库采用不同的粒度。 *模型设计中的技巧 复合指标尤其是比率类指标的定义，必须注意累加时是先加减后乘除，还是反之。户数、笔数的计算，这类指标在分析或报表中经常出现，但不需要作为单独的指标物理存在于数据库中，但定义

29、分析模型时一定应该准备。度量的时间特性，针对分析指标在时间维上的不同表现，可分为可累加指标、半可累加指标和不可累加指标。 2、在原有数据基础上构建逻辑数据仓库 如果直接使用OLTP系统中的数据进行数据分析处理，会遇到许多麻烦，有时甚至是不可能实现的。这并不是说关系数据库不好，而是因为其设计思路不适应较大规模数据分析。因此在使用这种方法时，需要注意下列问题的处理: *不同的时间单位 这是实现过程中最常遇到的问题，也往往是最难解决的问题。OLTP系统中存储的时间往往采用与实际业务发生相同的时间单位，如帐务数据单位为日期，财务报表单位为月或半年。而面向分析时，往往要将不同时间单位的数据统一到同一个结

30、果中，这样就必须存在适当的转换机制才能实现。 *冗余信息 所谓冗余信息，就是指不同关系表中存在的同一含义的字段，而同一含义不仅指这些字段的取得或计算方式一样，还指它们成立的条件一样，例如截止某一时间同一地区的同一贷种的贷款余额。在OLTP系统中，这样的字段往往是基于性能考虑而设计的，而在面向分析设计模型时，为了保证结果的唯一性和准确性，就必须用且只用其中之一的数据产生分析结果。 *表间连接 由于OLTP系统中表的设计面向业务处理，既要保证数据的完整性、一致性，又要考虑响应时间，因此表与表之间既相对独立，又相互依赖。在设计数据仓库逻辑模型时，对表间的连接必须做出相应取舍，既要保证分析数据能通过连

31、接取得或计算出，又要避免出现环路，造成分析数据的歧义。另外，不同的连接途径还会出现不同的查询速度，影响数据分析的响应性能。 *统计表的设计 如果上述问题不能在原有数据库基础上得到很好的解决，那么权益之计就是构建统计表，即简单化的数据仓库，形式类似数据仓库的事实表，定时计算统计数据放入，将时间、冗余、连接等问题摈除，进行简单分析。 二、数据抽取中的问题 数据抽取是一件技术含量不高，但非常烦琐的工作，必须有专人负责数据抽取的工作。在对其进行设计时，要注意的问题有: 1、数据抽取的规则要作为元数据进行规范和管理，抽取过程中的源表、源字段、目的表、目的字段、转换规则以及转换条件都要作好详细记录。这样不仅便于编程人员实现，而且在抽取