一种HADOOP上的通用数据服务开发框架和机制

[size=xx-small]前言[/size]
如何快速的将hadoop上海量的数据快速的以可视化的方式展示给用户，很多传统的数据仓库或者OLAP在处理这种场景也是各种方式。我们这里数据平台采用了一种特殊的方式，
大大简化了数据产出的难度，提高了数据开发的成本。

[size=xx-small]核心模块[/size]
下图是常见的离线计算的数据流向图：

[img]http://dl.iteye.com/upload/attachment/0080/9224/d2e33b23-0c1a-347e-b541-c345edfbf7a8.jpg[/img]

这种大数据处理的框架的好处是隔离性好，数据存储在应用的关系型数据库之后，查询性能较好，在关系型数据库上建立索引，就能够很容易满足大部分查询情况。
我们团队在开发数据分析平台的时候，利用MYSQL采用了一种创新型的数据存储方式，并在此基础上形成了一套完整的数据交换，数据存储，以及数据服务。
其整体架构图如下：

[img]http://dl.iteye.com/upload/attachment/0080/9218/ef2d9525-4f21-3b2a-bd45-539f2e87dfba.jpg[/img]

其包含三个部分的处理模块：
[size=x-small]数据产出单元[/size]
这部分是数据ETL的开发，也就是产出数据的脚本，大部分是HIVE SQL，当然也有Map/reduce程序（以JAR包的方式），部署在HADOOP平台上，然后通过任务调度，循环执行产出数据。
这块的功能主要是在hadoop上，这里不详细描述了。

[size=x-small]数据交换单元[/size]
当用户在HADOOP上产出一份二维表的数据的时候（上面所讲的模块），常见的处理方式如下（左边的表示HADOOP表，右边表示关系型数据库表）


[img]http://dl.iteye.com/upload/attachment/0080/9226/32efb764-87c6-36f1-99b8-190da57d2570.jpg[/img]

在数据分析平台里面采用的方式是这样的，原始方式表和表的数据对拷，我们的方案变化为:所有的数据变成单表的一个字段


[img]http://dl.iteye.com/upload/attachment/0080/9222/5ffb39cf-50e7-3315-a6ea-249684898b0a.jpg[/img]

在这里CONTENT字段是利用了MySql的mediumtext字段，最大长度支持16777215个字符，换算出来大概是32M的容量。也就是说如果这个HADOOP上的按照日期的单表总数据容量不超过32M，那么就可以存成一个一个字符串。
其表结构的设计如下：

[img]http://dl.iteye.com/upload/attachment/0080/9232/50efb145-1bdc-37af-be08-4f38bc39daf8.jpg[/img]

考虑到通用性以及存储成本，在TXT，XML,JSON三种格式中选择了JSON，这样又可以节省不少存储空间,占用的网络带宽也小。
于是这样一种低成本的数据同步方案就达成了，其好处有：
1. 不需要单独在应用(数据分析平台) 新建任何数据表，只需要按照存储格式进行转换之后存如MYSQL（或者其他关系型数据库）的单表中；
2. 节省开发时间，可以快速建立数据同步和回流；
3. 数据解析的成本较小，采用通用性的JSON格式，可以直接输出成用户想要的格式；

不过这样的缺点也很明显：容易产生OOM；
当需要将数据还原的时候，需要花费大量的计算在解析JSON数据上；
所以我们统一做了一个解析JSON格式的小引擎来完成JSON数据还原为二维表的工作。原先采用JSONLIB格式解析JSON数据，发现性能有问题：当同时有多个用户在浏览大数据时，经常导致OOM。
当多个字符串JSON文本拼凑成一个完成的数据串时，会占用大量的内存，一下子就会撑满内存。典型的场景就是用户在导出/查询超过100W条记录的数据时，内存中都是非格式化的数据；以线上数据库4G内存为例，最多也就能容纳125条记录，也就100W条的数据（以每万条记录最多保存32M为例，实际情况可能根据每个hadoop表字段长短和字段值大小有关系）。

[size=x-small]数据解析单元[/size]
当数据存储在MYSQL单表数据库中，作为一个大文本字段之后，这些数据需要解析出来变成JAVA对象提供服务。所以需要设计一个解析引擎。

[img]http://dl.iteye.com/upload/attachment/0080/9228/c28f719b-4ef8-3c95-93cf-8c9996423b03.jpg[/img]

就是将上图3的数据流向变成反向：
从KV结构转变成标准的二维表结构

[size=xx-small]遇到的问题[/size]
1. 数据量大，解析查询耗时耗力；在采用分布式缓存之后，仍然会存在少量的OOM；
类似全网流量试图数据，每天有800W以上，一次查询仍然会导致OOM；
有张表每天800W的数据，大致会导致数据库每天增加20G左右的容量，导致磁盘空间写满；
下图是线上实际遇到的一个问题，海量的数据将磁盘写满：


2. 不能利用数据库中的索引以及SQL的各种功能，完全依靠查询时解析文本并拼凑数据，故目前只适合后台系统；
[size=xx-small]存储改进方案[/size]
将MYSQL的innodb引擎变成开源的infobright数据仓库引擎，非常方便的将数据LOAD到数据库里面
优点：
　　查询性能高：百万、千万、亿级记录数条件下，同等的SELECT查询语句，速度比MyISAM、InnoDB等普通的MySQL存储引擎快5～60倍
　　存储数据量大：TB级数据大小，几十亿条记录
　　高压缩比：在项目中可以达到10：1到40：1，极大地节省了数据存储空间
　　基于列存储：无需建索引，无需分区
　　适合复杂的分析性SQL查询：SUM, COUNT, AVG, GROUP BY

InfoBright的字段格式压缩：

[img]http://dl.iteye.com/upload/attachment/0080/9216/d434590b-5e97-34af-b99e-f6499ba37185.jpg[/img]

　　限制：
　　不支持数据更新：社区版Infobright只能使用“LOAD DATA INFILE”的方式导入数据，不支持INSERT、UPDATE、DELETE
　　不支持高并发：只能支持10多个并发查询；
非常适合这种海量数据的大容量存储与查询。