百万到亿级数据的快速条件查询

[sli]

一个分析系统, 需要按照日期和一个 index 来查询所有符合条件的 id. 再去重,然后通过 ID 来拿相对的属性.

现有的架构是用 Hbase 来存储数据, 以date_index 为 rowkey, id 作为 qualifier, 查询直接拿 key 去 get, 简单测试发现取得数据的速度达不到要求. 获取两条数据花费接近两分钟... 实际查询需要获取上百条...

再之前的做法是以id为 rowkey, date_index 作为 qualifier 然后使用 Hbase 的 ColumnPrefixFilter 来过滤再取所有的 rowkey, 但是查 doc 发现 filter 会做全表扫描... 鉴于数据量每天的增长大概在百万级, 这个性能会随着运行时间越来越差...

现在的想法是用 ElasticSearch 来做, 直接把属性也索引进去, 求问有没有什么更好的做法...

[liprais]

为啥不预先算好

[apoclast]

elasticsearch 可以, 不过亿级略微困难

[sli]

@liprais 因为查询的这个日期是可选的, 没法预测时间范围...也想过全都提前算好, 把所有可能的时间范围都算一遍...到后期的话, 这个量也是起飞的...

[sli]

@apoclast 困难是说不太能做到实时么?

[server]

没有耕坏的地，只有累死的牛，es 还怕这个！！！

[zhmin]

我觉得是你的 rowkey 没设计好，可以试试用日期和 index 拼接起来，构建 rowkey。亿级的数量，对于 hbase 完全扛得住

[funky]

上 OLAP kylin

[rrfeng]

两条数据是只 date 范围加 index 联合获取到的 ID 去重之后只有 2 条？
这个关键在于 index 的区分度啊，不是什么系统能解决的

另外觉得这个 HBase 比 ES 靠谱。

[rrfeng]

加机器…

[sli]

@zhmin 现在 rowkey 就是 date 加 index，然后把 id 作为列名，试了下这么取的话，挺慢的...而且 hbase 的 sharding 是按行的，这百万个列全在一个 region，取的时候可能没有真的利用到分布式存储，取连续的行的时候，压力全在一台机子上...

[sli]

@rrfeng 是按照 date 加 index 这种 rowkey 的方式取了两行，两个一百万列的行，然后取列名去重之后大概还是百万个 ID...

[sli]

@funky 谢谢，明天我试试

[MasterC]

impala

[sli]

@MasterC 谢谢，我试试

[zhmin]

@sli 这个过程是 hbase 查询数据慢，还是去重慢。如果是去重慢，是不是可以加 spark 优化？

[zhmin]

@sli 抱歉，问题没看清楚。

[sli]

@zhmin 是 hbase 取数据慢，spark 可能不太适合这个，hbase 里存的算是对于源数据经过计算之后的中间结果，是在中间结果上做 aggregation 然后展示，要求尽可能实时展示结果...数据量小的话没问题，百万条数据的话 Hbase 就不太能胜任了...

[slixurd]

ElasticSearch 能做到千万级数据 TP99 几十毫秒的性能
不过也取决于磁盘速度,最好能上 SSD/内存

[sli]

@slixurd 谢谢，今儿试试看

[hienchu]

如果是对属性做统计的话，es 在亿级别完全没问题。