从大数据谈起1：OLTP和OLAP的设计区别

     最近互联网技术有四个趋势非常火爆：

1. 移动
2. 社交
3. 云计算
4. 大数据

    这个文章系列主要讲大数据的一些方方面面。首先要讲的是一个抽象概念，可能很多人想起大数据必定首先想起hadoop和mysql集群一类的，可惜这些都是工具，并非是大数据的全部，只研究工具怎么玩在技术上就落了下乘。我们首先还是从概念来看，大数据处理系统概念其实很简单，只有两个组成部分：存储+查询。不管再复杂的大数据分析系统，都是这两个部分的组合： 存储是指将所有有效数据存放到介质中，必要时读取。这个数据的范围就太广了，包括了结构化的，常见比如数据库的数据表、比如订单、用户关系、收藏列表。也有可能是非结构化的，这种在互联网公司很常见，比如访问日志、新闻文本、邮件正文、微博内容等。查询其实是对数据的加工和变化，简单比如过滤、求和、求平均等，复杂的比如协同过滤， 自然语言处理。 我们最简单的来想可以把查询当做是对N维数据的变换输出。在设计大数据处理系统时，首先需要从这两个层面来考虑，需要考虑的因素包括：1、数据大小有多大；2、数据如何使用； 3、数据更新频率。

    不管再牛X的技术人员，都是要老老实实做需求的，老板简单的需求往往可以把几个超牛X的技术人员搞得痛不欲生。从目前来看需要大数据的主要应用领域，也只有两个： 联机事务处理OLTP（On-line Transaction Processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

OLTP一般就是把大数据用于在线业务，比如淘宝的订单交易、商品展示、历史交易、百度的网页搜索、新浪的微博内容展示等。这种需求要求有实时性，查询以后需要在秒级别返回，且对于服务稳定性和容错性有一定要求的。另外，读操作的数量远远大于写操作，且增量数据的大小要远远小于历史数据。在设计OLTP的数据系统中，主要技术难点有：

1. 分层
2. 分片
3. 分布式事务

    OLAP主要是做离线分析，对时效性要求不高，跑几个小时到几天问题都不大，并且机器挂了也没事，大不了restart一下。但是这种系统往往数据量非常大，维数特别多，基本都需要把历史数据全部扫描1-2遍。在设计OLAP系统里主要涉及到技术有：

1. 列存储
2. 降维
3. 切分

	OLTP	OLAP
用户	操作人员，低层管理人员	决策人员，高级管理人员
功能	日常操作处理	分析决策
设计	面向应用	面向主题
数据	当前的， 最新的细节的， 二维的分立的	历史的， 聚集的， 多维的，集成的， 统一的
存取	读/写数十条记录	读上百万条记录
工作单位	简单的读写	复杂查询
DB大小	0-100G	TB-PB级别

 

 

 

    从我自己的观点来看，OLTP做起来相对容易，并且企业产品和开源产品非常多。小型项目用mysql+redis+memcached足够应付。大型项目在开源社区的支持下，hadoop +hbase+redis也可以从无到有地应对需求，迅速减少小公司同大公司的差距。甚至连之前NOSQL的各大产品一直纠结的CAP原则，目前也隐隐有了逼近的解决方案，至少在可用性A和分区容忍度P达到的基础上，基本能把一致性C的延迟时间降低到秒级甚至毫秒级。而大型商业产品推出的分布式数据库，和一些开源分布式产品，例如淘宝开源的OceanBase都在保证分布式数据库的ACID的原子性上进行了一定程度的尝试。

而OLAP相对起来较为复杂，由于数据是多维的，以往以语义性著称的SQL语言也在数据分析时显得力不从心。在这方面建模和抽象变得很重要，如何解决数据的语义性和查询的可描述性变得很困难。相比起来，这方面的突破才显得不那么容易。目前OLAP主要的开源产品包括HDFS、HIVE和Impala等，至于商业产品，因为没有机会用到，在这里就不提了

    总体来看，如何根据需求来设计系统才是一个技术人员需要考虑的问题，过分的设计和过分的资源消耗都是不合适。下次我们再介绍下OLTP里的分层思想