1、發展歷史
從業務團隊和大數據團隊煙囪式的開發，到構建大數據平臺，18年開始行動，速度還是可以的。18年Flink不太成熟，使用Sparkstreaming屬于正常的選擇范疇，同時，構建了任務調度平臺+SQL開發平臺，降低開發難度，提升開發效率，是一個不錯的選擇。
隨著任務增大，對于延遲、狀態的管理、多任務的穩定性都有非常大的挑戰，19年轉向Flink，社區非?；钴S，成果也非常多。
在FLink的基礎上，基于之前的SQL平臺功能，基于Flink1.8 快速構建了SQL2.0的功能，從此開啟了實時數倉的建設。
隨著公司的事件越來越多，為了滿足公司事件流處理場景，20年底基于Flink1.11構建了SQL3.0的事件處理平臺。
目前支持了30+個產品，1000+個任務（2019.5~2020.12），數據量達2500億/日（所有流量、行業日志、數倉建設的數據），峰值達300萬/秒，數據的支撐度還是蠻可觀的。
2、平臺架構
從功能特征層面，分4個維度
1）任務托管：支持任務托管的能力，包括任務的編輯發布、任務啟停、版本管理、監控報警等；
2）多語言開發：支持Java、Scala、Python各類實時任務的開發，方便各種實時任務的接入；
3）多種任務類型：自定義任務、模板任務、場景任務（SQL），SQL任務占比比較高達到80%左右；
4）資源隔離：對于數據量大且穩定的任務，提供專有隊列，確保穩定可靠；對于數據量小，可以使用公共隊列；
從分層架構來看，整個平臺架構分為四層：
1）計算&存儲層：消息隊列、Flink/SparkStreaming、Hive、Redis、RMDB、Hbase、ClickHouse、Doris、HDFS、YARN；
2）引擎層：StreamSQL、DataStream、StreamCEP；
3）開發管理層：分場景、自定義、模板3類任務處理。包括模板管理、任務管理、實例管理、數據源管理、連接管理、項目管理、資源管理、監控報警；
4）應用場景：ETL、監控、BI、推薦、風控、運營等；
從整體架構來看，底層是計算和存儲，計算支持FLink和Spark，存儲支持消息隊列、各種OLAP、同時支持Mysql、Hive實時落盤，維表支持Redis、Hbase存儲。ClickHouse主要是實時OLAP的存儲，由于Doris支持update且關聯查詢支持的比較好，也引入了Doris做為實時的OLAP的存儲。
引擎層主要是封裝SQL引擎、DataStream的通用性操作，事件處理方面，Flink的CEP做了普通規則的封裝。
開發管理層提供了3種場景的任務開發、監控、資源管理。
對于大數據平臺來說，可用性方面，一個是計算的可持續，一個是任務調度運行的穩定性，一個是預警監控，3者為平臺成功的核心要素，支撐整個業務的穩定運行；
任務調度是一個比較關鍵的內容，從任務的狀態來看，主要是啟動任務，創建實例，實例創建后，則有啟動狀態（成功、失?。?、運行狀態（成功、失?。还苁菃舆€是運行，都可以手動開啟和手動停止，也可以通過定時任務啟動或重試。在整個的運行過程中，需要設置延遲、心跳的閾值、重試的次數，如果不能在重試次數內完成，則要通知任務負責人介入處理。
再說一下預警監控。所有的監控日志都存入influxDB，進行可視化的處理，可以通過大屏或圖表，展示系統運行的實際情況。同時通過依賴注入和Flink 任務支持自定義 Reporter 的 metrics 獲取日志信息，在拿到監控信息后，可以實時的進行延遲報警、心跳報警，同時也可以基于血緣關系進行流量分析，還可以支撐起狀態及任務的恢復。
監控整體的技術處理流程為，基于Spark的SDK、Flink的自定義 Reporter 的 metrics 、Java agent的依賴注入3種方式完成日志的采集，將所有日志推入Kafka，然后基于預警監控平臺，實時計算進行監控預警，并將結果存入influxDB進行可視化展示和報告的呈現，為研發人員提供強有力的技術監控信息，為架構的優化、系統的穩定運行提供強有力的技術支撐。
3、實時數倉
從功能特征包括了元數據管理，數據分層架構，其中數據分層架構有以下幾個原則：
1）實時，分層越少越好，中間環節太多，出問題的概率越大；
2）SQL層面，支持標準語法，維表關聯，提供圖形化的SQL開發環境，支持豐富的內置函數和UDF；
3）血緣，平臺支持圖形化和完善的鏈路分析，實時標準數據流的變化和異常；
4）多源支持，不管是前端日志，還是后端日志，還是各種DB都做到了很好的支撐；
架構層面，整體來看依然是Lambda架構，實時與離線分離，離線對實時進行覆蓋修復。
整體來說，行業日志，后端日志、DB數據采集統一到Kafka，再送入到ODS層，同時維度數據會存儲到Redis或Hbase中，在計算過程中做維度關聯使用；DWD層會進行維度關聯的處理，然后將結果存入ClickHouse中，以滿足部分業務查詢場景訴求；DWS也會做一些匯總聚合，結果也會存入ClickHouse中，以滿足部分業務的查詢場景訴求；但不管是基于DWD還是DWS的查詢，ClickHouse支持關系查詢時都力不從心，引入Doris，支持Update和關聯查詢，更好的提供查詢服務。
4、實時開發平臺
實時開發平臺主要是SQL的編輯器、調試器、SQL引擎、血緣管理等。
編輯器的整體界面，包括編輯器、執行計劃查看器、任務調試，同時也可以定義源表、維表、輸出表，也可以定義流表并自動生成DDL（DDL也支持SQL編輯）。
對于開發來說，調試是非常核心的一個功能。一般調試分析自動和手動2種方式。手動需要準備樣例數據，復制到開發界面；自動方式則會從上游的SQL任務獲取校例數據。元數據信息（Kafka、Hbase、Clickhouse等）是動態獲得的，元信息與樣例共同生成DebugSQL去調用 SQL引擎的公共服務。SQL引擎得到樣例數據后，如果有關聯維表的操作，則會關聯線上維表，在SQL引擎中執行調試，將結果送給UI端展示，展示時分為樣例數據和下游結果數據。
血緣關系，是非常有價值的，從溯源分析、問題排查、差異分析、提升用戶體驗、變動/異常預警方面都大有可為。建立在元數據定義的基礎上，在元數據管理方面需要有很好的設計，支撐起相關的分析，確保上述能力的高效兌現。
SQL引擎是抹平開發人員與大數據各種數據源的鴻溝的利器，能夠大大提升開發及運維效率，要確定SQL的標準語法，然后通過解釋轉換器轉換為標準語法，基于標準語法進行執行計劃的分析生成，最終對接Flink引擎進行實際計算，完成數據處理的過程。比如源上面，支持多種源比如Kafka；對于維表支持Hbase、Redis、ClickHouse多種源；對于數據存儲支持Redis、Hbase、ClickHouse、Kafka、Doris、Mysql等；
最新版本中Flink1.11 支持DDL，所以這部分我們不會再做，而是直接使用其新特性：
解析模塊（Parse Model）將用戶原始的 SQL 解析成內部的執行計劃，完全依賴于 Flink SQL。Connector Model 完成目前 Flink 尚未支持的 Connector 開發。
Format Model 實現數據源字段的序列化和反序列化。
執行模塊（Execute Model）基于 Flink1.11 SQL API 執行解析后的執行計劃。
UDF 模塊是專門處理 UDF 的解析，如參數調用的合法驗證、權限驗證、細致的數據權限限制。
SDK Model 是對外提供的標準化服務，如 SQL 文本開發的驗證，debug 功能等。
以上是關于BK的實時數倉的學習總結，整體架構緊跟潮流，并且在FlinkSQL的實踐上，有很好的經驗。特別是任務調度引擎、SQL引擎，很好的支撐起業務的運行；同時實時開發編輯器、調試器，大大降低了資產開發人員的難度和學習成本；存儲查詢引擎也引入了Mysql、Redis、Hbase、ClickHouse、Doris組件，很好的滿足了不同場景的數據查詢要求；這些維度都是可以借鑒。
