很可惜 T 。T 您現(xiàn)在還不是作者身份，不能自主發(fā)稿哦～
如有投稿需求，請把文章發(fā)送到郵箱tougao@appcpx.com，一經(jīng)錄用會有專人和您聯(lián)系
咨詢?nèi)绾纬蔀榇河鹱髡哒埪?lián)系：鳥哥筆記小羽毛（ngbjxym）
場景決定一切。離線數(shù)倉的時候數(shù)據(jù)更新頻率是T+1，也就是說必須隔一天才能看到結(jié)果，今天看昨天的數(shù)據(jù)。但是數(shù)據(jù)界有一個確定的結(jié)論，就是數(shù)據(jù)越新，價值越大。于是就有了推薦、風(fēng)控等各種實時應(yīng)用場景，讓數(shù)據(jù)在最有價值的時候被利用好。在這些場景中，對數(shù)據(jù)的實時性要求就非常高，往往需要毫秒級反應(yīng)，否則會影響用戶體驗，帶來不必要的損失。
在最開始的時候，業(yè)界采用Storm進(jìn)行實時數(shù)據(jù)流計算。后來有了spark streaming，現(xiàn)在最火熱的當(dāng)屬Flink了。在離線數(shù)據(jù)倉庫架構(gòu)設(shè)計的時候，大家知道需要分層，數(shù)據(jù)得落地在數(shù)據(jù)存儲介質(zhì)中，一般是各種數(shù)據(jù)庫。但是實時場景，數(shù)據(jù)一直是在流動的，數(shù)據(jù)怎么落地？怎么分層？以下圖為例，數(shù)據(jù)從各種日志中實時讀取過來，最后流向?qū)崟r大屏，大屏計算結(jié)果就必須得有個地方存著啊。
上圖看上去很不錯，能在大屏上直接展示結(jié)果。但是一細(xì)看，就會有無數(shù)問題：大屏上需要展示多少指標(biāo)？面對任性的業(yè)務(wù)，面對他們 無窮無盡 的需求，作為技術(shù)能做的是怎么能更好的服務(wù)他們？如何做到以數(shù)據(jù)驅(qū)動業(yè)務(wù)的成長，以數(shù)據(jù)驅(qū)動產(chǎn)業(yè)數(shù)字化？
業(yè)務(wù)的需求多變，指標(biāo)可能是無窮無盡的，導(dǎo)致的也就是開發(fā)速度可能不盡人意?？赡軆商觳庞幸粋€指標(biāo)的產(chǎn)出，復(fù)雜的可能一個星期乃至更長。如果需求不能加以控制，我們將陷入無盡的任務(wù)中。如果拒絕需求，業(yè)務(wù)的需求得不到滿足，數(shù)據(jù)團(tuán)隊存在的意義又會大大降低。我們該怎么辦？
那么我們有沒有可能在犧牲一些查詢速度的同時，來提升我們的開發(fā)速度，我們應(yīng)該都知道spark streaming 和flink都是支持sql開發(fā)的。那么flink 或者spark streaming 來進(jìn)行sql 開發(fā)，時效性和靈活性會比較低，直接開放給業(yè)務(wù)方，用戶體驗會非常不好。這是一個很值得思考的問題。那么我們又該咋辦？
我們是不是可以嘗試將我們的binlog 數(shù)據(jù)以及埋點(diǎn)數(shù)據(jù)進(jìn)行拉寬，也就是寬表化的一些操作？變成離線數(shù)倉那樣的OLAP？自主化的查詢呢？對，這就是實時數(shù)倉的誕生！
實時數(shù)倉在我理解中呢，可以對外進(jìn)行服務(wù)，并且可以實時的進(jìn)行OLAP查詢，也就是在線化查詢 Ad-hoc化的查詢。
初始
在我剛來公司的時候，并沒有實時數(shù)倉，只是一些批處理化的操作，并且是一種煙囪式的開發(fā)。數(shù)據(jù)流程是這樣的，我們采用的greenplum來做的準(zhǔn)實時數(shù)倉，每15分鐘去業(yè)務(wù)庫和神策系統(tǒng)拉取實時數(shù)據(jù)到greenplum中進(jìn)行計算，如下圖所示。
我們這個時候肯定可以發(fā)現(xiàn)，假如指標(biāo)多的時候，那么對于開發(fā)速度來講是一個十分緩慢的一個過程，并且會造成很多數(shù)據(jù)的冗余計算，有些指標(biāo)并不能復(fù)用。
在對公司情況有所了解之后，我選擇了Flink作為實時數(shù)倉的核心組件。在熟悉了業(yè)務(wù)之后，我選了一個線上分析的需求，簡單梳理了一下數(shù)據(jù)流向：
上線之后效果還不錯，業(yè)務(wù)方非常滿意，領(lǐng)導(dǎo)也加以贊許。但是后來慢慢的需求多了起來，我意識到拿flink寫需求肯定會陷入無盡的任務(wù)。我明白必須要避免煙囪式的開發(fā)，應(yīng)該做好數(shù)據(jù)架構(gòu)，把數(shù)據(jù)和業(yè)務(wù)徹底解耦！
其實實時數(shù)倉也很簡單，你把實時表都想象成離線寬表一樣的話，那么直接在寬表上進(jìn)行計算不就好了嗎。OK，咱開始實戰(zhàn)。
按照CIF設(shè)計規(guī)范，要拉寬這些數(shù)據(jù)表，得有核心場景。我們公司是比較關(guān)心銷售的，把離線的銷售寬表拿實時展現(xiàn)出來就是很好的一個場景。
先確定數(shù)據(jù)源，我們的數(shù)據(jù)是從業(yè)務(wù)庫來。但是我們的postgresql 比較老，并沒有binlog這些的操作。我當(dāng)初就和研發(fā)的架構(gòu)探討了一下，他們那邊借助觸發(fā)器來進(jìn)行給我往kafka中打數(shù)據(jù)，解決數(shù)據(jù)源的問題。
然后解決數(shù)據(jù)質(zhì)量問題，我對數(shù)據(jù)先進(jìn)行了校驗，也就是看看我要的字段是否都齊全，數(shù)據(jù)是否有問題。這兩個問題都解決之后，就開始嘗試用flink接入kafka的數(shù)據(jù)。
這個時候我數(shù)據(jù)是拿到了，但是我需要拉寬，我應(yīng)該怎么拉寬？我選擇把相關(guān)維度表放置到redis，這樣比較快。這樣在flink的map方法中進(jìn)行查詢redis中的數(shù)據(jù)來進(jìn)行拉寬維度表。
這個時候就來問題了，我的維度表是會更新的啊。我也就問了我們組的業(yè)務(wù)大佬，咨詢了一下，發(fā)現(xiàn)維度表無非就是門店維表、品類維表（一級類、二級類、三級類等）、城市維表、商品維表、主推表等。這些都是緩慢變化維，即使是更新，也會提前上線幾天進(jìn)行更新。并且我們在凌晨0點(diǎn)到2點(diǎn)是不進(jìn)行出庫操作的，我在這個時候進(jìn)行維度表更新操作不就好了嗎。那么也就有下面的設(shè)計，定時進(jìn)行redis中的維度數(shù)據(jù)更新：
那么接下來我們就可以進(jìn)行銷售寬表的拉寬操作了，但是我這個時候又發(fā)現(xiàn)了一個問題，我拉寬之后存在哪里，這個時候我得思考的幾點(diǎn)是。第一單表查詢足夠快、最好支持join。那么我開始的調(diào)研過幾款 Tidb、Doris、Druid、Clickhouse。我在單機(jī)測試的表現(xiàn)上來看，clickhouse給我?guī)砹藷o與倫比的感覺。并且考慮到當(dāng)時的業(yè)務(wù)場景，也就毅然決然的采用了Clickhouse為基礎(chǔ)的實時數(shù)倉。
然后就這樣的一個架構(gòu)持續(xù)了大概兩個月的時間，業(yè)務(wù)也越來越復(fù)雜。比如：門店需要對導(dǎo)購拉新來做當(dāng)日的績效考核，因此需要接入一些用戶維度表。那么我們總計有2000多萬的用戶，我全部都導(dǎo)入的redis話會有一些問題。同時還有一些實時需求，例如要在用戶寬表中標(biāo)記出來這個用戶是不是新會員、是否是孕婦等。
另外還有一些交易回溯分?jǐn)偟膯栴}，例如一個用戶購買了一個A 產(chǎn)品，贈了一個B產(chǎn)品，那么這個時候，品類間的毛利就有了一些損失。例如買一件衣服送一罐奶粉，那么這個時候就有了問題，不同品類的負(fù)責(zé)人不干了，因為贈品的KPI少了。衣服的總監(jiān)愿意啊，買的人多了，但是奶粉的總監(jiān)不干了，我毛利沒了啊。所以就有了回溯分?jǐn)傔@一個事情。人生太艱難了，解決技術(shù)問題，還得解決業(yè)務(wù)問題
。
我就寫了個flink程序，自定義了一個source實時的去庫里面拉取數(shù)據(jù)，因為沒有binlog。但是不能實時的去啊，對庫的影響太大了。那么這個時候就想到了我每次間隔一分鐘去拉取一次放到redis當(dāng)中，然后flink join 的時候就寫入到clickhouse中。
對于沒有join上的，就放到kafka的另一個topic中例如 dws_sold_detail_retry 然后再開一個flink 專門消費(fèi)這個。假如還沒有join上 就繼續(xù)放到這個topic中，在日志中追加一個重試次數(shù)，假如這個消息重試了超過5次，則認(rèn)為消費(fèi)失敗，不再消費(fèi)。為了避免此類情況影響統(tǒng)計結(jié)果，我增加了一個實時數(shù)據(jù)監(jiān)控，每天的銷售額差異不能超過百分之3，超過就報警，進(jìn)行人工干預(yù)。
就這樣，慢慢的加入了其他的一些寬表，例如庫存、優(yōu)惠券、會員寬表、促銷寬表等。但是慢慢的問題也有了，那就是flink寫入clickhouse的時候假如表特別寬的話，代碼量是很大的。后來我就引入了waterdrop。
也就是以上的架構(gòu)圖。
在以上的架構(gòu)中，我的核心思想就是，用flink拉寬、計算之后，交給olap引擎做多維分析，對數(shù)據(jù)和業(yè)務(wù)進(jìn)行解耦。
這個架構(gòu)是靈活可擴(kuò)展的，部分組件是可以完美的可插拔的，例如flink可以改成spark streaming、storm。clickhouse可以根據(jù)不同的業(yè)務(wù)場景更改為tidb、drois、greenplum、kudu等。
那么上面的架構(gòu)也有一些問題，例如維度表太大了怎么辦，后面我又引入了二級緩存。也就是引入的hbase，并且支持對外提供查詢?nèi)齻€月內(nèi)的數(shù)據(jù)實時查詢。
最終架構(gòu)圖：
以上就是中國好胖子吳慶志的分享，有任何問題，歡迎添加好胖子微信wuqingzhi128私聊，代價：一頓燒烤。
擴(kuò)展閱讀：Flink+ClickHouse+各廠實戰(zhàn)分享案例，后臺回復(fù)“實時數(shù)倉”即可下載。
配合以下文章享受更佳
【附下載】實時數(shù)倉架構(gòu)設(shè)計與選型
【詳解】SparkStreaming實時任務(wù)處理的三種語義
本文為作者獨(dú)立觀點(diǎn)，不代表鳥哥筆記立場，未經(jīng)允許不得轉(zhuǎn)載。
《鳥哥筆記版權(quán)及免責(zé)申明》 如對文章、圖片、字體等版權(quán)有疑問，請點(diǎn)擊 反饋舉報
我們致力于提供一個高質(zhì)量內(nèi)容的交流平臺。為落實國家互聯(lián)網(wǎng)信息辦公室“依法管網(wǎng)、依法辦網(wǎng)、依法上網(wǎng)”的要求，為完善跟帖評論自律管理，為了保護(hù)用戶創(chuàng)造的內(nèi)容、維護(hù)開放、真實、專業(yè)的平臺氛圍，我們團(tuán)隊將依據(jù)本公約中的條款對注冊用戶和發(fā)布在本平臺的內(nèi)容進(jìn)行管理。平臺鼓勵用戶創(chuàng)作、發(fā)布優(yōu)質(zhì)內(nèi)容，同時也將采取必要措施管理違法、侵權(quán)或有其他不良影響的網(wǎng)絡(luò)信息。
一、根據(jù)《網(wǎng)絡(luò)信息內(nèi)容生態(tài)治理規(guī)定》《中華人民共和國未成年人保護(hù)法》等法律法規(guī)，對以下違法、不良信息或存在危害的行為進(jìn)行處理。
1. 違反法律法規(guī)的信息，主要表現(xiàn)為：
1)反對憲法所確定的基本原則；
2)危害國家安全，泄露國家秘密，顛覆國家政權(quán)，破壞國家統(tǒng)一，損害國家榮譽(yù)和利益；
3)侮辱、濫用英烈形象，歪曲、丑化、褻瀆、否定英雄烈士事跡和精神，以侮辱、誹謗或者其他方式侵害英雄烈士的姓名、肖像、名譽(yù)、榮譽(yù)；
4)宣揚(yáng)恐怖主義、極端主義或者煽動實施恐怖活動、極端主義活動；
5)煽動民族仇恨、民族歧視，破壞民族團(tuán)結(jié)；
6)破壞國家宗教政策，宣揚(yáng)邪教和封建迷信；
7)散布謠言，擾亂社會秩序，破壞社會穩(wěn)定；
8)宣揚(yáng)淫穢、色情、賭博、暴力、兇殺、恐怖或者教唆犯罪；
9)煽動非法集會、結(jié)社、游行、示威、聚眾擾亂社會秩序；
10)侮辱或者誹謗他人，侵害他人名譽(yù)、隱私和其他合法權(quán)益；
11)通過網(wǎng)絡(luò)以文字、圖片、音視頻等形式，對未成年人實施侮辱、誹謗、威脅或者惡意損害未成年人形象進(jìn)行網(wǎng)絡(luò)欺凌的；
12)危害未成年人身心健康的；
13)含有法律、行政法規(guī)禁止的其他內(nèi)容；
2. 不友善：不尊重用戶及其所貢獻(xiàn)內(nèi)容的信息或行為。主要表現(xiàn)為：
1)輕蔑：貶低、輕視他人及其勞動成果；
2)誹謗：捏造、散布虛假事實，損害他人名譽(yù)；
3)嘲諷：以比喻、夸張、侮辱性的手法對他人或其行為進(jìn)行揭露或描述，以此來激怒他人；
4)挑釁：以不友好的方式激怒他人，意圖使對方對自己的言論作出回應(yīng)，蓄意制造事端；
5)羞辱：貶低他人的能力、行為、生理或身份特征，讓對方難堪；
6)謾罵：以不文明的語言對他人進(jìn)行負(fù)面評價；
7)歧視：煽動人群歧視、地域歧視等，針對他人的民族、種族、宗教、性取向、性別、年齡、地域、生理特征等身份或者歸類的攻擊；
8)威脅：許諾以不良的后果來迫使他人服從自己的意志；
3. 發(fā)布垃圾廣告信息：以推廣曝光為目的，發(fā)布影響用戶體驗、擾亂本網(wǎng)站秩序的內(nèi)容，或進(jìn)行相關(guān)行為。主要表現(xiàn)為：
1)多次發(fā)布包含售賣產(chǎn)品、提供服務(wù)、宣傳推廣內(nèi)容的垃圾廣告。包括但不限于以下幾種形式：
2)單個帳號多次發(fā)布包含垃圾廣告的內(nèi)容；
3)多個廣告帳號互相配合發(fā)布、傳播包含垃圾廣告的內(nèi)容；
4)多次發(fā)布包含欺騙性外鏈的內(nèi)容，如未注明的淘寶客鏈接、跳轉(zhuǎn)網(wǎng)站等，誘騙用戶點(diǎn)擊鏈接
5)發(fā)布大量包含推廣鏈接、產(chǎn)品、品牌等內(nèi)容獲取搜索引擎中的不正當(dāng)曝光；
6)購買或出售帳號之間虛假地互動，發(fā)布干擾網(wǎng)站秩序的推廣內(nèi)容及相關(guān)交易。
7)發(fā)布包含欺騙性的惡意營銷內(nèi)容，如通過偽造經(jīng)歷、冒充他人等方式進(jìn)行惡意營銷；
8)使用特殊符號、圖片等方式規(guī)避垃圾廣告內(nèi)容審核的廣告內(nèi)容。
4. 色情低俗信息，主要表現(xiàn)為：
1)包含自己或他人性經(jīng)驗的細(xì)節(jié)描述或露骨的感受描述；
2)涉及色情段子、兩性笑話的低俗內(nèi)容；
3)配圖、頭圖中包含庸俗或挑逗性圖片的內(nèi)容；
4)帶有性暗示、性挑逗等易使人產(chǎn)生性聯(lián)想；
5)展現(xiàn)血腥、驚悚、殘忍等致人身心不適；
6)炒作緋聞、丑聞、劣跡等；
7)宣揚(yáng)低俗、庸俗、媚俗內(nèi)容。
5. 不實信息，主要表現(xiàn)為：
1)可能存在事實性錯誤或者造謠等內(nèi)容；
2)存在事實夸大、偽造虛假經(jīng)歷等誤導(dǎo)他人的內(nèi)容；
3)偽造身份、冒充他人，通過頭像、用戶名等個人信息暗示自己具有特定身份，或與特定機(jī)構(gòu)或個人存在關(guān)聯(lián)。
6. 傳播封建迷信，主要表現(xiàn)為：
1)找人算命、測字、占卜、解夢、化解厄運(yùn)、使用迷信方式治??；
2)求推薦算命看相大師；
3)針對具體風(fēng)水等問題進(jìn)行求助或咨詢；
4)問自己或他人的八字、六爻、星盤、手相、面相、五行缺失，包括通過占卜方法問婚姻、前程、運(yùn)勢，東西寵物丟了能不能找回、取名改名等；
7. 文章標(biāo)題黨，主要表現(xiàn)為：
1)以各種夸張、獵奇、不合常理的表現(xiàn)手法等行為來誘導(dǎo)用戶；
2)內(nèi)容與標(biāo)題之間存在嚴(yán)重不實或者原意扭曲；
3)使用夸張標(biāo)題，內(nèi)容與標(biāo)題嚴(yán)重不符的。
8.「飯圈」亂象行為，主要表現(xiàn)為：
1)誘導(dǎo)未成年人應(yīng)援集資、高額消費(fèi)、投票打榜
2)粉絲互撕謾罵、拉踩引戰(zhàn)、造謠攻擊、人肉搜索、侵犯隱私
3)鼓動「飯圈」粉絲攀比炫富、奢靡享樂等行為
4)以號召粉絲、雇用網(wǎng)絡(luò)水軍、「養(yǎng)號」形式刷量控評等行為
5)通過「蹭熱點(diǎn)」、制造話題等形式干擾輿論，影響傳播秩序
9. 其他危害行為或內(nèi)容，主要表現(xiàn)為：
1)可能引發(fā)未成年人模仿不安全行為和違反社會公德行為、誘導(dǎo)未成年人不良嗜好影響未成年人身心健康的；
2)不當(dāng)評述自然災(zāi)害、重大事故等災(zāi)難的；
3)美化、粉飾侵略戰(zhàn)爭行為的；
4)法律、行政法規(guī)禁止，或可能對網(wǎng)絡(luò)生態(tài)造成不良影響的其他內(nèi)容。
二、違規(guī)處罰
本網(wǎng)站通過主動發(fā)現(xiàn)和接受用戶舉報兩種方式收集違規(guī)行為信息。所有有意的降低內(nèi)容質(zhì)量、傷害平臺氛圍及欺凌未成年人或危害未成年人身心健康的行為都是不能容忍的。
當(dāng)一個用戶發(fā)布違規(guī)內(nèi)容時，本網(wǎng)站將依據(jù)相關(guān)用戶違規(guī)情節(jié)嚴(yán)重程度，對帳號進(jìn)行禁言 1 天、7 天、15 天直至永久禁言或封停賬號的處罰。當(dāng)涉及欺凌未成年人、危害未成年人身心健康、通過作弊手段注冊、使用帳號，或者濫用多個帳號發(fā)布違規(guī)內(nèi)容時，本網(wǎng)站將加重處罰。
三、申訴
隨著平臺管理經(jīng)驗的不斷豐富，本網(wǎng)站出于維護(hù)本網(wǎng)站氛圍和秩序的目的，將不斷完善本公約。
如果本網(wǎng)站用戶對本網(wǎng)站基于本公約規(guī)定做出的處理有異議，可以通過「建議反饋」功能向本網(wǎng)站進(jìn)行反饋。
(規(guī)則的最終解釋權(quán)歸屬本網(wǎng)站所有)