如何快速的将hadoop上海量的数据快速的以可视化的方式展示给用户，很多传统的数据仓库或者OLAP在处理这种场景也是各种方式。我们这里数据平台采用了一种特殊的方式，
大大简化了数据产出的难度，提高了数据开发的成本。
核心模块
下图是常见的离线计算的数据流向图：
这种大数据处理的框架的好处是隔离性好，数据存储在应用的关系型数据库之后，查询性能较好，在关系型数据库上建立索引，就能够很容易满足大部分查询情况。
我们团队在开发数据分析平台的时候，利用MYSQL采用了一种创新型的数据存储方式，并在此基础上形成了一套完整的数据交换，数据存储，以及数据服务。
其整体架构图如下：
其包含三个部分的处理模块：
数据产出单元
这部分是数据ETL的开发，也就是产出数据的脚本，大部分是HIVE SQL，当然也有Map/reduce程序（以JAR包的方式），部署在HADOOP平台上，然后通过任务调度，循环执行产出数据。
这块的功能主要是在hadoop上，这里不详细描述了。
数据交换单元
当用户在HADOOP上产出一份二维表的数据的时候（上面所讲的模块），常见的处理方式如下（左边的表示HADOOP表，右边表示关系型数据库表）
在数据分析平台里面采用的方式是这样的，原始方式表和表的数据对拷，我们的方案变化为:所有的数据变成单表的一个字段
在这里CONTENT字段是利用了MySql的mediumtext字段，最大长度支持16777215个字符，换算出来大概是32M的容量。也就是说如果这个HADOOP上的按照日期的单表总数据容量不超过32M，那么就可以存成一个一个字符串。
其表结构的设计如下：
考虑到通用性以及存储成本，在TXT，XML,JSON三种格式中选择了JSON，这样又可以节省不少存储空间,占用的网络带宽也小。
于是这样一种低成本的数据同步方案就达成了，其好处有：
1. 不需要单独在应用(数据分析平台) 新建任何数据表，只需要按照存储格式进行转换之后存如MYSQL（或者其他关系型数据库）的单表中；
2. 节省开发时间，可以快速建立数据同步和回流；
3. 数据解析的成本较小，采用通用性的JSON格式，可以直接输出成用户想要的格式；
不过这样的缺点也很明显：容易产生OOM；
当需要将数据还原的时候，需要花费大量的计算在解析JSON数据上；
所以我们统一做了一个解析JSON格式的小引擎来完成JSON数据还原为二维表的工作。原先采用JSONLIB格式解析JSON数据，发现性能有问题：当同时有多个用户在浏览大数据时，经常导致OOM。
当多个字符串JSON文本拼凑成一个完成的数据串时，会占用大量的内存，一下子就会撑满内存。典型的场景就是用户在导出/查询超过100W条记录的数据时，内存中都是非格式化的数据；以线上数据库4G内存为例，最多也就能容纳125条记录，也就100W条的数据（以每万条记录最多保存32M为例，实际情况可能根据每个hadoop表字段长短和字段值大小有关系）。
数据解析单元
当数据存储在MYSQL单表数据库中，作为一个大文本字段之后，这些数据需要解析出来变成JAVA对象提供服务。所以需要设计一个解析引擎。
就是将上图3的数据流向变成反向：
从KV结构转变成标准的二维表结构
遇到的问题
1. 数据量大，解析查询耗时耗力；在采用分布式缓存之后，仍然会存在少量的OOM；
类似全网流量试图数据，每天有800W以上，一次查询仍然会导致OOM；
有张表每天800W的数据，大致会导致数据库每天增加20G左右的容量，导致磁盘空间写满；
下图是线上实际遇到的一个问题，海量的数据将磁盘写满：
2. 不能利用数据库中的索引以及SQL的各种功能，完全依靠查询时解析文本并拼凑数据，故目前只适合后台系统；
存储改进方案
将MYSQL的innodb引擎变成开源的infobright数据仓库引擎，非常方便的将数据LOAD到数据库里面
优点：
查询性能高：百万、千万、亿级记录数条件下，同等的SELECT查询语句，速度比MyISAM、InnoDB等普通的MySQL存储引擎快5～60倍
存储数据量大：TB级数据大小，几十亿条记录
高压缩比：在项目中可以达到10：1到40：1，极大地节省了数据存储空间
基于列存储：无需建索引，无需分区
适合复杂的分析性SQL查询：SUM, COUNT, AVG, GROUP BY
InfoBright的字段格式压缩：
限制：
不支持数据更新：社区版Infobright只能使用“LOAD DATA INFILE”的方式导入数据，不支持INSERT、UPDATE、DELETE
不支持高并发：只能支持10多个并发查询；
非常适合这种海量数据的大容量存储与查询。