隨著互聯(lián)網(wǎng)的發(fā)展從紅海時(shí)代進(jìn)入藍(lán)海時(shí)代，數(shù)據(jù)的時(shí)效性對(duì)企業(yè)的精細(xì)化運(yùn)營(yíng)越來越重要，在每天產(chǎn)生的海量數(shù)據(jù)中，如何挖掘出實(shí)時(shí)有效的信息，對(duì)于公司的快速?zèng)Q策、產(chǎn)品的快速迭代都非常重要。在本地生活服務(wù)領(lǐng)域的兩大巨頭，滴滴在自己的業(yè)務(wù)如順風(fēng)車、美團(tuán)在自己的業(yè)務(wù)如團(tuán)購?fù)赓u中進(jìn)行實(shí)時(shí)數(shù)倉的建設(shè)，為消費(fèi)者提供更好的服務(wù)，如我們?cè)诘蔚紊峡梢愿斓拇虻礁阋说能?、在美團(tuán)上可以更快的取到最想要吃的餐，這其中的功勞也要算實(shí)時(shí)數(shù)倉一份。那么實(shí)時(shí)數(shù)倉到底是什么呢？與傳統(tǒng)數(shù)倉有什么區(qū)別？如何建設(shè)實(shí)時(shí)數(shù)倉呢？

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

在數(shù)倉的開發(fā)實(shí)現(xiàn)中包含四個(gè)模塊，即物理存儲(chǔ)、數(shù)據(jù)抽象、runtime作業(yè)執(zhí)行、編程接口。那么離線數(shù)倉和實(shí)時(shí)數(shù)倉有什么區(qū)別呢？在物理存儲(chǔ)模塊，離線數(shù)倉一般使用HDFS存儲(chǔ)，實(shí)時(shí)數(shù)倉使用Kafka消息隊(duì)列進(jìn)行存儲(chǔ)，在數(shù)據(jù)抽象模塊，離線數(shù)倉使用HIve表，實(shí)時(shí)數(shù)倉使用streamtable。在作業(yè)執(zhí)行模塊，離線數(shù)倉使用mapreudce，而實(shí)時(shí)數(shù)倉使用FlinkStreaming。在編程模塊，離線數(shù)倉使用HiveSQL進(jìn)行開發(fā)，實(shí)時(shí)數(shù)倉使用FlinkSQL 進(jìn)行開發(fā)。這就是實(shí)時(shí)數(shù)倉和離線數(shù)倉在開發(fā)實(shí)現(xiàn)上的區(qū)別了。

介紹完了數(shù)倉概念、實(shí)時(shí)數(shù)倉和傳統(tǒng)數(shù)倉的區(qū)別之后，我們?cè)賮砜纯?strong>技術(shù)選型。

在實(shí)時(shí)數(shù)倉的建設(shè)中對(duì)于大規(guī)模數(shù)據(jù)的處理架構(gòu)有Lambda架構(gòu)、Kappa架構(gòu)，從業(yè)界使用情況、靈活性、容錯(cuò)性、成熟度、遷移成本、批/流處理代碼來看，Lambda都是最佳的方案。在實(shí)時(shí)計(jì)算引擎上，F(xiàn)link是最佳的選擇方案，因?yàn)楸容^準(zhǔn)確、延時(shí)低、業(yè)界內(nèi)使用多、易用性高。在實(shí)時(shí)存儲(chǔ)引擎上，綜合業(yè)務(wù)維度索引、高并發(fā)情況、高性能查詢特征，一般推薦ClickHouse。

介紹完技術(shù)選型之后，我們來看看實(shí)時(shí)數(shù)倉和實(shí)時(shí)存儲(chǔ)兩塊如何實(shí)現(xiàn)？

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

在整個(gè)業(yè)務(wù)系統(tǒng)的架構(gòu)設(shè)計(jì)中分為兩部分，即實(shí)時(shí)數(shù)倉和實(shí)時(shí)存儲(chǔ)。對(duì)于實(shí)時(shí)數(shù)倉我們已經(jīng)介紹了，而對(duì)于實(shí)時(shí)存儲(chǔ)，一般滿足三個(gè)需求，即支持海量數(shù)據(jù)存儲(chǔ)、支持分布式高可用、支持高性能查詢。對(duì)于海量數(shù)據(jù)的寫入，業(yè)界內(nèi)一般采用clickhouse大數(shù)據(jù)庫存儲(chǔ)。為了保障系統(tǒng)的高可用，互聯(lián)網(wǎng)通用的模式是分布式部署，一般借助分布式協(xié)調(diào)框架Zookeeper來進(jìn)行實(shí)現(xiàn)，數(shù)據(jù)寫入某一個(gè)分片時(shí)，zookeeper告訴同一個(gè)分片的其它副本，副本來拉取數(shù)據(jù)，保障同一分片內(nèi)的數(shù)據(jù)是一致的。在數(shù)據(jù)查詢中，借助于存儲(chǔ)數(shù)據(jù)庫clickhouse的稀疏索引優(yōu)勢(shì)，將時(shí)間維度和內(nèi)容進(jìn)行稀疏索引建立，之后就可以基于內(nèi)容進(jìn)行查詢了。

在互聯(lián)網(wǎng)流量為王的時(shí)代，通過數(shù)據(jù)精準(zhǔn)的了解用戶情況，進(jìn)行準(zhǔn)確的營(yíng)銷和運(yùn)營(yíng)才能把用戶長(zhǎng)久的留在自己平臺(tái)，從而保障業(yè)務(wù)的長(zhǎng)久發(fā)展，在滴滴的打車業(yè)務(wù)中采用實(shí)時(shí)數(shù)倉，可以知道某個(gè)時(shí)間點(diǎn)某個(gè)區(qū)域的乘客發(fā)單情況、司機(jī)應(yīng)答情況，從而采取對(duì)應(yīng)的優(yōu)惠券觸發(fā)或加派司機(jī)進(jìn)行調(diào)度支持等策略，現(xiàn)在滴滴推出的特惠快車背后也有實(shí)時(shí)數(shù)倉的功勞呢，系統(tǒng)通過實(shí)時(shí)數(shù)倉發(fā)現(xiàn)該時(shí)間點(diǎn)乘客較少、司機(jī)比較空閑，于是通過比較優(yōu)惠價(jià)格，提高乘客打車欲望、增加司機(jī)收入。

通過本文的介紹，相信你已經(jīng)了解了BAT、TMD等互聯(lián)網(wǎng)巨頭都在建設(shè)的實(shí)時(shí)數(shù)倉到底是什么樣了吧？如果是準(zhǔn)備從事數(shù)據(jù)分析行業(yè)的朋友，實(shí)時(shí)數(shù)倉是一個(gè)不錯(cuò)的方向噢；而對(duì)于待在互聯(lián)網(wǎng)圈、使用互聯(lián)網(wǎng)服務(wù)的朋友，在享受服務(wù)的同時(shí)了解一些背后的邏輯也是不錯(cuò)噢！