求推荐个流水数据分析(BI)的轮子

i00i   (烟灰·独孤求胖)2019-03-14 16:21:19
数据量不算很大,每次最多操纵几百万~几千万的记录数,直接MySQL查询已经比较耗时。
需要从流水表关联几个元数据表。
主要是选取一个时间段的流水数据,能根据若干维度(字段)进行聚合运算。
如果支持下钻最好,不能也没关系,出图大致是普通的柱/线/饼/散点够用。
粗略检索,眼花缭乱啊,superset、redash、kylin似乎等都能做。
xWvxYWYxvWx   (xWvxYWYxvWxxWvxYWYxvWx)2019-03-14 16:35:56
这个是业界老难题了,目前各种轮子漫天飞,没有银弹。
【 在 i00i (烟灰·独孤求胖) 的大作中提到: 】
: 标 题: 求推荐个流水数据分析(BI)的轮子
cestlavie   (along the border between earth and hell)2019-03-14 16:37:44
流水数据,我理解就是一个大宽表,可以考虑用Druid/imply,展示层可以用Superset或者Imply
【 在 i00i 的大作中提到: 】
: 数据量不算很大,每次最多操纵几百万~几千万的记录数,直接MySQL查询已经比较耗时。
itworker   (IT民工)2019-03-14 16:39:37
某些有时间规律的指标可以提前计算,比如月总计年总计。
但是需要实时计算的没有啥好办法,任意时间段总计这种。
【 在 i00i 的大作中提到: 】
:
i00i   (烟灰·独孤求胖)2019-03-15 07:56:01
哈哈,感谢大家的建议。
我突然想到,这个需求跟zabbix/nagios之类的监控工具真有点像。。
【 在 itworker 的大作中提到: 】
: 某些有时间规律的指标可以提前计算,比如月总计年总计。
RAV4   (hehe)2019-03-15 11:04:16
把mysql换掉就行了吧
【 在 i00i (烟灰·独孤求胖) 的大作中提到: 】
: 数据量不算很大,每次最多操纵几百万~几千万的记录数,直接MySQL查询已经比较耗时。
i00i   (烟灰·独孤求胖)2019-03-15 12:10:14
换成啥呢?
其实不仅是MySQL性能的问题啦,从抓取数据、计算、展示,后端到前端,目前是要写一大坨代码的。
用那些BI工具的好处是你可以少写很多代码,大多数时候写SQL加上一些配置就够了。
【 在 RAV4 的大作中提到: 】
: 把mysql换掉就行了吧
Inshua   (在庭)2019-03-15 13:26:34
换 pg,pg 有 lateral join
mysql 连 parallel query 都不支持
【 在 i00i (烟灰·独孤求胖) 的大作中提到: 】
: 数据量不算很大,每次最多操纵几百万~几千万的记录数,直接MySQL查询已经比较耗
时。
hgoldfish   (老鱼)2019-03-15 13:30:17
时间序列服务器?可以用 time series database 这个关键搜搜。最近比较火的似乎是那个 influxdb, es 也有一个方案。不过我都没试过。。
【 在 i00i (烟灰·独孤求胖) 的大作中提到: 】
: 数据量不算很大,每次最多操纵几百万~几千万的记录数,直接MySQL查询已经比较耗时。
xWvxYWYxvWx   (xWvxYWYxvWxxWvxYWYxvWx)2019-03-15 15:25:47
我给3种方案吧。
1. 直接用 PG 11, 把数据按天分区,你可以 pre join 成一个宽表再存,也可以不 join,
取决于你的需求。如果你的查询,范围大多是查一天或少数几天数据的话,这个方案比较
合理。把 PG 调得好一点,上 SSD, 开并行查询,每个分区几千万行数据一般问题不大。
这种直接用 PG 的方案,数据量大的时候,查起来比 MySQL 快几倍很正常。也许你简单地换到 PG 就解决问题了。
2. 如果你的数据具有时间序列的特征,并且更新很少,甚至是 append only 的,那么可以考虑上 PG 的拓展 TimescaleDB. 上了 TimescaleDB, 你读写表的操作基本上跟直接读写 PG 一样,同时写性能号称比裸 PG 提升几十倍(未验证),查询性能提升几倍(我本人验证过)。
3. 如果数据量进一步增大,特别是有许多个基数很高的维度,需要做任意维度组合的分析统计型查询,事情就比较麻烦了。基本上现在所有的轮子都得跪,跪的姿势取决于你的维度数量,维度基数以及你对性能和实时性的要求。Druid.io, Kudu 等等一大票轮子在排队等着你哩。
【 在 i00i (烟灰·独孤求胖) 的大作中提到: 】
: 标 题: Re: 求推荐个流水数据分析(BI)的轮子
i00i   (烟灰·独孤求胖)2019-03-15 17:05:45
挖~ 感谢楼上各位大佬的建议,我觉得都靠谱。我根据这边的实际情况一并回复吧。
目前的状况是流水数据跟业务数据都在MySQL集群(PXC,存储SSD)里。
但是流水表可以拆出来存到PG里(部分流水表已拆分到mongodb)。
我对PG很不熟悉,会有一定的学习代价,influxdb经常听说,也还没用过。
流水是append only的,不过会有个别状态字段update,没有delete。
TimescaleDB看来也是个不错的选择。
在我的选型规划里,将来替代MySQL的是TiDB,然后数据库要进行拆分,
流水数据拆到mongodb(或大家推荐的PG/influxdb/TimescaleDB)。
底层数据操纵工具是prestodb/TiSpark/Spark,BI层用superset/redash等工具。
再下一步就不好说了,看业务怎样发展,技术路线再怎么演进。
xWvxYWYxvWx   (xWvxYWYxvWxxWvxYWYxvWx)2019-03-15 18:35:15
根据我有限的经验,
OLAP 型应用不要用 MongoDB!
不要用 MongoDB!
不要用 MongoDB!
【 在 i00i (烟灰·独孤求胖) 的大作中提到: 】
: 标 题: Re: 求推荐个流水数据分析(BI)的轮子
MyWorkLife   (我是谁)2019-03-15 18:47:16
有流水表就好办了
上spark或者flink做流式计算
把感兴趣的指标实时算出来
涉及到时间段统计的,把计算结果用最小时间颗粒度(比如天)保存
然后在需要的时候再提交一个批计算任务做时间段统计
【 在 i00i (烟灰·独孤求胖) 的大作中提到: 】
: 标 题: Re: 求推荐个流水数据分析(BI)的轮子
i00i   (烟灰·独孤求胖)2019-03-15 19:27:48
哈哈哈,听起来有故事的样子,有空讲讲呗?
明白了,既然如此我会重新考虑这个问题,
当时引入mongodb主要是为了把非核心的却占空间的数据腾出MySQL。
这些流水数据丢了不会对核心业务造成影响。
目前数据量还不大,迁移代价小。
【 在 xWvxYWYxvWx 的大作中提到: 】
: 根据我有限的经验,
i00i   (烟灰·独孤求胖)2019-03-15 19:29:57
赞~ 我调查一下这个怎么做。
最小时间刻度,TP那边是到秒,AP这边到分钟就可以了。
【 在 MyWorkLife 的大作中提到: 】
: 有流水表就好办了
cestlavie   (along the border between earth and hell)2019-03-16 18:50:33
求展开说说 这个有啥坑?性能?不支持Sql?
【 在 xWvxYWYxvWx (xWvxYWYxvWxxWvxYWYxvWx) 的大作中提到: 】
: 根据我有限的经验,
xWvxYWYxvWx   (xWvxYWYxvWxxWvxYWYxvWx)2019-03-16 23:01:55
我以为基本是常识。自己搜下就知道了。
【 在 cestlavie (along the border between earth and hell) 的大作中提到: 】
: 标 题: Re: 求推荐个流水数据分析(BI)的轮子
mopo   (Fred Li)2019-03-21 14:43:04
除了某些前端框架感觉就没有什么地方适用mongo的,都不用说OLAP。。。
【 在 xWvxYWYxvWx 的大作中提到: 】
: 根据我有限的经验,

水木社区