Infobright 企业版数据导入和数据擦写实验

拿到一个IEE的试用版证书,试了下作为日志存储和计算的方案。统计数据查询就不用测了,ICE试试就能感受出来,比hive反正快了不少。
这里主要还是想测试 INSERT / UPDATE / DELETE

实验环境的日志系统使用 rsyslog -> flume-ng -> IEE/HDFS.
使用Flume-ng自带的HDFS Sink写HDFS的方案一直很稳定,目录按天分,写脚本预先创建目录、加Hive分区,使用hive进行分析。
但是由于可能对当天数据有统计需求hdfs.rollInterval设的比较小,目前是2分钟,每天都会有大量小文件,hive处理速度十分慢。

Flume-ng 找人写了个简单的入mysql的插件,单加了一个队列,把日志文件切分后按列送进mysql,插件要求数据库insert使用prepare批量处理insert。

1 数据导入

官方文档里有个说法:

早先看了ICE的文档,数据基本都是LOAD进去的,考虑到这个文档的说法,加了个myisam的表。
建表语句如下:

数据insert使用的是myisam,因为IEE不带InnoDB的引擎。
计划是每隔多少分钟,把 myisam 表里的增量数据insert到 brighthouse 表里。
为此写了个简单的存储过程,并加了一个id记录表

这样,再部署一个脚本,5分钟执行一次

就行了。
另外,存储过程里没处理myisam数据回收的事情,隔段时间就得人肉去分段删除。

数据很久没删了,但是测试脚本还在跑。

关键 Flume-NG配置:

2 数据删除

还做了另外一个实验,因为IEE比ICE多了常规SQL语法的支持,虽然有限,但是毕竟好用多了。
文档里写了:

加了个表,做反复擦写的实验。
同样的数据,先

再把符合条件的数据使用

重新导入。

每操作一次执行一次show table status 查看表的comment,里边有压缩率的汇报。
结果看着压缩率从 1.5 降到1.1, 0.6, 0.4。raw size一直不变,但是表空间一直在膨胀,实验表的raw size一直在950M左右,而几次擦写之后,Data Length到了4.5GB。
DROP重来就好。
于是只能

我拿一张表做了个实验

凑了一个刷表的存储过程

执行

结果

Infobright 企业版数据导入和数据擦写实验 by @sskaje: https://sskaje.me/2015/01/infobright-iee-data-testing/

Incoming search terms: