从大数据谈起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. 切分