大数据处理技术的总结与分析.docx
《大数据处理技术的总结与分析.docx》由会员分享，可在线阅读，更多相关《大数据处理技术的总结与分析.docx（43页珍藏版）》请在冰点文库上搜索。
大数据处理技术的总结与分析
数据分析处理需求分类
1事务型处理
在我们实际生活中，事务型数据处理需求非常常见，例如：
淘宝网站交易系统、12306网站火车票交易系统、超市POS系统等都属于事务型数据处理系统。
这类系统数据处理特点包括以下几点：
一是事务处理型操作都是细粒度操作，每次事务处理涉及数据量都很小。
二是计算相对简单，一般只有少数几步操作组成，比如修改某行的某列；
三是事务型处理操作涉及数据的增、删、改、查，对事务完整性和数据一致性要求非常高。
四是事务性操作都是实时交互式操作，至少能在几秒内执行完成；
五是基于以上特点，索引是支撑事务型处理一个非常重要的技术。
在数据量和并发交易量不大情况下，一般依托单机版关系型数据库，例如ORACLE、MYSQL、SQLSERVER，再加数据复制（DataGurad、RMAN、MySQL数据复制等）等高可用措施即可满足业务需求。
在数据量和并发交易量增加情况下，一般可以采用ORALCERAC集群方式或者是通过硬件升级（采用小型机、大型机等，如银行系统、运营商计费系统、证卷系统）来支撑。
事务型操作在淘宝、12306等互联网企业中，由于数据量大、访问并发量高，必然采用分布式技术来应对，这样就带来了分布式事务处理问题，而分布式事务处理很难做到高效，因此一般采用根据业务应用特点来开发专用的系统来解决本问题。
2数据统计分析
数据统计主要是被各类企业通过分析自己的销售记录等企业日常的运营数据，以辅助企业管理层来进行运营决策。
典型的使用场景有：
周报表、月报表等固定时间提供给领导的各类统计报表；市场营销部门，通过各种维度组合进行统计分析，以制定相应的营销策略等。
数据统计分析特点包括以下几点：
一是数据统计一般涉及大量数据的聚合运算，每次统计涉及数据量会比较大。
二是数据统计分析计算相对复杂，例如会涉及大量goupby、子查询、嵌套查询、窗口函数、聚合函数、排序等；有些复杂统计可能需要编写SQL脚本才能实现。
三是数据统计分析实时性相对没有事务型操作要求高。
但除固定报表外，目前越来越多的用户希望能做做到交互式实时统计；
传统的数据统计分析主要采用基于MPP并行数据库的数据仓库技术。
主要采用维度模型，通过预计算等方法，把数据整理成适合统计分析的结构来实现高性能的数据统计分析，以支持可以通过下钻和上卷操作，实现各种维度组合以及各种粒度的统计分析。
另外目前在数据统计分析领域，为了满足交互式统计分析需求，基于内存计算的数据库仓库系统也成为一个发展趋势，例如SAP的HANA平台。
3数据挖掘
数据挖掘主要是根据商业目标，采用数据挖掘算法自动从海量数据中发现隐含在海量数据中的规律和知识。
数据挖掘主要过程是：
根据分析挖掘目标，从数据库中把数据提取出来，然后经过ETL组织成适合分析挖掘算法使用宽表，然后利用数据挖掘软件进行挖掘。
传统的数据挖掘软件，一般只能支持在单机上进行小规模数据处理,受此限制传统数据分析挖掘一般会采用抽样方式来减少数据分析规模。
数据挖掘的计算复杂度和灵活度远远超过前两类需求。
一是由于数据挖掘问题开放性，导致数据挖掘会涉及大量衍生变量计算，衍生变量多变导致数据预处理计算复杂性；二是很多数据挖掘算法本身就比较复杂，计算量就很大，特别是大量机器学习算法，都是迭代计算，需要通过多次迭代来求最优解，例如K-means聚类算法、PageRank算法等。
因此总体来讲，数据分析挖掘的特点是:
1、数据挖掘的整个计算更复杂，一般是由多个步骤组成计算流，多个计算步骤之间存在数据交换，也就是会产生大量中间结果，难以用一条sql语句来表达。
2、计算应该能够非常灵活表达，很多需要利用高级语言编程实现。
二大数据背景下事务型处理系统相关技术
在google、facebook、taobao等大互联网公司出现之后，这些公司注册和在线用户数量都非长大，因此该公司交易系统需要解决“海量数据+高并发+数据一致性+高可用性”的问题。
为了解决该问题，从目前资料来看，其实没有一个通用的解决方案，各大公司都会根据自己业务特点定制开发相应的系统,但是常用的思路主要包括以下几点：
（1）数据库分片，结合业务和数据特点将数据分布在多台机器上。
（2）利用缓存等机制，尽量利用内存，解决高并发时遇到的随机IO效率问题。
（3）结合数据复制等技术实现读写分离，以及提高系统可用性。
（4）大量采用异步处理机制，对应高并发冲击。
（5）根据实际业务需求，尽量避免分布式事务。
1相关系统介绍
1） 阿里CORBAR系统
阿里COBAR系统是一个基于MYSQL数据库的分布式数据库系统，属于基于分布式数据库中间件的分布式数据库系统。
该系统是前身是陈思儒开发的“变形虫”系统（以前调研过），由于陈思儒离开阿里去了盛大，阿里当心“变形虫”稳定性等问题，重新开发该项目。
该系统主要采用数据库分片思路，实现了：
数据拆分、读写分离、复制等功能。
由于此系统由于只需要满足事务型操作即可，因此相对真正并行数据库集群（例如TeraData等），此类系统提供操作没有也不需要提供一些复杂跨库处理，因此该系统存在以下限制：
（1）不支持跨库的join、分页、排序、子查询。
（2）insert等变更语句必须包括拆分字段等。
（3）应该不支持跨机事务（以前变形虫不支持）。
说白了此类系统不具备并行计算能力,基本上相当于数据库路由器！
另外此类系统的在实际应用的关键问题是，根据什么对数据进行切分，因为切分不好会导致分布式的事务问题。
2） 阿里OceanBase系统
该系统也是淘宝为了解决高并发、大数据环境下事务型处理而定制开发的一个系统。
该系统主要思路和特点如下：
（1）他们发现在实际生成环境中，每天更新的数据只占总体数据的1%不到，因此他们把数据分为：
基线数据和增量更新数据。
（2）基线数据是静态数据，采用分布式存储方式进行存储。
（3）只在一台服务器上存储和处理增量更新数据，并且是在内存中存储和处理更新数据。
（4）在系统负载轻的时候，把增量更新批量合并到基线数据中。
（5）数据访问时同时访问基线数据和增量更新数据并合并。
因此这样好处是：
（1）读事务和写事务分离
（2）通过牺牲一点扩展性（写是一个单点），来避免分布式事务处理。
说明：
该系统虽然能处理高并发的事务型处理，号称很牛逼，但其实也只是根据电商的事务处理来定制开发的专用系统，个人认为其技术难度小于oracle等通用型的数据库。
该系统无法应用到银行或者12306等，因为其事务处理的逻辑远远比电商商品买卖处理逻辑复杂。
在目前的大数据时代，一定是基于应用定制才能找到好的解决方案！
3） 基于Hbase的交易系统
在hadoop平台下，HBASE数据库是一个分布式KV数据库，属于实时数据库范畴。
支付宝目前支付记录就是存储在HBASE数据库中。
HBASE数据库接口是非SQL接口，而是KV操作接口（基于Key的访问和基于key范围的scan操作），因此HBASE数据库虽然可扩展性非常好，但是由于其接口限制导致该数据库能支持上层应用很窄。
基于HBASE应用的设计中，关键点是key的设计，要根据需要支持的应用来设计key的组成。
可以认为HBASE数据库只支持作为KEY的这一列的索引。
虽然目前HBASE有支持二级索引的方案，二级索引维护将会比较麻烦。
2并发和并行区别
并发是指同时执行通常不相关的各种任务，例如交易型系统典型属于高并发系统。
并行是通过将一个很大的计算任务，划分为多个小的计算任务，然后多个小计算任务的并行执行，来缩短该计算任务计算时间。
两者主要区别在于：
（1）通讯与协调方面：
在并行计算中，由于多个小任务同属一个大的计算任务，因此小任务之间存在依赖关系，小任务之间需要大量通讯和协调；相反，并发中的多个任务之间基本相互独立，任务与任务之间相关性很小。
（2）容错处理方面：
由于并发任务之间相互独立，某个任务执行失败并不会影响其它的任务。
但是并行计算中的多个任务属于一个大任务，因此某个子任务的失败，如果不能恢复（粗粒度容错与细粒度容错），则整个任务都会失败。
3本章总结
数据量大不一定需要并行计算，虽然数据量大，数据是分布存储，但是如果每次操作基本上还是针对少量数据，因此每次操作基本上都是在一台服务器上完成，不涉及并行计算。
只是需要通过数据复制、数据缓存、异步处理等方式来支撑高并发访问量
三大数据背景下数据统计分析技术介绍
随数据量变大，和事务处理不同的是，单个统计分析涉及数据量会非常大，单个统计分析任务涉及数据会分散在多台服务器上，且由于计算量大，采用单台服务器进行计算，会导致计算时间非常长，单个统计分析任务必须采用并行计算方式来加快单个统计分析任务执行速度。
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、Shardquery、Citusdb。
n 基于SPARK的Shark、基于Dryad的SCOPE、基于Tez的stinger。
n 基于hadoop+index的JethroData系统
n 基于内存计算的Druid系统
这些系统都解决了海量数据下的数据统计分析的问题，并且这些系统另外一个共同特点是都提供了SQL或者类SQL接口。
为了能够较好研究这些系统，我们需要对并行查询与并行计算的相关技术做一个简要的介绍。
首先所有的系统都可以分为三个层次:
语义层、并行计算引擎层、分布式存储层。
语义层提供一个编程接口让用户表达所需要计算，并负责把该计算翻译成底层并行计算引擎可以执行的执行计划，并由并行计算引擎来执行，最下面一层是分布式存储层。
对于提供类SQL接口并行计算系统，语义层可以认为是SQL解析层。
1）语义层
SQL语言是一种声名式语言，SQL只是表达了要做什么，而没有表达怎么做。
为此，SQL解析层主要作用是：
将用户提交的基于SQL的统计分析请求，转化为底层计算引擎层可以执行的执行计划。
也就是解决“怎么做”的问题。
SQL解析层工作主要包括两个大方面:
（1）通过语法分析技术来理解要做什么。
在关系数据库中，一般会把SQL语言分析后，形成树型结构的执行计划。
（2）在语法分析技术上，利用各种优化技术和算法，找出一种最经济物理执行计划。
优化可以分为两个方面：
一是逻辑层面优化、二是物理执行层面优化。
（1）逻辑层优化
逻辑层面个人认为主要是因为同样表达一个分析请求，有的人SQL写的好，有的人SQL写的烂，因此在逻辑层面可以通过一些等价关系代数变换，实现查询重写，将写的比较烂的sql变换为好的写法。
比较典型优化是：
“把投影和过滤下沉，先执行过滤和投影操作”，减少中间结果。
（2）物理层优化
物理层面优化是在逻辑优化后，结合实际物理执行过程，找出最优的物理执行计划。
生成物理查询计划的工作包括:
ü 增加一些操作符：
包括扫描和排序等。
ü 确定各个操作符实现算法。
例如扫描是全表扫描还是利用索引；Join是采用HASH连接、索引连接、合并排序等实现算法中的那一种。
ü 确定操作符之间的数据流转方法：
物化还是流水线方式。
ü 采用基于代价估算方法确定最优的物理执行计划，目前代价估算主要是以估算该物理计划需要的IO量。
另外对于并行数据库，则还要考虑通讯代价，即尽量减少数据在各个机器之间的传递。
在物理层优化的代价估算过程中，代价估算需要依靠很多统计信息，如表有多大，表中相关列的值分布是什么样子等。
传统数据库在数据Load过程中会事先计算好这些统计信息。
并行计算中还需要考虑通讯代价。
需要指出是，由于imapla、Presto、HIVE等系统只是一个查询引擎，它们可以直接查询以普通文件方式存储在HDFS系统上的文件，因此这些系统一般无法使用索引和各种统计信息来进行物理执行计划的优化，这些系统一般只能在逻辑层进行一些基于规则静态优化。
根据SHARK论文，SHARK系统支持根据前面一些节点计算获得的信息，来动态优化后面执行计划。
（3）物化与流水线执行方法
一条SQL语句对开发人员而言，感觉只是一次调用，但是实际上在数据库内部，一条SQL语句执行其实是有多个操作符组合而成的的树型结构计算流。
如下图：
针对该计算流有两种执行方式：
一是基于物化或者是实体化执行方式，另外一种是基于数据流的执行方式。
第一种方法的过程是：
把各个操作运算排序，并把每个操作运算的输出的中间结果存储在磁盘上，直到被另外一个操作运算所读取。
另外一种方法是同时交错进行多个运算，由一个运算产生每个元组直接传递给下一个运算，而不将中间结果存储到磁盘，也不用等到前一个运算全部运算完毕。
例如：
两个表连接后，再进行投影操作。
如果采用第一种方法，则需要
把两表连接中间结果临时写入磁盘，然后再读取该结果执行投影操作。
而如果采用第二种方法，则连接操作一旦产生一个元组就可以立刻送到投影操作去进行投影操作。
流水线方法可以极大避免大量的中间结果磁盘IO。
因此数据库一般会采取流水线方法来执行。
流水执行方法有两种模式：
一种是需求驱动流水线，也就是从上层主动向下层要求元组，另外一种是生产者驱动流水线执行方式，由低层主动产生元组，由下层向上层推。
目前大部分数据库引擎采用的是需求驱动流水线，实现方式采用基于Graefe提出的迭代器模型。
该模型把每个操作都表达为由三个接口：
open（）, getnext（）,close（）。
每个操作被调用open（）进行准备工作，然后通过反复迭代被调用getnext来获取下一个元组，最后被调用close来进行清理工作。
通过构建迭代器网络，也就是迭代器之间的互相调用，就可以实现需求驱动流水线。
当然不是任何操作都可以流水执行，流水执行条件是：
操作要满足在接收输入元组时可以输出元组。
例如排序操作就无法进行流水操作，在执行排序操作前都必须进行实体化。
（4）SQL解析层与并行计算引擎层
由于不同并行计算引擎层的执行计划表达不同，因此不同系统需要将SQL解析成不同的形式物理执行计划，例如：
MPP关系数据库一般是把SQL解析成树状结构的物理执行计划。
HIVE、Tezning数据库是把SQL解析成DAG结构的多个MAPREDUCE组合。
DRemel等则类似MPP关系数据库，把SQL解析成一个树状结构执行计划。
微软SCOPE则需要把类SQL解析成DAG结构的Dryad可执行的执行计划。
SHARK则需要把SQL解析成基于scala语言的DAG结构执行计划。
并发
并行
2）并行计算引擎层
（1）并行计算形式
并行化可以分为水平并行（无依赖并行）与垂直并行（流水线并行）两类。
如下图：
如果两个操作OP1、OP2无相互依赖关系，则称这两个操作相互独立。
水平并行化指的是互相独立的多个操作或者一个操作内互相独立的多个子操作分别由不同的处理机并行执行的形式。
例如，排序操作、扫描操作由不同处理机并行执行就是水平并行化的实例。
水平并行中一个非常常见的就是基于数据划分的并行，例如MAPREDUCE，就是通过将数据划分到多台服务器上，并行执行MAP和Reduce来进行并行运算。
也有人把这种基于数据划分并行与操作独立并行区分开。
垂直并行化则是指存在流水线方式依赖关系的操作分别由不同处理机并行执行的形式。
流水线方式依赖：
如果OP2无需等待OP1执行完毕即可在另一处理机上开始执行。
由于一般情况下，流水的级数远小于处理的数据条目，因此流水并行主要意义是在可以避免中间结果磁盘IO操作，对并行度的贡献相对较小。
（2）并行计算面临的问题与并行计算框架
并行计算需要解决的问题主要包括几下几个方面：
自动并行化、通讯、任务调度、并发控制、容错、资源管理。
由于并行计算面向上述一系列问题，因为业界为了简化并行程序开发，提供了一系列的并行计算底层库或者框架。
在高性能计算领域，最常用于并行计算编程的库是MPI库，但是该库主要只是解决通讯问题。
这导致容错、资源管理、任务调度、并行化等方面问题需要程序员来解决，因此利用MPI开发并行程序相对比较困难。
最近一些年，各大型互联网公司开发开发了一系列的通用并行计算框架。
包括谷歌公司的MAPREDUCE框架、微软公司的Dryad框架（目前微软已经停止该项目开发，转而支持hadoop）、谷歌公司基于BSP模型的Pregel框架、Twitter公司的Storm框架、Yahoo公司S4框架、HortonWorks公司的Tez框架、Berkeley大学的spark框架等通用并行计算框架。
有了这些框架了，程序开发时只需要编写串行执行程序即可，而且也不用考虑任务与任务之间的并发控制以及通讯等问题，其它所有问题都有框架来解决，这样就大大简化并行程序开发难度。
例如采用MAPREDUCE框架，我们只需要提供MAP函数和Reduce函数，这些函数对程序员而言，都只是对本地数据操作。
目前虽然并行计算框架很多，但是可以把它们分成几个大类（基于BSP并行图计算引擎请参考第四章）：
流数据并行计算框架
Storm、S4是属于流数据并行计算框架，适合对流数据实时处理，也就是在数据写入磁盘前对数据进行实时并发运算。
这类特点是计算不变，数据一直在变化。
在上一个文档中，对此框架做过详细介绍，这里不再详细介绍。
基于DAG通用批处理并行计算框架
MapReduce、Tez、Dryad、Spark等属于基于DAG（有向无环图）的通用批处理并行计算框架。
这类框架是针对存储在存储设备上的一批数据进行分析处理，而且把分析处理流程利用DAG模型来表达。
在这些框架中MAPREDUCE是最早出现的框架，而后面出现的一系列框架都为了改进MR框架不足而出现的升级版本。
MR框架主要不足是两个方面：
一是编程接口太简单，表现在单个MAPREDUCE无法表达复杂运算，所以在实际应用环境中都是通过多个MR作业组合来完成一个任务。
为了简化MR作业组合，在早期出现了一系列项目来执行组和式MR作业，例如Cascading项目。
另外一个方面所有问题都必须转换为MAP和REDUCE模式，导致程序编写比较麻烦。
二是MR只支持基于数据分区并行方式，不支持流水线并行，采用是步步物化策略来提高可靠性，当是这种导致大量中间结果物化，IO开销非常大。
因此Tez、Dryad、Spark等后续框架改进主要针对以下两点进行改进：
一是直接支持基于DAG结构表达方法，DAG使得用户能够非常清晰地写出非常复杂的业务逻辑；
二是通过支持流水线并性方式或者是尽量将中间结果放内存等方式，解决中间结果物化导致的IO开销问题。
Dryad和Spark框架在执行运算时，都会自动识别可以采取流水线方式执行的计算步骤，并尽量采用流水线执行方式来执行。
容错：
由于支持流水线并行或者采取把中间结果放内存的方式，因此要必须考虑容错的问题。
由于这些框架都采用的是DAG结构，DAG中一个节点所代表计算的执行是不会对输入进行修改（所谓函数式编程），因此可以多次重复执行不会影响计算。
因此如果某个节点计算失败，它可以根据输入重复计算，而如果输入数据也消失了，则让前一个节点重新计算。
所有这一切都是由框架自动执行。
当然需要指出的是对一些流水线执行的多个计算步骤，如果某个计算节点失败，则只能整个流水线整体失败。
基于Tree结构的MPP并行查询引擎
MPP并行数据库与Dremel、impala、Presto、Shardquery、Citusdb都采用的是基于Tree结构并行查询引擎。
此类并行计算引擎共同特点是：
一是针对SQL专用并行计算引擎，只支持SQL或者类SQL语义。
二是执行计划都是树状结构；
三是以流水线或者将中间结果放入内存方式来实现快速计算。
四是粗粒度容错机制。
它们之间不同点：
一MPP并行数据库中并行查询引擎与底层存储是紧耦合的，导致如果采用MPP并行数据库，则只能通过SQL来访问数据，无法采用其他计算引擎直接处理存储在数据库中的数据。
二Impala、Presto都只是一个并行查询引擎，它们可以直接查询以文件方式存储在HDFS上的数据,这样同一份数据既可以利用这些引擎来实现交互式查询，也可以支持利用其他计算框架进行更深入分析。
三Dremel只支持Google自己的基于嵌套结构列式存储（ColumnIO）。
该引擎也主要适合于聚合型计算，不支持join操作。
四上述引擎中只有MPP并行数据库可以利用索引以及各种统计信息来优化物理执行过程，因此该系统执行效率应该是最高。
五Dremel、impala都只适合中间结果越来越小的查询，因为这些系统都是把中间结果放在内存，一旦某个中间节点输出结果超过内存，则整个任务会失败，例如大表之间Join。
六shardquery和citusdb都是在单机版本关系数据库基础上，采用增加一层中间件方式来支持并行查询。
n基于Tree并行计算引擎与基于DAG并行计算引擎本质区别
基于Tree结构并行计算引擎与基于DAG并行计算引擎从表面上看，它们之间的主要区别是在于语义层面：
前者主要专用与SQL类，而后者更通用。
但是MPP并行关系数据库引擎、Imapla等都会支持通过UDF来扩展和解决标准SQL语言表达能力，另外SQL语言本身可以通过嵌套查询、子查询、union等各种方法表达很复杂的计算过程，因此从语义表达层面来讲他们之间不存在本质区别。
这两者之间主要区别还是在于表达执行计划结构方面：
树结构是一个逐步汇聚的一个计算过程，无法表达split结构，因此基于DAG表达结构更灵活和通用。
个人认为：
树型结构可能更加适合采用迭代器模型来实现流水线式的操作（只有树结构才有上下层的关系，因此方便实现上层操作符嵌套调用下层操作符）。
所以不是所有计算都可以通过一个复杂SQL语句来表达！
（5）自动并行化、数据重分布、本地调度
并行计算引擎最重要的一个职责是自动并行。
根据前面的并行计算基础知识，并行计算的形式主要包括：
基于数据划分水平并行、基于流水线垂直并行、基于无依赖水平并行三种方式。
大数据属于数据密集型计算，数据数量远远超过计算步骤数量。
因此基于数据划分并行方式是最有效的一种并行计算方法。
在整个并行计算过程中，基于数据划分中涉及数据可以分为两大类：
原始数据与中间结果数据。
n 原始数据划分以及SN、SD架构讨论
原始数据则可能存在两种情况：
一是在Shared-nothing架构中，原始数据本身就已经划分好了，例如HDFS或者SN架构MPP数据库；另外一种情况如shared-disk结构中，原始数据没有划分。
第一种情况下针对原始数据划分并行计算，就要受该划分的限制。
例如在MAPREDUCE中，map输入是存储在HDFS上的数据文件，因此MAP实例个数一是不能少于该数据文件分片数，二是MAP实例最好运行在该数据文件所在机器，也就是要求任务调度时，能把该任务调度到特定机器上，即所谓“本地调度”，将计算尽量移动到数据。
第二种情况下，由于所有计算节点都可以看到所有数据，因此此时可以根据计
升级会员 