业务速查hive巨型表模型设计

某业务需求查询用户用电监测表，详细业务详情记不清了，需要查询某个用户的最早业务时间。具体到SQL语句上面， 就是查询某个用户的最小业务时间对应的那条数据。

数据量非常大，增量2.4千万/天。根据业务时间按天分区， 目前存储了2020年数据。数据存储在hive 中。

 业务点：业务会给出一个用户ID，用这个用户ID，到这张大表中查询其最小业务时间，比如有2020-01-01  和2020-01-02两条数据， 其中2020-01-01业务时间最小，那么就取2020-01-01 这条数据，返回给用户。

难点：查询这张表，再计算最小时间，非常消耗集群资源。而且随着时间推移，隐患越来越大，不可控。

下面把分析思路，解决方案，维护措施说明。

解决方案：

分析思路2：

     解决问题的关键点在于新模型表。新模型一个用户ID，只存储1条数据，其数据量可控， 通过查询现有表，大概有2.3千万数据量，“新装用户”基本上不多.  一个月30万不到。其数据量还可以接受。

 再结合分区，更贴切现有的业务。这里不再多说了。

维护措施：

   新模型表数据对数据更新的力度有要求。

在大表更新之后，业务查询之前，保证新模型表业务更新完成。而且需要做成增量更新。

   现在已经是1年左右时间。 也就是需要维护现有数据。还好是一次性维护。而且基本上更新第一天已经更新了近95%的数据了。

思考问题：

如果业务经常以少量（一个或者有限数量）用户的相关数据， 那么这个模型表怎么设计。