隨著互聯網的發展從紅海時代進入藍海時代，數據的時效性對企業的精細化運營越來越重要，在每天產生的海量數據中，如何挖掘出實時有效的信息，對于公司的快速決策、產品的快速迭代都非常重要。在本地生活服務領域的兩大巨頭，滴滴在自己的業務如順風車、美團在自己的業務如團購外賣中進行實時數倉的建設，為消費者提供更好的服務，如我們在滴滴上可以更快的打到更便宜的車、在美團上可以更快的取到最想要吃的餐，這其中的功勞也要算實時數倉一份。那么實時數倉到底是什么呢？與傳統數倉有什么區別？如何建設實時數倉呢？

數倉，即存放數據的倉庫，包括全量數據、歷史數據。類型上又分為實時數倉、離線數倉，所謂實時數倉是指數據的實時性更高、延遲性低，一般是統計一天以內的數據，支持毫秒級的統計，在建設工具上一般采用Flink，而離線數倉則統計歷史數據，在建設工具上一般采用Hive。對于實時性要求比較高的場景，如實時的交易分析、實時數據看板（比如雙十一的成交額看板）、實時業務監控、實時數據接口服務等，我們就需要實時數倉了。

在數倉的開發實現中包含四個模塊，即物理存儲、數據抽象、runtime作業執行、編程接口。那么離線數倉和實時數倉有什么區別呢？在物理存儲模塊，離線數倉一般使用HDFS存儲，實時數倉使用Kafka消息隊列進行存儲，在數據抽象模塊，離線數倉使用HIve表，實時數倉使用streamtable。在作業執行模塊，離線數倉使用mapreudce，而實時數倉使用FlinkStreaming。在編程模塊，離線數倉使用HiveSQL進行開發，實時數倉使用FlinkSQL 進行開發。這就是實時數倉和離線數倉在開發實現上的區別了。

介紹完了數倉概念、實時數倉和傳統數倉的區別之后，我們再來看看技術選型。

在實時數倉的建設中對于大規模數據的處理架構有Lambda架構、Kappa架構，從業界使用情況、靈活性、容錯性、成熟度、遷移成本、批/流處理代碼來看，Lambda都是最佳的方案。在實時計算引擎上，Flink是最佳的選擇方案，因為比較準確、延時低、業界內使用多、易用性高。在實時存儲引擎上，綜合業務維度索引、高并發情況、高性能查詢特征，一般推薦ClickHouse。

介紹完技術選型之后，我們來看看實時數倉和實時存儲兩塊如何實現？

在實時數倉中包含四層，即數據接入層ODS、數據明細層DWM、數據匯總層DWS、數據應用層APP。如下圖所示，ODS層是數據的源頭，包含系統的消息隊列數據、系統日志、流量埋點數據、系統消息，不同業務線可能采用的方式存儲數據，但是在接入數倉時需要統一來源接入，這樣可以方便數據的處理以及數據一致性。在數據明細層，一般分兩類進行數據建設，一類是業務數據明細、一類是按維度進行數據拆分，比如在美團中，商家的地理位置、評分、菜品、價格就是明細數據，也可以按地域維度、商家維度、菜品維度、價格維度進行建設。在匯總層主要基于共性維度進行建模分析，比如系統的日活、月活等數據，在匯總層就可以統一的運算。在APP層主要就是把實時數據寫入應用系統的數據庫，用于建設實時看板、實時特征應用、實時分析。

在整個業務系統的架構設計中分為兩部分，即實時數倉和實時存儲。對于實時數倉我們已經介紹了，而對于實時存儲，一般滿足三個需求，即支持海量數據存儲、支持分布式高可用、支持高性能查詢。對于海量數據的寫入，業界內一般采用clickhouse大數據庫存儲。為了保障系統的高可用，互聯網通用的模式是分布式部署，一般借助分布式協調框架Zookeeper來進行實現，數據寫入某一個分片時，zookeeper告訴同一個分片的其它副本，副本來拉取數據，保障同一分片內的數據是一致的。在數據查詢中，借助于存儲數據庫clickhouse的稀疏索引優勢，將時間維度和內容進行稀疏索引建立，之后就可以基于內容進行查詢了。

在互聯網流量為王的時代，通過數據精準的了解用戶情況，進行準確的營銷和運營才能把用戶長久的留在自己平臺，從而保障業務的長久發展，在滴滴的打車業務中采用實時數倉，可以知道某個時間點某個區域的乘客發單情況、司機應答情況，從而采取對應的優惠券觸發或加派司機進行調度支持等策略，現在滴滴推出的特惠快車背后也有實時數倉的功勞呢，系統通過實時數倉發現該時間點乘客較少、司機比較空閑，于是通過比較優惠價格，提高乘客打車欲望、增加司機收入。

通過本文的介紹，相信你已經了解了BAT、TMD等互聯網巨頭都在建設的實時數倉到底是什么樣了吧？如果是準備從事數據分析行業的朋友，實時數倉是一個不錯的方向噢；而對于待在互聯網圈、使用互聯網服務的朋友，在享受服務的同時了解一些背后的邏輯也是不錯噢！