日千万级记录的 OLAP，大家用 MySQL 还是 Druid.io 还是有其他好东西?

[binjjam]

有个日志埋点接收服务，每天大概有 1500W 的请求，需要每 5 分钟进行一些聚合，原始数据大概是 16 个维度，然后取出其中的 5 个左右进行单独聚合。之前使用的是 Percona 的 MySQL 5.5，MyISAM 引擎按天进行表分区，由于每 5 分钟只聚合该 5 分钟内的数据，所以数据量也不多，统计不会有什么问题。
然后有个老哥提出，需要每 5 分钟统计一次当天 0 点到统计时刻的情况，其实就是把原先 5 分钟内的数据统计扩大到 5 分钟到一整天 这样的一个情况，大致相当于到了每天的 20 点后，数据量都是比较大的，然后用 MySQL 的问题就体现出来了，group by 的时候会等很久，大概有个 2 分钟以上，因为统计的任务比较多，导致无法再 5 分钟内进行完所有统计。
于是就进行了各种调研，发现有个叫 Druid.io 的玩意专门用来玩实时 OLAP 的，不过鄙人测试了下，并没有快到哪里去，一方面是因为 queryGranularity 我是按秒的，另外一方面可能是我的服务器不行（ Intel(R) Xeon(R) CPU X5650 @ 2.67GHz 64G RAM ） 。
最近我又搞了个 10.2.6-MariaDB，相同的配置下，比 Percona 的要稍快一点，但是依旧无法避免这个需要聚合千万条数据的问题。之前也测试过 InfoBright，由于我那些列基本上都是每行全满的，用了 brighthouse 发现并没有比原先的 MyISAM 快多少，所以就放弃这个了。
不知道各位大侠在这方面是怎么做的？像 bugly 那种那么多数据不知道怎么统计才比较快？

补充说明下，统计主要是统计去重用户这些，比如说 00:00~00:05 用户 A 出现了不管多少次，这 5 分钟内，去重统计的话他也只算 1 次，然后如果 00:05~23:59 他又出现了不管多少次，那么在这一天内他也只算一次。
曾经也用 redis 的 set 来去重，这个的话是可以的，不过比较占内存而且都要自己实现，比较麻烦；而 Hyperloglog 的话，druid.io 在设计表结构的时候就可以指定某些字段进行这个聚合，快确实是快，不过不是很准（ redis 的 Hyperloglog 准些）

[misaka19000]

ELK ？

[binjjam]

@misaka19000 ELK 在聚合方面也比较抓鸡

[billlee]

程序逻辑能不能改进？比如聚合 0 - 10 分钟的数据的时候，能否复用 0-5 分钟的聚合结果？

[hellommd]

把每 5 分钟的结果聚合在一起？

[binjjam]

@billlee 之前尝试过放在 redis 里面，是可以做到这点的，就是原始日志入库的时候都丢那些需要统计的到 redis 里，然后到点再从 redis 里取出来，因为统计可能不够及时，没办法直接一天放一个 set （不然可能进去的结果已经是包含了下个 5 分钟的数据了），当时搞的是 5 分钟 1 个 key，然后取并集的做法，不够需要维护很多很多 key 呢，比较麻烦~
可能我这个套路不科学

[binjjam]

@hellommd 去重统计的话，一天内每个 5 分钟的结果加起来并不是这一天的总去重结果呢

[mkstring]

为啥不用 hive

[ihuotui]

应该尝试流式计算，基于静态数据再统计这种方式 实时性不好

[binjjam]

@ihuotui 流式计算老哥能指点一二么，druid.io 这个也算是流..数据从 kafka 到 druid.io 然后再自己去拿结果。

[billlee]

@binjjam #5 你既然是从 kafka 取数据的，为什么会控制不好时间区间呢？ Kafka 里面的消息都有 timestamp 的啊

[binjjam]

@billlee kafka 实时被 druid.io 消费了哇...原始数据流只有一份，
00:05 统计 00:00:00~00:04:59 的数据，
00:10 统计 00:00:00~00:09:59 的数据，
...
第二天 00:00 统计前一天 00:00:00~23:59:59 的数据