當前，數(shù)據(jù)倉庫被分為離線數(shù)倉和實時數(shù)倉，離線數(shù)倉一般是傳統(tǒng)的T+1型數(shù)據(jù)ETL方案，而實時數(shù)倉一般是分鐘級甚至是秒級ETL方案。并且，離線數(shù)倉和實時數(shù)倉的底層架構也不一樣，離線數(shù)倉一般采用傳統(tǒng)大數(shù)據(jù)架構模式搭建，而實時數(shù)倉則采用Lambda、Kappa等架構搭建。

其中，實時數(shù)倉又被細分為兩類：一類是標準的實時數(shù)倉，所有ETL過程都通過Spark或Flink等實時計算、落地；另一類是簡化的實時數(shù)倉，甚至是離線數(shù)倉的簡單升級，這類數(shù)倉叫做準實時數(shù)倉。

接下來，本文重點梳理準實時數(shù)倉應用場景！

簡單理解，準實時數(shù)倉一定會有延遲，相比一天只統(tǒng)計一次的離線數(shù)據(jù)倉庫，準實時倉庫要根據(jù)業(yè)務需求，按照小時、分鐘或者秒來計算。這里，以5分鐘為界限，5分鐘出一次結果，可以基于Structured Streaming實現(xiàn)準實時數(shù)據(jù)倉庫構建，這是一個基于流式數(shù)據(jù)基礎之上的離線操作，即按照時間切分批次，整體的數(shù)據(jù)在流式計算引擎上面，也就是在Structured Streaming上面。

實時數(shù)倉項目分行業(yè)、分領域，以新聞資訊類為例，比如今日頭條、一點資訊、騰訊新聞、網(wǎng)易新聞、百度瀏覽器、360瀏覽器、新浪、搜狐等。這類應用有哪些數(shù)據(jù)源？一般包括用戶信息、隱私以及和用戶收益相關的業(yè)務數(shù)據(jù)；還有用戶瀏覽文章留下的行為日志；用戶發(fā)布作品產(chǎn)生的內(nèi)容日志，這些信息首先會收集到Kafka上。

之后的過程是，通過Spark Structured Streaming消費Kafka的原始數(shù)據(jù)。這里需要強調(diào)一點，采用Spark Structured Streaming有三個原因。第一，實現(xiàn)流批統(tǒng)一，可以處理批計算；第二支持file sink，實現(xiàn)端到端的一致性語義；第三，可以控制sink到HDFS的時間，比如：對批次數(shù)據(jù)設置5分鐘節(jié)點，延時低，處理速度快。

從sink到HDFS時，可以選擇使用Hudi，也可以選擇不使用Hudi，如果通過Spark Streaming直接寫數(shù)據(jù)到HDFS時，不可避免地要處理小文件問題，一般有四種處理方式。第一,增大批處理能力，但也會增加延遲；第二分區(qū)合并；第三外部程序融入；第四，如果文件沒有達到指定大小，下一個批次寫數(shù)據(jù)的時候不創(chuàng)建文件，而是和已存在的小文件合并。這四種方式各有其使用場景，無論采用哪種方式，都會增加工作量。但是，如果通過Hudi寫入數(shù)據(jù)，小文件的問題，Hudi會幫忙解決。

還有一個問題，除了用戶行為事件日志不會更新，很多業(yè)務數(shù)據(jù)需要實時更新，比如：用戶信息的修改。但是，HDFS本身不支持更新，導致需要修改的數(shù)據(jù)要經(jīng)過一個復雜的處理流程，并且在整個過程中，數(shù)據(jù)的實時性也無法保證，如果使用Hudi，可以在相對較短的延遲下，比如分鐘級別，提供數(shù)據(jù)更新的支持，同時Hudi也支持ACID。

當原始數(shù)據(jù)落地到HDFS上，可以在落地過程中做一些數(shù)據(jù)預處理的工作，比如之前在Flume Interceptor中的數(shù)據(jù)處理工作，之后我們可以通過Hive建立對應的外部表，可以對這些表劃分一個層次，叫做ODS層的表，這些表都是最原始數(shù)據(jù)，也是數(shù)倉的第一層。

建立完ODS層的Hive表，就可以根據(jù)業(yè)務需求查詢數(shù)據(jù)了。至于，我們是不是要構建更上層的數(shù)倉層次，要根據(jù)業(yè)務需求來確定。映射Hive的原始數(shù)據(jù)層ODS后，就有數(shù)據(jù)可以分析處理，分析使用的是Presto分析引擎，基于內(nèi)存的計算框架，計算速度要比Hive和Spark快很多。

使用Presto查詢操作完成OLAP分析處理，還會整合Spring Boot框架，使用JDBC連接Presto，提供對外查詢接口，供分析人員使用。