将mysql的数据转存到Hadoop做实时统计分析，应该采用怎样的解决方案

最新推荐文章于 2025-11-08 16:45:24 发布

转载最新推荐文章于 2025-11-08 16:45:24 发布 · 6.1k 阅读

文章标签：

#大数据

网络专栏收录该内容

11 篇文章

订阅专栏

针对大量API调用数据导致MySQL统计效率低下问题，本文探讨了多种解决方案，包括使用Hadoop进行离线处理后再导入MySQL供查询，以及利用Elasticsearch、Spark等工具实现高效实时分析。

转自：点击打开链接https://www.zhihu.com/question/50367525

首页发现话题

将mysql的数据转存到Hadoop做实时统计分析，应该采用怎样的解决方案？

数据主要是公司开发的API的外界调用信息，然后将信息统计好制成图形放到网页上，信息包括总调用次数、用户数、平均响应时间、终端等等等。然后现在提供了按年、月、日 (按日统计是个日期区间，类似2016/5/12-2016-7/2) 的统计形式，类似运营商提供的统计每日通话时长功能。

由于现在数据量大起来了，每日增量负荷也越来越大，导致mysql在按天统计显示结果时页面得相应好久好久。部门内部考虑把数据迁移到Hadoop上，可是Hive响应速度有点慢，HBase对统计工作又不是特别友好，所以请教一下大家有没有对工具或解决方案方面的建议或意见？

关注者

106

被浏览

6344

20 个回答

使用mysql慢的原因是查询操作太复杂，需要计算量太大。
所以，想办法让mysql里存的是你要展示的数据，不需要什么复杂统计，就能快了。
让mysql里存你要显示的数据的方法一般无外乎先把原始数据存一个地儿（例如hdfs或者msyql另一个表中），然后定期起一些任务从这些原始数据算出你要展示的数据，存到mysql里。
具体要不要用hadoop我倒感觉你们数据量可能还没大到必须要用，前期就定时起单机程序或者直接用mysql的event都行。

另外，你标题中说要做实时分析，实际上，但我看你需求，认为实时分析可能是没必要的，定期（如每小时）启动任务处理上一个小时的数据即可。如果确实有实时需求，可能需要每个数据产生时发送给一个程序来处理（数据量太大时可以使用flink或storm等分布式流式计算系统），将处理的结果写入结果mysql中。不过这样做会使系统复杂度提升很大（一般流式处理实现起来都比批量处理复杂很多），如果可以批量能满足需求，应尽可能选用批量处理。

编辑于 2016-11-29

2 条评论

RunshenZ 4 个月前

               这个是ETL吧？(extract, transform, load). 
             

知乎用户 3 个月前

               不是etl,是bi. 应该是需要一个dashboard.
             

                  写下你的评论...

可以试试tidb 支持mysql协议处理这种query会比mysql好不少

发布于 2016-12-03

为什么不用elasticsearch

发布于 2016-11-29

给出一种实践过得方案：
1.数据可以直接存放到hdfs。如果是日志文件可以用flume等工具传输，如果数据存在关系型数据库中可以选择使用sqoop导入hdfs
2.数据在hdfs上就好办了，你可以写mr或者干脆用hive计算统计结果，最后的结果数据应该是很少的。
3.将上面的结果数据倒回到MySQL（这里有很多方法可以选择），用来做在线查询
over

发布于 2016-09-07

N+1的数据的统计结果应该是不会变的吧？直接加cache。

发布于 2016-12-01

用es就可以了，可以先把mysql数据灌到hive 上，作etl处理，然后创建基于es的hive 外部表,把数据灌到es

编辑于 2017-03-16

从技术角度来看，mysql足够应付大中型数据。但是你要看具体统计一下每天的数据增量和是否真的有必要保存那么多数据统计中。用hadoop不是为了快，而是因为mysql或者oracle都无法及时处理这么巨量的数据。是能和不能的区别。
还有一些小公司用hadoop，那是政治考量。或者说前瞻性考量。

我同意张云聪的建议。

而且，其实你可以做一个summary的表，然后summary还有summaryhistory,这样可以保留每一天的结果。甚至按小时，分钟来保留，对数据库来说都是小菜一碟。
每天统计时候，只需要做增量统计就可以了。速度肯定是飞快的。

发布于 2016-12-31

当前yelp开源了一套实时流的数据处理框架就支持将mysql导入至kafka中处理。https://engineeringblog.yelp.com/2016/09/data-pipeline-salesforce-connector.html

发布于 2016-12-16

用elasticsearch是个好办法
可以每天先批量跑出结果数据放到mysql中，这样就只需要一些简单计算了
如果来源数据是实时产生的，可以考虑storm或spark streaming这样的流处理器实时的做计算
总之就是先把复杂的计算通过流式处理或提前批量的方式算好得到一个中间结果，这个中间结果中包含的数据应该就是极小且不需要很多步骤就可以得到最终结果的
最后，按照你需要的方式，考虑包括elasticsearch、mysql、redis之类的存储

发布于 2016-12-06

你们一定在寻找一个关系性数据库的使用习惯，但是同时能兼顾容量扩展的数据存储系统，找了一圈发现hive是做离线数据处理的太慢，hbase做实时的够快，但是和自己系统MySQL的使用习惯相差甚远。
首先，我觉得，你们一定要考虑明白到底需不需要用hadoop，数据量少的情况下用hadoop不一定比MySQL快。如果只是单纯想加快hive的速度，那么推荐试试impala，如果公司内部大部分程序员还是关系数据库的设计方式和开发习惯，那么推荐试试greenplum。
最后说一下，还是不要简单认为上了hadoop，你们系统的性能一下就提高了，就能满足MySQL搞不定的东西，不是这样的。

发布于 2016-12-04

如果是个实时监控分析的需求的话，那可能需要搭一套实时OLAP的系统了，mysql就用来存一些结果数据和web server就好了。实时计算的话可能需要搭一套storm/samza/flink了，然后用flume专门来采集下数据。如果没有这么实时的需求的话，离线的嫌慢就把hive换成spark吧

编辑于 2016-12-03

大概四年前，我们使用sqoop来做hadoop和mysql的数据转换

发布于 2016-11-29

使用greenplum

发布于 2016-11-29

难道不是用impala吗，多准备点内存。

发布于 2016-11-29

如果数据是需要增删改的用hbase存储，然后使用hive外表关联，用hive算出结果在导回mysql，目前基本都这样玩。

发布于 2016-11-29

可以将细粒度的数据保存到hdfs上，小时天等聚合粒度的数据导回到mysql做在线查询

发布于 2016-09-10

推荐一个工具clodera还是coldera来的突然忘记了，我是做oracle与hadoop实时交互的没有做过mysql oracle与hadoop实时交互用的是odch组件，mysql应该会有相同的组件，这个没有了解过。一点点意见。。。

发布于 2016-09-07

耶！我又被要请回答这种程序员的问题了诶！可是我什么都不知道

发布于 2016-09-07

我们公司用的一套东西叫做，ETL，适合离线计算。

发布于 2016-12-03

这个在MySQL上本来就有现成的解决方案吧。

hive这种东西也拿出来说。。。你们没人懂大数据吗

需求说的不太明确，所以我也没法明确的给方案。。。你可能会用到，mycat canal/ogg storm drill MySQLcluster ignite kyrin，总有一款适合你

cloudera附赠的那几个导数据的小东西我就不提了

编辑于 2016-12-01

1 条评论

Joker 4 个月前

               cloudera-scm-agent起不来，log日志也没有，只有out文件，out文件表示Python问题；cm安装过程报错无法安装cloudera-manager-agent包，yum源找不到镜像或者相关包，怎么破
             

                  写下你的评论...

下载知乎客户端

与世界分享知识、经验和见解