用户行为的数据放进hadoop中还是mysql中再进行统计？为什么？

[Drop1]

最终确定要做5种类型的推荐，每种推荐类型及需要的数据简要叙述如下：

1、根据商品id获得所属类别的销售排行榜
* 商品id
* product_category表（商品与类别的关系表）
* order_items表（订单明细表。位于Order库）
2、根据商品id获得浏览了该商品的用户最终购买的商品
* 商品id
* user_visited_prd表：能获得浏览了该商品的所有用户
* product_category表（商品与类别的关系表）：从此表中能够获得类别
* orders表
* order_items表（订单明细表）
3、根据商品id获得其关联商品
* 商品id
* r_pid_related_pid表：人为在此表中设置商品与商品之间的关联。此表用于在OA中做细调。

4、根据商品id获得购买了该商品的用户还购买的商品
* 商品id
* orders表
* order_items表
* product_category表：从此表中获得类别。

5、根据商品id获得浏览了该商品的用户还浏览了的商品
* 商品id
* user_visited_prd表
* product_category表


我认为的作法是：

数据就放在mysql数据库中，每天凌晨3点跑一个定时任务，分析这些数据，得出最终的今天这一天的推荐结果数据放入数据库表中，然后前端页面调用接口查询这个最终结果数据就行了。

原因：
1、数据放在数据库中，查询、统计方便。
2、数据库表中已经有这些数据，直接用就行了，这样保证了：
（1）、数据源只有一个
（2）、数据的最新性
避免了：
（1）、同步数据所带来的数据大量重复、不即时性、复杂性
增加了：
（1）、维护量


而我们经理的想法是：

将所有需要的数据，放入hdfs中，然后用hadoop进行分析，得出来最终的结果数据，再放入mysql数据库表中。前端接口再查询访问这些最终的结果数据。

我认为这样做的好处是（按重要度排列）：

1、所有的数据放入了hdfs中，而不放入线上mysql数据库中，这样在统计分析数据时，就不会影响正在下单、操作数据库的用户。
2、利用了hadoop的“分布”式“计算”框架的优势，可以像多核cpu一起共同计算一样，这样分析速度会快。
3、减少了线上mysql数据库的负担。
4、所有需要的数据，都放在hdfs中，这样让相关人员的思路也会觉得清晰。

我认为这样做的缺点：

1、数据不放在数据库中，查询、统计不如写sql语句那样方便。得写map－reduce程序，与写sql语句相比复杂得多。
2、现在数据库表中已经有这些数据，还需要再复制一份到hdfs中，这就使：
（1）、数据源有了2个，那就必然涉及到同步问题，也就要解决同步的那些问题：
* 数据的最新性
* 数据的大量重复
* 维护量




请老师指点，应该选取哪种方案呢？为什么？急！谢谢您师兄！

[wisdomhxz]

当你数据量达到一定量级的时候，在hadoop分布计算优势很明显。 而你在mysql直接分析，会占用大量IO，甚至影响在线系统稳定。 前提，数据量够大。如果只是几千几百的数据，那么确实在mysql搞就可以了。

[johnny_zuo]

跟你的数据量有关，如果数据量较大，还是把数据导到hive中，用hive直接写sql分析也是一样的

[小爽昵称已被占用]

同ls..看数据量..

[晚起的鸟]

经理对吧，凌晨3点也有买东西的，数据量大的话，你跑任务，会卡的不行，所以这些任务分离出来，分析完再给它，这样多好。你说的两个缺点都不是缺点：1你说复杂，技术总要提高嘛，技术复杂也得提高啊，不能不前进吧。2其实你们要放到hadoop上的数据只是第一个吧？因为第一个实时性不要求，只要显示昨天之前的就行吧？所以根本不要同步，只要半夜把销售量相关的大量数据给hadoop即可，处理完后再还给mysql，或者放到其他单独数据库，然后产品销量这块的数据直接调用即可。

[撸大湿]

引用 楼主 Drop1 的回复:

我认为这样做的好处是（按重要度排列）： 1、所有的数据放入了hdfs中，而不放入线上mysql数据库中，这样在统计分析数据时，就不会影响正在下单、操作数据库的用户。 我认为这样做的缺点： 1、数据不放在数据库中，查询、统计不如写sql语句那样方便。得写map－reduce程序，与写sql语句相比复杂得多。 2、现在数据库表中已经有这些数据，还需要再复制一份到hdfs中，这就使： （1）、数据源有了2个，那就必然涉及到同步问题，也就要解决同步的那些问题： * 数据的最新性 * 数据的大量重复 * 维护量

见粗体字，就这一条原因足以打倒LZ认为的所有缺点。 不影响正常业务是第一最高优先级