當前，數據倉庫被分為離線數倉和實時數倉，離線數倉一般是傳統的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，提供對外查詢接口，供分析人員使用。