当前，数据仓库被分为离线数仓和实时数仓，离线数仓一般是传统的T+1型数据ETL方案，而实时数仓一般是分钟级甚至是秒级ETL方案。并且，离线数仓和实时数仓的底层架构也不一样，离线数仓一般采用传统大数据架构模式搭建，而实时数仓则采用Lambda、Kappa等架构搭建。

　　其中，实时数仓又被细分为两类：一类是标准的实时数仓，所有ETL过程都通过Spark或Flink等实时计算、落地；另一类是简化的实时数仓，甚至是离线数仓的简单升级，这类数仓叫做准实时数仓。

　　接下来，本文重点梳理准实时数仓应用场景！

　　简单理解，准实时数仓一定会有延迟，相比一天只统计一次的离线数据仓库，准实时仓库要根据业务需求，按照小时、分钟或者秒来计算。这里，以5分钟为界限，5分钟出一次结果，可以基于Structured Streaming实现准实时数据仓库构建，这是一个基于流式数据基础之上的离线操作，即按照时间切分批次，整体的数据在流式计算引擎上面，也就是在Structured Streaming上面。

　　实时数仓项目分行业、分领域，以新闻资讯类为例，比如今日头条、一点资讯、腾讯新闻、网易新闻、百度浏览器、360浏览器、新浪、搜狐等。这类应用有哪些数据源？一般包括用户信息、隐私以及和用户收益相关的业务数据；还有用户浏览文章留下的行为日志；用户发布作品产生的内容日志，这些信息首先会收集到Kafka上。

　　之后的过程是，通过Spark Structured Streaming消费Kafka的原始数据。这里需要强调一点，采用Spark Structured Streaming有三个原因。第一，实现流批统一，可以处理批计算；第二支持file sink，实现端到端的一致性语义；第三，可以控制sink到HDFS的时间，比如：对批次数据设置5分钟节点，延时低，处理速度快。

　　从sink到HDFS时，可以选择使用Hudi，也可以选择不使用Hudi，如果通过Spark Streaming直接写数据到HDFS时，不可避免地要处理小文件问题，一般有四种处理方式。第一,增大批处理能力，但也会增加延迟；第二分区合并；第三外部程序融入；第四，如果文件没有达到指定大小，下一个批次写数据的时候不创建文件，而是和已存在的小文件合并。这四种方式各有其使用场景，无论采用哪种方式，都会增加工作量。但是，如果通过Hudi写入数据，小文件的问题，Hudi会帮忙解决。

　　还有一个问题，除了用户行为事件日志不会更新，很多业务数据需要实时更新，比如：用户信息的修改。但是，HDFS本身不支持更新，导致需要修改的数据要经过一个复杂的处理流程，并且在整个过程中，数据的实时性也无法保证，如果使用Hudi，可以在相对较短的延迟下，比如分钟级别，提供数据更新的支持，同时Hudi也支持ACID。

　　当原始数据落地到HDFS上，可以在落地过程中做一些数据预处理的工作，比如之前在Flume Interceptor中的数据处理工作，之后我们可以通过Hive建立对应的外部表，可以对这些表划分一个层次，叫做ODS层的表，这些表都是最原始数据，也是数仓的第一层。

　　建立完ODS层的Hive表，就可以根据业务需求查询数据了。至于，我们是不是要构建更上层的数仓层次，要根据业务需求来确定。映射Hive的原始数据层ODS后，就有数据可以分析处理，分析使用的是Presto分析引擎，基于内存的计算框架，计算速度要比Hive和Spark快很多。

　　使用Presto查询操作完成OLAP分析处理，还会整合Spring Boot框架，使用JDBC连接Presto，提供对外查询接口，供分析人员使用。