mysql大表的解决方案，及Hive分页查询

蜂信物联FastBee平台https://gitee.com/beecue/fastbee

阿里资料开源项目https://gitee.com/vip204888

百度低代码前端框架https://gitee.com/baidu/amis

OpenHarmony开源项目https://gitcode.com/openharmony

仓颉编程语言开放项目https://gitcode.com/Cangjie
先说一下遇到的问题，然后给出自己的解决方案，虽然不一定是最佳的解决方法，但是目前确实解决了公司的大表数据问题，如果其他小伙伴有更好的解决方法，也请多多交流，给出自己的解决方法。

目前所有的数据和工具组件都是基于腾讯云搭建和管理，先说下我们遇到的情况：

1.mysql表查询数据量较大（最大的一张表已经达到33亿条数据，整个mysql已经达到2.9T的数据存储），

2.mysql表每日新增数据量较大（增量最大的表，每日新增数据量在4千万条左右的数据）

3.需要支持事务操作，部分表需要支持更新操作。

4.支持复杂操作，包括模糊，排序，分组统计和分页等操作。

5.低延迟，用户选择的任务条件查询，响应时间应该控制在3-5s。

6.实时数据的写入和查询操作,目前实时数据每10分钟处理一次，大概400G左右的数据。

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

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操作;

最后

一次偶然，从朋友那里得到一份“java高分面试指南”，里面涵盖了25个分类的面试题以及详细的解析：JavaOOP、Java集合/泛型、Java中的IO与NIO、Java反射、Java序列化、Java注解、多线程&并发、JVM、Mysql、Redis、Memcached、MongoDB、Spring、Spring Boot、Spring Cloud、RabbitMQ、Dubbo 、MyBatis 、ZooKeeper 、数据结构、算法、Elasticsearch 、Kafka 、微服务、Linux。

这不，马上就要到招聘季了，很多朋友又开始准备“金三银四”的春招啦，那我想这份“java高分面试指南”应该起到不小的作用，所以今天想给大家分享一下。

请注意：关于这份“java高分面试指南”，每一个方向专题（25个）的题目这里几乎都会列举，在不看答案的情况下，大家可以自行测试一下水平 且由于篇幅原因，这边无法展示所有完整的答案解析
请注意：关于这份“java高分面试指南”，每一个方向专题（25个）的题目这里几乎都会列举，在不看答案的情况下，大家可以自行测试一下水平 且由于篇幅原因，这边无法展示所有完整的答案解析