在我们的实际生活中，办公型数据处理的需求非常常见。 例如淘宝网网站交易系统、12306网站火车票交易系统、超级销售点系统等都是办公型数据处理系统。
一数据分析处理需求分类
1 事务型处理
在我们的实际生活中，办公型数据处理的需求非常常见。 例如淘宝网网站交易系统、12306网站火车票交易系统、超级销售点系统等都是办公型数据处理系统。
这类系统数据处理特点包括以下几点：
第一，事务性操作是一种细分操作，每个事务涉及的数据量很少。
二是计算比较简单，一般由少数操作组成，如修改某一行某一列；
第三，事务处理操作与添加、删除、修改和调查数据有关，对事务完整性和数据一致性要求非常高。
第四，所有事务操作都是实时交互操作，至少可以在几秒钟内执行。
五、基于以上特点，索引是支撑办公型处理的非常重要的技术。
如果数据量和并发事务量很少，通常依赖于独立的关系数据库(如ORACLE、MYSQL或SQLSERVER )，并添加高可用性措施(如数据复制、RMAN或MYSQL数据复制)
当数据量和并发交易量增加时，通常可以采用ORALCE RAC集群方式，也可以通过硬件升级(采用小型机、大型机等，银行系统、运营商计费系统、证书卷系统等)进行支持。
对于淘宝、12306等互联网企业来说，事务性操作由于数据量大、访问并发性强，必然会采用分布式技术进行应对，带来分布式事务处理问题，但也能高效地进行分布式事务处理
2 数据统计分析
数据统计主要是各类企业分析自己的销售记录等企业日常运营数据，辅助企业管理层做出运营决策。 典型使用场景为周报表、月报表等一定时间提供给导师的各种统计表； 营销部门通过各种维度的组合进行统计分析，制定适当的营销战略等。
数据统计分析特点包括以下几点：
一是数据统计一般涉及大量数据的聚合运算，每个统计的数据量都很大。
第二，数据统计分析的计算相对复杂，包括goupby、子查询、嵌套查询、窗口函数、聚合函数和排序。 根据复杂的统计信息，可能需要编写SQL脚本来实现。
三是数据统计分析实时性比较事务型操作要求高。 但是，除了固定报告以外，越来越多的用户希望进行交互式实时统计；
传统的数据统计分析主要采用基于MPP并行数据库的数据仓库技术。 主要采用维度模型，通过预计算等方法，将数据组织成适合统计分析的结构，实现高性能的数据统计分析，支持通过向下钻取和向上钻取操作实现各种维度的组合和各种粒度的统计分析。
另外，目前在数据统计分析领域，为了满足交互式统计分析的需要，基于内存计算的数据库仓库系统也呈发展趋势，如SAP的HANA平台。
在这里我还是要推荐下我自己建的大数据学习交流qq裙：522189307 ， 裙 里都是学大数据开发的，如果你正在学习大数据 ，小编欢迎你加入，大家都是软件开发党，不定期分享干货（只有大数据开发相关的），包括我自己整理的一份最新的大数据进阶资料和高级开发教程，欢迎进阶中和进想深入大数据的小伙伴。上述资料加群可以领取
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本章总结
数据量大不一定需要并行计算，虽然数据量大，数据是分布存储，但是如果每次操作基本上还是针对少量数据，因此每次操作基本上都是在一台服务器上完成，不涉及并行计算。只是需要通过数据复制、数据缓存、异步处理等方式来支撑高并发访问量