hive处理集市层实时统计需求思路

一、背景

CDC工具 + flink目前可以做到数据实时入hive，所以很多需求可能也需要实时性要求，非毫秒级的。可能就是半个小时统计、一个小时统计这样的指标，但是数据要求实时。

这类需求没用flink或者spark去处理，要用hive来做。

二、思路阐述

图中表的简要说明：

1）SRC_T1，这个是一张5分钟的实时表，通过flink程序实时采集数据进hive中；

2）TMP1，这个是无分区的hive表，用来保留近实时历史全量数据；

3） TMP2，这个是定时任务用到的临时表。处理数据先写到临时表，再覆写TMP1。

4）DM_M1，这个是集市层的实时指标表，需要每半个小时统计一次最新数据。

图中两个任务的说明：

处理逻辑参考图中叙述；

注意事项：

DM层的统计任务高度依赖TMP1的准实时性，TMP1的全量最新数据是又TMP2的任务处理的。所以得先保证TMP2的任务运行。如果TMP1是前一天的最新数据，基本不需要考虑这个问题，只是要主要0点-1点的DM数据。

即如果是半小时或1小时，11点时，调度执行顺序： TMP2早于DM表任务。

设计初衷：

因为实时采集，SRC_T1这个表的特点就是分区特别多，重复数据多。一条业务的CRUD，CDC可能会捕捉到多条记录，如insert，多次update。而DM需求只关心最新状态就行了。

如果不做中间表，直接在DM统计扫码SRC_T1全表去重，再统计逻辑出结果，可能OOM或者半个小时计算无法完成。

设计了TMP1后，DM只需加载TMP1的全表，跟今天的增量数据即可。 加载分区数据量大大减少了，这是其一；

拿全量历史 + 最新增量数据union all后去重，处理速度会比直接SRC_T1全表处理速度快，这是第二点。

另外TMP1也可以作为一个历史缓冲，如果实施指标不对，可以先排查是这部分数据出了问题，还是今天增量数据出了问题，这个是第三点。而且这两部分数据都不会特别多，排查问题快。

缺点是增加处理任务和流程复杂性，还必须注意任务调度的先后顺序。

三、最后说明

这一类实时需求采用hive也是无奈，这个思路应该可以保证实时指标的统计。

如果大家觉得这个方案有什么漏洞，或者有什么更好的思路，欢迎评论留言，或者私信我。