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

一种HADOOP上的通用数据服务开发框架和机制 - JAVA博客 - ITeye技术网站
http://scholers.iteye.com/blog/1816855/

其包含三个部分的处理模块： 数据产出单元 这部分是数据ETL的开发，也就是产出数据的脚本，大部分是HIVE SQL，当然也有Map/reduce程序（以JAR包的方式），部署在HADOOP平台上，然后通过任务调度，循环执行产出数据。 这块的功能主要是在hadoop上，这里不详细描述了。 数据交换单元 当用户在HADOOP上产出一份二维表的数据的时候（上面所讲的模块），常见的处理方式如下（左边的表示HADOOP表，右边表示关系型数据库表） 在数据分析平台里面采用的方式是这样的，原始方式表和表的数据对拷，我们的方案变化为:所有的数据变成单表的一个字段 点击查看原始大小图片 在这里CONTENT字段是利用了MySql的mediumtext字段，最大长度支持16777215个字符，换算出来大概是32M的容量。也就是说如果这个HADOOP上的按照日期的单表总数据容量不超过32M，那么就可以存成一个一个字符串。

遇到的问题 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

遇到的问题

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