2024年最新mysql大表的解决方案，及Hive分页查询，美的java面试题

最后

面试是跳槽涨薪最直接有效的方式，马上金九银十来了，各位做好面试造飞机，工作拧螺丝的准备了吗？

掌握了这些知识点，面试时在候选人中又可以夺目不少，暴击9999点。机会都是留给有准备的人，只有充足的准备，才可能让自己可以在候选人中脱颖而出。

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

从上面很容易看出来我们遇到的，

1.单表数据量较大，已经无法支撑前台部分业务的正常操作；

2.部分统计程序写入已经达到上限（MySQL每天写入8万条的数据），造成其他任务无法正常执行，经常在凌晨脚本启动后，不能按时处理完数据，造成其他任务的挤压（注：所有离线和实时均采用spark处理，yarn资源调度采用的Fair策略，目前腾讯云不支持Capacity策略）。

对于我们的mysql表，我们存储的大部分都是统计数据，因为早期数据量较少，统计能力有限，以及考虑到和前台交互较频繁，所以一直存储在关系型数据库中，才造成目前遇到这种的窘境，已经到不了不改变的的地步，因为数据的增量越来越大。

我们的解决步骤和方法：

1.首先，我们第一个考虑的时候结合业务，前面用户的操作

2.对表中数据进行了检查和审查之后，发现大数据中经常遇到的2/8定律，20%的用户占了80%的数据。我们考虑分库和分表操作，将部分数据量较大的用户迁入到其他服务器的数据库中，但是增大的前端可视化部门的工作压力，同时统计部门的统计程序需要全部调整，用来区分不同的用户。

3.使用大数据技术解决，将离线数据，全部迁移到Hive中，按天分区管理，使用presto做复杂查询，实时数据保留，继续写入mysql，对于有更新操作的表，直接写入到Hbase中，使用phoenix处理。

在迁移数据的过程中，我们刚开始使用的是sqoop导取mysql数据到Hive，动态分区，后来发现这样有一些弊端，因为无法解决spark写入Mysql的性能问题，我们对spark进行了各种优化，将数据的处理时间控制在了5分钟左右，但是却经常在写mysql的时候需要将近1个钟头的时间，于是直接将离线统计全部直接直接写入HDFS，现在基本上分析和写入时间在10分钟左右。同时也解决了数据挤压的问题。

最后问题解决了，目前我们做了一个中间微服务，使用springboot做查询，分为两部分处理，

a.用户对历史数据（昨天，最近1周或最近1个月，以及指定任意时间段区间，除今天之外）的操作，我们均采用presto操作;

b.用户查询今天的实时操作，我们直接读取mysql中的数据，目前单表数据量最大在千万级，所以msyql完全能支撑的住，而且性能还不错。对于用户指定较长时间段的查询，包括实时今天的数据操作时，我们采取，presto+mysql同时分析处理，然后通过程序对数据进行最后统一的合并，分页，排序，这个目前还在优化，以达到准确性在可承受范围内。

以上是我们的解决方法，PHP人员直接调用我们的接口，不需要关心我们底层使用的什么技术（当然这个解决方法只是基于我们目前的业务场景的解决方法，不一定是最优的解决方案，但是目前给我们统计大量的数据涌进来时，提供了一定的缓冲时间），同时将可视化和底层数据剥离开，如果目前的方法达到瓶颈，再次无法满足性能的要求，后面考虑使用其他技术处理，最主要的是这次调整降低了公司的经济支出，不用被动的去升级资源配置。

最后，给出了一个Hive中分页的查询操作，主要使用到row_number和between，and。

select c.*

from(

select row_number() over (order by b.ev_paras_value ASC ) as sort_field, b.*

from (

select a.app_key, a.event_key, a.ev_paras_value, a.paras_uv, a.paras_count

FROM (

select app_key, event_key, ev_paras_value,

最后

面试是跳槽涨薪最直接有效的方式，马上金九银十来了，各位做好面试造飞机，工作拧螺丝的准备了吗？

掌握了这些知识点，面试时在候选人中又可以夺目不少，暴击9999点。机会都是留给有准备的人，只有充足的准备，才可能让自己可以在候选人中脱颖而出。

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

acb)收录**

需要这份系统化的资料的朋友，可以点击这里获取