c*******u 发帖数: 1657 | 1 目前hadoop上面每天都会有新的acitivity数据进来,一开始公司要求界面能提供最近
一个月,两个月的数据给用户查询。 现在是这样做的,用hive在后台每天计算之前30
天和60天的数据,主要是group by, 过程大概是几个小时,然后把计算结果导入到
cassandra,然后用户查询的时候只需要传入查的是30天的还是60天的数据就很快可以
查到了。
现在公司有个新的要求,就是要求用户还可以选择多个category(最终显示结果是按照
category分类的)查询,以前group by的话就直接把所有category都算好了,然后直接
显示在界面。如果允许用户在界面上面check多个category再查询,如果还是按照之前
的方法,那么就得提前计算好所有的combination of category的数据,显然是不现实
的。如果不提前做计算,直接把raw data扔到cassandra,一个是数据量太大,不知道
用API计算的时候,内存是否能够用,再一个时间上面也无法保证几秒之内就能算出来。
请问这种情况应该怎么办? 用spark或者storm, Flink取代hive在raw data上面做带
group by的查询会很快吗? raw data大概是有几个billion rows,大小大概是几个T,
spark/storm/flink能做到十几秒之内得出查询结果吗? |
S***s 发帖数: 104 | 2 try presto, should meet your requirement
30
【在 c*******u 的大作中提到】 : 目前hadoop上面每天都会有新的acitivity数据进来,一开始公司要求界面能提供最近 : 一个月,两个月的数据给用户查询。 现在是这样做的,用hive在后台每天计算之前30 : 天和60天的数据,主要是group by, 过程大概是几个小时,然后把计算结果导入到 : cassandra,然后用户查询的时候只需要传入查的是30天的还是60天的数据就很快可以 : 查到了。 : 现在公司有个新的要求,就是要求用户还可以选择多个category(最终显示结果是按照 : category分类的)查询,以前group by的话就直接把所有category都算好了,然后直接 : 显示在界面。如果允许用户在界面上面check多个category再查询,如果还是按照之前 : 的方法,那么就得提前计算好所有的combination of category的数据,显然是不现实 : 的。如果不提前做计算,直接把raw data扔到cassandra,一个是数据量太大,不知道
|
c*******u 发帖数: 1657 | 3 btw,如果把raw data扔到cassandra,根据用户选择的不同的criteria,可以把数据限定
到某几个category,然后再把每个小时里面的数据用API计算,这样总的数据量大概需
要几个G的内存,计算只是加法运算和check number of uniques的计算,不知道用Java
来处理,总耗时能有多少。 |
w**z 发帖数: 8232 | 4 这个只有试了才知道。如果需要在几秒之内出结果,只能事先算好了。
Java
【在 c*******u 的大作中提到】 : btw,如果把raw data扔到cassandra,根据用户选择的不同的criteria,可以把数据限定 : 到某几个category,然后再把每个小时里面的数据用API计算,这样总的数据量大概需 : 要几个G的内存,计算只是加法运算和check number of uniques的计算,不知道用Java : 来处理,总耗时能有多少。
|
m****o 发帖数: 182 | 5 直接上Lucene试试?group by可以尝试用Lucene-grouped解决。当然这个方案是撸单机
的,数据量太大的话就得去看看solr能不能搞了。 |
c*********e 发帖数: 16335 | 6 每个category建一个table.
30
【在 c*******u 的大作中提到】 : 目前hadoop上面每天都会有新的acitivity数据进来,一开始公司要求界面能提供最近 : 一个月,两个月的数据给用户查询。 现在是这样做的,用hive在后台每天计算之前30 : 天和60天的数据,主要是group by, 过程大概是几个小时,然后把计算结果导入到 : cassandra,然后用户查询的时候只需要传入查的是30天的还是60天的数据就很快可以 : 查到了。 : 现在公司有个新的要求,就是要求用户还可以选择多个category(最终显示结果是按照 : category分类的)查询,以前group by的话就直接把所有category都算好了,然后直接 : 显示在界面。如果允许用户在界面上面check多个category再查询,如果还是按照之前 : 的方法,那么就得提前计算好所有的combination of category的数据,显然是不现实 : 的。如果不提前做计算,直接把raw data扔到cassandra,一个是数据量太大,不知道
|
g*********9 发帖数: 1285 | 7 每个category的导入cassandra,查询的时候如果是多个category,再aggregate.
30
【在 c*******u 的大作中提到】 : 目前hadoop上面每天都会有新的acitivity数据进来,一开始公司要求界面能提供最近 : 一个月,两个月的数据给用户查询。 现在是这样做的,用hive在后台每天计算之前30 : 天和60天的数据,主要是group by, 过程大概是几个小时,然后把计算结果导入到 : cassandra,然后用户查询的时候只需要传入查的是30天的还是60天的数据就很快可以 : 查到了。 : 现在公司有个新的要求,就是要求用户还可以选择多个category(最终显示结果是按照 : category分类的)查询,以前group by的话就直接把所有category都算好了,然后直接 : 显示在界面。如果允许用户在界面上面check多个category再查询,如果还是按照之前 : 的方法,那么就得提前计算好所有的combination of category的数据,显然是不现实 : 的。如果不提前做计算,直接把raw data扔到cassandra,一个是数据量太大,不知道
|
f*****z 发帖数: 13 | |
F****n 发帖数: 3271 | 9 既然是“用户可以在界面上选则”那么肯定是简单的conjunction/disjunction,
如果你的aggregations都是线性的(平均总数之类)
可以建立disjoint intermediate categories 并用API计算agg和count
比如Categories A, B => (A but not B), (B but not A), (A and B)
所有的combinations都可以由这些intermediate results 简单得出。
Java
【在 c*******u 的大作中提到】 : btw,如果把raw data扔到cassandra,根据用户选择的不同的criteria,可以把数据限定 : 到某几个category,然后再把每个小时里面的数据用API计算,这样总的数据量大概需 : 要几个G的内存,计算只是加法运算和check number of uniques的计算,不知道用Java : 来处理,总耗时能有多少。
|
w**z 发帖数: 8232 | 10 Cassandra 不是这么用的。
30
【在 c*******u 的大作中提到】 : 目前hadoop上面每天都会有新的acitivity数据进来,一开始公司要求界面能提供最近 : 一个月,两个月的数据给用户查询。 现在是这样做的,用hive在后台每天计算之前30 : 天和60天的数据,主要是group by, 过程大概是几个小时,然后把计算结果导入到 : cassandra,然后用户查询的时候只需要传入查的是30天的还是60天的数据就很快可以 : 查到了。 : 现在公司有个新的要求,就是要求用户还可以选择多个category(最终显示结果是按照 : category分类的)查询,以前group by的话就直接把所有category都算好了,然后直接 : 显示在界面。如果允许用户在界面上面check多个category再查询,如果还是按照之前 : 的方法,那么就得提前计算好所有的combination of category的数据,显然是不现实 : 的。如果不提前做计算,直接把raw data扔到cassandra,一个是数据量太大,不知道
|
|
|
c*********e 发帖数: 16335 | 11 咋用的你说清楚啊。
【在 w**z 的大作中提到】 : Cassandra 不是这么用的。 : : 30
|
w********m 发帖数: 1137 | 12 理论上java可以满足需求。不管多少个线程,这个是disk IO bound。SSD的max read可
以0.5GB/s。5TB的可以10秒钟处理完。
当然这个是理论的。实践中,用Elasticsearch 加 kibana 应该是比较好的解决办法。 |
x***4 发帖数: 1815 | 13 你的workload是不是对查aggregate(sum,mean之类的)?如果是,Cassandra 就不是
很合适了。
30
【在 c*******u 的大作中提到】 : 目前hadoop上面每天都会有新的acitivity数据进来,一开始公司要求界面能提供最近 : 一个月,两个月的数据给用户查询。 现在是这样做的,用hive在后台每天计算之前30 : 天和60天的数据,主要是group by, 过程大概是几个小时,然后把计算结果导入到 : cassandra,然后用户查询的时候只需要传入查的是30天的还是60天的数据就很快可以 : 查到了。 : 现在公司有个新的要求,就是要求用户还可以选择多个category(最终显示结果是按照 : category分类的)查询,以前group by的话就直接把所有category都算好了,然后直接 : 显示在界面。如果允许用户在界面上面check多个category再查询,如果还是按照之前 : 的方法,那么就得提前计算好所有的combination of category的数据,显然是不现实 : 的。如果不提前做计算,直接把raw data扔到cassandra,一个是数据量太大,不知道
|
w**z 发帖数: 8232 | 14 Cassandra 本质上拿来当 kV store 用最好,拿来做 report ,就是用错工具了。
【在 c*********e 的大作中提到】 : 咋用的你说清楚啊。
|
w**z 发帖数: 8232 | 15 数据读进内存还要计算,看这个算法是怎么样的了, 需要多大的内存。 我们其实自己
做过一个database, 但数据量太大,ssd 装不下。 我们把数据 shard 以后, 24 台机
器并行计算,60 秒可以勉强处理2b records, 但对内存要求太高。
这和use case有很大关系,楼主需求不说得更明白一点,我们这都属于瞎扯淡。
【在 w********m 的大作中提到】 : 理论上java可以满足需求。不管多少个线程,这个是disk IO bound。SSD的max read可 : 以0.5GB/s。5TB的可以10秒钟处理完。 : 当然这个是理论的。实践中,用Elasticsearch 加 kibana 应该是比较好的解决办法。
|
c*******u 发帖数: 1657 | 16 可能我没说清楚,这个catgory是二级的分类,界面上和数据上的分类结构大概是这样:
domain1 -> {category1, category2, cateogry3, ...} -> {millions of ids}
domain2 -> {category1, category5, cateogry6, ...} -> {millions of ids}
domain3 -> {category3, category4, cateogry6, ...} -> {millions of ids}
domain大概有50w个,category大概有几百个,如果只是按照category建table,那么不
考虑domain的话,计算的时候是没有意义的,因为界面是先选择domain,然后结果要显
示为:
Cateogry5 Unique#ids/Unique#ids belong to this domain ...
cateogry3 Unique#ids/Unique#ids belong to this domain ...
...
就是说按照属于这个域名底下的某个category的unique#id和属于整个domain的unique#
id的比例排序。 当然界面结果还有按照所有属于这个domain和这个category的unique
id的一些属性求和计算的一些东西,所以用SQL的group by domain, category,基本上
就能把结果搞出来,但是就是慢。
【在 c*********e 的大作中提到】 : 每个category建一个table. : : 30
|
c*******u 发帖数: 1657 | 17 我的cassandra里面存的是最终结果,所以不用做sum之类的,计算过程是在hadoop里面
用Hive跑的。
问题是现在要求interactive query,那么提前计算好所有的combination,太不现实。
【在 x***4 的大作中提到】 : 你的workload是不是对查aggregate(sum,mean之类的)?如果是,Cassandra 就不是 : 很合适了。 : : 30
|
c*******u 发帖数: 1657 | 18 是KV store,里面存的是最终结果,K是domain,然后V是domain底下每个cateogry的统
计数据,然后一查询,就能把这个domain底下每个category的统计数据拿到了,直接列
出来就好了,基本上什么计算都不做。
【在 w**z 的大作中提到】 : Cassandra 本质上拿来当 kV store 用最好,拿来做 report ,就是用错工具了。
|
c*******u 发帖数: 1657 | 19 可能我没说清楚,这个catgory是二级的分类,界面上和数据上的分类结构大概是这样:
domain1 -> {category1, category2, cateogry3, ...} -> {millions of ids}
domain2 -> {category1, category5, cateogry6, ...} -> {millions of ids}
domain3 -> {category3, category4, cateogry6, ...} -> {millions of ids}
domain大概有50w个,category大概有几百个,如果只是按照category建table,那么不
考虑domain的话,计算的时候是没有意义的,因为界面是先选择domain,然后结果要显
示为:
Cateogry5 Unique#ids/Unique#ids belong to this domain ...
cateogry3 Unique#ids/Unique#ids belong to this domain ...
...
就是说按照属于这个域名底下的某个category的unique#id和属于整个domain的unique#
id的比例排序。 当然界面结果还有按照所有属于这个domain和这个category的unique
id的一些属性求和计算的一些东西,所以用SQL的group by domain, category,基本上
就能把结果搞出来,但是就是慢。
【在 w**z 的大作中提到】 : 数据读进内存还要计算,看这个算法是怎么样的了, 需要多大的内存。 我们其实自己 : 做过一个database, 但数据量太大,ssd 装不下。 我们把数据 shard 以后, 24 台机 : 器并行计算,60 秒可以勉强处理2b records, 但对内存要求太高。 : 这和use case有很大关系,楼主需求不说得更明白一点,我们这都属于瞎扯淡。
|
w********m 发帖数: 1137 | 20 Using a compound primary key行不行?
domain + category |
|
|
N*****m 发帖数: 42603 | 21 spark, flink, presto都行。不过,你的原始数据组织得优化一下。
aws redshift刚搞了个spectrum,8秒可以query 6.1 billion rows,数据在s3上面。
30
【在 c*******u 的大作中提到】 : 目前hadoop上面每天都会有新的acitivity数据进来,一开始公司要求界面能提供最近 : 一个月,两个月的数据给用户查询。 现在是这样做的,用hive在后台每天计算之前30 : 天和60天的数据,主要是group by, 过程大概是几个小时,然后把计算结果导入到 : cassandra,然后用户查询的时候只需要传入查的是30天的还是60天的数据就很快可以 : 查到了。 : 现在公司有个新的要求,就是要求用户还可以选择多个category(最终显示结果是按照 : category分类的)查询,以前group by的话就直接把所有category都算好了,然后直接 : 显示在界面。如果允许用户在界面上面check多个category再查询,如果还是按照之前 : 的方法,那么就得提前计算好所有的combination of category的数据,显然是不现实 : 的。如果不提前做计算,直接把raw data扔到cassandra,一个是数据量太大,不知道
|
c*****e 发帖数: 3226 | 22 这个在理,建议上 spark,
storm 更实时,但是据说项目支撑不够。
数据量太多,也不会很快,这样你就得设计独特的数据存储机制实现预处理。
【在 N*****m 的大作中提到】 : spark, flink, presto都行。不过,你的原始数据组织得优化一下。 : aws redshift刚搞了个spectrum,8秒可以query 6.1 billion rows,数据在s3上面。 : : 30
|
s*******8 发帖数: 3 | 23 需要interactive的话你需要对read优化的database/system,如果数据可以load到别的
数据库上再做运算的话可以考虑bigquery,vertica,redshift,greenplum之类的解决
方案;如果数据只能放在hadoop/hdfs上面的话那就上presto,impala,sparkSQL之类
方案的;理论上基于hdfs的解决方案可能performance相对会差些,毕竟底层storage上
就决定效率不是特别高。 |
c*******u 发帖数: 1657 | 24 倒不是一定不能load到别的数据库,我觉得如果用bigquery, vertica, redshift,
greenplum这样的估计性能会好一些,但是要付费
另外,我担心presto, sparkSQL之类的是否可以在几秒钟之内对几个billion甚至几十
个b的数据完成聚合操作。 之前有调查说Impala, presto, drill这样的SQL-on-Hadoop
,相对于Hive能提高10倍左右的速度,因为我拿Hive测试过,如果仅仅是10倍,显然是
不能满足我们的要求的。
【在 s*******8 的大作中提到】 : 需要interactive的话你需要对read优化的database/system,如果数据可以load到别的 : 数据库上再做运算的话可以考虑bigquery,vertica,redshift,greenplum之类的解决 : 方案;如果数据只能放在hadoop/hdfs上面的话那就上presto,impala,sparkSQL之类 : 方案的;理论上基于hdfs的解决方案可能performance相对会差些,毕竟底层storage上 : 就决定效率不是特别高。
|
w**z 发帖数: 8232 | 25 几秒之内要完成这样得数据量的计算,只能事先算好。 从硬盘读,再计算,几秒完成
,
physically not possible.
Hadoop
【在 c*******u 的大作中提到】 : 倒不是一定不能load到别的数据库,我觉得如果用bigquery, vertica, redshift, : greenplum这样的估计性能会好一些,但是要付费 : 另外,我担心presto, sparkSQL之类的是否可以在几秒钟之内对几个billion甚至几十 : 个b的数据完成聚合操作。 之前有调查说Impala, presto, drill这样的SQL-on-Hadoop : ,相对于Hive能提高10倍左右的速度,因为我拿Hive测试过,如果仅仅是10倍,显然是 : 不能满足我们的要求的。
|
l**********0 发帖数: 150 | 26 每个domain下最多有多少category?
样:
【在 c*******u 的大作中提到】 : 可能我没说清楚,这个catgory是二级的分类,界面上和数据上的分类结构大概是这样: : domain1 -> {category1, category2, cateogry3, ...} -> {millions of ids} : domain2 -> {category1, category5, cateogry6, ...} -> {millions of ids} : domain3 -> {category3, category4, cateogry6, ...} -> {millions of ids} : domain大概有50w个,category大概有几百个,如果只是按照category建table,那么不 : 考虑domain的话,计算的时候是没有意义的,因为界面是先选择domain,然后结果要显 : 示为: : Cateogry5 Unique#ids/Unique#ids belong to this domain ... : cateogry3 Unique#ids/Unique#ids belong to this domain ... : ...
|
N*****m 发帖数: 42603 | 27 自己试试就知道了。10+s完全可行。
Hadoop
【在 c*******u 的大作中提到】 : 倒不是一定不能load到别的数据库,我觉得如果用bigquery, vertica, redshift, : greenplum这样的估计性能会好一些,但是要付费 : 另外,我担心presto, sparkSQL之类的是否可以在几秒钟之内对几个billion甚至几十 : 个b的数据完成聚合操作。 之前有调查说Impala, presto, drill这样的SQL-on-Hadoop : ,相对于Hive能提高10倍左右的速度,因为我拿Hive测试过,如果仅仅是10倍,显然是 : 不能满足我们的要求的。
|
c*******u 发帖数: 1657 | 28 maybe around 10 or 20
【在 l**********0 的大作中提到】 : 每个domain下最多有多少category? : : 样:
|
c*******u 发帖数: 1657 | 29 which one can achieve that?
【在 N*****m 的大作中提到】 : 自己试试就知道了。10+s完全可行。 : : Hadoop
|
N*****m 发帖数: 42603 | 30 上面都说过了啊:presto, redshift都行。
这里是netflix三年前的benchmark:
http://techblog.netflix.com/2014/10/using-presto-in-our-big-data-platform.html
aws的athena就是presto,你先搞到s3试试。
【在 c*******u 的大作中提到】 : which one can achieve that?
|
|
|
w********m 发帖数: 1137 | |
S***s 发帖数: 104 | 32 Athena very fast, but it could fail on some complicated queries
I had some queries which ran 30 minutes on my presto EMR cluster and finish
on Athena in about 2 minutes. It's well tuned by aws with metastore built-in
However Athena charge by scanned bytes...
much harder to predict and control the cost
if you use it for one off use case, it should be great.
【在 N*****m 的大作中提到】 : 上面都说过了啊:presto, redshift都行。 : 这里是netflix三年前的benchmark: : http://techblog.netflix.com/2014/10/using-presto-in-our-big-data-platform.html : aws的athena就是presto,你先搞到s3试试。
|
S***s 发帖数: 104 | 33 redshift spectrum is a api wrapper of Athena, with the same SLA and cost
【在 N*****m 的大作中提到】 : spark, flink, presto都行。不过,你的原始数据组织得优化一下。 : aws redshift刚搞了个spectrum,8秒可以query 6.1 billion rows,数据在s3上面。 : : 30
|
S***s 发帖数: 104 | 34 I'll add if you are not afraid of tinkering with new tech stack
try MapD, they just open sourced their core tech
https://www.mapd.com/blog/
benchmark is very positive
http://tech.marksblogg.com/benchmarks.html
http://tech.marksblogg.com/billion-nyc-taxi-rides-aws-ec2-p2-8xlarge-mapd.html
finish
in
【在 S***s 的大作中提到】 : Athena very fast, but it could fail on some complicated queries : I had some queries which ran 30 minutes on my presto EMR cluster and finish : on Athena in about 2 minutes. It's well tuned by aws with metastore built-in : However Athena charge by scanned bytes... : much harder to predict and control the cost : if you use it for one off use case, it should be great.
|