如何構建準實時數倉？

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