1：基於 flink 的實時資料倉儲是如何做的？
我們要從 flink 的優勢開始入手，介紹基於 flink 的實時數倉建設的關鍵技術選型和整體設計。
傳統的離線資料倉儲將業務資料集中進行儲存後，以固定的計算邏輯定時進行etl和其他建模後產出報表等應用。離線資料倉儲主要是構建 t+1 的離線資料，通過定時任務每天拉取增量資料，然後建立各個業務相關的主題維度資料，對外提供 t+1 的資料查詢介面。計算和資料的實時性均較差，業務人員無法根據自己的即時性需要獲取幾分鐘之前的實時資料。資料本身的價值隨著時間的流逝會逐步減弱，因此資料發生後必須盡快地達到使用者的手中，實時數倉的構建需求也應運而生。
總之就是一句話：時效性的要求。
flink 在實時數倉和實時 etl 中有天然的優勢：
狀態管理，實時數倉裡面會進行很多的聚合計算，這些都需要對狀態進行訪問和管理，flink 支援強大的狀態管理；
豐富的 api，flink 提供了極為豐富的多層次 api，包括 stream api、table api 及 flink sql；
生態完善，實時數倉的用途廣泛，flink 支援多種儲存（hdfs、es 等）；
批流一體，flink 已經在將流計算和批計算的 api 進行統一。
我們在進行實時數倉的設計時，一般也是分為 ods 源資料接入層、dwd 明細層、dws 彙總層、adm 應用層。
這其中比較關鍵的技術點：實時數倉的明細層的彙總一般是基於 flink 等接入 kafka 訊息進行關聯的，維度表的資料一般會放在 hdfs、hbase 中作為明細層的補充。另外，在實時資料倉儲中要選擇不同的 olap 庫來滿足即席查詢。
此外，可以將自己的實時資料的架構圖完整畫出來，這樣會給人很深刻的印象，你可以參考下面兩張架構設計圖。
網易嚴選的實時資料倉儲設計圖
美團的實時數倉分層架構模型圖
2：基於 flink 的實時計算平台是如何做的？
實時計算平台的搭建是隨著越來越多的業務場景需要實時計算而產生的。由於離線計算天然時效性不強，一般都是隔天級別的滯後，業務資料隨著實踐的推移，本身的價值就會逐漸減少。
由於 flink 在架構、容錯、反壓上表現出來的優勢和特性，使得 flink 在實時計算平台的搭建上占有一席之地。
一般的實時計算平台的構成大都是由以下幾部分構成。
在實際業務中，大量的實時計算都是基於訊息系統進行的資料收集和投遞，這都離不開強大的訊息中介軟體。目前業界使用最廣的是 kafka，另外一些重要的業務資料還會用到其他訊息系統比如 rocketmq 等。kafka 因為高吞吐、低延遲的特性，特別適合大數量量、高 qps 下的業務場景，而 rocketmq 則在事務訊息、一致性上有獨特的優勢。
flink 在計算層同時支援流式及批量分析應用，這就是我們所說的批流一體，flink 承擔了資料的實時採集、實時計算和下游傳送的角色。隨著 blink 的開源和一些其他實時產品的開源，支援視覺化、sql 化的開發模式已經越來越普及。
這裡是我們的實時資料儲存層，儲存層除了傳統 mysql 等儲存引擎以外，還會根據場景資料的不同儲存在 redis、hbase、olap 中。而這一層我個人認為最重要的技術選型則是 olap。olap 的技術選型直接制約著資料儲存層和資料服務層的能力。關於 olap 的技術選型，可以參考這裡。
資料服務層會提供統一的對外查詢、多維度的實時彙總，加上完善的租戶和許可權設計，能夠支援多部門、多業務的資料需求。另外，基於資料服務層還會有資料的展示、大屏、指標視覺化等。
我們在回答這個面試問題時，可以結合自己的實際專案回答，例如，在實時資料收集層中的技術選型是什麼、支援了多大的資料量以及取得的業務成果；並且可以把自己的架構圖完整地畫出來。你也可以參考下面的架構圖來畫出自己的整體架構圖。
美團的實時計算平台圖
微博的實時計算平台圖
3：有沒有做過基於 flink sql 的計算平台？你有什麼思路？
基於 flink sql 的實時計算平台是很多大公司提高開發效率、降低開發成本、降低維護成本作出的選擇。一般的 sql 開發平台都會有以下幾個模組：
這其中，sql 的開發和提交是核心，成熟的 sql 開發平台應該是和公司常用的元件棧打通，基於 flink 原生的 sql 模組支援更為豐富的 source 和 sink。並且支援豐富的作業配置，如作業 checkpoint、重啟策略等。
許可權管理模組中，我們的 sql 應該在作業級別進行多租戶的許可權管控，對於原表和目標表更應該精確到開發者級別。
udf 模組應該支援使用者自定義基於業務的複雜 udf，並且可以快捷方便地更新版本。
資源和排程模組可以支援運算元級別的並行度和記憶體設定，並且應該支援作業在不同集群間進行切換。
日誌和監控模組中是我們進行作業調優、異常監控非常重要的模組，我們應該有專門的服務進行日誌收集和查詢，異常監控方面可以做到指定到人且不同渠道（郵件、**、釘釘等）的報警。
技術方案設計
概要設計文件 技術方案 1.由原始需求逐步拆分，深入 後期迭代增加 2.資料流圖，整體流程 每一條資料流鏈路，便於查問題節點 3.不僅給技術開發看，面向產品和測試，對測試的輸出和產品的輸出 4.寫出支撐功能點，前端對接的資料結構 流程 需求評審 設計方案評審 資料鏈路，需求拆分 技術方案評審 實現方...
監控系統Metis方案設計
監控系統metis方案設計 一 概述 對於乙個業務系統而言，不同的角色關注的點會有一定差異。領導或負責人系統獲取系統的sla，系統間的相互作用，展示資源消耗情況 運維人員需要獲取基礎設施和服務的實時狀態資訊，各種軟硬體錯誤，效能變化及效能瓶頸 開發人員需要知道系統主要效能瓶頸，經常出現的錯誤，便於著...
優美的配色方案設計
怎麼做好 設計配色 一直是個難題 雖然 上有各種各樣的色庫，但配色仍然至關重要，不得已的話可以親自動手，況且樂趣滿滿。這個沒有一套標準 所以看自己怎麼喜歡怎麼來 你可以使用 illustrator keynot 和你想到的其他用著順手的工具。vi設計包含的遠不止選擇顏色和字型，如果要給公司尋找一套配...