大数据分析技术研究报告(二)
二 大数据背景下事务型处理系统相关技术
在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本章总结
数据量大不一定需要并行计算，虽然数据量大，数据是分布存储，但是如果每次操作基本上还是针对少量数据，因此每次操作基本上都是在一台服务器上完成，不涉及并行计算。只是需要通过数据复制、数据缓存、异步处理等方式来支撑高并发访问量。