2020, Vol. 31
2. 中国人民大学 信息学院, 北京 100872;
3. 大数据系统软件国家工程实验室(北京理工大学), 北京 100081
2. School of Information, Renmin University of China, Beijing 100872, China;
3. National Engineering Laboratory of Big Data System Software(Beijing Institute of Technology), Beijing 100081, China
近年来, 随着大数据技术在各行各业中的应用和发展, 大量的实际应用中数据量都超出了常规单机的存储和计算能力.分布式水平扩展成为了大数据系统的必由之路.在面向分析的大数据系统中, 由于需要分析和处理大批量的历史和新生数据, 大规模的水平扩展更成为了最为迫切的需求.HDFS(Hadoop distributed file system)旨在解决大数据的分布式存储问题, 它随着Hadoop生态圈一起出现并发展成熟, 具有开源、可移植、高可用、高容错、可大规模水平扩展等特性.随着Hadoop生态圈的繁荣发展, HDFS也在各行各业的大数据系统中得到了广泛的应用.
HDFS作为底层的文件存储系统, 其上支撑着非常丰富的应用场景, 如复杂查询分析、交互式分析、详单查询、Key-Value存储和查询、迭代计算等.上层的系统和应用从HDFS读取数据并向HDFS写入数据或者中间结果.HDFS的性能问题将影响到其上所有大数据系统和应用, 因此, HDFS性能的优化变得至关重要.但HDFS的性能优化非常具有挑战性.作为一个通用的分布式文件系统, 在优化HDFS时, 要保证其稳定和通用的访问接口以及高可用性和高可扩展等其他特性, 其性能优化存在很多限制.并且, 由于硬件设备的发展和Hadoop上应用的丰富性, 性能优化往往需要针对特定的硬件和应用.因此, 在保证HDFS基本接口和特性不被破坏的前提下, 如何最大限度地优化HDFS的存储性能, 在过去10余年中一直都是学术界和工业界研究的重点.已有的相关综述大多着眼于大数据管理和大数据分析系统的研究进展, 并从宏观角度分析和对比了部分基于HDFS的扩展系统, 但没有聚焦到底层的HDFS存储和优化技术[1, 2].为了更好地优化HDFS系统的存储性能, 本文对大数据分析背景下HDFS的存储和优化的研究成果进行了系统的整理和分析, 以供后续研究参考.
本文第1节概述HDFS的发展历程, 介绍HDFS的系统架构和基本原理, 总结HDFS存储系统的特点和面临的挑战, 并给出本文的研究框架.第2节从文件逻辑结构的角度介绍文件存储格式、文件压缩和数据索引等基于文件逻辑结构的HDFS存储和优化技术.第3节从HDFS系统硬件设备的维度出发, 研究针对外存、内存和网络传输中不同硬件的存储和优化技术.第4节从应用的维度出发, 概括了HDFS上的主要应用场景以及针对不同应用的存储和优化方法.最后, 第5节总结全文, 指出HDFS存储系统当前面临的挑战, 并对未来研究方向加以展望.
1 HDFS存储系统概述本节介绍HDFS存储系统的发展历程以及系统架构和基本原理, 并总结和归纳HDFS的存储特点及面临的主要挑战.最后, 基于对HDFS存储特点和挑战的分析, 给出本文的研究框架, 即:从HDFS上数据存储和访问性能的3个主要影响维度, 对已有的存储和优化技术进行研究和综述.
1.1 HDFS存储系统的发展历程HDFS是Hadoop中的分布式存储系统.Hadoop最早起源于Cafarella和Cutting开发的Nutch[3]. Nutch是一个开源的搜索引擎, 在分布式存储和计算框架方面参考了谷歌发表的关于GFS[4]和MapReduce[5]的两篇论文.之后, Nutch中的分布式文件系统NDFS(Nutch distributed file system)和分布式计算框架MapReduce独立开源, 成为一个新的项目, 即Hadoop.此后, Hadoop受到开源社区的青睐, 日益流行, 成为了Apache顶级项目, 并在许多公司内部得到了应用, 形成了一个成熟的生态系统.
作为Hadoop的重要子系统, HDFS自开源后有多次重要的版本更新, 不断加入新的特性和功能, 以支持更可靠、规模更大、更高效的数据管理和访问.表 1列出了自开源来HDFS的重要版本更新.2010年发布的0.21.0版本中加入了Append功能, 即用户可以追加写HDFS上的文件.HDFS的2.x系列属于新一代Hadoop系统, 该大版本除了进行大量代码实现上的优化外, 还支持HDFS Federation来增强系统的扩展性.另外, 2.x系列还适应存储硬件的发展, 增加了新特性以提高数据管理和访问的效率.例如, Hadoop在2.3.0版本开始支持异构存储(heterogeneous storage)[6]和集中式缓存管理(centralized cache management)[7], 以更好地利用除磁盘外的存储介质提高存储性能; 随后, 在2.6.0版本中, HDFS加入了对SSD、内存的层级化存储的支持, 还引入了Archival Storage[8]来分离存储“冷”“热”数据, 用户可以配置存储规则指定文件的存储介质和类型.2017年12月, Apache Hadoop发布了3.0.0版本.作为3.x版本的第一个GA(general available)版本, HDFS开始支持纠删码(erasure coding)[9]作为冗余副本之外的另一种数据容错方式, 减少数据容错机制对存储空间的占用.
|
Table 1 Descriptions of important versions of HDFS in Apache Hadoop 表 1 Apache Hadoop中HDFS的重要版本更新 |
1.2 HDFS存储系统的架构和基本原理
HDFS存储系统被设计用来在大规模的廉价服务器集群上可靠地存储大规模数据, 并提供高吞吐的数据读取和追加式写入.单个HDFS集群可以扩展至几千甚至上万个节点[10].本节从HDFS的集群架构和数据块的放置与容错两个方面介绍HDFS的架构和基本原理, 以便更深入地分析HDFS存储系统的特点.
(1) 集群架构
HDFS将所存储的文件划分为较大的数据块(data block, 如128MB), 并将这些数据块分布式地存储于集群中的各个节点上.如图 1所示, HDFS集群中的NameNode节点负责管理集群中的元数据.
|
Fig. 1 Architecture and data block replacement strategy of HDFS cluster 图 1 HDFS集群架构和副本放置策略 |
元数据主要包括文件系统的命名空间和数据块的存储位置等.为防止NameNode的单点故障, HDFS设计了Secondary NameNode作为NameNode的备份.另外, 随着集群规模的扩大和存储的文件数量的增长, 元数据的大小也随之增加, 单节点的内存难以满足元数据的存储需求, HDFS引入了Federation机制, 允许一个HDFS集群中存在多个NameNode, 每个NameNode分管一部分目录, 彼此独立.集群中负责管理节点数据的是DataNode, 每个DataNode负责节点本地文件系统中数据块的管理, 并定时向NameNode发送心跳, 反馈本节点状态.为提供存储的容错性, 每个数据块都存有一定数量的副本, 用户可以自行设置(默认为3).所有的数据块(图 1中的彩色方块, 相同颜色的方块表示同一数据块及其副本)由NameNode决定存储的位置.
(2) 数据块放置与容错
HDFS中, 默认采用机架敏感(rack awareness)的副本放置策略.如图 1所示, 彩色方块代表数据块, 相同颜色的色块表示同一数据块的副本.在副本数为3的情况下, HDFS的默认副本放置策略将3个副本中的2个放在同一机架(rack)中的两个不同DataNode上, 另外1个副本放置在不同机架的DataNode上.如果HDFS集群跨越多个数据中心, 还可以配置更多的副本数, 并调整副本放置策略, 保证至少1个副本存储在不同的数据中心[11].这样的副本放置策略在容错和写入性能方面进行了有效的权衡:一方面保证了数据副本在多节点、多机架甚至多数据中心的冗余, 提高了系统容错能力; 另一方面, 保证了尽可能多的副本优先写入到网络距离较近的节点(如同一节点、机架或数据中心)中, 由于网络距离较近的节点间网络带宽较高、传输延迟较低, 保证了HDFS Client向HDFS中写入数据块的性能.在进行集群的扩展、负载均衡调整和恢复丢失的数据块时, HDFS会自动根据副本放置策略移动副本的存储位置和为恢复的数据块选择新的存储位置, 并对上层应用透明[10, 11].副本机制基于冗余存储来提供存储的容错, 占用了数倍于原始文件大小的存储空间.为减少对存储空间的占用, HDFS还支持基于纠删码EC的容错机制, 可以在保证同等可靠性的情况下将存储利用率提高近一倍[12, 13].纠删码是在存储空间和计算代价之间的权衡, 通过增加编码和解码的计算代价来提高存储空间的利用率, 适用于冷数据的存储.目前, HDFS在同一集群同时支持副本和纠删码两种容错机制, 用户可以根据应用需求使用.
1.3 HDFS存储系统的特点和挑战依据上文对HDFS的系统架构和数据存储、容错等基本原理的分析, 本节从系统的容错性、扩展性、可移植性和数据读写等方面总结出HDFS存储系统的特点, 并针对当前应用场景的变化和硬件设备的发展分析HDFS存储系统面临的挑战.
HDFS存储系统的特点包括:
(1) 高容错.HDFS在设计之初就针对非高可靠的普通廉价服务器, 充分考虑了集群的容错性, 设计了心跳检测、副本、纠删码和Secondary NameNode等机制.基于这些机制, HDFS能快速发现节点故障, 并迅速恢复, 在软件层提供高容错和高可靠的数据存储服务;
(2) 高可扩展.HDFS拥有良好的可扩展性, 集群可以扩展到数千甚至上万节点的超大规模, 这保证了存储容量的动态扩展, 突破了传统数据库系统和数据存储系统的限制, 适合存储和管理超大规模的数据;
(3) 高可移植性.HDFS用Java语言开发, 屏蔽了底层硬件的细节, 可以兼容不同的硬件设备, 在不同平台上部署;
(4) 多数据模型.HDFS中数据基本的组织结构是文件, 不同类型的数据都可以抽象为文件来存储, 包括文本、关系表、图等.因此, HDFS可以灵活地支持结构化和非结构化等多种类型的数据存储;
(5) 侧重大文件顺序读写.HDFS中, 大量小文件会增加NameNode元数据管理的负担, 并且不能很好地利用磁盘顺序读写的I/O性能, 导致读写吞吐低.过大的文件也会导致数据迁移和恢复的延迟很高.因此, HDFS一开始经验性地选择了64MB作为默认数据块大小, 后来调整为128MB, 适合大文件的存储和高吞吐的数据访问;
(6) 侧重一次写入、多次读取的访问模式.HDFS上的文件一旦被创建和写入完毕后, 便不能更新已经写入的内容, 只能截断或追加写文件.这种设计符合HDFS的设计初衷, 即各类数据存储在HDFS之上, 被不同的应用反复读取, 且每个应用任务都会读取大部分甚至是全部的数据.
HDFS存储系统的特点契合当前大数据存储大容量(volume)、生成快(velocity)和多类型(variety)的需求, 在大数据系统, 尤其是面向分析的大数据系统中得到了广泛的应用.但随着应用场景的日益多样化和硬件设备的飞速发展, HDFS存储系统仍然面临着新的挑战, 这些挑战主要包括:
(1) HDFS不支持数据随机写入和修改.在此前提下, 支持以随机写入为主的Key-Value等NoSQL存储系统具有挑战;
(2) HDFS主要面向高吞吐数据访问优化, 低延迟访问没有足够保障.在此前提下, 支持以数据的低延迟访问为主的交互式分析和迭代计算等具有挑战;
(3) HDFS设计之初是针对传统磁盘优化的, 随着新型硬件设备的发展, 应用新型硬件设备进一步提高HDFS的性能具有挑战;
(4) HDFS上汇聚的数据和支持的应用负载类型多样, 针对不同负载自适应地优化存储性能具有挑战.
1.4 研究框架结合上文对HDFS系统特点和挑战的分析可以看出:HDFS系统在容错性、扩展性和可移植性等方面已经比较成熟, 而数据读写的特点也契合当今大数据分析的需求.因此, 当前对HDFS的研究重点应该是如何在维持自身特点的前提下克服其性能局限, 最大程度地满足不同应用的需求, 提高数据存储和访问的性能.这样在生产系统中无需维护多套存储系统和多份数据, 降低了存储的成本和数据ETL(extract-transform-load)的代价, 也避免了多份数据之间的一致性问题和时效性问题.
而HDFS上数据存储和访问的性能主要受到3个维度的影响, 即逻辑层面数据在文件内部如何组织、物理层面网络和存储设备的特性以及应用层面用户读写数据的方式.因此, 本文从文件逻辑结构、硬件设备和应用场景这3个维度对HDFS上的存储优化技术进行研究和综述(研究框架如图 2所示).
|
Fig. 2 The research framework of storage optimization techniques on HDFS 图 2 HDFS存储和优化技术研究框架 |
(1) 文件逻辑结构维度
文件是HDFS中数据组织的基本形式, HDFS上数据的存储和读取都是围绕文件进行的.因此, 如何基于文件组织数据, 即文件的逻辑结构, 会对HDFS的数据读写性能产生重大影响.目前, 这方面的研究主要围绕文件存储格式、文件压缩方法和数据索引技术这3个方面展开, 借鉴了很多数据库中成熟的优化设计, 如列存储、数据压缩和聚簇索引等.未来, 自适应行列混合存储、可直接查询的数据压缩方法以及基于机器学习模型的索引技术可能会是新的研究突破点.
(2) 硬件设备维度
随着硬件的发展, 除传统磁盘外, 大内存和固态硬盘在企业中的应用越来越多.非易失性内存作为一种新型硬件正受到越来越广泛的关注, 并被认为可能对现有存储架构产生颠覆性的影响.在网络方面, RDMA结合高速网络已经成为许多企业数据中心的标配.HDFS的底层硬件平台正面临着从传统磁盘和低速网络走向异构存储结合高速网络的转变.为适应这种变化, 本文从内存存储、网络传输和外存存储这3个角度分析了现有基于不同硬件的HDFS存储和优化技术.当前研究主要集中在大内存、固态硬盘和RDMA技术在HDFS中的应用上, 针对SMR磁盘和非易失性内存的研究还比较少, 且非易失性内存尚未得到大规模的应用.集成这些新硬件的同时, 未来还需进一步研究异构的存储技术, 数据按需存储在不同类型的存储设备上, 并动态迁移.
(3) 应用场景维度
存储优化技术的根本目的在于服务应用, 提高实际应用场景中数据存储和访问的性能.因此, 从应用场景的角度出发, 更能看出HDFS上已有存储和优化技术取得的成果和存在的不足.该维度主要对HDFS上各类应用的典型I/O特征进行归纳总结, 并分析不同I/O特征下适用的存储和优化技术, 为实际应用和未来研究提供借鉴.当前, HDFS上最大的不足是对以低延迟读取或实时更新为主的应用场景的支持, 需要结合新的存储硬件进一步深入研究.
针对HDFS的存储和优化技术随着硬件技术的发展和应用场景的变化而不断发展.本文从文件逻辑结构的角度综述了各种文件存储格式、压缩方法和索引等优化技术, 再从硬件特性的角度分析了各项优化技术与硬件特性之间的关系以及针对新型硬件的优化技术.最后, 结合对应用场景的分析, 从应用的角度对各种HDFS存储优化技术的出发点和优劣势进行分析总结.3个维度的分析紧密结合, 且大部分在前两个维度中被分析的工作会同时在应用场景的维度上再加以讨论.这样可以更加深入地理解HDFS上的存储和优化技术, 为未来学术界和工业界的研究与开发提供参考.
2 面向文件逻辑结构的HDFS存储和优化技术文件是HDFS中数据管理的基本逻辑单元, 文件的逻辑结构决定了数据在文件内的组织和存储方式, 对数据读写性能有着至关重要的影响.这种影响主要从文件存储格式、文件压缩和数据索引这3个方面体现.其中, 文件存储格式定义了文件内部的数据组织方式, 文件压缩决定了文件的物理存储大小, 数据索引过滤掉不需要读取的文件内容.在实际应用中, 这3个方面的优化技术是相互结合的.例如:在一个查询的执行过程中, 数据索引对文件和文件中的数据块进行过滤, 读取时按照文件格式的定义访问数据, 最终读取到压缩后的数据并解压缩得到结果.
当前, HDFS上流行的文件存储格式包括通用的行存储格式(如TextFile、XML、JSON、CSV、Sequence File、Map File和Avro[14]等)和为关系数据优化的列存储格式(如RCFile[15]、ORC[16]、Parquet[17]和CarbonData[18]等).这些文件存储格式各有所长.行存储中的数据在文件内按行连续存储, 方便流式追加写入和全量扫描, 在PageRank等MapReduce计算任务中应用广泛.随着SQL-on-Hadoop的兴起, 传统的行存储已经无法满足基于关系表的大数据分析的需求.此时, 列存储打开了一扇新的大门.列存储将同列的数据连续存储, 在数据访问时只读取需要的列, 这样就避免了不必要的I/O, 并提高了数据压缩的效果.在行存储和列存储的基础上, 行列混合存储根据查询负载将频繁一起被访问的列聚成列组, 并调整列的物理存储顺序, 进一步降低磁盘访问时的跳读代价, 提升查询性能.
2.1 文件存储格式 2.1.1 行存储行存储, 也即NSM(N-aray storage model)存储模型, 将数据按行在磁盘页(page)上连续存储, 是早期普遍采用的存储模型.HDFS中的Text File、XML、JSON、CSV、Sequence File、Map File和Avro等文件存储格式也都采用行存储的思想.这些格式中, 数据被水平划分为若干个数据块, 每个数据块内按行存储.其中, Text File、XML、JSON和CSV是常见的存储格式.因其格式简单灵活、可读性高, 很多数据类型都基于这几种基本格式存储, 如图数据存储中的GraphSON和GraphML分别基于JSON和XML格式, CSV格式也在数据分析中被经常用来存储表格数据.除这几种常见格式外, Sequence File是针对Map Reduce实现的二进制存储格式, 它将数据按照⟨key, value⟩对的形式序列化到文件中, 并且支持数据块级别的压缩.Map File在Sequence File的基础上对数据按照key排序, 并加入索引, 用于快速查找.Avro文件格式同Sequence File类似, 都是存储的二进制的序列化内容.但Avro文件格式中采用了更加高效的数据序列化技术, 支持多语言的数据读写, 并且在文件中包含数据的schema, 可以自描述.
行存储的优势在于数据可以流式追加写入, 写入的延迟较低, 且格式简单, 易于编写Map Reduce程序进行处理.其缺点在于如果只需要访问行内的一小部分数据, 也需要将整行数据读入内存, 浪费了磁盘I/O.因此, 面向行的存储适合于按行扫描的情况.在上述行存储格式中, Text File、XML、JSON和CSV都是常用的数据存储和交换格式, Sequence File和Map File是针对MapReduce设计的存储格式, Avro是面向复杂对象存储的数据格式.
2.1.2 列存储列存储技术最早在面向分析的数据库系统中广泛应用.早期的关系数据库是面向写优化的, 普遍采用NSM(N-ary storage model)存储模型.直到1985年, Copeland提出了DSM存储模型[19], 将关系表按列划分, 每列单独连续存储.DSM证明了对于分析查询, 列存储能帮助查询获得明显的性能提升.基于这个思想, Stonebreaker等人设计和实现了C-store[20], 对后续研究和应用产生了较大影响.
列存储将同列的数据连续存储, 在数据访问时只读取需要的列, 避免了不必要的I/O, 并提高了数据压缩的效果, 最终提高查询的I/O性能[21].当HDFS上SQL查询分析应用(尤其是SQL-on-Hadoop系统)的分析性能达到瓶颈后, 列存储被很快从数据库中借鉴过来解决数据访问的性能问题.但按照DSM的思想在HDFS上将数据按列单独连续存储为文件或数据块, 会导致各列数据被分散到集群的不同节点上, 在恢复记录时, 需要从不同节点读取多个数据块, 造成额外的网络开销和计算开销, 并且影响计算的并行度.
针对这个问题, HDFS上流行的列存储文件格式RCFile、ORC、Parquet和CarbonData等借鉴了内存存储格式PAX存储模型[22]的思想, 采用了如图 3所示的方式实现列存储[23, 24].数据文件被水平划分为行组(row group), 行组内数据按列连续存储为列块(column chunk).一个列块中存储了行组内一个列上的所有数据项.一个列存储格式文件中包含一个或多个HDFS数据块, 一个数据块中包含一个或多个行组(通常, 一个数据文件只包含一个数据块, 一个数据块只包含一个行组为最优配置[16-18]).这样的列存储格式保证了数据表中所有数据列存储在同一个数据块中, 避免了跨节点的数据连接.在行组内部采用列存储, 仍然可以发挥列存储在I/O和数据压缩方面的优势.同时, 行组作为数据处理的并发单元, 不影响HDFS环境下数据处理的并发度.因此, RCFile、ORC、Parquet和CarbonData等文件格式在工业界得到了广泛应用.
|
Fig. 3 Standard columnar data storage layout on HDFS 图 3 HDFS上的标准列存储布局 |
RCFile是较早的HDFS列存储格式, 一开始应用在Facebook Hive[25]和Yahoo Pig[26]中.它的默认行组大小只有4MB, 一个数据块中包含多个行组.每个行组中有一个元数据区域存储行组中各个列的位置偏移.
RCFile支持对行组中的每列数据分别应用RLE(run-length encoding)编码和Gzip[27]压缩, 并在查询时支持Lazy Decompression, 即压缩的数据在读入内存后不会立即全部被解压, 而是被真正访问时才被解压.这种优化可以利用查询中的过滤条件减少不必要的数据解压, 降低CPU和内存资源的消耗.
ORC在RCFile的基础上进行了大量优化.
● 首先, ORC在行组的元信息中添加了对统计信息和布隆过滤(Bloom filter)等的支持, 并加入了谓词下推(predicate pushdown)的功能, 这些优化对数据过滤起到了很好的效果;
● 其次, ORC支持了字典编码、RLE编码、位压缩(big packing)等多种编码方式, 并且可以根据数据类型和列上的统计信息自动采用不同的压缩编码方式, 提升了数据编码的效果;
● ORC还支持将嵌套数据类型(如Json, Map)分解为数据列存储在二维数据表中[16];
● ORC中还有一个优化的细节增大了默认行组的大小, 将其从RCFile的4MB提高到256MB(Hive中默认为64MB), 这个优化提高了I/O的连续性[23];
● 最后, ORC能支持文件内记录的更新和删除.
Parquet的数据组织方式和ORC类似, 默认采用128MB的行组大小[17], 并且同样支持根据列的数据类型和统计信息对数据进行自动的编码压缩.不同的是, Parquet默认支持的数据模型就是嵌套结构的, 它借鉴了Google Dremel[28]中的嵌套数据分解技术对数据进行编码存储, 从而实现高效的嵌套数据的存储和访问.
CarbonData是2016年开源的一种列存储格式, 并已成为Apache开源项目.CarbonData中除了支持ORC和Parquet中的数据编码压缩和嵌套数据类型之外, 还将列块划分为页面(默认一个页面包含32 000个数据项), 在页面范围内对各个列上的数据分别排序, 大幅提高数据压缩效果.由于页面是较小的存储单元, 各个列上相对应的一组页面在查询执行时可以快速地在内存中进行连接、重建为元组.此外, CarbonData提供了多种索引的支持, 包括倒排索引和多维键值(multi dimensional key, 简称MDK)索引.CarbonData还支持全局字典, 同一个数据表内使用同一个字典对数据进行编码压缩, 这样可以直接在编码后的数据上执行过滤和分组等计算, 仅对最终的查询结果进行解压, 无需对全部数据解压缩.
ORC、Parquet和CarbonData是目前工业界普遍应用的Apache开源列存储格式, 其中, ORC和Parquet开源较早, 发展比较成熟, 在大部分应用场景中都不分伯仲, 且大部分查询引擎, 如Spark SQL[29]、Presto[30]和Hive[25]等都对两种存储格式有很好的支持.CarbonData开源较晚, 相比于ORC和Parquet, 加入了大量索引和复杂数据编码的支持, 更适合对延迟较低的交互式查询的需求, 目前支持Hive、Presto和Spark SQL作为查询引擎, 并结合SparkSQL进行了深度优化.这几种流行的开源列存储格式的对比见表 2.
|
|
Table 2 Comparisons of popular open source columnar storage formats on HDFS 表 2 HDFS上主要的开源列存储格式对比 |
除了以上的开源列存储格式, CIF[34]还提出了一个类似DSM的存储格式, 即:将数据表中各个列分别存储在不同的数据块中, 并通过修改HDFS的数据块放置策略将这些数据块存放在相同的Datanode上.对比RCFile在默认行组大小(4MB)下的性能, CIF有明显的性能提升.但在后来的研究工作中, 文献[23]证明:当HDFS列存储格式中采用了较大的行组之后, I/O连续性得到了明显的提升, 相比之下, CIF没有性能收益.而且改变数据块放置策略需要对HDFS进行修改, 工程实施难度较大, 容易破坏HDFS的容错性和负载均衡.因此, 现有HDFS上的主流存储格式都还是基于PAX的思想.
2.1.3 行列混合存储通用的列存储格式适合大部分分析型负载, 但在一些应用中, 可以根据查询的访问特征进一步优化列存储的内部布局.文献[35, 36]中提出:将频繁一起访问的列聚成列组, 每个列组连续存储, 构成行列混合存储.
文献[36]中采用枚举算法对列的所有组合进行枚举, 从中选出适合当前负载的列组组合, 每个HDFS文件副本都采用不同的列组组合, 在查询执行时, 从中选择读取代价最低的副本读取.并且为降低元组恢复(tuple reconstruction)的代价, 将列组中的数据按行存储.但该方案有3个缺点.
1) 需要修改HDFS的内部设计和实现, 破坏了系统的通用性;
2) 枚举算法的计算复杂度随列个数的增加而呈指数级增长, 只适合列个数较少的场景;
3) 元组恢复的代价在文献[23]中被证实并不是列存储中的主要性能开销, 并且列组中的数据按行存储在C-Store[21]中被证实不如列式存储更优.
列式存储可以避免读取列组中的部分列时的不必要I/O, 另外, 文献[24]也表明, 将列聚成列组的主要优势在于当一个列组中的列被连续访问时减少了磁盘跳读的代价.因此在实际的行列混合存储中, 很少将列组内的数据按行存储.
针对上述问题, 文献[24]提出了基于启发式算法的列排序的方法取代列组组合.相比于列组组合, 列排序在提高HDFS列存储系统数据读取性能的前提下实现起来更加简单, 且无需对现有的HDFS列存储系统作任何修改.通过分析查询负载对数据列的访问记录, 文献[24]将列组的优化问题定义为列的物理存储顺序的排序问题, 并证明该问题为NP-Hard.实验结果表明:列排序技术在宽表(几百上千列)的场景下可以将查询性能提高1倍左右, 比列组组合的效果更好.
2.2 文件压缩技术除了在列存储格式中使用的数据编码算法之外, HDFS上的数据可以采用一些无损压缩算法对文件进行进一步压缩, 如Snappy、LZO、Gzip、bzip2[37]等.数据压缩不仅可以节约存储, 还可以提高数据处理的性能.HDFS环境下的计算任务还可以对计算中间结果压缩后再写入磁盘, 从而大幅度降低了中间结果的大小, 提高了数据处理的性能[38].不同压缩算法之间的对比见表 3.
|
|
Table 3 Comparisons of common compression methods on HDFS 表 3 HDFS中常用压缩算法的对比 |
HDFS中常用的数据压缩算法分为可拆分(splittable)和不可拆分(non-splittable)两类.Snappy具有高压缩速度和较好的压缩率, 它在速度和压缩率之间作了较好的权衡[38].由于Snappy是不可拆分算法, 即压缩后的文件不可拆分, 它需要在一个特定的文件格式(如Parquet, ORC)中使用.LZO和Snappy类似, 比较注重压缩速度.不同的是, LZO压缩后的文件是可拆分的, 因此相对于Snappy, LZO更适合用作一个独立的压缩格式来对HDFS上的文本格式的文件进行压缩.Gzip提供了较高的压缩性能, 平均达到Snappy的2.5倍, 但其写入性能不如Snappy.在读性能方面, Gzip和Snappy接近.Gzip同样是不可拆分算法, 因此也需要嵌入在一个文件格式中使用.在部分情况下, Gzip的压缩效果太好, 导致压缩出的数据很小、数据块数很少, 所以在执行数据处理任务时的并行度可能会偏低, 从而导致数据处理的速度反而降低[38].这个问题可以通过使用较小的数据块来避免.bzip2提供了非常好的压缩性能, 但是其解压性能较差, 通常只用于存储空间非常有限的情况.
2.3 数据索引技术索引能够帮助查询快速定位要读取的数据, 对于降低查询执行的延迟非常关键.但对于分布式的环境和海量的数据, 传统数据库中的索引技术很难全都直接应用在HDFS上.目前, HDFS上普遍采用的索引技术包括聚簇存储、Bitmap和统计信息等, 这些索引占用很小的存储空间, 且维护简单.
Hive中支持将数据表根据一个或多个属性进行分桶(bucket), 如对数据按照生成日期的年、月、日划分, 查询部分日期的数据可以直接利用Bucket过滤掉不相关的数据, 相当于按照数据生成日期建立聚簇索引[39].此外, Hive还支持利用Bitmap索引对数据进行过滤[39].
HAIL[40, 41]提出在HDFS上利用数据块多副本, 在每个副本上按照不同的属性对数据排序、建立聚簇索引, 从而利用多副本容错机制支持多个不同的聚簇存储, 在查询时, 根据查询条件选择合适的聚簇存储.这种方案利用了多副本机制来建立多个聚簇索引, 可以应对不同的查询需求, 但索引建立的开销也增加了, 并且需要对HDFS的内部设计和实现进行较大的改动, 在实际应用中并不提倡.针对建立索引影响数据落地实时性的问题, 文献[41]中提出了Lazy Indexing的方法, 即:数据写入时不建立索引, 而是在查询读取数据的同时动态建立索引, 并在查询执行完成后将索引刷写到HDFS上.这种方式牺牲了数据首次查询的性能, 换取了数据落地的实时性.
CarbonData[18]是HDFS上的新型列存储格式.CarbonData中除了采用页面内数据按主键排序以提高压缩效果之外, 还支持多维主键上的聚簇索引(CarbonData中的MDK, 即multi dimension keys), 即多个维度的数据拼接成主键.与HAIL中的数据块内聚簇不同, CarbonData采用数据段(segment)粒度的聚簇索引.向数据表中加载一次数据即形成一个数据段, CarbonData对一个数据段内的数据按照主键排序后存储到HDFS中, 并将各个数据块中的统计信息集中存储在元数据中.这样, 在查询时可以通过集中存储的元数据快速进行数据块过滤、命中相关的数据块和块内数据页.但是数据段粒度的聚簇索引会对数据导入的性能有一定的影响.
文献[42, 43]提出在聚簇索引的基础上, 还可以在数据块内采用非聚簇索引, 支持其他属性上的元组过滤.文献[43]中还提出了基于动态一致性哈希实现数据的高吞吐实时划分、索引和入库.文献[44]提出在ORC的基础上增加冗余的数据列支持聚簇索引, 通过少量的存储空间开销实现索引属性上数据的快速查找.除显式的索引外, ORC、Parquet、CarbonData等列存储格式在元数据中记录各个行组上的统计信息, 查询可以根据统计信息过滤掉不相关的行组, 这种Data Skipping方式可以看作是一种隐式索引.文献[42]中提出了一种细粒度的Data Skipping技术, 通过提取历史查询中的数据过滤条件, 将数据元组和过滤条件建立映射, 为每个数据元组建立特征向量, 并根据特征向量对元组进行聚集.这种方法可以将查询中被频繁共同访问的元组聚集到同一个数据块中, 从而使得查询可以直接命中相关数据块, 避免读取不必要的数据.实验结果表明, 该方法在查询性能上比基于范围聚簇的数据块组织方式高2~5倍.但这种方法在大规模的数据集上建立特征向量的时间开销太大, 且针对历史查询的优化改变了数据的聚集方式, 可能会给新出现的查询带来负面影响.
2.4 小结本节从文件存储格式、文件压缩方法和数据索引技术这3个方面介绍了面向文件逻辑结构的HDFS存储和优化技术.目前, 基于行存储的文件格式最多、适应面最广, 涵盖了文本、关系表、图结构等多种数据类型, 已经发展成熟, 后续优化空间不大.面向关系表的列存储研究较多, 且取得了很好的成果.ORC、Parquet和CarbonData等几种常见的存储格式都得到了广泛应用, 给查询带来了很大的性能提升.行列混合存储会是未来面向关系表的存储格式的主要发展方向, 这方面目前研究较少, 其中, 结合应用负载的自适应优化仍是一个难题.文件压缩技术基本上是直接应用已有的成熟算法, 没有大的改进和突破, 但为了减少反序列化的开销和内存占用, 可直接查询的编码和压缩技术在HDFS上的应用值得探讨, 如succinct数据结构[45]等.数据索引技术当前的趋势主要是文件内部的数据索引和全局数据字典等, CarbonData中引入了数据库中常用的聚簇和倒排等索引技术, 未来可以探索更多数据库中索引技术在HDFS上的应用.另外, Kraska等人提出learned index structure[46]利用机器学习技术对数据建模替代传统索引, 可以进一步在HDFS上进行尝试.
3 面向硬件设备的HDFS存储和优化技术硬件是存储系统的基础, 不同硬件具有不同的特性, 需要不同的优化技术最大化地利用这些特性来提高HDFS的性能.本节从外存存储、内存存储和网络传输这3个层级, 分析不同硬件设备的特点和基于这些硬件设备的存储及优化技术.
3.1 外存存储HDFS在设计之初是将传统磁盘作为主要存储介质.然而随着存储硬件的发展, SMR磁盘和固态硬盘已经被广泛应用, HDFS也开始集成多种不同的外存设备.本节介绍针对HDFS中不同外存设备的典型优化技术(见表 4).
|
|
Table 4 Storage and optimization techniques for HDFS based on external storage devices 表 4 基于外存存储设备的HDFS存储和优化技术 |
3.1.1 传统磁盘
传统磁盘依赖于磁盘自身的旋转和磁头在磁盘上的移动来读写数据, 随机读写时需要频繁进行磁盘寻道, 磁头在磁盘上来回移动, 读写的性能差.因此, 传统磁盘更适合顺序读写的操作.HDFS的设计最初建立在传统磁盘上, 对HDFS的存储优化都是从减少磁盘I/O和提高磁盘I/O效率两个方面进行的.
缓存机制在减少磁盘I/O方面有很好的效果, HDFS及其上的计算框架和查询引擎都设计了不同的缓存机制(在第3.2节给出详细讨论).另外, 第2节中讨论的列存储、数据压缩和数据索引都是减少磁盘I/O的常用方法.列存储可以避免读取不必要的数据列, 数据块内部可以利用统计信息和索引进行过滤, 并利用对数据的高效编码和压缩效果来减少数据分析时的磁盘I/O[21, 22].
在优化磁盘I/O效率方面, 因为磁盘的随机跳读代价高, 所以主要是减少磁盘的随机I/O, 提高I/O连续性.第2节中讨论的自适应列存储通过分析查询负载和数据列的访问特征, 将被频繁一起访问的列在物理上相近地存储, 提高了列存储的I/O连续性.另外, HDFS支持将数据块均衡地存储在本地的多个数据目录下[47], 每个目录可以挂载一块单独的磁盘, 从而支持单机多磁盘的并行读写, 提高数据读写的总带宽和吞吐量.但HDFS没有对磁盘上的读写操作进行细粒度的调度.由于磁盘是串行I/O设备, 随机读写性能差, 在大规模并行计算中可能发生大量读取进程或线程对磁盘的过度争用.因此, 文献[48]提出在Datanode中为每一块本地磁盘启动一个服务线程, 负责该磁盘上的读写操作, 从而将磁盘上并发的读写变成串行的读写, 减少磁盘随机跳转(seek)和磁盘调度的开销.但这种方式对HDFS系统的侵入较大, 并未得到普遍采用, 主要还是在应用层将大量小的随机读写尽可能合并为大的顺序读写.LSM-Tree(log-structured merge-tree)[49]便是采用这种思想的典型存储结构.LSM- Tree在磁盘上采用Copy-on-Write的策略, 将对文件上的随机写操作变为顺序的追加写入, 之后再通过批量合并操作(合并操作本身也是顺序读写文件)消除数据冗余, 极大地提高了数据的写入吞吐量.这种结构在Key-Value数据库中的应用十分广泛, BigTable[50]和HBase[51]中也利用LSM-Tree优化数据的写入.除了随机的小I/O之外, HDFS上可能存储了很多小文件, 这些小文件降低了I/O的连续性, 且增加了NameNode元数据管理的负担, 因此, HDFS中提供了file archive[52]的功能自动合并小文件.
3.1.2 SMR磁盘SMR(shingled magnetic recording)磁盘是一种基于传统磁盘的存储密度更高的硬件, 它对传统磁盘的结构进行了一个巧妙的调整, 将磁盘的相邻磁道互相重叠来获得更高的存储密度[53].这种设计在提高磁盘容量的同时, 使得在一个磁道上的写入会覆盖相邻磁道的数据.因此, SMR磁盘上随机的数据写入会带来严重的写放大问题[54].SMR磁盘在提高存储容量、降低单位存储价格的同时牺牲了随机写入的性能, 适合批量顺序写入而随机更新很少的应用场景[55], 如企业的历史数据存储.现有的基于SMR磁盘的存储和优化技术主要包括两个方面:一是将SMR磁盘应用到HDFS中, 二是进一步优化基于SMR磁盘的读写性能.
在SMR磁盘的应用方面, 随着Hadoop集群存储数据量的不断增加, 海量数据堆积在HDFS集群中, 其中大部分是很少被访问的历史数据.为了降低历史数据存储的成本, Hadoop引入了Archival Storage[8]功能.该功能使得上层应用可以通过制定存储策略, 将访问频次很低或不再被访问的文件存储在存储密度高、价格低廉的Archive类型的存储设备上.SMR磁盘就是一种非常适合HDFS中Archive类型的存储设备, 在HDFS中使用它能够减少历史数据对优质存储资源的占用, 降低储存成本.
在针对SMR磁盘的优化方面, 文献[56]针对SMR磁盘实现了SMR设备仿真器和对SMR感知的本地文件系统ShingledFS.它优化了文件系统的写I/O来最大程度地发挥顺序写的性能, 并提出了适应SMR磁盘特点的垃圾回收算法.ShingledFS是基于FUSE实现的对叠瓦式磁盘感知的文件系统, 可以应用到HDFS集群中.但该工作主要是验证SMR磁盘可以有效支持大数据负载, 在Hadoop集群中作为高容量低成本的存储设备, 并未对垃圾回收算法等进行深入研究, 不能应用于对性能要求很高的场景.为进一步优化基于SMR磁盘的数据读写性能, ManyLogs[57]针对叠瓦式磁盘随机写性能差的特点, 提出一种新的文件系统的日志记录方法, 将许多小的随机日志写入转变为顺序写入.文献[58]提出基于磁盘内缓存和新的存储单元S-block的方式优化随机写入.文献[59]提出了适合叠瓦式磁盘的STL(shingled translation layer)和GC(garbage collection)方法.这些优化有助于提高基于叠瓦式磁盘的文件系统的读写性能, 使叠瓦式磁盘可以更好地应用在HDFS中.
3.1.3 固态硬盘随着固态硬盘(solid state disk, 简称SSD)容量的增加和成本的降低, 越来越多的企业选用固态硬盘作为存储设备来加速数据访问.现代的固态硬盘一般由Flash阵列(flash memory array)持久化存储数据, DRAM芯片配合Flash阵列缓存数据, 并且内部还有一个作为控制器的处理芯片实现了接口协议和地址转换(flash translation layer, 简称FTL)等功能[60, 61].相比于磁盘, SSD不依赖于磁头的机械运动来读写数据, 拥有更高的带宽和IOPS.
除了磁盘以外, HDFS可以兼容包括固态硬盘和DRAM在内的不同类型的存储设备, 形成异构存储[6].其中, DataNode可以将本地存储设备的类型和使用情况暴露给NameNode, 这样, NameNode可以动态感知每个节点的存储类型.上层应用可以为存储的文件指定存储类型的偏好, 如将文件优先存储在固态硬盘上, 还可以设置存储策略, 将一个或者所有副本存储在固态硬盘上.这样, 上层应用可以利用固态硬盘存储一个副本作为磁盘的缓存或者存储所有副本来加速数据的读写.
除了HDFS的内置支持外, Hadoop生态系统中常用的分布式缓存系统Alluxio[62]也支持将固态硬盘作为层级化存储(内存、固态硬盘和磁盘这3种层级)的一部分.Alluxio可以根据用户指定的策略将数据存储在合适的层级中.固态硬盘作为内存和磁盘之间的缓存, 使得Alluxio可以在突破内存容量限制的同时, 减少磁盘I/O带来的性能损失.对于频繁访问的较大的数据, 应用也可以指定将它们缓存在固态硬盘中, 提高Spark等上层应用的数据访问效率[63].
另外, hats[64]修改了HDFS原有的数据放置策略, 将固态硬盘作为磁盘的上层存储, 数据的副本存储到不同层级中.修改后, 文件先在SSD中存储, 再复制到磁盘中, 读取时则优先从最上层读取.这种放置策略提高了数据写入的性能, 但会造成数据访问的不均衡.类似地, Triple-H[65]提出基于HPC(high performance computing)集群的HDFS文件放置策略, 以利用高性能节点的内存和固态硬盘.hats和Triple-H都是将文件的多个副本放置不同层级的存储设备中, 没有结合文件的访问特征和设备底层的I/O特性进行动态优化, 难以充分发挥固态硬盘的性能优势.文献[66]和Venu[67]根据应用负载的访问特征预测未来的热点数据, 自动地将“热”的数据存储到固态硬盘中, 将“冷”的数据迁移到磁盘中.
为了进一步优化固态硬盘在HDFS中的使用, 文献[68, 69]发现, 配置高速网络可以进一步发挥固态硬盘在HDFS中的性能优势.基于传统磁盘的HDFS集群在并发读写较高的时候性能会急剧下降[45], 而固态硬盘在并发读写较高的情况下会获得更好的性能[68].文献[70]提出基于Linux异步I/O的精确预读取模型, 更好地利用固态硬盘的I/O性能, 能够带来18%的性能提升.
除了作为比传统磁盘更高效的存储设备, 固态硬盘还可以作为计算设备, 即, 利用SSD控制器中嵌入的低能耗处理器对本地数据进行简单计算(in-storage computing, 简称ISC).ISC的思想是移动计算使之更加靠近数据, 这种方式能提高计算性能和降低数据移动带来的能量消耗.Samsung提出了Smart SSD模型[71], 将CPU处理器和DRAM存储包装到SSD中, 使得该SSD设备可以运行自定义的用户程序.文献[61]将SQL Server中关系查询的一些操作下推到SSD中执行, 大幅度提高了查询的执行性能和降低了能量消耗.文献[72]利用固态硬盘的计算能力实现了适应ISC的MapReduce框架, 将Mapper任务下推到固态硬盘中执行, 这种设计给MapReduce带来了2.3倍的性能提升, 并大幅降低了计算的能源消耗.
不同于传统磁盘, 固态硬盘的数据块的擦除次数是有限制的, 普通固态硬盘的擦除次数在3000~5000之间[73].为了尽可能延长HDFS中固态硬盘的使用寿命, 文献[70]修改了NameNode中的数据块放置策略, 在放置数据块时尽量平衡DataNode节点上固态硬盘的使用.
3.2 内存存储HDFS通常将数据块存储在磁盘文件系统中.由于磁盘的带宽和IOPS都较低, 在大规模数据处理中通常利用内存缓冲(buffer)来将随机读写转换为顺序读写, 以及利用内存缓存(in-memory cache)来弥补CPU和磁盘之间的速度差异.另外, 非易失内存的出现也为HDFS的优化提供了新的方向.表 5列出了典型的基于内存存储的HDFS存储和优化技术.
|
|
Table 5 Storage and optimization techniques for HDFS based on memory storage 表 5 基于内存存储的HDFS存储和优化技术 |
3.2.1 内存缓冲和缓存
HDFS上的Key-Value存储将内存作为数据的读写缓冲, 将随机读写转化为顺序读写.HBase作为BigTable的开源实现, 采用LSM-Tree来解决磁盘IOPS低、随机写入延迟大的问题.LSM-Tree将数据在内存和磁盘上分层存储, 内存中缓存最近写入和修改的数据, 然后批量写出到磁盘或固态硬盘.这种方式提高了写吞吐, 但数据查询时需要对多层数据的查找结果进行汇总才能得到最终结果.为了保证数据查询的性能和控制写放大, LSM- Tree对内存和磁盘上的数据进行批量归并(merge), 从而在读写性能之间做出比较好的权衡.
除了利于加速数据写入外, 内存更主要的是缓存文件来加速应用的数据访问性能.HDFS从2.3.0版本开始增加了集中式缓存管理(centralized cache management, 简称CCM)功能[7].这是HDFS自身提供的一种显式缓存机制, 允许用户指定HDFS中的一个存储路径并将其中的文件缓存在内存中.对于要缓存的文件, Namenode通知存储该文件数据块的Datanode将数据块缓存在进程JVM的堆外内存中.堆外内存不受Java虚拟机垃圾回收机制的管理, 避免了额外的垃圾回收开销.在集中式缓存管理功能出现之前, HDFS依靠Datanode本地操作系统的Page Cache来进行文件内容的缓存.操作系统Page Cache不掌握文件系统上层应用的数据访问模式, 只根据规则进行简单的预读和缓存置换[74, 75].因此, 需频繁访问的文件页面很容易因为其他文件上的大量顺序读操作而被驱逐出Page Cache, 不仅导致缓存命中率低, 而且导致大量不必要的页面置换, 浪费了I/O和计算资源.另外, 由于Page Cache在操作系统内核空间中, 当Datanode进程读取Page Cache中的内容时, 需要进行一次内存复制, 将Page Cache中的页面复制到JVM的进程空间中.对于频繁访问数据的迭代计算, 内存复制消耗大量的CPU机器周期, 影响计算性能.
相对于操作系统的Page Cache, 集中式缓存管理可以发挥分布式内存的优势.缓存由Namenode统一管理, 同一数据块的副本只有部分会被缓存, 避免多个副本都被读入操作系统Page Cache, 浪费内存空间.数据访问时, HDFS上的应用可以查询到被缓存的数据块的位置, 并将任务调度到缓存所在的节点上, 提高数据访问的性能.另外, 集中式缓存管理还实现了内存的零复制(zero-copy), 降低了内存复制带来的CPU周期消耗.但HDFS的集中式缓存管理目前仅支持文件和目录级别的缓存, 不支持数据块或用户自定义的缓存粒度, 当文件较大而应用仅需访问文件中的部分数据时, 缓存的效果并不明显, 且被缓存的文件需要应用程序在运行时指定, 不能根据查询负载动态选择.
除了HDFS内置的集中式缓存管理外, Tachyon[76]及其后续版本Alluxio[62]也为HDFS上的应用提供了通用的分布式缓存管理, 缓存的数据可以被不同应用共享.Tachyon/Alluxio提供与HDFS兼容的文件访问接口, 采用Lineage机制来支持数据快速写入和容错.计算任务将数据转换的结果写入一个新的文件, 一系列计算过程中输出的文件就构成了Lineage Graph.发生错误时, 通过检查点和重计算来进行恢复.相对于基于副本的容错技术, 基于Lineage的容错不需要在节点之间通过网络进行副本复制, 实验结果表明:Lineage的数据写入速度比内存文件系统上的HDFS还高110倍[76], 从而保证了分布式缓存的写入性能.Alluxio也支持磁盘、SSD、内存多级存储, 默认根据LRU策略将内存中的数据淘汰到外存.另外, 应用程序可以指定数据存储的介质, 将频繁访问的数据缓存在SSD或内存中[62].
除了通用的文件缓存外, Apache Arrow[77]提供了针对列存储的内存缓存, 支持不同系统之间共享数据, 减少数据在不同系统之间移动的序列化和反序列化开销.此外, HDFS上的一些计算框架和查询引擎也根据自身需要设计了专用的分布式内存管理机制.RDD(resilient distributed datasets)[78]是Spark中的分布式内存数据结构, 分为若干个Partition, 分布式地存储在集群各个节点上, 用于加速Spark中的迭代和交互式计算.每个RDD都是静态的(immutable), 对RDD的转换操作都将产生新的RDD.HDFS上的文件可以作为RDD的数据输入和数据输出, Spark计算的中间结果则以RDD的形式存储在内存中.RDD的容错主要依赖于Lineage机制和计算过程中的检查点(checkpoint).尽管创建RDD需要进行大量的内存复制, RDD的访问性能仍然远高于存储在磁盘上的HDFS文件.加之RDD与HDFS一样支持容错, 而且Spark采用Lazy Execution[29], 仅在数据转换操作执行时才动态创建RDD, 一定程度上避免了不必要的内存开销, 因此在大规模的迭代和交互式计算中具有很大的优势.
Flink[79]面向有状态的流处理, 采用DataStream和DataSet作为抽象的内存数据结构.两种抽象数据结构在Flink运行环境中都通过Dataflow Graph实现, 即:将一系列数据转换操作形成流水线, 数据一边产生一边被消费, 提高了内存利用率, 缓解了因为内存不足而向磁盘刷写中间结果导致的存储性能下降问题.与Spark中的RDD不同, Flink中的DataFlow并不是静态的, 因此不需要进行频繁的内存复制.另外, Flink采用异步Snapshot作为容错的方式[80], 平衡了同步Snapshot导致的全局阻塞和Lineage机制的重新计算.类似HDFS的集中式缓存管理, Flink运行环境将Dataflow中的数据序列化后存储在JVM堆外的内存段(memory segments)中, 减少了JVM垃圾回收造成的开销.Flink还支持直接在不反序列化的堆外内存段数据上执行排序和连接操作, 降低了数据反序列化造成的额外开销.
HDFS环境下的其他大数据分析引擎, 如Presto、Impala、Drill[81]也采用基于内存的流水线式数据缓冲区, 将计算任务编译成有向无环图(DAG), 在内存中不断产生和消费数据.这种方式避免了计算中间结果落地HDFS, 缓解磁盘性能瓶颈, 为HDFS上的交互式数据分析提供了支持.此外, ElasticSearch[82]中也利用内存缓存和索引数据, 提供实时的数据检索.
3.2.2 非易失性内存非易失内存(nonvolatile memory, 简称NVM)作为一种新型存储受到了广泛的关注, 它主要包括自旋矩传输磁存储器(spin-torque transfer RAM, 简称STT-RAM)、相变存储器(phase-change memory, 简称PCM)和电阻式存储器(resistive random access memory, 简称RRAM)等具有非易失性特点的存储设备[83], 可以类似DRAM一样按字节寻址(byte-addressability), 又不会在断电后丢失数据, 因此被认为是一种具有广泛应用前景的新型存储[84].目前, 市场上最新的非易失性内存产品是Intel的Optane Apache Pass内存条, 该内存条基于3D Xpoint技术, 单条最大容量为512GB.NVM有着比磁盘和固态硬盘更高的读写性能, 同时还能持久化地存储数据, 因此, 最近几年开始出现将NVM集成到HDFS中的研究工作.
文献[85]提出了NVFS(NVM- and RDMA-aware HDFS), 它基于现有的HDFS, 加入了对NVM和RDMA的支持.NVFS中NVM提供两种访问模式:块访问和内存访问, 分别对应NVFS-BlkIO和NVFS-MemIO接口.块访问模式下, NVM可以作为块设备被加载到DataNode的本地文件系统中, 文件系统的I/O操作调用NVMe接口通过底层的NVMe驱动实现.内存访问模式下, DataNode的读写线程可以通过NVM的直接内存访问接口(direct memory interface)按照内存语义(memory semantics)访问NVM.客户端的DataStreamer和Responder分别基于RDMA发送数据和接收响应消息, DataNode端的RDMA Receiver会接收网络中的数据, 数据的读写通过NVFS- BlkIO或NVFS-MemIO接口进行.针对上层应用, NVFS也作了一些优化, 如HBase中持久化HFile和日志文件的延迟比较高, 影响Put操作的性能, NVFS中将WAL日志存储在NVM中, 其他数据存储在SSD中.
整体而言, 当前对NVM的研究还处于起步阶段, 且由于缺乏大规模量产的NVM存储设备, 当前的研究主要基于NVM模拟器进行, 一定程度上阻碍了相关研究的进行.未来, 随着NVM设备的大规模应用, NVM能为HDFS带来巨大的性能提升.但如何让NVM以HDFS可感知的方式集成进来, 以及如何针对NVM设计有效的数据放置策略, 这些仍需要进一步加以研究.
3.3 网络传输HDFS作为一个分布式的存储系统, 数据读取和写入过程中都可以涉及网络传输.对网络传输的优化也是HDFS优化的一个重要部分.
3.3.1 本地I/O和并行复制HDFS支持短路本地读取(short-circuit local reads)[86].当HDFS Client在Datanode上读取本地数据块时, 可以通过短路本地读取来直接读取本地磁盘上的数据, 避免通过TCP套接字读取数据.这样节省了数据从磁盘读入Datanode进程空间, 然后复制到TCP发送缓冲区, 再通过TCP协议栈发送到Client进程空间的过程, 对于提高I/O性能有一定的帮助.在HDFS数据写入时, 数据块需要复制到集群中的其他节点作为副本, 文献[87]将HDFS中默认的流水线的复制方式改为并行复制来优化数据块的复制, 即DFSClient负责将副本并行复制到所有节点, 提高写数据时数据复制的性能.
3.3.2 RDMAInfiniBand[88]是一种通用的高速连接网络, 实现了RDMA(remote direct memory access)技术, 在企业中被广泛使用.RDMA允许一个进程直接读取远端进程的内存数据, 远端进程不需要参与数据传输的过程, 只需要指定内存读写地址, 开启传输即可, 这个特性极大地降低了网络传输的延迟和传输中的CPU占用, 同时减少了应用态和内核态之间的内存复制以及CPU的上下文切换.基于RDMA的网络连接, HDFS的随机和顺序写性能能够在传统磁盘上分别提高30%和100%;配合固态硬盘使用时, 性能提高更为明显[71].可以预见地, RDMA将成为数据中心的标准网络连接技术.
为了优化HDFS中的数据传输, 文献[89]设计和实现了基于RDMA的HDFS.
● 首先, 在HDFS的客户端和DataNode实现中修改了数据传输相关的类, 添加了对RDMA的支持.这些类通过底层的JNI接口利用InfiniBand网络进行通信, JNI接口中封装了轻量级、高性能的C语言通信库UCR(unified communication runtime)[90], 为网络通信提供运行时环境.修改后的HDFS降低了节点间数据传输的延迟, 尤其是写数据块时数据复制的网络延迟, 实验结果表明, 可以将HBase的Put性能提高26%;
● 其次, 在DFSClient和DataNode中加入了Connection的概念, 每个Connection对象都会维护一个预分配的缓冲区, 用来避免JNI和UCR之间的数据复制.
除了数据传输外, 消息通信也是Hadoop中网络通信的一大开销, 对此, 文献[91]实现了基于RDMA的Hadoop RPC框架——RPCoIB, 提高Hadoop中RPC的性能达到50%.
HDFS中, 数据写入是I/O密集型的操作, 也是主要的性能瓶颈之一.HDFS数据块的写入分为4个步骤.
● 从网络中读取数据到Java的I/O流中;
● 处理读取到的数据;
● 复制数据到副本中;
● 写数据到本地磁盘.
默认地, HDFS写入时每个数据块由一个线程负责, 每个线程按步骤顺序执行, 这样每次网络中的数据分片都需要等待上一个分片写入磁盘后才能被读取和处理.在基于RDMA的HDFS中, 这个问题更加明显, 因为写入的性能瓶颈从网络传输变为了本地磁盘的持久化.为了解决这个问题, 文献[92]提出在基于RDMA的HDFS中利用SEDA(staged event-driven architecture)架构[93], 为每个步骤分配一个队列, 将单线程的顺序执行变为多步骤的并发执行.
3.4 小结HDFS一开始就是面向传统磁盘设计和实现的, 基于传统磁盘的优化和应用已经趋于成熟.但高密度、低成本的SMR磁盘为HDFS引入了新的研究挑战, 且目前相关研究还有较多不足, 包括设计高效利用SMR磁盘特性的文件系统以及选择合适的数据放入SMR磁盘中.固态硬盘在HDFS之外的研究工作很多, 且在Key-Value数据存储等场景中应用十分成熟, 但出于成本考虑, 目前在HDFS集群中并未普遍采用固态硬盘替换传统磁盘, 而是作为磁盘的辅助存储设备.这就带来了新的挑战, 即, 固态硬盘和磁盘如何协同使用以及数据如何在固态硬盘和磁盘之间动态迁移.大内存和RDMA技术在现代的数据中心中应用十分广泛, 大幅提高了数据读取和网络传输的性能.NVM是未来的研究热点, 目前受制于NVM设备的研发, 尚未有成熟的应用, 已有的研究工作主要关注如何设计文件系统在HDFS中集成NVM设备, 而未对HDFS的存储性能作深入优化.
未来, HDFS集群必然是构建在高速RDMA网络和各类存储设备之上的异构集群, 如何在异构体系结构平台上构建一个高效的分布式异构存储方案, 包括对不同设备I/O性能的感知、文件及副本的放置策略、数据在设备间的动态迁移等, 还有很大的研究空间, 且这些研究工作涉及对HDFS较大的改动, 需要与开源社区紧密合作, 才能真正在产业界产生影响.
4 面向应用场景的HDFS存储和优化技术在当今大数据的环境下, HDFS作为通用的分布式存储系统, 汇集了关系、文本、图结构等各种各样的海量数据, 并向上支撑了丰富的应用场景.本节总结HDFS存储系统的主要应用场景, 并分析和概括不同应用场景下典型的HDFS存储及优化技术(见表 6).
|
|
Table 6 Typical storage and optimization techniques of HDFS tailored for different applications 表 6 不同应用负载的HDFS存储和优化技术 |
4.1 应用场景
(1) 数据汇聚存储
在国内, 电信运营商在日常运营中积累了大量用户数据, 包括用户真实、详细的个人基本信息、通话者的地理位置信息和通话信息等, 这些每天TB级别增长的业务数据汇聚存储在HDFS中, 用于支撑上层用户偏好分析、网络流量优化等各种分析应用[94].相比电信运营商, 互联网企业对HDFS的应用更为广泛.百度一度是国内Hadoop的最大使用者之一, 拥有的Hadoop集群节点总数超过万台, 存储了爬取的网页数据、用户日志数据和广告数据等[95].阿里巴巴基于Hadoop研制了云梯(cloud ladder)系统, 利用HDFS存储面向分析的淘宝用户数据和交易信息等[96].在国外, Amazon、Facebook、Twitter、Yahoo!和Hulu等互联网公司基于HDFS汇聚用户行为等业务数据, 为用户提供精准的分析.其中, Twitter基于HDFS存储和分析用户发布的动态、日志文件和中间数据, 集群规模超过万台, 存储了超过300PB的数据[97].
在这些应用中, HDFS存储的数据多种多样, 既有结构化的数据, 也有非结构化的数据; 既有最新的热点数据, 也有压缩存储的历史数据.在数据的汇聚存储过程中, 预处理是一个普遍的需求.相比于传统数据库的ETL (extract, transform, load), HDFS的数据导入性能更高.Hive和Sqoop[98]利用MapReduce将数据库中的数据导入HDFS上.此外, Spark Streaming可以对流式数据进行ETL操作, 然后持久化到HDFS中.
(2) 复杂查询分析
基于HDFS的SQL和类SQL分析系统, 如Pig、Hive、Presto、Impala、Spark SQL、HAWQ[99]、Kylin[100]等支持对海量数据的复杂查询分析.这一类系统将数据表以数据文件和数据块的形式存储在HDFS中, 由HDFS负责数据存储的负载均衡、容错和提供数据的高吞吐读写, 利用大规模集群的并行计算能力对海量的结构化数据进行批量的分析, 提供数据报表和决策支持.这类应用读取的数据量较大, 要求底层存储系统有较高吞吐的数据读取能力.
(3) Ad-hoc查询和交互式分析
Ad-hoc查询和交互式分析是数据分析过程中常用的方式.例如, 数据分析师通过对移动应用中用户行为数据的分析来洞悉应用设计和产品逻辑的缺点, 改善应用可用性和产品功能.在这个过程中, 分析师往往需要结合数据可视化的技术, 对数据进行多轮交互式的查询.交互中的查询大多是ac-hoc的, 分析师会根据上一轮交互的结果临时生成, 或在数据集中随机探索.这类应用要求查询执行的延迟较低, 能够快速生成可视化的结果, 并且查询的多样性较高.Apache Drill和ElasticSearch等都可以支持这类应用, 并在查询执行时要求底层存储系统提供低延迟的数据访问[101, 102].
(4) 详单查询
HDFS上存储了海量的数据, 很多应用中需要根据精确的查询条件对海量数据进行查询.例如, 电信运营商需要对流量和通话记录等进行精细化分析, 针对网络日志中的某IP地址查询某段时间的被访问记录, 或从通话记录中查询某号码的通话记录等[43].在这类应用中, 查询实际需要访问的数据量很小, 要求很低的数据读取延迟.因此, 为避免全表扫描, 数据过滤机制的设计非常重要.
(5) Key-Value存储和查询
Key-Value存储提供基于键值的低延迟、高吞吐的数据CRUD操作.BigTable提出了在GFS上构建分布式Key-Value存储的系统实现方法.作为BigTable的开源实现, HBase在HDFS上构建了分布式Key-Value存储. Facebook基于HBase支持Messages和社交网络中用户信息等数据的存储和分析[103].由于HDFS不支持数据的随机写操作, HBase将写入和修改的数据缓存在内存中, 批量地与HDFS上的数据文件进行合并.
(6) 流计算
在移动网络、物联网等应用中, 大量数据会实时生成.在从不同数据源实时收集这些数据的同时, 对这些数据进行流式处理和计算也十分重要.证券行业中, 证券交易监管机构需要对实时发生的证券交易进行监控, 并发现其中的违法违规行为.在线游戏平台和视频播放平台实时分析用户的访问延时, 改善用户的游戏和视频观看体验.地图应用实时记录用户的地理位置数据, 更新用户的行为轨迹.
HDFS上的流计算引擎, 如Spark Streaming[104]、Flink等为了降低计算延迟, 仅将HDFS作为流计算中数据的落地存储, 或将HDFS中的文件作为数据源, 通过流式的计算模型进行处理.而流计算的中间结果则通过内存数据结构进行管理.分布式消息队列系统, 如Kafka[105]也支持在落地HDFS之前对消息进行流式的处理.
(7) 迭代计算
在HDFS存储的海量数据上, 机器学习和图计算等迭代计算的需求非常旺盛.腾讯广点通利用Spark内存计算和快速迭代的优势, 支持其广告推荐算法的实时训练和系统的实时预测.淘宝利用GraphX[106]对用户图数据进行分析, 发现用户社区.优酷利用Spark实现在线视频的推荐和广告投放.
HDFS上的图计算引擎, 如Hama[107]、GraphX等, 机器学习框架, 如Mahout[108]、MLlib[109]等, 均基于HDFS支持大规模的迭代计算.由于HDFS本身不支持随机低延迟的数据读写, 因此, HDFS上的迭代计算应用通常需要额外设计消息传输机制和基于内存的数据结构.
本小节总结了HDFS常见的应用, 这些应用与HDFS之间有丰富的数据读写交互.在对这些交互行为进行分析后, 本文将它们背后的I/O特征归纳分类为高吞吐读取、低延迟读取、批量写入和实时更新这4种模式.其中, 复杂查询分析的I/O模式主要为高吞吐读取, Ad-hoc查询和交互式分析、详单查询、Key-value查询、流处理和计算和迭代式计算主要为低延迟读取, 数据汇聚存储主要是批量写入, Key-value存储主要为实时更新.不同的I/O模式需要应用不同的HDFS存储和优化技术.
4.2 高吞吐读取高吞吐读取是HDFS的看家本领, 也是HDFS上最为常见的数据访问模式.HDFS本身的设计就是为了优化高吞吐的并行数据读取和计算.但随着基于HDFS的SQL查询分析系统, 如Hive、Presto、Impala、Spark SQL等的广泛应用, 针对批量查询分析的存储优化技术也不断出现和发展.
从文件逻辑结构的维度看, 由于复杂查询分析中大部分查询通常只访问数据表中的部分属性, 列式数据存储成为目前通用的存储方案.列存储可以支持仅读取需要列的数据, 并且拥有比行存储更好的数据压缩效果, 节省磁盘I/O.行列混合存储根据查询负载中的数据访问特征进一步优化列存储的物理布局, 如将一些被频繁访问的列的组合在物理上存储在一起, 可以有效减少数据读取时的跳读代价.列存储和行列混合存储中, 数据压缩和索引是常用的减少数据读取I/O的方法, 结合文件存储格式, 能有效提高查询效率.
从硬件设备的维度看, 随着大内存的普及, 基于Alluxio的内存文件缓存和分析引擎内部的数据缓存机制等都能充分利用大内存的优势, 加速复杂查询的执行.在存储介质方面, RDMA可以降低大量数据网络传输时的CPU消耗, 以及减少用户态和内核态之间的数据复制, 提高集群中的网络效率.
以基于Presto的复杂SQL查询为例, HDFS上的关系表存储为许多列存储文件, 这些文件经过压缩, 并在元数据中记录统计信息作为索引.HDFS可以根据历史查询的访问特征对列存储文件的物理布局进行自适应优化.并且, 基于大内存的硬件平台, Presto可以利用Alluxio进行数据缓存, 避免每次查询都从磁盘读取大量数据.远程读取数据和执行的查询任务还可以利用RDMA降低数据传输的延迟.
4.3 低延迟读取低延迟读取是HDFS的弱项.但HDFS集群构建成本低, 提供了良好的扩展性、容错性和高的可用性, 汇聚了海量的各类数据.其中, 对很多数据的访问要求HDFS提供低延迟的读取.
利用大内存、固态硬盘、非易失性内存和RDMA等硬件加速是降低数据读取延迟的主要方法.HDFS支持集中式缓存管理, 可以将指定的文件缓存到节点的内存中.查询引擎一般也利用内部的内存管理机制加速数据的访问, 如Spark中的RDD.此外, 还可配合通用的分布式内存管理系统Alluixio一起使用, 将不同应用频繁访问的数据自动缓存在内存中.随着固态硬盘容量的增加和成本的降低, 固态硬盘的使用更加普遍.相比于磁盘, 固态硬盘拥有更好的读写性能, 适合低延迟的应用场景.非易失性内存能够基于字节访问数据, 提供优于固态硬盘的数据访问性能, 同时还能持久化地存储数据, 非常适合低延迟读取的访问负载.当需要远程读取数据时, 网络延迟也是数据读取延迟的重要组成部分.RDMA可以在InfiniBand的基础上, 允许一个进程直接读取远端进程的内存数据, 而远端进程不需要参与数据传输的过程, 只需要指定内存读写地址, 开启传输即可.
在磁盘上, 列存储和行列混合存储结合索引技术可以帮助快速定位要读取的数据的位置, 也有助于降低查询的I/O延迟.ORC、Parquet、CarbonData等列存储格式在元数据中记录各个行组上的统计信息, 查询可以根据统计信息过滤掉不相关的行组.ORC中还支持bitmap索引, 记录列中的数据是否为空值.另外, CarbonData支持建立多维聚簇索引.在Key-Value查询时, LSM-Tree本身也是一种索引结构, 可以降低查询的延时.
以交互式分析为例, 应用程序利用Alluxio和查询引擎的内置缓存机制将聚合的中间结果缓存在内存中, 还可以将部分数据持久化到非易失内存上减少对磁盘的访问.磁盘上, 数据按列存储, 并建立多种索引机制, 加速数据从磁盘读取到内存.另外, 节点间的网络通信利用RDMA技术加速.
4.4 批量写入HDFS作为文件系统, 相对于传统的数据库系统, 其本身具有很好的数据批量写入性能.在数据写入过程中, 数据块需要复制到集群中的其他节点, 此时, 并发复制和RDMA技术都可以加速这个过程.另外, 文献[43]和文献[110]针对日志数据, 设计和实现了高效的并发数据写入的流水线, 可以提高数据加载的性能, 并允许应用访问正在加载中的数据.如今, 数据分析越来越注重时效性, 数据快速批量入库的需求越来越强烈, 而目前相关的研究和系统实现还较少.
随着批量写入的数据量的不断增加, 存储的代价也越来越高.一方面, 数据压缩能够减少实际存储的数据大小; 另一方面, 能支持更高密度、更廉价存储的SMR磁盘受到大家的青睐.尽管由于其底层的叠瓦式设计, SMR在随机更新时会有很高的写放大, 但是在顺序写入时能保证高的写入性能, 非常适合作为冷数据的存储设备.另外, 冗余副本容错机制也是导致存储数据量变大的原因之一, HDFS中引入的纠删码EC机制可以在保证同等可靠性的情况下, 将存储利用率提高近1倍.
4.5 实时更新HDFS在数据写入方面的一个主要限制是只支持数据的追加式写入, 而实时更新则要求对数据内容进行毫秒级延迟的更新操作, 并支持较高的事务吞吐量.显然, 在HDFS的文件系统上直接更新数据无法满足性能要求.目前, HDFS上的数据更新技术主要基于LSM-tree的思想, 数据更新先记录在内存中, 然后批量地写入文件系统.典型的系统实现是实现Key-value模型的HBase.此外, HDFS上的列存储格式, 如ORC和CarbonData, 也支持对数据进行低延迟的更新, 其实现原理与LSM-Tree类似.但由于列存储本身并不适合数据更新操作, 所以更新操作的吞吐量很低, 通常只有每秒几次至几十次.LSM-Tree的思想是将数据更新操作暂存在内存中, 对内存消耗较大, 大内存可以将更多的数据缓存在内存中, 同时, 固态硬盘和非易失性内存可以提供远优于磁盘的随机访问性能, 结合这些可以更好地发挥LSM-tree的优势.另外, RDMA可以降低节点间网络传输的延迟, 有助于提高数据更新的性能.
4.6 小结本节从高吞吐读取、低延迟读取、批量写入和实时更新这4种I/O模式分析了HDFS上常见的应用, 及其对应的典型存储和优化技术.在很多实际场景中, 同一个HDFS集群上往往运行着多种类型的应用程序, 如同时存在需要高吞吐读取的复杂SQL查询和需要低延迟读取的图查询和KV查询, 并且还有大量数据在不断批量写入.未来的HDFS存储更可能作为一个存储的基础设施, 上层应用按照不同的抽象数据模型管理和分析数据.例如:数据以文本形式被批量装载到HDFS上, 然后被抽取为关系表和图进行查询分析; 同时, 作为机器学习模型训练的输入, 机器学习和查询分析的中间结果以KV的形式存储, 以供未来使用.在对这种多样化应用的支持上, 目前HDFS还有很多不足:首先, HDFS不能很好地针对不同数据的访问特征进行定制化的优化; 其次, 由于主要依赖磁盘读写数据, HDFS在面向低延迟的数据访问上还有很大不足; 最后, HDFS不支持文件随机更新, 在实时更新方面存在很大的应用限制.这些问题还需要通过结合新的存储硬件进一步深入研究来加以解决.
5 总结及未来研究方向本文从文件逻辑结构、硬件设备和应用场景这3个维度对现有的HDFS存储和优化技术进行了分析和总结.目前, HDFS作为通用的分布式文件系统, 强调高可扩展和低成本地提供高可靠的海量数据存储, 保证副本的强一致, 高吞吐地落地快速生成的数据, 以及基于文件存储多样化的数据, 包括结构化数据和文档、图等半结构化和非结构化的数据.HDFS的这些特点契合了大数据的大容量、生成快和多类型的特性, 未来更可能作为大数据存储和分析的基础设施, 支持多模型和多应用的数据存储.另外, 随着异构体系结构的大数据平台在工业界逐渐成为常态, 新型的硬件设备也开始迅速在企业中得到推广和应用, HDFS的底层硬件平台也将从传统磁盘和低速网络走向异构存储和高速网络连接.在HDFS未来的发展方向上, 目前的研究工作虽然已经取得了一定的进展, 但仍然存在很多问题值得深入探讨和研究.本节总结了未来研究可能的挑战和机遇.
1)基于异构平台的数据存储
从硬件平台来看, 存储设备的发展十分迅速.HDFS的设计初衷是基于通用的廉价硬件提供可靠、高吞吐的数据存储和访问.但随着硬件的发展, 传统的磁盘性能和存储容量都已经达到瓶颈, 新的硬件, 如固态硬盘、非易失性内存和SMR磁盘等受到广泛关注.目前, HDFS已有的功能和研究着重于将不同硬件集成到HDFS中, 但还没有很好的机制让HDFS能够智能感知不同设备的I/O特性, 并根据数据的访问特征动态改变数据的存储方式, 在异构的环境下最大程度地发挥各类硬件的性能优势.这里面临的挑战主要包括:设计HDFS对设备I/O性能的感知机制; 结合设备I/O特点和应用需求动态放置和迁移文件及其副本; 新硬件在集成时还需要针对硬件特点进一步优化, 如叠瓦式磁盘的随机写放大、固态硬盘的寿命问题等.
2)面向应用负载的自适应存储优化
从上层应用来看:
● 一方面, 在大数据Hadoop生态系统不断发展的过程中, HDFS因其自身的稳定可靠、简单易用、扩展性高等优点, 使得越来越多的上层应用和系统将其作为统一的底层存储.HDFS成为了事实上的“数据中心”, 其上存储的数据类型和支持的分析负载越来越多元化;
● 另一方面, 在企业中, 不同部门和用户经常基于同一份全量数据进行查询分析, 如不同用户分别在Presto和Hive上查询同一份关系数据, 导致同一份数据服务多样的查询负载.在这种应用场景下, 基于人工制定策略的存储优化难以生效, 需要研究根据应用负载的自适应优化技术, 如行列混合存储中根据应用负载自动优化列的物理存储顺序[24].
自适应优化技术在传统数据库中早有研究[111], 为HDFS上研究的开展提供了很好的借鉴.从20世纪90年代开始, 用于决策支持的分析型数据库快速发展.相对于事务型数据库, 分析型数据库中的查询通常更为复杂, 查询优化技术也相对复杂, 导致分析型数据库难以完全依靠人工调优[111].在索引选择、物化视图、数据划分等偏向存储方面的自适应优化变得非常关键.在自适应索引选择[112, 113]、查询计划优化[114]、数据存储格式优化[115]等方面出现了很多相关的研究工作.
3)结合机器学习的存储优化技术
由于数据存储优化问题复杂度非常高, 早期的存储优化主要基于固定的规则和策略.随着大规模机器学习的发展, 一些研究工作也尝试将深度学习等技术用于解决数据存储和查询执行的优化问题[46, 116-118].HDFS上的应用类型复杂多样, 硬件平台也趋于多样化, 对于HDFS上的存储优化问题, 数据库优化的思想具有很好的借鉴意义, 包括利用RNN模型对查询负载建模和预测[116]、利用神经网络构建数据索引[46]、利用强化学习解决复杂优化问题[119]等.
| [1] |
Karun AK, Chitharanjan K. A review on hadoop-HDFS infrastructure extensions. In:Proc. of the 2013 IEEE Conf. on Information & Communication Technologies. IEEE, 2013, 132-137.
http://www.wanfangdata.com.cn/details/detail.do?_type=perio&id=CC0214658464 |
| [2] |
Du XY, Lu W, Zhang F. History, present, and future of big data management systems. Ruan Jian Xue Bao/Journal of Software, 2019, 30(1): 127-141(in Chinese with English abstract).
http://www.jos.org.cn/1000-9825/5644.htm [doi:10.13328/j.cnki.jos.005644] |
| [3] |
Cafarella M, Cutting D. Building Nutch:Open source search. Queue, 2004, 2(2): 54.
[doi:10.1145/988392.988408] |
| [4] |
Sanjay G, Howard G, Shun-Tak L. The Google file system. In:Proc. of the SOSP, 2003, 29-43.
http://cn.bing.com/academic/profile?id=0066d49192ab21652c267150501ff724&encoded=0&v=paper_preview&mkt=zh-cn |
| [5] |
Dean J, Ghemawat S. MapReduce:Simplified data processing on large clusters. Communications of the ACM, 2008, 51(1): 107-13.
http://d.old.wanfangdata.com.cn/Periodical/rjxb201201003 |
| [6] |
Hortonworks. Heterogeneous storages in HDFS. https://zh.hortonworks.com/blog/heterogeneous-storages-hdfs/
|
| [7] |
Apache Hadoop. Centralized cache management in HDFS. http://hadoop.apache.org/docs/r2.3.0/hadoop-project-dist/hadoop-hdfs/CentralizedCacheManagement.html
|
| [8] |
Apache Hadoop. Archival storage, SSD & memory. https://hadoop.apache.org/docs/r2.6.0/hadoop-project-dist/hadoop-hdfs/ArchivalStorage.html
|
| [9] |
Apache Hadoop. Erasure coding. https://hadoop.apache.org/docs/r3.0.0/hadoop-project-dist/hadoop-hdfs/HDFSErasureCoding.html
|
| [10] |
Konstantin S, Hairong K, Sanjay R, Robert C. The Hadoop distributed file system. In:Proc. of the MSST, 2010, 1-10.
http://d.old.wanfangdata.com.cn/OAPaper/oai_doaj-articles_08f3afdcf505a41eff75054c54573444 |
| [11] |
White T. Hadoop:The Definitive Guide. 4th ed., O'Reilly Media, Inc, 2015.
http://d.old.wanfangdata.com.cn/Periodical/jsjyjyfz2012z1004 |
| [12] |
Hakim W, John K. Erasure coding vs. replication:A quantitative comparison. In:Proc. of the IPTPS Workshop, 2001, 328-338.
http://d.old.wanfangdata.com.cn/NSTLQK/NSTL_QKJJ0216931351/ |
| [13] |
Xia MY, Mohit S, Mario B, David AP. A tale of two erasure codes in HDFS. In:Proc. of the FAST, 2015, 213-226.
http://cn.bing.com/academic/profile?id=86daefdda523d789d56f1150954cb083&encoded=0&v=paper_preview&mkt=zh-cn |
| [14] |
Apache Avro. Avro official site. https://avro.apache.org/
|
| [15] |
He YQ, Lee RB, Huai Y, Shao Z, Jain N, Zhang XD, Xu ZW. RCFile:A fast and space-efficient data placement structure in MapReduce-based warehouse systems. In:Proc. of the ICDE, 2011, 1199-1208.
http://d.old.wanfangdata.com.cn/Periodical/jsjkx201504014 |
| [16] |
Apache ORC. ORC official site. https://orc.apache.org/
|
| [17] |
Apache Parquet. Parquet official site. http://carbondata.apache.org/
|
| [18] |
Apache CarbonData. CarbonData official site. http://carbondata.apache.org/
|
| [19] |
Copeland GP, Khoshafian SN. A decomposition storage model. ACM SIGMOD Record, 1985, 14(4): 268-279.
[doi:10.1145/971699.318923] |
| [20] |
Stonebraker M, Abadi DJ, Batkin A, Chen X, Cherniack M, Ferreira M, Lau E, Lin A, Madden S, O'Neil E, O'Neil P. C-store:A column-oriented DBMS. In:Proc. of the 31st Int'l Conf. on Very Large Data Bases. VLDB Endowment, 2005, 553-564.
http://d.old.wanfangdata.com.cn/Periodical/xbnyxb200706058 |
| [21] |
Abadi J D, Madden RS, Hachem N. Column-stores vs. row-stores:How different are they really? In:Proc. of the SIGMOD, 2008, 967-980.
http://d.old.wanfangdata.com.cn/NSTLHY/NSTL_HYCC0211594996/ |
| [22] |
Ailamaki A, DeWitt DJ, Hill MD, Skounakis M. Weaving relations for cache performance. In:Proc. of the VLDB, Vol. 1, 2001, 169-180.
http://www.wanfangdata.com.cn/details/detail.do?_type=perio&id=CC027175227 |
| [23] |
Huai Y, Ma SY, Lee RB, O'Malley O, Zhang XD. Understanding insights into the basic structure and essential issues of table placement methods in clusters. In:Proc. of the VLDB, 2013, 1750-1761.
http://www.wanfangdata.com.cn/details/detail.do?_type=perio&id=CC0214593606 |
| [24] |
Bian HQ, Yan Y, Tao WB, Chen JL, Chen YG, Du XY, Moscibroda T. Wide table layout optimization based on column ordering and duplication. In:Proc. of the SIGMOD, 2017, 299-314.
https://www.researchgate.net/publication/310953040_Big_Wide_Table_Layout_Optimization_based_on_Column_Ordering_and_Duplication |
| [25] |
Thusoo A, Sarma JS, Jain N, Shao Z, Chakka P, Anthony S, Liu H, Wyckoff P, Murthy R. Hive:A warehousing solution over a map-reduce framework. Proc. of the VLDB Endowment, 2009, 2(2): 1626-1629.
[doi:10.14778/1687553.1687609] |
| [26] |
Apache Pig. Pig official site. https://pig.apache.org/
|
| [27] |
GZip. GZip official site. http://www.gzip.org/
|
| [28] |
Melnik S, Gubarev A, Long JJ, Romer G, Shivakumar S, Tolton M, Vassilakis T. Dremel:Interactive analysis of Web-scale datasets. In:Proc. of the VLDB, 2010, 330-339.
http://d.old.wanfangdata.com.cn/NSTLQK/NSTL_QKJJ0211423928/ |
| [29] |
Armbrust M, Xin SR, Lian C, Huai Y, Liu D, Bradley KJ, Meng XR, Kaftan T, Franklin JM, Ghodsi A, Zaharia M. Spark SQL:Relational data processing in spark. In:Proc. of the SIGMOD, 2015, 1383-1394.
http://d.old.wanfangdata.com.cn/Periodical/jsjyjyfz201802003 |
| [30] |
Facebook. Presto official site. https://prestodb.io/
|
| [31] |
Apache Impala. Impala official site. https://impala.apache.org/
|
| [32] |
Google. Snappy official site. https://google.github.io/snappy/
|
| [33] |
Oberhumer. LZO official site. https://www.lzop.org/
|
| [34] |
Floratou A, Patel JM, Shekita EJ, Tata S. Column-oriented storage techniques for MapReduce. In:Proc. of the VLDB, 2011, 419-429.
http://d.old.wanfangdata.com.cn/OAPaper/oai_arXiv.org_1105.4252 |
| [35] |
Guo SJ, Xiong J, Wang WP, Lee RB. Mastiff:A mapreduce-based system for time-based big data analytics. In:Proc. of the CLUSTER, 2012, 72-80.
http://d.old.wanfangdata.com.cn/Periodical/jq200512009 |
| [36] |
Alekh J, Jorge-Arnulfo Q, Dittrich J. Trojan data layouts:Right shoes for a running elephant. In:Proc. of the SOCC, 2011, 21.
http://cn.bing.com/academic/profile?id=d3565730a3350ccf2b7b3ee38afb639e&encoded=0&v=paper_preview&mkt=zh-cn |
| [37] |
BZip. BZip2 official site. http://www.bzip.org/
|
| [38] |
Shapira G, Seidman J, Malaska T, Grover M. Hadoop Application Architectures. O'Reilly Media, Inc, 2015.
http://d.old.wanfangdata.com.cn/Periodical/jcjx201603008 |
| [39] |
Apache. Hive language manual. https://cwiki.apache.org/confluence/display/Hive/LanguageManual
|
| [40] |
Dittrich J, Quiané-Ruiz JA, Richter S, Schuh S, Jindal A, Schad J. Only aggressive elephants are fast elephants. In:Proc. of the VLDB, 2012, 1591-1602.
http://d.old.wanfangdata.com.cn/NSTLHY/NSTL_HYCC0214080714/ |
| [41] |
Richter S, Quiané-Ruiz JA, Schuh S, Dittrich J. Towards zero-overhead adaptive indexing in hadoop. arXiv Preprint arXiv: 1212. 3480, 2012. https://www.researchgate.net/publication/233917692_Towards_Zero-Overhead_Adaptive_Indexing_in_Hadoop
|
| [42] |
He L, Chen JC, Du XY. Multi-layered index for HDFS-based systems. Ruan Jian Xue Bao/Journal of Software, 2017, 28(3): 502-513(in Chinese with English abstract).
http://www.jos.org.cn/1000-9825/5161.htm [doi:10.13328/j.cnki.jos.005161] |
| [43] |
Bian HQ, Chen YG, Qin XP, Du XY. A fast data ingestion and indexing scheme for real-time log analytics. In:Proc. of the APWeb, 2015, 841-852.
https://link.springer.com/chapter/10.1007/978-3-319-25255-1_69 |
| [44] |
Zhao LP. DuBAI:Duplication-based indexes for HDFS columnar storage[MS. Thesis]. Beijing: Renmin University of China, 2017.
|
| [45] |
Agarwal R, Khandelwal A, Stoica I. Succinct:Enabling queries on compressed data. In:Proc. of the USENIX NSDI, 2015, 337-350.
http://d.old.wanfangdata.com.cn/Periodical/tynxb200808013 |
| [46] |
Kraska T, Beutel A, Chi EH, Dean J, Polyzotis N. The case for learned index structures. In:Proc. of the 2018 Int'l Conf. on Management of Data, 2018, 489-504.
http://cn.bing.com/academic/profile?id=a080193816ca62559ef6568244d14a26&encoded=0&v=paper_preview&mkt=zh-cn |
| [47] |
Apache Hadoop. HDFS disk balancer. https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HDFSDiskbalancer.html
|
| [48] |
Shafer J, Rixner S, Cox AL. The Hadoop distributed filesystem:Balancing portability and performance. In:Proc. of the ISPASS, 2010, 122-133.
|
| [49] |
O'Neil P, Cheng E, Gawlick D, O'Neil E. The log-structured merge-tree (LSM-tree). Acta Informatica, 1996, 33(4): 351-385.
[doi:10.1007/s002360050048] |
| [50] |
Chang F, Dean J, Ghemawat S, Hsieh WC, Wallach DA, Burrows M, Gruber RE. Bigtable:A distributed storage system for structured data. ACM Trans. on Computer Systems (TOCS), 2008, 26(2): 4.
http://d.old.wanfangdata.com.cn/Periodical/jsjgcysj201005061 |
| [51] |
Apache. HBase official site. http://hbase.apache.org/
|
| [52] |
White T. Small files problem. https://blog.cloudera.com/blog/2009/02/the-small-files-problem/
|
| [53] |
Tim F, Gibson G. Shingled magnetic recording:Areal density increase requires new data management. ACM Trans. on Storage, 2013, 38(3): 22.
http://cn.bing.com/academic/profile?id=22d8d1f4042810a0b410e3345aacb7bc&encoded=0&v=paper_preview&mkt=zh-cn |
| [54] |
Abutalib A, Shafaei M, Desnoyers P. Skylight-A window on shingled disk operation. In:Proc. of the TOS, 2015, 16.
http://www.wanfangdata.com.cn/details/detail.do?_type=perio&id=d354833ffc1d4944a0dbd89b2866f8c5 |
| [55] |
Amer A, Long DD, Miller EL, Paris JF, Schwarz ST. Design issues for a shingled write disk system. In:Proc. of the MSST, 2010, 1-12.
https://www.researchgate.net/publication/228716521_Design_Issues_for_a_Shingled_Write_Disk_System |
| [56] |
Anand S, Gibson G, Ganger G. Shingled magnetic recording for big data applications. Carnegie Mellon University Parallel Data Laboratory Technical Report, 2012.
|
| [57] |
Patana-anake T, Martin V, Sandler N, Wu C, Gunawi HS. Manylogs:Improved CMR/SMR disk bandwidth and faster durability with scattered logs. In:Proc. of the MSST, 2016, 1-16.
https://ieeexplore.ieee.org/document/7897075 |
| [58] |
Cassuto Y, Sanvido MA, Guyot C, Hall DR, Bandic ZZ. Indirection systems for shingled-recording disk drives. In:Proc. of the MSST, 2010, 1-14.
http://www.wanfangdata.com.cn/details/detail.do?_type=perio&id=CC0211169605 |
| [59] |
He WP, Du DHC. SMaRT:An approach to shingled magnetic recording translation. In:Proc. of the FAST, 2017, 121-134.
http://d.old.wanfangdata.com.cn/Periodical/jsjyjyfz201607004 |
| [60] |
Wikipedia. Solid-state drive. https://en.wikipedia.org/wiki/Solid-state_drive
|
| [61] |
Do J, Kee YS, Patel JM, Park C, Park K, DeWitt DJ. Query processing on smart SSDs:Opportunities and challenges. In:Proc. of the 2013 ACM SIGMOD Int'l Conf. on Management of Data. ACM Press, 2013, 1221-1230.
https://www.researchgate.net/publication/262161617_Query_processing_on_smart_SSDs_Opportunities_and_challenges |
| [62] |
Alluxio Inc. Accelerating On-demand Data Analytics with Alluxio. While Paper, 2016.
|
| [63] |
Alluxio. Effective spark RDDs with Alluxio. https://www.alluxio.com/blog/effective-spark-rdds-with-alluxio
|
| [64] |
Krish KR, Anwar A, Butt AR. hats:A heterogeneity-aware tiered storage for Hadoop. In:Proc. of the CCGrid, 2014, 502-511.
http://d.old.wanfangdata.com.cn/Periodical/zgfazz201304007 |
| [65] |
Islam NS, Lu X, Wasi-ur-Rahman M, Shankar D, Panda DK. Triple-H:A hybrid approach to accelerate HDFS on HPC clusters with heterogeneous storage architecture. In:Proc. of the CCGrid, 2015, 101-110.
http://d.old.wanfangdata.com.cn/Periodical/zgnxgbzz200908001 |
| [66] |
Subramanyam R. HDFS heterogeneous storage resource management based on data temperature. In:Proc. of the 2015 Int'l Conf. on Cloud and Autonomic Computing (ICCAC). IEEE, 2015, 232-235.
http://cn.bing.com/academic/profile?id=03488f8e5ead3731af6422afe9b17c7b&encoded=0&v=paper_preview&mkt=zh-cn |
| [67] |
Krish KR, Iqbal MS, Butt AR. Venu:Orchestrating SSDS in Hadoop storage. In:Proc. of the 2014 IEEE Int'l Conf. on Big Data (big data). IEEE, 2014, 207-212.
http://d.old.wanfangdata.com.cn/NSTLQK/NSTL_QKJJ0225429981/ |
| [68] |
Sangwhan M, Lee J, Kee YS. Introducing ssds to the hadoop mapreduce framework. In:Proc. of the CLOUD, 2014, 272-279.
http://www.wanfangdata.com.cn/details/detail.do?_type=perio&id=CC0214628942 |
| [69] |
Sur S, Wang H, Huang J, Ouyang X, Panda DK. Can high-performance Interconnects benefit Hadoop distributed file system. In:Proc. of the MASVDC Workshop, 2010.
http://d.old.wanfangdata.com.cn/NSTLHY/NSTL_HYCC0213694040/ |
| [70] |
Hong J, Li L, Han C, Jin B, Yang Q, Yang Z. Optimizing Hadoop framework for solid state drives. In:Proc. of the Big Data, 2016, 9-17.
http://www.wanfangdata.com.cn/details/detail.do?_type=perio&id=059cd52db1812bc07347b1d8e02ee813 |
| [71] |
Kang Y, Kee YS, Miller EL, Park C. Enabling cost-effective data processing with smart SSD. In:Proc. of the 29th IEEE Symp. on Mass Storage Systems and Technologies (MSST). IEEE, 2013, 1-12.
|
| [72] |
Dongchul P, Wang JG, Kee YS. In-storage computing for Hadoop MapReduce framework: Challenges and possibilities. IEEE Trans. on Computers, 2016, PP(99): 1-1.
|
| [73] |
Colgrove J, Davis JD, Hayes J, Miller EL, Sandvig C, Sears R, Wang F. Purity:Building fast, highly-available enterprise Flash storage from commodity components. In:Proc. of the SIGMOD, 2015, 1683-1694.
http://d.old.wanfangdata.com.cn/Periodical/kjwh201216055 |
| [74] |
McCabe C, Wang A. New in CDH 5.1: HDFS read caching. http://blog.cloudera.com/blog/2014/08/new-in-cdh-5-1-hdfs-readcaching
|
| [75] |
Mauerer W. Professional Linux Kernel Architecture. Wrox, 2008.
http://cn.bing.com/academic/profile?id=842bc2a6ec33d8671021824e79829006&encoded=0&v=paper_preview&mkt=zh-cn |
| [76] |
Li H, Ghodsi A, Zaharia M, Shenker S, Stoica I. Tachyon:Reliable, memory speed storage for cluster computing frameworks. In:Proc. of the SOCC, 2014, 1-15.
http://d.old.wanfangdata.com.cn/OAPaper/oai_arXiv.org_1310.8003 |
| [77] |
Apache Arrow. Apache arrow official site. https://arrow.apache.org
|
| [78] |
Zaharia M, Chowdhury M, Das T, Dave A, Ma J, McCauley M, Stoica I. Resilient distributed datasets:A fault-tolerant abstraction for in-memory cluster computing. In:Proc. of the NSDI, 2012, 2.
http://cn.bing.com/academic/profile?id=5a4abbc12ecc6657cacf42da1c92f4b0&encoded=0&v=paper_preview&mkt=zh-cn |
| [79] |
Carbone P, Katsifodimos A, Ewen S, Markl V, Haridi S, Tzoumas K. Apache flink:Stream and batch processing in a single engine. Bulletin of the IEEE Computer Society Technical Committee on Data Engineering, 2015, 36(4).
|
| [80] |
Carbone P, Fóra G, Ewen S, Haridi S, Tzoumas K. Lightweight asynchronous snapshots for distributed dataflows. arXiv Preprint arXiv:, 1506, 08603.
http://www.wanfangdata.com.cn/details/detail.do?_type=perio&id=Arxiv000001298774 |
| [81] |
Apache Drill. Apache drill official site. https://drill.apache.org
|
| [82] |
Gupta P, Nair S. Survey paper on elasticsearch. Int'l Journal of Science and Research, 2016, 5(1): 333-336.
|
| [83] |
Shu J, Lu Y, Zhang J, Zheng W. Research progress on non-volatile memory based storage system. Science & Technology Review, 2016, 32: 019(in Chinese with English abstract).
http://www.wanfangdata.com.cn/details/detail.do?_type=perio&id=kjdb201614014 |
| [84] |
Pelley S, Wenisch TF, Gold BT, Bridge B. Storage management in the NVRAM era. In:Proc. of the VLDB, 2013, 121-132.
http://www.wanfangdata.com.cn/details/detail.do?_type=perio&id=CC0215026160 |
| [85] |
Islam NS, Wasi-ur-Rahman M, Lu XY, Panda DK. High performance design for HDFS with byte-addressability of NVM and RDMA. In:Proc. of the Int'l Conf. on Supercomputing, 2016, 8-21.
http://cn.bing.com/academic/profile?id=12b88dd59f833ebb46696a7fb971c4a8&encoded=0&v=paper_preview&mkt=zh-cn |
| [86] |
Apache Hadoop. HDFS short-circuit local reads. https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/ShortCircuitLocalReads.html
|
| [87] |
Islam NS, Lu XY, Wasi-ur-Rahman M, Panda DK. Can parallel replication benefit hadoop distributed file system for high performance interconnects? In:Proc. of the HOTI, 2013, 75-78.
https://www.researchgate.net/publication/271494430_Can_Parallel_Replication_Benefit_Hadoop_Distributed_File_System_for_High_Performance_Interconnects |
| [88] |
InfiniBand. InfiniBand official website. http://www.infinibandta.org
|
| [89] |
Islam NS, Rahman MW, Jose J, Rajachandrasekar R, Wang H, Subramoni H, Panda DK. High performance RDMA-based design of HDFS over InfiniBand. In:Proc. of the Int'l Conf. on High Performance Computing, Networking, Storage and Analysis, 2012, 35-46.
http://cn.bing.com/academic/profile?id=6e17319b07dcc3ce74e7f6e3c7bb47e4&encoded=0&v=paper_preview&mkt=zh-cn |
| [90] |
Jose J, Luo M, Sur S, Panda DK. Unifying UPC and MPI runtimes:Experience with MVAPICH. In:Proc. of the 4th Conf. on Partitioned Global Address Space Programming Model, 2010, 5.
http://cn.bing.com/academic/profile?id=f0dfd7a2de87ac3f3f0a92f3c6bba924&encoded=0&v=paper_preview&mkt=zh-cn |
| [91] |
Lu XY, Islam NS, Wasi-Ur-Rahman M, Jose J, Subramoni H, Wang H, Panda DK. High-performance design of Hadoop RPC with RDMA over InfiniBand. In:Proc. of the ICPP, 2013, 641-650.
http://www.wanfangdata.com.cn/details/detail.do?_type=perio&id=CC0214361367 |
| [92] |
Islam NS, Lu XY, Rahman MWU, Panda DK. SOR-HDFS:A SEDA-based approach to maximize overlapping in RDMA-enhanced HDFS. In:Proc. of the Int'l Symp. on High-Performance Parallel and Distributed Computing, 2014, 261-264.
|
| [93] |
Matt W, Culler D, Brewer E. SEDA:An architecture for well-conditioned, scalable internet services. In:Proc. of the SIGOPS, 2001, 230-243.
http://d.old.wanfangdata.com.cn/Periodical/bjhkhtdxxb200803020 |
| [94] |
Yu F. Case analysis on telecom Carriers' application of big data. Proc. of the Systems & Solutions, 2014, 8(6): 63-69, 83(in Chinese with English abstract).
http://d.old.wanfangdata.com.cn/Periodical/xxtxjs201406014 |
| [95] |
Xia JB, Wei ZK, Fu K, Chen Z. Review of research and application on Hadoop in cloud computing. Proc. of the Computer Science, 2016, 43(11): 6-11(in Chinese with English abstract).
[doi:10.11896/j.issn.1002-137X.2016.11.002] |
| [96] |
Guo MJ. Research on big data and cloud computing platform applications. Proc. of the Modern Science & Technology of Telecommunications, 2014, 44(8): 7-11(in Chinese with English abstract).
[doi:10.3969/j.issn.1002-5316.2014.08.002] |
| [97] |
Twitter. Hadoop filesystem at Twitter. https://blog.twitter.com/engineering/en_us/a/2015/hadoop-filesystem-at-twitter.html
|
| [98] |
Apache Sqoop. Sqoop official site. https://sqoop.apache.org
|
| [99] |
Chang L, Wang ZW, Ma T, Jian LR, Ma LL, Goldshuv A, Lonergan L, Cohen J, Sherry G, Bhandarkar M. HAWQ:A massively parallel processing SQL engine in Hadoop. In:Proc. of the SIGMOD, 2014, 1223-1234.
http://d.old.wanfangdata.com.cn/Periodical/rjhjcdl201708048 |
| [100] |
Ranawade VS, Navale S, Dhamal A. Online analytical processing on Hadoop using apache skylin. Int'l Journal of Applied Information Systems, 2017, 12(2): 1-5.
|
| [101] |
Hausenblas M, Nadeau J. Apache Drill:Interactive ad-hoc analysis at scale. Big Data, 2013, 1(2): 100-104.
[doi:10.1089/big.2013.0011] |
| [102] |
Elasticsearch BV. Elasticsearch-Hadoop: Best of two worlds for real-time analysis. https://www.elastic.co/products/hadoop
|
| [103] |
Aiyer AS, Bautin M, Chen GJ, Damania P, Khemani P, Muthukkaruppan K, Ranganathan K, Spiegelberg N, Tang L, Vaidya M. Storage infrastructure behind Facebook messages:Using HBase at scale. IEEE Data Engineering Bulletin, 2012, 35(2): 4-13.
|
| [104] |
Zaharia M, Das T, Li H, Hunter T, Shenker S, Stoica I. Discretized streams:Fault-tolerant streaming computation at scale. In:Proc. of the SOSP, 2013, 423-438.
|
| [105] |
Kreps J, Narkhede N, Rao J. Kafka:A distributed messaging system for log processing. In:Proc. of the NetDB, 2011, 1-7.
http://d.old.wanfangdata.com.cn/Periodical/ranj201601015 |
| [106] |
Gonzalez JE, Xin RS, Dave A, Crankshaw D, Franklin MJ, Stoica I. GraphX:Graph processing in a distributed dataflow framework. In:Proc. of the OSDI, 2014, 599-613.
http://d.old.wanfangdata.com.cn/Periodical/jsjyjyfz201612007 |
| [107] |
Siddique K, Akhtar Z, Yoon EJ, Jeong YS, Dasgupta D, Kim Y. Apache Hama:An emerging bulk synchronous parallel computing framework for big data applications. IEEE Access, 2016, 4: 8879-8887.
[doi:10.1109/ACCESS.2016.2631549] |
| [108] |
Apache. Mahout official site. https://mahout.apache.org/
|
| [109] |
Meng X, Bradley J, Yavuz B, Sparks E, Venkataraman S, Liu D, Xin D. Mllib:Machine learning in apache spark. The Journal of Machine Learning Research, 2016, 17(1): 1235-1241.
http://d.old.wanfangdata.com.cn/Periodical/slsfzkxxxb201502005 |
| [110] |
Jin G, Wang Y, Qin X, Chen Y, Du X. Towards real-time analysis of ID-associated data. In:Proc. of the Int'l Conf. on Conceptual Modeling, 2018, 26-30.
|
| [111] |
Chaudhuri S, Narasayya VR. Self-Tuning database systems:A decade of progress. In:Proc. of the VLDB, 2007, 3-14.
|
| [112] |
Chaudhuri S, Narasayya VR. An efficient, cost-driven index selection tool for Microsoft SQL server. In:Proc. of the VLDB, 1997, 146-155.
http://www.wanfangdata.com.cn/details/detail.do?_type=perio&id=CC029838316 |
| [113] |
Bruno N, Chaudhuri S. An online approach to physical design tuning. In:Proc. of the ICDE, 2007, 826-835.
|
| [114] |
Chakkappen S, Budalakoti S, Krishnamachari R, Valluri SR, Wood A, Zait M. Adaptive statistics in Oracle 12c. In:Proc. of the VLDB, 2017, 1813-1824.
http://www.wanfangdata.com.cn/details/detail.do?_type=perio&id=10.1080/10485250902984875 |
| [115] |
Alagiannis I, Idreos S, Ailamaki A. H2O:A hands-free adaptive store. In:Proc. of the SIGMOD, 2014, 1103-1114.
http://d.old.wanfangdata.com.cn/Periodical/gpxygpfx201803050 |
| [116] |
Pavlo A, Angulo G, Arulraj J, Lin H, Lin J, Ma L, Santurkar S. Self-driving database management systems. In:Proc. of the CIDR, 2017.
http://cn.bing.com/academic/profile?id=4fc2bc2b0455ad9a2d1c0ea754da6d25&encoded=0&v=paper_preview&mkt=zh-cn |
| [117] |
Arulraj J, Pavlo A, Menon P. Bridging the archipelago between row-stores and column-stores for hybrid workloads. In:Proc. of the SIGMOD, 2016, 583-598.
http://cn.bing.com/academic/profile?id=0264272dbbca37d9d901c7635fcd1565&encoded=0&v=paper_preview&mkt=zh-cn |
| [118] |
Van Aken D, Pavlo A, Gordon GJ, Zhang B. Automatic database management system tuning through large-scale machine learning. In:Proc. of the SIGMOD, 2017, 1009-1024.
http://cn.bing.com/academic/profile?id=a63d627e0ddc866f20da639f522b4af9&encoded=0&v=paper_preview&mkt=zh-cn |
| [119] |
Sharma A, Schuhknecht FM, Dittrich J. The case for automatic database administration using deep reinforcement learning. arXiv Preprint arXiv: 1801.05643, 2018.
|
| [2] |
杜小勇, 卢卫, 张峰. 大数据管理系统的历史、现状与未来. 软件学报, 2019, 30(1): 127-141.
http://www.jos.org.cn/1000-9825/5644.htm [doi:10.13328/j.cnki.jos.005644] |
| [42] |
何龙, 陈晋川, 杜小勇. 一种面向HDFS的多层索引技术. 软件学报, 2017, 28(3): 502-513.
http://www.jos.org.cn/1000-9825/5161.htm [doi:10.13328/j.cnki.jos.005161] |
| [44] |
赵丽萍. DuBAI:基于数据复制的HDFS列存储上的索引技术研究与实现. 北京: 中国人民大学, 2017.
|
| [83] |
舒继武, 陆游游, 张佳程, 郑纬民. 基于非易失性存储器的存储系统技术. 科技导报, 2016, 32(14): 86-94.
http://www.wanfangdata.com.cn/details/detail.do?_type=perio&id=kjdb201614014 |
| [94] |
余飞. 电信运营商大数据应用典型案例分析. 信息通信技术, 2014, 8(6): 63-69, 83.
http://d.old.wanfangdata.com.cn/Periodical/xxtxjs201406014 |
| [95] |
夏靖波, 韦泽鲲, 付凯, 陈珍. 云计算中Hadoop技术研究与应用综述. 计算机科学, 2016, 43(11): 6-11.
[doi:10.11896/j.issn.1002-137X.2016.11.002] |
| [96] |
郭敏杰. 大数据和云计算平台应用研究. 现代电信科技, 2014, 44(8): 7-11.
[doi:10.3969/j.issn.1002-5316.2014.08.002] |