大数据处理技术的总结与分析.pdf

《大数据处理技术的总结与分析.pdf》由会员分享，可在线阅读，更多相关《大数据处理技术的总结与分析.pdf（50页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、 数据分析处理需求分类 1 事务型处理 在我们实际生活中，事务型数据处理需求非常常见，例如：淘宝网站交易系统、12306 网站火车票交易系统、超市 POS 系统等都属于事务型数据处理系统。这类系统数据处理特点包括以下几点：一是事务处理型操作都是细粒度操作，每次事务处理涉及数据量都很小。二是计算相对简单，一般只有少数几步操作组成，比如修改某行的某列；三是事务型处理操作涉及数据的增、删、改、查，对事务完整性和数据一致性要求非常高。四是事务性操作都是实时交互式操作，至少能在几秒内执行完成；五是基于以上特点，索引是支撑事务型处理一个非常重要的技术。在数据量和并发交易量不大情况下，一般依托单机版关系型数

2、据库，例如ORACLE、MYSQL、SQLSERVER，再加数据复制(DataGurad、RMAN、MySQL数据复制等)等高可用措施即可满足业务需求。在数据量和并发交易量增加情况下，一般可以采用 ORALCE RAC 集群方式或者是通过硬件升级(采用小型机、大型机等，如银行系统、运营商计费系统、证卷系统)来支撑。事务型操作在淘宝、12306 等互联网企业中，由于数据量大、访问并发量高，必然采用分布式技术来应对，这样就带来了分布式事务处理问题，而分布式事务处理很难做到高效，因此一般采用根据业务应用特点来开发专用的系统来解决本问题。2 数据统计分析 数据统计主要是被各类企业通过分析自己的销售记录

3、等企业日常的运营数据，以辅助企业管理层来进行运营决策。典型的使用场景有：周报表、月报表等固定时间提供给领导的各类统计报表；市场营销部门，通过各种维度组合进行统计分析，以制定相应的营销策略等。数据统计分析特点包括以下几点：一是数据统计一般涉及大量数据的聚合运算，每次统计涉及数据量会比较大。二是数据统计分析计算相对复杂，例如会涉及大量goupby、子查询、嵌套查询、窗口函数、聚合函数、排序等；有些复杂统计可能需要编写 SQL 脚本才能实现。三是数据统计分析实时性相对没有事务型操作要求高。但除固定报表外，目前越来越多的用户希望能做做到交互式实时统计；传统的数据统计分析主要采用基于 MPP 并行数据库

4、的数据仓库技术。主要采用维度模型，通过预计算等方法，把数据整理成适合统计分析的结构来实现高性能的数据统计分析，以支持可以通过下钻和上卷操作，实现各种维度组合以及各种粒度的统计分析。另外目前在数据统计分析领域，为了满足交互式统计分析需求，基于内存计算的数据库仓库系统也成为一个发展趋势，例如 SAP 的 HANA 平台。3 数据挖掘 数据挖掘主要是根据商业目标，采用数据挖掘算法自动从海量数据中发现隐含在海量数据中的规律和知识。数据挖掘主要过程是：根据分析挖掘目标，从数据库中把数据提取出来，然后经过 ETL 组织成适合分析挖掘算法使用宽表，然后利用数据挖掘软件进行挖掘。传统的数据挖掘软件，一般只能支

5、持在单机上进行小规模数据处理,受此限制传统数据分析挖掘一般会采用抽样方式来减少数据分析规模。数据挖掘的计算复杂度和灵活度远远超过前两类需求。一是由于数据挖掘问题开放性，导致数据挖掘会涉及大量衍生变量计算，衍生变量多变导致数据预处理计算复杂性；二是很多数据挖掘算法本身就比较复杂，计算量就很大，特别是大量机器学习算法，都是迭代计算，需要通过多次迭代来求最优解，例如 K-means聚类算法、PageRank 算法等。因此总体来讲，数据分析挖掘的特点是:1、数据挖掘的整个计算更复杂，一般是由多个步骤组成计算流，多个计算步骤之间存在数据交换，也就是会产生大量中间结果，难以用一条 sql 语句来表达。2、

6、计算应该能够非常灵活表达，很多需要利用高级语言编程实现。二 大数据背景下事务型处理系统相关技术 在 google、facebook、taobao 等大互联网公司出现之后，这些公司注册和在线用户数量都非长大，因此该公司交易系统需要解决“海量数据+高并发+数据一致性+高可用性”的问题。为了解决该问题，从目前资料来看，其实没有一个通用的解决方案，各大公司都会根据自己业务特点定制开发相应的系统,但是常用的思路主要包括以下几点：(1)数据库分片，结合业务和数据特点将数据分布在多台机器上。(2)利用缓存等机制，尽量利用内存，解决高并发时遇到的随机 IO 效率问题。(3)结合数据复制等技术实现读写分离，以及

7、提高系统可用性。(4)大量采用异步处理机制，对应高并发冲击。(5)根据实际业务需求，尽量避免分布式事务。1 相关系统介绍 1)阿里 CORBAR 系统 阿里 COBAR 系统是一个基于 MYSQL 数据库的分布式数据库系统，属于基于分布式数据库中间件的分布式数据库系统。该系统是前身是陈思儒开发的“变形虫”系统(以前调研过)，由于陈思儒离开阿里去了盛大，阿里当心“变形虫”稳定性等问题，重新开发该项目。该系统主要采用数据库分片思路，实现了：数据拆分、读写分离、复制等功能。由于此系统由于只需要满足事务型操作即可，因此相对真正并行数据库集群(例如 TeraData 等)，此类系统提供操作没有也不需要提

8、供一些复杂跨库处理，因此该系统存在以下限制：(1)不支持跨库的 join、分页、排序、子查询。(2)insert 等变更语句必须包括拆分字段等。(3)应该不支持跨机事务(以前变形虫不支持)。说白了此类系统不具备并行计算能力,基本上相当于数据库路由器！另外此类系统的在实际应用的关键问题是，根据什么对数据进行切分，因为切分不好会导致分布式的事务问题。2)阿里 OceanBase 系统 该系统也是淘宝为了解决高并发、大数据环境下事务型处理而定制开发的一个系统。该系统主要思路和特点如下：(1)他们发现在实际生成环境中，每天更新的数据只占总体数据的 1%不到，因此他们把数据分为：基线数据和增量更新数据。

9、(2)基线数据是静态数据，采用分布式存储方式进行存储。(3)只在一台服务器上存储和处理增量更新数据，并且是在内存中存储和处理更新数据。(4)在系统负载轻的时候，把增量更新批量合并到基线数据中。(5)数据访问时同时访问基线数据和增量更新数据并合并。因此这样好处是：(1)读事务和写事务分离(2)通过牺牲一点扩展性（写是一个单点），来避免分布式事务处理。说明：该系统虽然能处理高并发的事务型处理，号称很牛逼，但其实也只是根据电商的事务处理来定制开发的专用系统，个人认为其技术难度小于 oracle 等通用型的数据库。该系统无法应用到银行或者 12306 等，因为其事务处理的逻辑远远比电商商品买卖处理逻辑

10、复杂。在目前的大数据时代，一定是基于应用定制才能找到好的解决方案！3)基于 Hbase 的交易系统 在 hadoop 平台下，HBASE 数据库是一个分布式 KV 数据库，属于实时数据库范畴。支付宝目前支付记录就是存储在 HBASE 数据库中。HBASE 数据库接口是非 SQL 接口，而是 KV 操作接口(基于 Key 的访问和基于key 范围的 scan 操作)，因此 HBASE 数据库虽然可扩展性非常好，但是由于其接口限制导致该数据库能支持上层应用很窄。基于 HBASE 应用的设计中，关键点是 key 的设计，要根据需要支持的应用来设计 key 的组成。可以认为 HBASE 数据库只支持作

11、为 KEY 的这一列的索引。虽然目前 HBASE 有支持二级索引的方案，二级索引维护将会比较麻烦。2 并发和并行区别 并发是指同时执行通常不相关的各种任务，例如交易型系统典型属于高并发系统。并行是通过将一个很大的计算任务，划分为多个小的计算任务，然后多个小计算任务的并行执行，来缩短该计算任务计算时间。两者主要区别在于：(1)通讯与协调方面：在并行计算中，由于多个小任务同属一个大的计算任务，因此小任务之间存在依赖关系，小任务之间需要大量通讯和协调；相反，并发中的多个任务之间基本相互独立，任务与任务之间相关性很小。(2)容错处理方面：由于并发任务之间相互独立，某个任务执行失败并不会影响其它的任务。

12、但是并行计算中的多个任务属于一个大任务，因此某个子任务的失败，如果不能恢复(粗粒度容错与细粒度容错)，则整个任务都会失败。3 本章总结 数据量大不一定需要并行计算，虽然数据量大，数据是分布存储，但是如果每次操作基本上还是针对少量数据，因此每次操作基本上都是在一台服务器上完成，不涉及并行计算。只是需要通过数据复制、数据缓存、异步处理等方式来支撑高并发访问量 三 大数据背景下数据统计分析技术介绍 随数据量变大，和事务处理不同的是，单个统计分析涉及数据量会非常大，单个统计分析任务涉及数据会分散在多台服务器上，且由于计算量大，采用单台服务器进行计算，会导致计算时间非常长，单个统计分析任务必须采用并行计

13、算方式来加快单个统计分析任务执行速度。1 并行查询与并行计算技术介绍 在大数据背景下的数据统计分析技术门类很多，常见的有：n MPP 并行数据库:TeraData、GreenPlum、Vertica 等。n 基于 MapReduce 并行计算框架的数据仓库：HIVE(Hadoop 平台)、Tenzing（Google 公司）n 基于 Hbase 的 Phoenix 系统 n HadoopDB 系统 n EMC 公司的 hapt 系统 n MPP 分布式查询引擎：Dremel、Impala、Presto、Shard query、Citusdb。n 基于 SPARK 的 Shark、基于 Drya

14、d 的 SCOPE、基于 Tez 的 stinger。n 基于 hadoop+index 的 JethroData 系统 n 基于内存计算的 Druid 系统 这些系统都解决了海量数据下的数据统计分析的问题，并且这些系统另外一个共同特点是都提供了 SQL 或者类 SQL 接口。为了能够较好研究这些系统，我们需要对并行查询与并行计算的相关技术做一个简要的介绍。首先所有的系统都可以分为三个层次:语义层、并行计算引擎层、分布式存储层。语义层提供一个编程接口让用户表达所需要计算，并负责把该计算翻译成底层并行计算引擎可以执行的执行计划，并由并行计算引擎来执行，最下面一层是分布式存储层。对于提供类 SQL

15、 接口并行计算系统，语义层可以认为是 SQL 解析层。1)语义层 SQL 语言是一种声名式语言，SQL 只是表达了要做什么，而没有表达怎么做。为此，SQL 解析层主要作用是：将用户提交的基于 SQL 的统计分析请求，转化为底层计算引擎层可以执行的执行计划。也就是解决“怎么做”的问题。SQL 解析层工作主要包括两个大方面:(1)通过语法分析技术来理解要做什么。在关系数据库中，一般会把 SQL 语言分析后，形成树型结构的执行计划。(2)在语法分析技术上，利用各种优化技术和算法，找出一种最经济物理执行计划。优化可以分为两个方面：一是逻辑层面优化、二是物理执行层面优化。(1)逻辑层优化 逻辑层面个人认

16、为主要是因为同样表达一个分析请求，有的人 SQL 写的好，有的人 SQL 写的烂，因此在逻辑层面可以通过一些等价关系代数变换，实现查询重写，将写的比较烂的 sql 变换为好的写法。比较典型优化是：“把投影和过滤下沉，先执行过滤和投影操作”，减少中间结果。(2)物理层优化 物理层面优化是在逻辑优化后，结合实际物理执行过程，找出最优的物理执行计划。生成物理查询计划的工作包括:增加一些操作符：包括扫描和排序等。确定各个操作符实现算法。例如扫描是全表扫描还是利用索引；Join 是采用HASH 连接、索引连接、合并排序等实现算法中的那一种。确定操作符之间的数据流转方法：物化还是流水线方式。采用基于代价估

17、算方法确定最优的物理执行计划，目前代价估算主要是以估算该物理计划需要的 IO 量。另外对于并行数据库，则还要考虑通讯代价，即尽量减少数据在各个机器之间的传递。在物理层优化的代价估算过程中，代价估算需要依靠很多统计信息，如表有多大，表中相关列的值分布是什么样子等。传统数据库在数据 Load 过程中会事先计算好这些统计信息。并行计算中还需要考虑通讯代价。需要指出是，由于 imapla、Presto、HIVE 等系统只是一个查询引擎，它们可以直接查询以普通文件方式存储在 HDFS 系统上的文件，因此这些系统一般无法使用索引和各种统计信息来进行物理执行计划的优化，这些系统一般只能在逻辑层进行一些基于规

18、则静态优化。根据 SHARK 论文，SHARK 系统支持根据前面一些节点计算获得的信息，来动态优化后面执行计划。(3)物化与流水线执行方法 一条 SQL 语句对开发人员而言，感觉只是一次调用，但是实际上在数据库内部，一条 SQL 语句执行其实是有多个操作符组合而成的的树型结构计算流。如下图：针对该计算流有两种执行方式：一是基于物化或者是实体化执行方式，另外一种是基于数据流的执行方式。第一种方法的过程是：把各个操作运算排序，并把每个操作运算的输出的中间结果存储在磁盘上，直到被另外一个操作运算所读取。另外一种方法是同时交错进行多个运算，由一个运算产生每个元组直接传递给下一个运算，而不将中间结果存储

19、到磁盘，也不用等到前一个运算全部运算完毕。例如：两个表连接后，再进行投影操作。如果采用第一种方法，则需要 把两表连接中间结果临时写入磁盘，然后再读取该结果执行投影操作。而如果采用第二种方法，则连接操作一旦产生一个元组就可以立刻送到投影操作去进行投影操作。流水线方法可以极大避免大量的中间结果磁盘 IO。因此数据库一般会采取流水线方法来执行。流水执行方法有两种模式：一种是需求驱动流水线，也就是从上层主动向下层要求元组，另外一种是生产者驱动流水线执行方式，由低层主动产生元组，由下层向上层推。目前大部分数据库引擎采用的是需求驱动流水线，实现方式采用基于 Graefe 提出的迭代器模型。该模型把每个操作

20、都表达为由三个接口：open(),getnext(),close()。每个操作被调用 open()进行准备工作，然后通过反复迭代被调用getnext 来获取下一个元组，最后被调用 close 来进行清理工作。通过构建迭代器网络，也就是迭代器之间的互相调用，就可以实现需求驱动流水线。当然不是任何操作都可以流水执行，流水执行条件是：操作要满足在接收输入元组时可以输出元组。例如排序操作就无法进行流水操作，在执行排序操作前都必须进行实体化。(4)SQL 解析层与并行计算引擎层 由于不同并行计算引擎层的执行计划表达不同，因此不同系统需要将 SQL 解析成不同的形式物理执行计划，例如：MPP 关系数据库一

21、般是把 SQL 解析成树状结构的物理执行计划。HIVE、Tezning 数据库是把 SQL 解析成 DAG 结构的多个 MAPREDUCE 组合。DRemel 等则类似 MPP 关系数据库，把 SQL 解析成一个树状结构执行计划。微软 SCOPE 则需要把类 SQL 解析成 DAG 结构的 Dryad 可执行的执行计划。SHARK 则需要把 SQL 解析成基于 scala 语言的 DAG 结构执行计划。并发 并行 2)并行计算引擎层(1)并行计算形式 并行化可以分为水平并行(无依赖并行)与垂直并行(流水线并行)两类。如下图：如果两个操作 OP1、OP2 无相互依赖关系，则称这两个操作相互独立。

22、水平并行化指的是互相独立的多个操作或者一个操作内互相独立的多个子操作分别由不同的处理机并行执行的形式。例如，排序操作、扫描操作由不同处理机并行执行就是水平并行化的实例。水平并行中一个非常常见的就是基于数据划分的并行，例如 MAPREDUCE，就是通过将数据划分到多台服务器上，并行执行 MAP和Reduce来进行并行运算。也有人把这种基于数据划分并行与操作独立并行区分开。垂直并行化则是指存在流水线方式依赖关系的操作分别由不同处理机并行执行的形式。流水线方式依赖：如果 OP2 无需等待 OP1 执行完毕即可在另一处理机上开始执行。由于一般情况下，流水的级数远小于处理的数据条目，因此流水并行主要意义

23、是在可以避免中间结果磁盘 IO 操作，对并行度的贡献相对较小。(2)并行计算面临的问题与并行计算框架 并行计算需要解决的问题主要包括几下几个方面：自动并行化、通讯、任务调度、并发控制、容错、资源管理。由于并行计算面向上述一系列问题，因为业界为了简化并行程序开发，提供了一系列的并行计算底层库或者框架。在高性能计算领域，最常用于并行计算编程的库是 MPI 库，但是该库主要只是解决通讯问题。这导致容错、资源管理、任务调度、并行化等方面问题需要程序员来解决，因此利用 MPI 开发并行程序相对比较困难。最近一些年，各大型互联网公司开发开发了一系列的通用并行计算框架。包括谷歌公司的 MAPREDUCE 框

24、架、微软公司的 Dryad 框架（目前微软已经停止该项目开发，转而支持 hadoop）、谷歌公司基于 BSP 模型的 Pregel 框架、Twitter公司的 Storm 框架、Yahoo 公司 S4 框架、HortonWorks 公司的 Tez 框架、Berkeley 大学的 spark 框架等通用并行计算框架。有了这些框架了，程序开发时只需要编写串行执行程序即可，而且也不用考虑任务与任务之间的并发控制以及通讯等问题，其它所有问题都有框架来解决，这样就大大简化并行程序开发难度。例如采用 MAPREDUCE 框架，我们只需要提供MAP函数和 Reduce函数，这些函数对程序员而言，都只是对本地

25、数据操作。目前虽然并行计算框架很多，但是可以把它们分成几个大类(基于 BSP 并行图计算引擎请参考第四章)：流数据并行计算框架 Storm、S4 是属于流数据并行计算框架，适合对流数据实时处理，也就是在数据写入磁盘前对数据进行实时并发运算。这类特点是计算不变，数据一直在变化。在上一个文档中，对此框架做过详细介绍，这里不再详细介绍。基于 DAG 通用批处理并行计算框架 MapReduce、Tez、Dryad、Spark 等属于基于 DAG(有向无环图)的通用批处理并行计算框架。这类框架是针对存储在存储设备上的一批数据进行分析处理，而且把分析处理流程利用 DAG 模型来表达。在这些框架中 MAPR

26、EDUCE 是最早出现的框架，而后面出现的一系列框架都为了改进 MR 框架不足而出现的升级版本。MR 框架主要不足是两个方面：一是编程接口太简单，表现在单个 MAPREDUCE 无法表达复杂运算，所以在实际应用环境中都是通过多个 MR 作业组合来完成一个任务。为了简化 MR 作业组合，在早期出现了一系列项目来执行组和式 MR 作业，例如 Cascading 项目。另外一个方面所有问题都必须转换为 MAP 和 REDUCE 模式，导致程序编写比较麻烦。二是 MR 只支持基于数据分区并行方式，不支持流水线并行，采用是步步物化策略来提高可靠性，当是这种导致大量中间结果物化，IO 开销非常大。因此 T

27、ez、Dryad、Spark 等后续框架改进主要针对以下两点进行改进：一是直接支持基于 DAG 结构表达方法，DAG 使得用户能够非常清晰地写出非常复杂的业务逻辑；二是通过支持流水线并性方式或者是尽量将中间结果放内存等方式，解决中间结果物化导致的 IO 开销问题。Dryad 和 Spark 框架在执行运算时，都会自动识别可以采取流水线方式执行的计算步骤，并尽量采用流水线执行方式来执行。容错：由于支持流水线并行或者采取把中间结果放内存的方式，因此要必须考虑容错的问题。由于这些框架都采用的是 DAG 结构，DAG 中一个节点所代表计算的执行是不会对输入进行修改(所谓函数式编程)，因此可以多次重复执

28、行不会影响计算。因此如果某个节点计算失败，它可以根据输入重复计算，而如果输入数据也消失了，则让前一个节点重新计算。所有这一切都是由框架自动执行。当然需要指出的是对一些流水线执行的多个计算步骤，如果某个计算节点失败，则只能整个流水线整体失败。基于 Tree 结构的 MPP 并行查询引擎 MPP 并行数据库与 Dremel、impala、Presto、Shard query、Citusdb 都采用的是基于 Tree 结构并行查询引擎。此类并行计算引擎共同特点是：一是针对 SQL 专用并行计算引擎，只支持 SQL 或者类 SQL 语义。二是执行计划都是树状结构；三是以流水线或者将中间结果放入内存方式

29、来实现快速计算。四是粗粒度容错机制。它们之间不同点：一 MPP 并行数据库中并行查询引擎与底层存储是紧耦合的，导致如果采用MPP 并行数据库，则只能通过 SQL 来访问数据，无法采用其他计算引擎直接处理存储在数据库中的数据。二 Impala、Presto 都只是一个并行查询引擎，它们可以直接查询以文件方式存储在 HDFS 上的数据,这样同一份数据既可以利用这些引擎来实现交互式查询，也可以支持利用其他计算框架进行更深入分析。三 Dremel 只支持 Google 自己的基于嵌套结构列式存储(Column IO)。该引擎也主要适合于聚合型计算，不支持 join 操作。四 上述引擎中只有 MPP 并

30、行数据库可以利用索引以及各种统计信息来优化物理执行过程，因此该系统执行效率应该是最高。五 Dremel、impala 都只适合中间结果越来越小的查询，因为这些系统都是把中间结果放在内存，一旦某个中间节点输出结果超过内存，则整个任务会失败，例如大表之间 Join。六 shard query 和 citusdb 都是在单机版本关系数据库基础上，采用增加一层中间件方式来支持并行查询。n 基于 Tree 并行计算引擎与基于 DAG 并行计算引擎本质区别 基于 Tree 结构并行计算引擎与基于 DAG 并行计算引擎从表面上看，它们之间的主要区别是在于语义层面：前者主要专用与 SQL 类，而后者更通用。但

31、是 MPP 并行关系数据库引擎、Imapla 等都会支持通过 UDF 来扩展和解决标准 SQL 语言表达能力，另外 SQL 语言本身可以通过嵌套查询、子查询、union等各种方法表达很复杂的计算过程，因此从语义表达层面来讲他们之间不存在本质区别。这两者之间主要区别还是在于表达执行计划结构方面：树结构是一个逐步汇聚的一个计算过程，无法表达 split 结构，因此基于 DAG 表达结构更灵活和通用。个人认为：树型结构可能更加适合采用迭代器模型来实现流水线式的操作(只有树结构才有上下层的关系，因此方便实现上层操作符嵌套调用下层操作符)。所以不是所有计算都可以通过一个复杂 SQL 语句来表达！(5)自

32、动并行化、数据重分布、本地调度 并行计算引擎最重要的一个职责是自动并行。根据前面的并行计算基础知识，并行计算的形式主要包括：基于数据划分水平并行、基于流水线垂直并行、基于无依赖水平并行三种方式。大数据属于数据密集型计算，数据数量远远超过计算步骤数量。因此基于数据划分并行方式是最有效的一种并行计算方法。在整个并行计算过程中，基于数据划分中涉及数据可以分为两大类：原始数据与中间结果数据。n 原始数据划分以及 SN、SD 架构讨论 原始数据则可能存在两种情况：一是在 Shared-nothing 架构中，原始数据本身就已经划分好了，例如 HDFS 或者 SN 架构 MPP 数据库；另外一种情况如sh

33、ared-disk 结构中，原始数据没有划分。第一种情况下针对原始数据划分并行计算，就要受该划分的限制。例如在MAPREDUCE 中，map 输入是存储在 HDFS 上的数据文件，因此 MAP 实例个数一是不能少于该数据文件分片数，二是 MAP 实例最好运行在该数据文件所在机器，也就是要求任务调度时，能把该任务调度到特定机器上，即所谓“本地调度”，将计算尽量移动到数据。第二种情况下，由于所有计算节点都可以看到所有数据，因此此时可以根据计算特点灵活选择：数据划分粒度、并行度、参与计算的节点。例如在 ORALCE 并性机制中，ORALCE可以针对某张表，按block或者partition 为单位进

34、行划分。根据上述分析我们可以发现 SD 架构相对 SN 架构，在针对原始数据第一级并性计算时，SD 架构更灵活，SN 架构面临的一个缺陷就是如果原始数据分布不均衡，则存在计算倾斜问题。但是现在大部分大的数据库厂商的 MPP 数据库还是采用了 SN 架构。根据网上所查资料来看,主要原因有两点：一是SD架构下，磁盘是一个共享资源，计算节点越多磁盘争抢概率越大(和RAID随机 IO 冲突道理一样)，导致该架构可扩展性不够好，也就是可能计算节点越多，效率相反不会提高。二是从缓存角度来看，SD 架构下每个机器缓存都要面向全数据库，会导致命中概率底下；目前 ORACLE-RAC 开发一个 fusion c

35、ache 技术，实现了一个全局共享缓存来解决上述问题，但是可想而知这会影响系统可扩展性。因此超过一定规模数据分析系统，都是采用 SN 架构。中间结果数据划分与数据重分布 中间结果是由各个计算节点产生的，因此中间结果生成是就是分布在各个参与计算节点之上的，因此：一：SD 架构下数据共享好处，对中间结果无效。二：如果由于计算任务之间需要，需要在任务之间传递中间结果，则即使是 SD架构也存在数据重分布的问题，主要是中间结果重分布，也就是中间结果传输。另外从该过程我们还可以得出另外一个结论：一：对于复杂的数据处理，索引只能影响第一级计算，对于中间结果，由于只使用一次，因此没有必要去针对中间结果建立索引

36、。也就是即使我们将数据存储在关系型数据库中，也只有第一级计算能有效利用数据库索引。二：即使采用并行数据库，如果我们的整个计算过程不能用一个SQL 语句来表达，则我们必须自己解决中间结果的划分与并性计算的问题。(6)并行计算引擎架构与资源管理 所有并行计算引擎实现基本上都是主从结构，即一个 MASTER+多个 slave 节点的结构。由 client 向 MASTER 提交一个 job,然后由 Master 负责将逻辑执行计划变成实际执行计划，并由 Master 负责将各个任务分发到各个 slave 中，并负责各个任务的调度。MPP 数据库查询引擎架构 MAPREDUCE 架构和该架构缺点 Ma

37、preduce 框架中，JobTracker 承当 MASTER 的职责，一般和 HDFS 中的NadeNode 节点安装在一个服务器上。TaskTracker 安装在各个 DataNode 上，承担 Slave 的角色。流程如下：(1)首先用户程序(Client Program)提交了一个 job，job 的信息会发送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他需要与集群中的机器定时通信(heartbeat),需要管理哪些程序应该跑在哪些机器上，需要管理所有job 失败、重启等操作。(2)TaskTracker 是 Map-reduce 集

38、群中每台机器都有的一个部分，他做的事情主要是监视自己所在机器的资源情况（资源的表示是“本机还能起多少个map-task，多少个 reduce-task”，每台机器起 map/reduce task 的上限是在建立集群的时候配置的），另外 TaskTracker 也会监视当前机器的 tasks 运行状况。(3)TaskTracker 需要把这些信息通过 heartbeat 发送给 JobTracker，JobTracker 会搜集这些信息以给新提交的 job 分配运行在哪些机器上。MAPREDUCE 结构存在以下缺点：(1)jobtracker 只能安装在一台服务器上，集中式作业控制导致可扩展性

39、不好，另外 JobTracker负责事情太多，容易成为性能瓶颈。(2)资源调度与编程模型紧耦合，只支持 MAPREDUCE 一种编程模型。(3)资源划分太简单，每个 TaskTracker 只是简单把整个机器资源按 map task slot 和 reduce task slot 来划分，而没有考虑不通任务所需的内存和 CPU 等的资源不同。针对上述特点，hadoop 平台开发通用的资源管理器 yarn，只负责资源管理和分配，即通过把 jobtrack 中的资源管理分配自和并行应用程序调度与控制分离，从而实现双层调度框架：由 yarn 把资源分配给各计算引擎 MASTER，再由MASTER 分

40、配给各个 TASK。资源管理器 YARN 流程如下：1)client 通过一个 CLC(container launch context)向 ResourceManager提交一个应用 2)RM 启动该应用的 AplicationMaster。AplicationMaster 启动后先向ResourceManager 注册，并利用心跳信息，定期向 ResourceManager 报告自己存活性和资源分配请求 3)ResourceManager 分配一个 container(container 包括 CPU 个数和所需内存数量)时，AplicationMaster 构造一个 CLC,并在该 co

41、ntainer 对应机器上Nodemanager 上启动该 container。AplicationMaster 监控该 container 的运行状态，并且该资源需要被回收时，由 AplicationMaster 停止该 container。监控 container 内部的作业的执行进度是 AplicationMaster 的职责。4)一旦整个运行完毕，AM 从 RM 中解除注册，并且干净退出。这种架构优点是：优点一：减小了 JobTracker（也就是现在的 ResourceManager）的资源消耗，并且让监测每一个 Job 子任务(tasks)状态的程序分布式化了，更安全、更优美。也就

42、是 ApplicationMaster 是每个应用一个，并且不通应用对应的ApplicationMaster 的实例可以运行在不同服务器上。优点二：能够支持不同的编程模型 ApplicationMaster 是一个可变更的部分，用户可以对不同的编程模型写自己的 ApplicationMaster，让更多类型的编程模型能够跑在 Hadoop 集群中。优点三：对于资源的表示比之前以剩余 slot 数目更合理。3)存储层 数据存储层主要包括以下几类：一类是基于 MPP 数据库集群，这类系统特点是存储层与上层并型计算引擎是紧耦合，属于封闭性的系统。二是采用分布式文件系统，例如 SharK、Stinge

43、r、HIVE、Impala、Scope 等。Shark、Stinger、Hive、Imapla 都采用 HDFS 文件系统作为存储层，Scope采用微软自己开发的分布式文件系统。此类系统特点是存储层与上层计算引擎层之间是松耦合关系。三是存储层基于单机版本关系数据库，例如 CitusDB 采用 PostSQL 数据库系统、shardquery 采用 Mysql 数据库系统。此类系统类似于一个中间件，也可以认为上层和底层存储层属于松耦合关系。四是可以支持各种异构的存储系统，例如 Presto、Tenzing。Presto 设计即支持 HDFS 也支持存储在 Mysql 中的数据，但是目前只支持 H

44、DFS;Tenzing 底层支持：Google File System、MySQL、Bigtable。不同存储系统对上层计算有一些影响，典型如 Tenzing 系统会利用底层存储系统的一些特性：(1)例如如果低层是 mysql 数据库，则可以直接利用 mysql 索引来过滤(2)如果底层是 bigtable 数据库，则可以直接利用 bigtable 范围 scan 来过滤(3)如果底层是列存储系统，则可以只扫描需要扫描的列。(4)如果底层是列存储系统，且头文件里面有该列最大值和最小值，则可以利用该信息直接跳过某些文件的扫描。另外需要指出的是，目前已上所有系统都有一个趋势就是采用列式存储。例如H

45、IVE 开发了行列混合的 RCFILE 文件格式(先按行划分，保证每行的数据不会垮机器存储，然后再按劣存储)，shark 系统开发了内存中的列式存储格式，citusDB开发了专用 postSQL 数据库的列式存储引擎。3 Druid 等专用系统简单介绍 1)JethroData 系统 JethroData 的特点是 hadoop+index。该系统对存储在 HDFS 上的结构化数据建立索引，并把索引文件也以普通文件方式存储在 HDFS 系统，并在查询处理时采取以下过程：(1)查询主节点负责分析 SQL 语句后，针对 sql 中的 where 条件部分，利用索引文件来得到符合 where 过滤条

46、件后的 rowid 集合。(2)该 rowid 集合涉及各 datanode 节点，采用并发方式来读取数据。(3)所有数据汇总到查询主节点，进行汇总与计算，并将最终结果返回给客户端。可以看出，由于该系统设计思路是希望通过索引来加速数据选择，因此只适合每次查询处理只涉及少量一部分数据。2)Druid 系统 本系统是美国 metamarket 公司开发的面向海量数据的实时统计分析系统，以实现针对上亿级别海量数据统计分析的延迟在 1 秒以内。该系统于 2012 年 10月开源。该系统可以认为是一个分布式的内存OLAP 系统。该系统主要分析的数据为交易记录，每条交易记录包括三个部分：交易发生的时间点、

47、多个维度属性、多个数值型度量属性。例如：该系统设计用来可以回答以下问题“有多少个针对 Justin Bieber 的编辑来自San Francisco?”、“一个月内来自 Calgary 的增加编辑字数的平均数是多少？”。而且要求：能够在高并发环境下，在 1 秒以内完成任意维度组合的统计，且保证系统高可用；还系统还要能够具备实时数据分析能力，也就是能够查询分析到最新的数据，延时时间为秒级。为了达到上述目标，该公司先后通过测试发现关系数据库技术和 NOSQL 数据库都无法满足其需求。关系型数据库由于磁盘 io 瓶颈导致性能无法满足需求，而NOSQL 数据库虽然可以采用预计算方法来达到高性能，但是

48、预计算无法满足分析需求灵活多变。为解决该问题，该公司自己开发 DRUID 系统，主要技术思路如下：(1)将原始数据(alpha数据)进行一定粒度合并，合并成 beta 数据。(2)将 beta 数据全部放入内存，并通过分布式内存方式解决单台服务器内存 上限问题。(3)针对纬度属性建立索引，以加速数据的选取。(4)采用分布式方式进行并行统计，为了保证分布式统计高效，该系统不支持join，而且对聚合计算不支持中位数等无法分布计算的聚合计算函数。(5)利用数据复制解决系统高可靠性问题。4 本章总结 1)MPP 并行数据库得益于流水线的执行以及基于统计优化等方面，使得 MPP并行数据库的执行效率是最高

49、的。但缺点包括：n 数据导入时间长，导入时要做各种预处理，例如一些统计信息；n 执行引擎和存储紧耦合导致数据难以被其他分析引擎进行分析；n 基于树型结构执行计划，导致 MPP 并行数据库表达能力有限，更适合做统计与查询，而不适合数据分析处理；n 容错性差，特别是一个任务涉及数据量越大，该缺陷越明显。2)HIVE、Tenzing、Shark、SCOPE、Stinger 等系统可以认为基本属于同一类系统。这类系统共同特点是：”通用并行计算引擎框架+SQL 解析层”。并且可以将 HIVE、Tenzing 看成是基于第一代系统，而 Shark、Scope、Stinger 是第二代系统。这一类系统特点如

50、下：n 存储层、执行引擎层、SQL 解析层三者分离，可以方便替换执行引擎，对使用者而言，同一份数据可以采用不同并行执行引擎来分析。n 在执行效率方面，由于存储和上层分离因此一半只能具备逻辑优化能力，另外由于 Tree 结构执行计划更容易采用流水线执行方式，因此这类系统执行效率总体来讲不如MPP关系数据库，它们之间排序是MPP数据库 第二代系统 第一代系统。n 在执行效率方面，另外一点是这类系统一般内置对索引的支持不是太好或者不支持。n 在大规模计算容错方面，这类系统要优于 MPP 关系数据库。3)Impala、Dremel 等可以认为属于同一类系统，此类系统介于前两者系统之间。这类系统特点是：