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

其中，實(shí)時(shí)數(shù)倉(cāng)又被細(xì)分為兩類：一類是標(biāo)準(zhǔn)的實(shí)時(shí)數(shù)倉(cāng)，所有ETL過(guò)程都通過(guò)Spark或Flink等實(shí)時(shí)計(jì)算、落地；另一類是簡(jiǎn)化的實(shí)時(shí)數(shù)倉(cāng)，甚至是離線數(shù)倉(cāng)的簡(jiǎn)單升級(jí)，這類數(shù)倉(cāng)叫做準(zhǔn)實(shí)時(shí)數(shù)倉(cāng)。

接下來(lái)，本文重點(diǎn)梳理準(zhǔn)實(shí)時(shí)數(shù)倉(cāng)應(yīng)用場(chǎng)景！

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

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

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

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

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

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

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

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