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

  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里的分层思想