|
2017-10-20
陈军成 等
鹏越网络空间安全研究院
鹏越网络空间安全研究院
鹏越是上海交通大学信息安全工程学院产业化平台。致力于全球网络空间安全前沿技术、人才培养、战略规划、网络空间治理、安全资讯、情报分析、人工智能、信息技术前沿等领域的研究，共建网络强国！ 根据维基百科的定义，大数据又称为巨量数据、海量数据、大资料等， 是指无法通过人工或者计算机，在合理的时间内达到截取、管理、处理并整理成为人类所能解读的形式的信息 ， 通常应用于商业模式及趋势的发现与探究、疾病预测、实时交通等领域，特别是在科学研究领域，如脑科学、基因科学、生物工程等．通常情况下，科学家面对的是海量数据，很难直接发现其中的因果关系，然而，借助大数据相关技术手段，科学家能相对容易地发现其中的关联关系．这种关联关系可以进一步指引科学家深入探究其中的因果关系． 与传统的数据相比，大数据具有5 V 特征， 即数据规模庞大 ( volume) 、速度快 ( velocity) 、形态多( variety) 、识别困难( veracity) 以及价值大但价值密度低( value) 等．大数据系统通常需要解决如何高效存储数据、如何处理瞬间爆发的数据以及如何应对形态各异的结构化、半结构化以及非结构化数据等问题． 针对这些问题，国际巨头 Google、Facebook、Amazon、Microsoft 和 Apache 的开源组织以及国内的百度、阿里巴巴、腾讯( BAT) 等均从各行业实际需求出发，提出了大数据相关文件系统、存储技术、大数据分析引擎等．本文从技术的角度， 对大数据文件系统、存储、大数据资源管理与调度、大数据分析引擎等大数据相关技术进行综述， 并进一步指出可能的技术发展方向． 1 大数据文件系统 1.1基于存储的分布式文件系统 分布式文件系统( distributed file system) 是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连．分布式文件系统的设计基于客户机 /服务器模式． 大数据庞大的数据规模、复杂的数据结构以及可能面对的高频访问， 给操作系统中传统的文件系统提出了挑战．为了解决这类问题， Google 公司于2003 年发表了 Google 内部研发的 Google 文件系统GFS． GFS 针对 Web 环境下批量大规模海量数据处理而制定，虽未公开其源码，但依然在学术界和工业界受到广泛关注．在GFS 的影响下， Doug Cutting和 Mike Cafarella 于 2004 年在 Nutch 中实现 GFS的开源版 本 HDFS ( Hadoop distributed file system)，并且在 2006年2月成为Apache Hadoop项目的关键组成部分． HDFS 是为以流式数据访问模式存储超大文件而设计的文件系统，支持超大文件( 数百 TB 甚至PB 级的数据) ，以普通硬件为基础，重点支持一次写入、多次读取的场景． HDFS架构如图1所示．HDFS采用主(master)/从(slave)架构．一个HDFS集群是由一个Namenode和一组Datanodes组成．Namenode是一个中心服务器，负责管理文件系统的名字空间(namespace)以及客户端对文件的访问．集群中的Datanode一般是一个节点，负责管理它所在节点上的存储．HDFS暴露了文件系统的名字空间，用户以文件的形式在上面存储数据．从内部看，1个文件被分成1个或多个数据块，这些块存储在1组Datanode上．Namenode执行文件系统的名字空间操作，如打开、关闭、重命名文件或目录．它也负责确定数据块到具体Datanode节点的映射．Datanode负责处理文件系统客户端的读写请求．在Namenode的统一调度下进行数据块的创建、删除和复制．
HDFS 支持在一个大集群中跨机器可靠地存储超大文件．它将每个文件存储成一系列的数据块，除了最后一个，所有的数据块都是同样大小．为了容错，文件的所有数据块都有副本．每个文件的数据块大小和副本系数均可配置， 应用程序指定某个文件的副本数目．副本系数可以在文件创建的时候指定，也可以在之后改变． HDFS 中的文件都是一次性写入，并且严格要求在任何时候只能有一个写入者． Namenode 全权管理数据块的复制， 周期性地从集群中的每个 Datanode 接收心跳信号和块状态报告．接收到心跳信号意味着该 Datanode 节点工作正常．块状态报告包含了一个该 Datanode 上所有数据块的列表． HDFS 的主要优势体现在一次写、多次读的应用场景，对于小文件支持开销较大， 并且 HDFS 存在单点问题．针对这些问题，Weil 提出了一套高性能、易扩展的、无单点的分布式文件存储系统 Ceph． Ceph 的主要目标是提供高可扩展性及对象存储、块存储和文件系统的存储机制． Ceph 提供一个单一的存储平台， 可以处理所有类型的数据存储( 包括对象、块和文件) ，其高扩展性可以达到 PB 级，拥有高容错性和高一致性数据冗余机制． 1. 2 基于分布式内存的文件系统 随着实时计算的需求增加，分布式内存计算持续升温，如何将海量数据近实时处理，如何把离线批处理的速度再提升到一个新的高度也是当前研究的重点．随着固态硬盘( solid state drivers， SSD) 等设备的发展，内存吞吐量呈指数增长，而磁盘的吞吐量增长缓慢，将原有计算框架中的磁盘文件替换为内存文件，成为提高效率的优化点． 基于这种考虑，AmpLab的李浩源等研发了Tachyon．Tachyon 是一个高容错的分布式内存文件系统， 其设计的核心内涵是，要满足当下“低延迟”的数据处理要求． Tachyon 是在内存中处理缓存文件，允许文件以访问内存的速度在集群框架中进行可靠的共享，类似于 Spark， Tachyon 的吞吐量比 HDFS 高出 100 倍． Spark 框架虽然也提供了强大的内存计算能力， 但其没有提供内存文件的存储管理能力，而 Tachyon 则弥补了 Spark 的不足之处． Tachyon 是架构在最底层的分布式文件存储和上层的各种计算框架之间的一种中间件， 其主要职责是将那些不需要存储到 DFS( distributed file system) 里的文件放入分布式内存文件系统中共享内存， 从而提高效率．同 时 可 以 减 少 内 存 冗 余、垃 圾 回 收( garbagecollect，GC) 时间等，Tachyon 在大数据中的层次关系如图 2 所示．
Tachyon 作为衔接底层文件系统(HDFS、Amazon S3) 和上层处理框架的缓存结构， 可提高实时分析系统的效率． 在分布式文件系统中， 相比而言，HDFS 适合存储大文件， Ceph 适合存储小文件( 已被纳入Linux 内核) ，而 Tachyon 则是内存文件系统， 其地位处于HDFS 和 Ceph 之上，MapＲeduce 和 Spark 之下． 1. 3 数据文件格式 在文件系统中，数据管理的最大挑战之一是如何管理大数据中的数据冗余．在传统的数据管理中，存在 2 种数据布局方式， 分别是行式存储模式(关系数据库) 和列式存储模式． 行式存储模式把不同数据类型的数据列连续、混合地存储在一起， 这种情况下要提高数据的压缩率将会非常困难， 而数据压缩率不高直接导致使用更多的磁盘存储空间．列式存储模式则不能保证同一个数据记录的所有字段都在集群中的同一个节点上，因此，重构原表数据记录的时候将在集群网络中造成大量的数据传输，这将产生大笔的性能开销，导致查询的处理速度非常慢． 结合行式存储模式和列式存储模式的优缺点，当前的大数据系统普遍采用混合式存储模式．ＲCFile 是 Hive 推出的一种专门面向列的数据格式．它遵循“先按列划分， 再垂直划分”的设计理念．在查询过程中，针对它并不关心的列时， 它会在输入 /输出 ( input /output， I /O)上跳过这些列． ＲCFile 在 map 阶段从远端拷贝仍然是拷贝整个数据块，并且拷贝到本地目录后ＲCFile 不是真正直接跳过不需要的列． ＲCFile 的主要特点包括: 1) 保证数据记录的所有字段都在集群中同一个节点上; 2) 集群节点上每一列数据单独压缩，使得ＲCFile 的数据压缩率非常高; 3) 在数据读取的时候只读取需要使用的数据列，不使用的数据列永远不会去读取．为了进一步降低 NameNode 的负载、提高数据的压缩效率， 在ＲCFile的基础上，俄亥俄州立大学的 Huai等提出了一种基于列式存储的改进版存储格式 OＲCFile． 嵌套数据是大数据系统中需要处理的常见数据模型，然而OＲCFile 的原生模型对此支持不足．针对这一问题，在Dremel 的启发下，Twitter 和Cloudera 合作研发了 Parquet． Parquet 将嵌套结构存储的数据存储成扁平格式， 并且在同一个数据文件中保存一行中的所有数据， 以确保在同一个节点上处理时每一行的所有列都可用．另外， Parquet使用一些自动压缩技术， 例如行程编码( run-length encoding，ＲLE ) 和 字 典 编 码( dictionary encoding，DE) ，极大地节约了存储空间． 现有大数据文件系统如 Hadoop、GFS 等， 充分利用非关系型特征，部分解决了大数据的数据种类繁多的问题; 而 ＲCFile 等数据文件格式， 则对数据进行了充分的压缩， 部分解决了大数据的数据规模庞大问题．在 SSD 逐渐普及的今天，如何充分利用SSD 构建更加高效的大数据文件系统是一个值得努力的方向． 2 分布式数据存储策略 数据一致性是大数据系统中必须解决的问题．不同的应用场景， 对数据一致性要求不同．根据一致性(consistency) 要求的强弱不同， 分布式数据存储策略可分为 ACID 和 BASE 两大类． ACID 是指数据库事务具有的4个特性:原子性(atomicity) 、一致性 (consistency) 、隔 离 性(isolation) 、持久性(durability) ． ACID 中的一致性要求比较强，每个事务的执行务必保证数据库从执行前的一致性状态迁移到执行后的另一个一致性状态．而 BASE 对一致性要求较弱， 它的 3 个特征分别是: 基本可用(basicallyavailable) 、软状态 /柔性事务(soft-state，即状态可以有一段时间的不同步) 和最终一致性( eventual consistency) ． 针对 ACID 和 BASE 两种策略， 下面重点阐述工业界和学术界几种典型的数据库系统． 2. 1 BASE 2. 1. 1 基于键－值对的数据库系统 基于键－值对的数据库系统的核心思想是， 所有数据均以( key，value) 的形式存储， 其中 key 表示唯一的关键字， value 表示真正的数据， 所有关于数据的访问均以关键字 key 进行搜索查询， 通常支持get、set 等操作． 在分布式系统中，横向扩展、数据可靠性以及单点故障给分布式键－值对存储系统带来了困难． 针对这些问题， 亚马逊公司研发的Dynamo系统，使用基于环的一致性哈希算法来应对计算资源动态加入和退出．具体来讲，把所有 Dynamo 系统中的节点看作一个环， 并且为环上的每个节点分配一个令牌，分配了不同令牌的节点位于环的不同位置，并且任意2 个令牌是不同的．然而， 在系统中的节点是不对称的， 即这些节点可能具有不同的计算能力，若每个节点对应一个令牌，那么会导致较低计算能力节点处理过多数据，而具有丰富计算能力的节点管理数据较少从而浪费了部分计算资源．为了解决该问题，Dynamo 引入“虚节点”技术，分配给虚节点的令牌实际上由实际节点所持有， 从而实际节点可拥有多个令牌．为了保证数据的可靠性， 除了原始数据外，还需将数据拷贝到原始数据所在节点的多个下游节点上．因此，当读取数据时， 若分配到的读取节点失效， 那么沿着环的方向寻找可用的存储该数据拷贝的下游节点． Dynamo 的节点发现机制、写操作高可用以及故障处理机制使其成为众多基于键－值对存储系统的基础．Voldemort 是Dynamo 的一个开源实现， 支持数据自动复制、数据自动分割、可插拔策略等． Cassandra系统架构与 Dynamo 类似， 是基于一致性哈希的完全 P2P 架构， 每行数据通过哈希来决定应该存在哪个或哪些节点中．集群没有 master的概念，所有节点都是同样的角色，彻底避免了整个系统的单点问题导致的不稳定性，集群间的状态同步通过 Gossip 协议进行 P2P 通信．每个节点都把数据存储在本地， 接受来自客户端的请求．每次客户端随机选择集群中的一个节点来请求数据， 接受请求的节点将对应的 key 在一致性哈希的环上定位到存储这个数据的节点，将请求转发到对应的节点上，并将对应若干节点的查询反馈给客户端． Cassandra 和 Dynamo 在应对数据的一致性、可用性和分区可容忍性方面同样比较灵活．具体来讲，Cassandra 的每个 keyspace 可配置一行数据写入多个节点( 设这个数为 N) 来保证数据不会因为机器宕机或磁盘损坏而丢失，即保证了 CAP 中的分区容忍度． 2. 1. 2 基于列的数据库系统 BigTable是 Google 公司研发的最早的基于列的存储系统，该系统支持数据表的横向扩展，用于处理包括 Web 索引、Google 地图等大型系统． 在数据的逻辑组织方面， 由于BigTable 可能要处理高达上百万列的记录， 但每个记录实际上存在的列较少， 大部分为空值， 即列是稀疏的．实际上，每次读取的数据列往往较少，且部分列同时被请求，因此，BigTable 采用多级映射数据结构: 1) 行关键字; 2) 列簇和列簇下的列关键字( 这些列往往被同时请求) ; 3) 版本时间戳．用时间戳来管理多个版本，当版本数量较多时，删除较老的版本． 在分布式体系架构上，BigTable 采用 GFS 分布式文件系统，并设计了 Chubby 分布式锁服务来解决分布式并发、同步和资源分配等问题． BigTable 的节点主要分为 2 类: 1) 1 个或多个 Master 节点，用于处理元数据相关的操作并支持负载均衡; 2) 可横向扩展的多个Tablet 节 点，用于存储数据库的Tablet 区块， 所有的数据访问都要 映 射 到相应的Tablet．由于 BigTable 采用了列簇和列存储模式， 在数据压缩方面具有很大的优势．为了加速列簇和列的管理， 设计了 SSTable 的格式作为 Tablet．具体的架构如图 3 所示．
根据BigTable 的设计思想， 开源界研发了基于JVM 的 HBase和基于C 的 HyperTable． HBase 基于开源的 GFS 分布式文件系统 HDFS， 实现了具有高可靠性、高性能、可伸缩和可实时读写的分布式数据库系统，后来发展成为 Apache 的一个顶级项目; 而 HyperTable则实现了分布式结构化组织并向应用提供类似表访问( 类 SQL) 的接口， 两者均广泛应用于工业界各大公司． 2. 1. 3 基于文档的存储系统 基于文档的存储系统本质上是一种半结构化数据系统，与传统的数据库从语义上较为接近，但是文档型数据的模式( schema) 是不固定的．此处的“文档”就是一个数据记录， 并且这个记录对包含的数据类型和内容进行自我描述，典型的文档包括 XML文档、HTML 文档以及 JSON 文档， 如用 JSON 描述一个人的数据记录，可表示为: { name: “小明”，sex: “male”， age: 10} ． 当前，典型的文档型数据库系统包括MongoDB和CouchDB． MongoDB 是一个面向集合的系统，即数据被存储在数据集中，一个数据集称为一个集合( 类似于关系数据库中的表格，但是不需要 预 先 定 义 模 式) ， 集合中的 文 档 以 BSON( JSON 的二进制序列) 的形式存放， Nytro MegaＲAID技术中的闪存高速缓存算法可帮助MongoDB 快速识别数据库内大数据集中的热数据， 提供一致的性能改进． CouchDB 与 MongoDB 类 似， 其 中 的 文 档 以JSON 的形式存放．从 CAP 理论的角度讲， CouchDB侧重于可用性( A) 和分区容忍度( P) ，而 MongoDB则侧重于一致性( C) 和 P． 2. 1. 4 基于图的数据系统 前面介绍的 3 种系统，都偏重于描述实体本身，然而，在很多情况下，除了实体本身之外， 实体与实体之间关联关系也非常重要， 如社交媒体中人与人之间的关系，本体论中本体之间的各种关系等．为了处理这种关系，基于图的数据库系统应运而生． 典型 的 基 于 图 的 数据 系 统 包 括 Neo4j和Titan． Neo4j 是一个嵌入式的 Java 持久化引擎， 该引擎基于传统磁盘文件系统， 与传统数据库的最大差异是并非将记录存储在表中， 而是存储在图(网络)中． Neo4j 具有良好的可扩展性， 可处理大规模数据，例如，具备在一台机器上处理数十亿节点/关系/属性的图的能力， 也可扩展到多台机器并行运行． 相对于关系数据库来说， 图数据库能够发挥在处理大量复杂、互连接、低结构化的数据的优势． Neo4j处理的数据是快速变化的动态数据，适合频繁地查询需求，避免了在关系数据库中耗时的多表连接操作带来的性能瓶颈和性能衰退问题．通过基于图的数据建模模型， Neo4j 能够以相同的速度遍历节点与边，且遍历速度与数据量大小没有任何关系．另外， Neo4j 还提供了丰富的图算法、推荐类算法和OLAP 风格的分析运算算子．而 Titan 则是一个典型的内存数据库系统，支持包括 HBase、Cassandra 等不同层次的存储层， 重点在存储和大规模图处理方面做了优化． 不同数据存储应对的场景不同，键－值对适用于快速索引查询场景; 列数据库适用于多版本数据场景; 文档数据库更多地应用于数据模式多变的场景; 图数据库则大量应用于社交网络和本体论相关应用中． 2. 2 ACID 基于 BASE 的数据库系统主要强调可用性和弱一致性，这种系统无法较好地处理全球分布的数据存储的一致性问题．针对这一问题， Google 研发了一系列存储系统． 鉴于已有大数据管理系统难以提供强一致性的缺陷，谷歌设计了具有高可扩展性和高可用性的Megastore存储系统．该系统基于 Bigtable，能够实现类似 ＲDBMS 的数据模型， 支持细粒度的数据分区; 采用 paxos 实现数据的同步复制， 即当更新一个记录时，所有备份节点能够近似实时地同步该更新，确保了所有备份的一致性． 在具体的实践中，Google 发现 Megastore 在吞吐量方面存在缺陷， 于是进一步研发了 Spanner． Spanner 是一个全球分布式的同步复制数据库， 能够支持高达百万台数据节点， 管理上万亿条记录．该系统所管理的节点能够分布在多达几百个数据中心，具有时间标记的数据的多个版本跨越了多个数据中心，并通过多版本和同步复制实现了外部一致性．该系统采用模式化的、半关系化的表存储数据，且数据在修改时以提交的时间戳标记不同版本， 能确保越旧的数据越容易被垃圾回收， 应用可根据需求读取不同版本的数据．与已有 NoSQL 不同的是，Spanner 支持类似关系数据库那样的通用事务， 具有基于 SQL 的查询语言． 总体来讲，Spanner 具有如下重要的特征: 1) 支持细粒度控制副本， 可动态配置数据中心管理副本的范围、数量， 降低数据读写延迟． 2) 支持读和写的外部一致性， 支持在一个时间戳下的跨越数据库的全球一致性的读操作．这些特征使得 Spanner 具备在全球分布式的一致的备份、一致的 MapＲeduce 执行和原子模式变更成为可能． CockroachDB是 Spanner 的一个开源实现．随着 Google 在广告业务方面的不停扩张， 实时性的 要 求 也 越 来 越 高， 而 BigTable、Megastore 和Spanner 均无法有效对此进行处理．因此， Google 又研发了新一代的处理系统 MESA． MESA 是一个具备跨地域复制和近实时特性的可伸缩数据仓库，提供 PB 级数据处理能力和亚秒级响应能力． MESA提供的数据模型与关系型数据库的数据模型极为相似，以表的方式管理数据，每个表具有特定的模式． MESA 以多版本方式存储数据， 与已有数据更新机制不同的是，在一定时间间隔内，以批处理方式扩散已有更新．当请求的数据正在更新时返回该数据的前置状态，从而保证数据一致性．具体来讲， 每隔几 min，上游系统以执行一次数据更新的批处理方式扩散已有更新到各副本．每个独立的、无状态的数据提交者，协调跨全部数据中心的更新操作，为每个更新批处理分配唯一的版本号，并采用 Paxos一致算法向各节点发布全部与该更新关联的元数据．当全球范围的大量 MESA 实例合并了一个更新之后，提交者就把该更新的版本号声明为新的提交版本号，并将该值存储在版本数据库里，从而该版本的数据可被请求． 当前，Google 的这三大系统已被全球各大公司所借鉴，国内的BAT 等也在此基础上研发了各自的内部系统． 分布式数据存储策略是工业界近年来最热的领域之一，各类非结构化数据库层出不穷， 然而， 由于其应对场景单一，局限性也十分明显，如何对上述各类工具进行融合优化，以适应日益复杂的需求是当前工业界和学术界共同的话题． （待续） （来源：互联网，作者：陈军成，丁治明，高需）
阅读
''
|
|
|
