这种情况该用那种big data tool？# Programming - 葵花宝典
m*8
1 楼
我父母准备11月来美国，明年11月左右回去。具体回去的时间要根据延期的时间来定？
我应该买flexible的机票吗？我第一次买这种机票， 没什么经验？请过来人指点一下
好吗？
多谢。
我应该买flexible的机票吗？我第一次买这种机票， 没什么经验？请过来人指点一下
好吗？
多谢。
b*e
2 楼
第一名：射手
乐观的射手待人特别的热情，开朗的个性很容易让人亲近。喜欢玩乐的他们接触的人群
自然也很广，在玩乐的过程中便会结交不少的朋友。因此，他们不光有好的同性缘，还
有相当不错的异性缘。诚实的他们与朋友相处时也特别的坦白，这样能避免和异性相处
时产生许多不必要的误会
第二名：天秤
美丽、俊俏的视觉效果当然更容易讨异性喜欢。天秤会打扮众所周知，所以从外形上他
们就很容易吸引住异性的目光。加上天秤是一个容易感染寂寞，又害怕寂寞的星座，于
是他们喜欢四处结交朋友来摆脱寂寞感。所以在天秤的身边，不光有同性朋友，还有不
少的异性朋友。
第三名：天蝎
性感且神秘的天蝎，或许在同性里的人缘不是很好，但他们在异性看来却相当的有魅力
。他们善解人意，很懂得处理人与人之间的关系，在与异性相处时更懂得何时能与对方
亲近，何时又该与对方保持距离。这使得异性和他们相处起来特别的轻松，也更愿意长
期与他们建立友谊关系。
第四名：处女
处女座的人在对待男女关系上非常的谨慎，所以异性和他们做朋友感觉特别的安全，不
用担心彼此会萌生复杂的爱情。他们待人细心，在与人相处时总能替对方着想，让人感
觉特别的贴心。虽然平时有些害羞，但彼此稍微熟悉了，他们的话题就会变得特别多，
因此，与异性相处不会尴尬，也很讨异性的喜欢。
第五名：双鱼
感情丰富的双鱼异性缘也不赖，这主要还是因为鱼儿们特别的有爱心，无论何时何地，
无论男女老少，只要看到别人有困难总喜欢去帮助对方，这样便让接受过他们帮助的人
特别感动，自然也愿意与他们建立友谊。加上鱼儿本来就喜欢广交朋友，自然而然身边
就有不少的异性朋友。
第六名：水瓶
水瓶座的人兴趣爱好广泛，又喜欢结交朋友，所以在很多的领域都有他们的朋友，其中
也不乏会有一些异性朋友。瓶子是属于把友情看得比爱情重的人，所以他们不会轻易越
过友谊的界线，破坏原有的纯真感情，这也是男女友谊所必须具备的要素。因此，瓶子
的异性缘总得来说还算不错
乐观的射手待人特别的热情，开朗的个性很容易让人亲近。喜欢玩乐的他们接触的人群
自然也很广，在玩乐的过程中便会结交不少的朋友。因此，他们不光有好的同性缘，还
有相当不错的异性缘。诚实的他们与朋友相处时也特别的坦白，这样能避免和异性相处
时产生许多不必要的误会
第二名：天秤
美丽、俊俏的视觉效果当然更容易讨异性喜欢。天秤会打扮众所周知，所以从外形上他
们就很容易吸引住异性的目光。加上天秤是一个容易感染寂寞，又害怕寂寞的星座，于
是他们喜欢四处结交朋友来摆脱寂寞感。所以在天秤的身边，不光有同性朋友，还有不
少的异性朋友。
第三名：天蝎
性感且神秘的天蝎，或许在同性里的人缘不是很好，但他们在异性看来却相当的有魅力
。他们善解人意，很懂得处理人与人之间的关系，在与异性相处时更懂得何时能与对方
亲近，何时又该与对方保持距离。这使得异性和他们相处起来特别的轻松，也更愿意长
期与他们建立友谊关系。
第四名：处女
处女座的人在对待男女关系上非常的谨慎，所以异性和他们做朋友感觉特别的安全，不
用担心彼此会萌生复杂的爱情。他们待人细心，在与人相处时总能替对方着想，让人感
觉特别的贴心。虽然平时有些害羞，但彼此稍微熟悉了，他们的话题就会变得特别多，
因此，与异性相处不会尴尬，也很讨异性的喜欢。
第五名：双鱼
感情丰富的双鱼异性缘也不赖，这主要还是因为鱼儿们特别的有爱心，无论何时何地，
无论男女老少，只要看到别人有困难总喜欢去帮助对方，这样便让接受过他们帮助的人
特别感动，自然也愿意与他们建立友谊。加上鱼儿本来就喜欢广交朋友，自然而然身边
就有不少的异性朋友。
第六名：水瓶
水瓶座的人兴趣爱好广泛，又喜欢结交朋友，所以在很多的领域都有他们的朋友，其中
也不乏会有一些异性朋友。瓶子是属于把友情看得比爱情重的人，所以他们不会轻易越
过友谊的界线，破坏原有的纯真感情，这也是男女友谊所必须具备的要素。因此，瓶子
的异性缘总得来说还算不错
i*i
3 楼
c*u
4 楼
目前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能做到十几秒之内得出查询结果吗？
一个月，两个月的数据给用户查询。 现在是这样做的，用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能做到十几秒之内得出查询结果吗？
a*n
5 楼
现在还有没有这种机票不清楚，如果没有，买半年往返然后改期，单程入境可能有
麻烦。当然也可能啥事没有。
【在 m****8 的大作中提到】
: 我父母准备11月来美国，明年11月左右回去。具体回去的时间要根据延期的时间来定？
: 我应该买flexible的机票吗？我第一次买这种机票， 没什么经验？请过来人指点一下
: 好吗？
: 多谢。
麻烦。当然也可能啥事没有。
【在 m****8 的大作中提到】
: 我父母准备11月来美国，明年11月左右回去。具体回去的时间要根据延期的时间来定？
: 我应该买flexible的机票吗？我第一次买这种机票， 没什么经验？请过来人指点一下
: 好吗？
: 多谢。
b*e
6 楼
第七名： 白羊
个性较为刚烈的羊儿领导欲特别强，喜欢指挥人，这便容易让人产生排斥感。少有男人
愿意顺从于女人，也少有女人乐意和霸道的男人相处。所以，羊儿偶尔要替他人着想才
好喔。
第八名：金牛
固执则是牛儿未上榜的最大原因，与异性间的沟通本来就不如同性间的那么自然，所以
金牛固执的个性，更是容易让异性觉得与牛儿不好相处。牛儿待人圆融一点才好招来异
性缘哟。
第九名：双子
双子的性格多重，总是让人难以琢磨，别说是异性，作为同性朋友都常常弄不懂他们在
想什么。所以，这便给异性与双子相处时产生了障碍。所以，双子与人相处时不要太随
性的好。
第十名： 巨蟹
善解人意的巨蟹性格比较的保守，因此“男女授受不亲”的思想多多少少对他们还有着
影响。所以免不了会刻意的与异性保持一些距离，其实他们只要放开思想束缚就好了。
第十一名：狮子
热情的狮子带有些许的霸道，这也是让异性会有些受不了的地方。感觉觉得和狮子们相
处时，总是被他们所压抑着。所以，狮子若不那么好强，和异性的关系也会好很多。
第十二名： 摩羯
摩羯座的人性格保守且内向，平日就不大喜欢与人说话，更不用说与异性交谈。所以摩
羯的异性缘不佳也是情理之中的事情。如果他们思想能开放一点，大方一点，相对会要
好一些。
【在 b******e 的大作中提到】
: 第一名：射手
: 乐观的射手待人特别的热情，开朗的个性很容易让人亲近。喜欢玩乐的他们接触的人群
: 自然也很广，在玩乐的过程中便会结交不少的朋友。因此，他们不光有好的同性缘，还
: 有相当不错的异性缘。诚实的他们与朋友相处时也特别的坦白，这样能避免和异性相处
: 时产生许多不必要的误会
: 第二名：天秤
: 美丽、俊俏的视觉效果当然更容易讨异性喜欢。天秤会打扮众所周知，所以从外形上他
: 们就很容易吸引住异性的目光。加上天秤是一个容易感染寂寞，又害怕寂寞的星座，于
: 是他们喜欢四处结交朋友来摆脱寂寞感。所以在天秤的身边，不光有同性朋友，还有不
: 少的异性朋友。
个性较为刚烈的羊儿领导欲特别强，喜欢指挥人，这便容易让人产生排斥感。少有男人
愿意顺从于女人，也少有女人乐意和霸道的男人相处。所以，羊儿偶尔要替他人着想才
好喔。
第八名：金牛
固执则是牛儿未上榜的最大原因，与异性间的沟通本来就不如同性间的那么自然，所以
金牛固执的个性，更是容易让异性觉得与牛儿不好相处。牛儿待人圆融一点才好招来异
性缘哟。
第九名：双子
双子的性格多重，总是让人难以琢磨，别说是异性，作为同性朋友都常常弄不懂他们在
想什么。所以，这便给异性与双子相处时产生了障碍。所以，双子与人相处时不要太随
性的好。
第十名： 巨蟹
善解人意的巨蟹性格比较的保守，因此“男女授受不亲”的思想多多少少对他们还有着
影响。所以免不了会刻意的与异性保持一些距离，其实他们只要放开思想束缚就好了。
第十一名：狮子
热情的狮子带有些许的霸道，这也是让异性会有些受不了的地方。感觉觉得和狮子们相
处时，总是被他们所压抑着。所以，狮子若不那么好强，和异性的关系也会好很多。
第十二名： 摩羯
摩羯座的人性格保守且内向，平日就不大喜欢与人说话，更不用说与异性交谈。所以摩
羯的异性缘不佳也是情理之中的事情。如果他们思想能开放一点，大方一点，相对会要
好一些。
【在 b******e 的大作中提到】
: 第一名：射手
: 乐观的射手待人特别的热情，开朗的个性很容易让人亲近。喜欢玩乐的他们接触的人群
: 自然也很广，在玩乐的过程中便会结交不少的朋友。因此，他们不光有好的同性缘，还
: 有相当不错的异性缘。诚实的他们与朋友相处时也特别的坦白，这样能避免和异性相处
: 时产生许多不必要的误会
: 第二名：天秤
: 美丽、俊俏的视觉效果当然更容易讨异性喜欢。天秤会打扮众所周知，所以从外形上他
: 们就很容易吸引住异性的目光。加上天秤是一个容易感染寂寞，又害怕寂寞的星座，于
: 是他们喜欢四处结交朋友来摆脱寂寞感。所以在天秤的身边，不光有同性朋友，还有不
: 少的异性朋友。
S*s
7 楼
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，一个是数据量太大，不知道
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，一个是数据量太大，不知道
i*t
8 楼
什么签证能一年啊？
【在 m****8 的大作中提到】
: 我父母准备11月来美国，明年11月左右回去。具体回去的时间要根据延期的时间来定？
: 我应该买flexible的机票吗？我第一次买这种机票， 没什么经验？请过来人指点一下
: 好吗？
: 多谢。
【在 m****8 的大作中提到】
: 我父母准备11月来美国，明年11月左右回去。具体回去的时间要根据延期的时间来定？
: 我应该买flexible的机票吗？我第一次买这种机票， 没什么经验？请过来人指点一下
: 好吗？
: 多谢。
g*2
9 楼
果然MJ最后
c*u
10 楼
btw,如果把raw data扔到cassandra,根据用户选择的不同的criteria，可以把数据限定
到某几个category，然后再把每个小时里面的数据用API计算，这样总的数据量大概需
要几个G的内存，计算只是加法运算和check number of uniques的计算，不知道用Java
来处理，总耗时能有多少。
到某几个category，然后再把每个小时里面的数据用API计算，这样总的数据量大概需
要几个G的内存，计算只是加法运算和check number of uniques的计算，不知道用Java
来处理，总耗时能有多少。
h*t
11 楼
大韩航空有1年OPEN的.我父母GP都买的那种.
来时定180天以下,如果延期的话再根据延期的时间该机票.
来时定180天以下,如果延期的话再根据延期的时间该机票.
E*T
12 楼
巨蟹 异性缘超级好的 好不好。。。。
俺内伤了很多年。。。。
俺内伤了很多年。。。。
w*z
13 楼
这个只有试了才知道。如果需要在几秒之内出结果，只能事先算好了。
Java
【在 c*******u 的大作中提到】
: btw,如果把raw data扔到cassandra,根据用户选择的不同的criteria，可以把数据限定
: 到某几个category，然后再把每个小时里面的数据用API计算，这样总的数据量大概需
: 要几个G的内存，计算只是加法运算和check number of uniques的计算，不知道用Java
: 来处理，总耗时能有多少。
Java
【在 c*******u 的大作中提到】
: btw,如果把raw data扔到cassandra,根据用户选择的不同的criteria，可以把数据限定
: 到某几个category，然后再把每个小时里面的数据用API计算，这样总的数据量大概需
: 要几个G的内存，计算只是加法运算和check number of uniques的计算，不知道用Java
: 来处理，总耗时能有多少。
m*u
14 楼
可是票的性质是半年票啊，延期改时间能改的超过180天吗？岂不是把票的性质改了？
S*i
15 楼
no.1
m*o
16 楼
直接上Lucene试试？group by可以尝试用Lucene-grouped解决。当然这个方案是撸单机
的，数据量太大的话就得去看看solr能不能搞了。
的，数据量太大的话就得去看看solr能不能搞了。
i*t
17 楼
机票改期是从出票之日起1年有效阿。
【在 m****u 的大作中提到】
: 可是票的性质是半年票啊，延期改时间能改的超过180天吗？岂不是把票的性质改了？
【在 m****u 的大作中提到】
: 可是票的性质是半年票啊，延期改时间能改的超过180天吗？岂不是把票的性质改了？
c*e
18 楼
每个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，一个是数据量太大，不知道
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，一个是数据量太大，不知道
m*u
19 楼
我被告知买的半年时间内的票一般都直接享有半年票的折扣，定性并限制为半年票。
我以前试了180/181还不知道是181/182天的票价，是个骤变。
求解啊求解啊
我以前试了180/181还不知道是181/182天的票价，是个骤变。
求解啊求解啊
g*9
20 楼
每个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，一个是数据量太大，不知道
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，一个是数据量太大，不知道
m*u
21 楼
我的意思是，我被告知，在出票之日起一年之内都可以改，但是因为是半年票，所以回
程必须改在半年内。有这说吗？我真希望我是被人忽悠了。
【在 i******t 的大作中提到】
: 机票改期是从出票之日起1年有效阿。
程必须改在半年内。有这说吗？我真希望我是被人忽悠了。
【在 i******t 的大作中提到】
: 机票改期是从出票之日起1年有效阿。
f*z
22 楼
prestoDB or Impala
i*t
23 楼
哪家公司的啊？
【在 m****u 的大作中提到】
: 我的意思是，我被告知，在出票之日起一年之内都可以改，但是因为是半年票，所以回
: 程必须改在半年内。有这说吗？我真希望我是被人忽悠了。
【在 m****u 的大作中提到】
: 我的意思是，我被告知，在出票之日起一年之内都可以改，但是因为是半年票，所以回
: 程必须改在半年内。有这说吗？我真希望我是被人忽悠了。
F*n
24 楼
既然是“用户可以在界面上选则”那么肯定是简单的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
: 来处理，总耗时能有多少。
如果你的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
: 来处理，总耗时能有多少。
m*u
25 楼
纳美
w*z
26 楼
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，一个是数据量太大，不知道
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
27 楼
咋用的你说清楚啊。
【在 w**z 的大作中提到】
: Cassandra 不是这么用的。
:
: 30
【在 w**z 的大作中提到】
: Cassandra 不是这么用的。
:
: 30
w*m
28 楼
理论上java可以满足需求。不管多少个线程，这个是disk IO bound。SSD的max read可
以0.5GB／s。5TB的可以10秒钟处理完。
当然这个是理论的。实践中，用Elasticsearch 加 kibana 应该是比较好的解决办法。
以0.5GB／s。5TB的可以10秒钟处理完。
当然这个是理论的。实践中，用Elasticsearch 加 kibana 应该是比较好的解决办法。
x*4
29 楼
你的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，一个是数据量太大，不知道
很合适了。
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
30 楼
Cassandra 本质上拿来当 kV store 用最好,拿来做 report ，就是用错工具了。
【在 c*********e 的大作中提到】
: 咋用的你说清楚啊。
【在 c*********e 的大作中提到】
: 咋用的你说清楚啊。
w*z
31 楼
数据读进内存还要计算，看这个算法是怎么样的了, 需要多大的内存。 我们其实自己
做过一个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 应该是比较好的解决办法。
做过一个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
32 楼
可能我没说清楚，这个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
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
33 楼
我的cassandra里面存的是最终结果，所以不用做sum之类的，计算过程是在hadoop里面
用Hive跑的。
问题是现在要求interactive query，那么提前计算好所有的combination，太不现实。
【在 x***4 的大作中提到】
: 你的workload是不是对查aggregate（sum，mean之类的）？如果是，Cassandra 就不是
: 很合适了。
:
: 30
用Hive跑的。
问题是现在要求interactive query，那么提前计算好所有的combination，太不现实。
【在 x***4 的大作中提到】
: 你的workload是不是对查aggregate（sum，mean之类的）？如果是，Cassandra 就不是
: 很合适了。
:
: 30
c*u
34 楼
是KV store，里面存的是最终结果，K是domain，然后V是domain底下每个cateogry的统
计数据，然后一查询，就能把这个domain底下每个category的统计数据拿到了，直接列
出来就好了，基本上什么计算都不做。
【在 w**z 的大作中提到】
: Cassandra 本质上拿来当 kV store 用最好,拿来做 report ，就是用错工具了。
计数据，然后一查询，就能把这个domain底下每个category的统计数据拿到了，直接列
出来就好了，基本上什么计算都不做。
【在 w**z 的大作中提到】
: Cassandra 本质上拿来当 kV store 用最好,拿来做 report ，就是用错工具了。
c*u
35 楼
可能我没说清楚，这个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有很大关系，楼主需求不说得更明白一点，我们这都属于瞎扯淡。
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
36 楼
Using a compound primary key行不行？
domain + category
domain + category
N*m
37 楼
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，一个是数据量太大，不知道
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
38 楼
这个在理，建议上 spark,
storm 更实时，但是据说项目支撑不够。
数据量太多，也不会很快，这样你就得设计独特的数据存储机制实现预处理。
【在 N*****m 的大作中提到】
: spark, flink, presto都行。不过，你的原始数据组织得优化一下。
: aws redshift刚搞了个spectrum，8秒可以query 6.1 billion rows，数据在s3上面。
:
: 30
storm 更实时，但是据说项目支撑不够。
数据量太多，也不会很快，这样你就得设计独特的数据存储机制实现预处理。
【在 N*****m 的大作中提到】
: spark, flink, presto都行。不过，你的原始数据组织得优化一下。
: aws redshift刚搞了个spectrum，8秒可以query 6.1 billion rows，数据在s3上面。
:
: 30
s*8
39 楼
需要interactive的话你需要对read优化的database/system，如果数据可以load到别的
数据库上再做运算的话可以考虑bigquery，vertica，redshift，greenplum之类的解决
方案；如果数据只能放在hadoop/hdfs上面的话那就上presto，impala，sparkSQL之类
方案的；理论上基于hdfs的解决方案可能performance相对会差些，毕竟底层storage上
就决定效率不是特别高。
数据库上再做运算的话可以考虑bigquery，vertica，redshift，greenplum之类的解决
方案；如果数据只能放在hadoop/hdfs上面的话那就上presto，impala，sparkSQL之类
方案的；理论上基于hdfs的解决方案可能performance相对会差些，毕竟底层storage上
就决定效率不是特别高。
c*u
40 楼
倒不是一定不能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上
: 就决定效率不是特别高。
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
41 楼
几秒之内要完成这样得数据量的计算，只能事先算好。 从硬盘读，再计算，几秒完成
，
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倍，显然是
: 不能满足我们的要求的。
，
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
42 楼
每个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 ...
: ...
样：
【在 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
43 楼
自己试试就知道了。10+s完全可行。
Hadoop
【在 c*******u 的大作中提到】
: 倒不是一定不能load到别的数据库，我觉得如果用bigquery, vertica, redshift,
: greenplum这样的估计性能会好一些，但是要付费
: 另外，我担心presto, sparkSQL之类的是否可以在几秒钟之内对几个billion甚至几十
: 个b的数据完成聚合操作。 之前有调查说Impala, presto, drill这样的SQL-on-Hadoop
: ，相对于Hive能提高10倍左右的速度，因为我拿Hive测试过，如果仅仅是10倍，显然是
: 不能满足我们的要求的。
Hadoop
【在 c*******u 的大作中提到】
: 倒不是一定不能load到别的数据库，我觉得如果用bigquery, vertica, redshift,
: greenplum这样的估计性能会好一些，但是要付费
: 另外，我担心presto, sparkSQL之类的是否可以在几秒钟之内对几个billion甚至几十
: 个b的数据完成聚合操作。 之前有调查说Impala, presto, drill这样的SQL-on-Hadoop
: ，相对于Hive能提高10倍左右的速度，因为我拿Hive测试过，如果仅仅是10倍，显然是
: 不能满足我们的要求的。
c*u
44 楼
maybe around 10 or 20
【在 l**********0 的大作中提到】
: 每个domain下最多有多少category？
:
: 样：
【在 l**********0 的大作中提到】
: 每个domain下最多有多少category？
:
: 样：
c*u
45 楼
which one can achieve that?
【在 N*****m 的大作中提到】
: 自己试试就知道了。10+s完全可行。
:
: Hadoop
【在 N*****m 的大作中提到】
: 自己试试就知道了。10+s完全可行。
:
: Hadoop
N*m
46 楼
上面都说过了啊：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?
这里是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
47 楼
spark +1
S*s
48 楼
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试试。
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
49 楼
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
【在 N*****m 的大作中提到】
: spark, flink, presto都行。不过，你的原始数据组织得优化一下。
: aws redshift刚搞了个spectrum，8秒可以query 6.1 billion rows，数据在s3上面。
:
: 30
S*s
50 楼
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.
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.
相关阅读
nodejs估计快挂了Youku has many more visitors than Netflixc++怎么实现这种结构？？从12306来看，国内IT水平不高12306最重要的是scale out和杜绝黄牛大家对这高中生写个app以$30M卖给Yahoo咋看是否值得把业务逻辑做到Hbase coprocessor里面?发现一个大牛我不认为12306是故意做成这样让黄牛赚钱mit有没有版面是讨论算法之类的一个mac号一小时最多买10张zhaoce同学一来，葵花宝典开怀给Java/Spring说几句好话java是最好的语言dart对于js来说单线程多线程说到底我为啥不喜欢12306的话题对于JAVA有一点无论谁都同意。给篇做优化的例子，普及下关于春运的票，你们都错了