由买买提看人间百态

boards

本页内容为未名空间相应帖子的节选和存档,一周内的贴子最多显示50字,超过一周显示500字 访问原贴
Programming版 - 这种情况该用那种big data tool?
相关主题
感觉flink出来之后,hadoop就显得不怎么再需要了L家不再用scala了。。
各位大牛,Apache Apex 怎么样?好虫,看看你的东东有没有问题?
Re: 请教板上老司机 关于组和以后的发展方向说说魏老师犯的几个常识性错误。
请问如何scale hive meta store mysql如何提高Spark在Yarn上的内存使用率
我对新技术的态度是:不到万不得已绝对不主动学习谁能给个简单的中文介绍几个系统
那些做 big data 的公司到底需要什么样的人?cs这几个方向,哪个现在和未来的状况最好?
想山寨palantir了Spark已经out了,能跳船的赶快
12306仍然一塌糊涂spark contributors
相关话题的讨论汇总
话题: domain话题: category话题: unique话题: ids话题: 计算
进入Programming版参与讨论
1 (共1页)
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
8
prestoDB or Impala
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,一个是数据量太大,不知道

相关主题
那些做 big data 的公司到底需要什么样的人?L家不再用scala了。。
想山寨palantir了好虫,看看你的东东有没有问题?
12306仍然一塌糊涂说说魏老师犯的几个常识性错误。
进入Programming版参与讨论
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
相关主题
如何提高Spark在Yarn上的内存使用率Spark已经out了,能跳船的赶快
谁能给个简单的中文介绍几个系统spark contributors
cs这几个方向,哪个现在和未来的状况最好?Flink可以contribute
进入Programming版参与讨论
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?
相关主题
看了flink,不能不说有点小期待各位大牛,Apache Apex 怎么样?
Flink Sparks Next Wave of Distributed Data ProcessingRe: 请教板上老司机 关于组和以后的发展方向
感觉flink出来之后,hadoop就显得不怎么再需要了请问如何scale hive meta store mysql
进入Programming版参与讨论
w********m
发帖数: 1137
31
spark +1
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.

1 (共1页)
进入Programming版参与讨论
相关主题
spark contributors我对新技术的态度是:不到万不得已绝对不主动学习
Flink可以contribute那些做 big data 的公司到底需要什么样的人?
看了flink,不能不说有点小期待想山寨palantir了
Flink Sparks Next Wave of Distributed Data Processing12306仍然一塌糊涂
感觉flink出来之后,hadoop就显得不怎么再需要了L家不再用scala了。。
各位大牛,Apache Apex 怎么样?好虫,看看你的东东有没有问题?
Re: 请教板上老司机 关于组和以后的发展方向说说魏老师犯的几个常识性错误。
请问如何scale hive meta store mysql如何提高Spark在Yarn上的内存使用率
相关话题的讨论汇总
话题: domain话题: category话题: unique话题: ids话题: 计算