黄色视频在线观,豆花AV在线免费观看,亚洲黄色视频网址,免费性爱视频网站,精品性爱一区二区三区,思思热视频,色偷偷av,一级操逼毛片

作者介紹

王天宜，TiDB 社區(qū)部門架構師。曾就職于 Fidelity Investment，Softbank Investment，擁有豐富的數(shù)據(jù)庫高可用方案設計經(jīng)驗，對 TiDB、Oracle、PostgreSQL、MySQL 等數(shù)據(jù)庫的高可用架構與數(shù)據(jù)庫生態(tài)有深入研究。

本文來自于 TiDB 社區(qū)部門架構師王天宜在 Apache Flink x TiDB Meetup · 北京站的分享，王天宜為大家分享了使用 TiDB + Flink 構建實時數(shù)倉的話題，本文將從以下三個方面展開：

實時數(shù)倉的經(jīng)典架構
Flink 在 TiDB 上的實時讀寫場景
Flink + TiDB 的典型用戶案例

實時數(shù)倉經(jīng)典架構

實時數(shù)倉有三個著名的分水嶺：

第一個分水嶺是從無到有，Storm 的出現(xiàn)打破了 MapReduce 的單一計算方式，讓業(yè)務能夠處理 T+0 的數(shù)據(jù)。

第二個分水嶺是從有到全，Lambda 與 Kappa 架構的出現(xiàn)，使離線數(shù)倉向實時數(shù)倉邁進了一步，而 Lambda 架構到 Kappa 架構的演進，實現(xiàn)了離線數(shù)倉模型和實時數(shù)倉模型的緊密結合。

第三個分水嶺是從繁到簡，Flink 技術棧的落地使實時數(shù)倉架構變得精簡，并且是現(xiàn)在公認的流批一體最佳解決方案。

未來是否會有其他的架構呢？我覺得一定會有，可以大膽猜測一下，可能是 OLTP 和 OLAP 相結合的 HTAP 場景，也有可能是分析與服務一體化的 HTAP 的場景。

1.1 Storm 架構

首先來看一下第一個分水嶺，Storm 架構。Storm 是 Twitter 開源的分布式實時大數(shù)據(jù)處理框架，后來捐贈給了 Apache 社區(qū)，被業(yè)界稱為實時版的 Hadoop。之前通用的 Hadoop 的 MapReduce 存在兩大問題，一是運維成本高，二是高延遲影響業(yè)務處理速度。在此背景下，Storm 開始逐漸取代 MapReduce，成為了流式計算中的佼佼者。2017 年，Storm 成為了天貓雙十一的流計算主流技術棧。

在這樣一個拓撲中，包含了 spout 和 bolt 兩種角色。數(shù)據(jù)在 spout 中傳遞，這些 spout 將數(shù)據(jù)以 tuples 的形式發(fā)送。Bolt 負責轉換數(shù)據(jù)流，一般來說，簡單的數(shù)據(jù)轉換一個 bolt 就可以完成，而復雜的數(shù)據(jù)轉換需要多個 bolt 串行完成。

Storm 架構，能夠解決低延遲的問題，但是這個框架并不完美，他有一個很大的痛點，Storm 無法支持基于時間窗口的邏輯處理。這個問題導致了 Storm 無法跨周期計算。為了解決這個問題，Storm 的爸爸 Nathan Marz 提出來 Lambda 架構。

1.2 Lambda & Kappa 架構

Lambda 架構可以分解為三層：

Batch layer：全體的數(shù)據(jù)，離線數(shù)據(jù)，更新 batch view。

Real time layer (speed layer)：實時數(shù)據(jù)，增量流數(shù)據(jù)，更新 real time view。

Serving layer：用于合并 batch view 與 real time view，得到最終的數(shù)據(jù)集。

Lambda 相對來說需要維護兩套架構，使用成本較高：

Batch enging & Real-time enging 兩路架構，相互獨立。
邏輯完全不同，對齊困難。
技術棧與模塊多，結構復雜。

LinkedIn 的 Jay 為了簡化這個邏輯，提出了 Kappa 架構，刪除了批處理的邏輯，認為只需要流處理就可以了。從設計上講，我們可以思考幾個問題：

為什么不能改進流計算讓他處理所有全量數(shù)據(jù)？
流計算天然的分布式性注定其擴展性一定是很好的，能夠通過添加并發(fā)來處理海量數(shù)據(jù)？
那么如何使用流計算對全量數(shù)據(jù)進行重新計算呢：

使用 kafka 等 MQ 保存數(shù)據(jù)，需要幾天就保存幾天；當需要全量數(shù)據(jù)時，重新起一個流計算實例，從頭開始讀取數(shù)據(jù)進行處理，輸出到結果集中存儲；當新的實例完成后，停止老的流式計算實例，并且刪除舊的結果。

1.3 Flink 架構

我們常說，天下武功，唯快不破。Flink 是一款 native streaming 的計算引擎，在實時計算場景最關心的就是速度快，延遲低。以 Flink 為計算引擎的實時數(shù)倉架構，重度依賴 OLAP 引擎。簡單來說，就是將計算的壓力從實時計算引擎轉嫁到了 OLAP 分析引擎上，在應用層的分析能夠更靈活。

一般來說，前端不同的數(shù)據(jù)源將數(shù)據(jù)寫入 MQ 中，由 Flink 消費 MQ 中的數(shù)據(jù)，做一些簡單的聚合操作，最后將結果寫入 OLAP 數(shù)據(jù)庫中。

我們會遇到一些問題：

隨著業(yè)務的變化，會引入越來越多的實時計算的需求，會有越來越多的實時分析，實時風控，實時推薦，實時查詢場景。數(shù)據(jù)存儲層沒有統(tǒng)一的管理，使得單一的數(shù)據(jù)存儲架構無法應對多變的需求。

此時我們需要思考兩個問題：

怎樣才能統(tǒng)一規(guī)劃管理數(shù)據(jù)？使用數(shù)據(jù)倉庫。
如何才能實現(xiàn)實時處理？使用實時計算引擎。

我們將離線數(shù)倉的一些設計架構結合實時計算引擎，就形成了標準的以 Flink + OLAP 為核心的實時數(shù)倉架構。這種架構我們稱之為煙囪式的實時數(shù)倉。煙囪式的實時數(shù)倉會產(chǎn)生數(shù)據(jù)孤島，導致嚴重的代碼耦合，每次遇到新的需求，都要從原始數(shù)據(jù)重新計算。

那么什么才是一個好的數(shù)據(jù)模型呢？這里我們可以借鑒一下傳統(tǒng)的離線數(shù)倉的架構，將數(shù)據(jù)存儲層細分成 ODS，DWS 和 DWS。基于這樣的結構，可以統(tǒng)一規(guī)范，更穩(wěn)定，業(yè)務適配性也更強。

總結一下幾種不同形態(tài)的實時數(shù)倉架構：從計算引擎上來看，Lambda 架構需要維護流批兩套計算引擎，相對較為麻煩。同時維護兩套引擎對于開發(fā)者的成本也是較高的。相比于 Lambda 和 Kappa 架構，F(xiàn)link 把一部分的關聯(lián)和預聚合操作從前面移到了后面，高度依賴于 OLAP 引擎。

應對邏輯變更的重算需求，Lambda 靠著獨立的批處理引擎進行重算，Kappa 架構通過重新統(tǒng)計消息隊列里面的數(shù)據(jù)進行重算，而 Flink 也需要將消息隊列中的數(shù)據(jù)重新導入到 OLAP 引擎中重算。

在過去，我們面對實時，數(shù)倉的邏輯是：性能不夠，架構來補。

在現(xiàn)在，我們面對實時，數(shù)倉的邏輯是：既要、還要，全都要。

1.4 實時數(shù)倉架構未來展望

未來是一定會有第四個分水嶺的。我們可以隨意的暢想一下。

對于分布式 OLTP 數(shù)據(jù)庫，我們通過添加分析類的引擎，最終實現(xiàn)將 OLTP 與 OLAP 合二為一，在使用上作為一個統(tǒng)一，在存儲上分離，而做到 OLAP 與 OLAP 互不干擾。這種 HTAP 的架構允許我們在 OLTP 的庫里面直接分析，而又不影響在線的業(yè)務，那么他會不會取代大數(shù)據(jù)系統(tǒng)呢？

在我看來，用戶的業(yè)務數(shù)據(jù)只是交易系統(tǒng)的一部分。還有大量的用戶行為事件，日志、爬蟲數(shù)據(jù)等信息需要匯總到數(shù)倉中進行分析。如何做到技術棧的統(tǒng)一也是未來大數(shù)據(jù)行業(yè)需要面臨的巨大的挑戰(zhàn)。友商 hologress 已經(jīng)為我們做出了一個典范。把 Flink + Holo 這一套系統(tǒng)服務化，用戶不需要去學習和接受每個產(chǎn)品的問題和局限性，這樣能夠大大簡化業(yè)務的架構，提升開發(fā)效率。當然，我也看到的是越來越多的 HTAP 產(chǎn)品 HSAP 化，越來越多的 HSAP 產(chǎn)品 HTAP 化。邊界與定義越來越模糊，就好比說 TiDB 有了自己的 DBasS 服務 TiDB Cloud，Holo 也有行存和列存兩種引擎。在我看到的是，越來越多的用戶，將爬蟲業(yè)務，日志系統(tǒng)接入 TiDB 中，HTAP 和 HSAP 都將成為數(shù)據(jù)庫生態(tài)中不可或缺的重要組成部分。

Flink 在 TiDB 上的實時讀寫場景

接下來我會從實時寫入場景，實時維表場景，CDC 場景和混合場景四個方面介紹一下 Flink 與 TiDB 適配方案。在此之前，我們可以看一下 Flink + TiDB 的生態(tài)架構全貌。

2.1 Flink + TiDB 的生態(tài)架構全貌

一般來說，我們將 Flink + TiDB 的生態(tài)架構分成四層：

第一層是數(shù)據(jù)源。數(shù)據(jù)源可以是多種多樣的，比如說 MySQL Binlog，比如說爬蟲的數(shù)據(jù)，比如說平面的 log 文件。

第二層是實時計算層，也就是我們說的 Flink。不過在實時計算層之前，數(shù)據(jù)源的數(shù)據(jù)會通過采集工具寫入 MQ 中，由 Flink 來消費 MQ 中的增量數(shù)據(jù)。

第三層是數(shù)據(jù)存儲。由于 Flink 相比于其他技術棧來說更依賴于 OLAP 引擎，需要一款強大的數(shù)據(jù)庫作為支撐。比如說 TiDB，我們既有適用于在線系統(tǒng)的行存 TiKV 引擎，也有適用于分析計算的列存 TiFlash 引擎。我覺得作為數(shù)據(jù)倉庫，數(shù)據(jù)的流動性是最重要的。所以我們不僅有數(shù)據(jù)流入的方案，也可以通過 TiCDC 將數(shù)據(jù)流出到其他的外部應用中。

最后一層是后端應用。可能是直接連接實時監(jiān)控系統(tǒng)，實時報表系統(tǒng)，也可能是將數(shù)據(jù)流入到 ES 這樣的搜索引擎中，進行下一步操作。

我們可以簡單的看一下 TiDB 的體系架構，TiDB 主要分為三個部分：

最前面的計算層 TiDB 負責接受客戶端的消息請求，將請求轉化為分布式的執(zhí)行計劃，并且下推到存儲層。TiDB 的存儲層分為兩種個引擎，一種是行存的 TiKV 引擎，對于 OLTP 的查詢更加友好。一種是列存的 TiFlash 引擎，對于 OLAP 的查詢更加友好。

TiDB 兼容 MySQL 5.7 協(xié)議，我們常說，TiDB 是一個大號的 MySQL，其實我們希望用戶能夠像使用單節(jié)點的 MySQL 那樣使用 TiDB。不用考慮什么分布式，不用考慮分庫分表。這一切操作由 TiDB 來完成。那么 TiDB 是如何將執(zhí)行計劃下推的呢？這中間必然涉及到 metadata。我們的元數(shù)據(jù)存儲在 PD server 中。TiDB 到 PD 中獲取到數(shù)據(jù)分布的信息后再下推執(zhí)行計劃。所以我們也稱 PD 是 TiDB 集群的大腦。

剛才提到過 Flink 重度依賴于 OLAP 引擎，我們也可以考量一下 TiDB 的 OLAP 能力。我們一直在提 HTAP，在同一套庫中，既處理 OLTP 的業(yè)務，也處理 OLAP 的業(yè)務。

那么 HTAP 最重要的是什么，在我看來無非是資源隔離。如何做到 AP 的重量級查詢不影響在線業(yè)務，是 HTAP 的基石。在這里，我們使用兩套存儲引擎，就如剛才所說，行存的 TiKV 天然的對點查比較友好，列存的 TiFlash 天然對重分析類查詢比較友好。談不上隔離，自始至終就不在一起。

2.2 實時寫入場景

其實我們一直在討論 Flink + TiDB 的鏈路解決方案。消息隊列這個詞反復地出現(xiàn)。Kafka，RabbitMQ，RocketMQ 這一類 MQ 工具，主要做的就是一發(fā)，一存，一消費這三件事情。我們可以看到使用 flink-sql-connector-kafka 這個 jar 包，可以輕松地通過 Flink 消費 Kafka 的數(shù)據(jù)。

與 MySQL 相似，我們可以使用 Flink 的 jdbc connector 將數(shù)據(jù)從 Flink 寫入到 TiDB 中。

那么這里需要注意的是，如果 TiDB 的表沒有設置主鍵，F(xiàn)link 使用的是 Append Only 模式。如果 TiDB 中的表設置了主鍵，后面的數(shù)據(jù)會根據(jù)主鍵覆蓋前面沖突的數(shù)據(jù)。

此外，前端業(yè)務量的突增可能導致流量高峰。那這種情況下，為了減少對下游數(shù)據(jù)庫的壓力，我們可以考慮在 Flink 與 TiDB 中間，接一個 Kafka 做削峰。

2.3 實時維表場景

還有一種非常重要的場景是實時維表場景。大家都知道，為了控制事實表的大小，我們盡可能地將事實表中的信息抽象成 ID。

在傳統(tǒng)的數(shù)倉中，DW 層可能會做一些聚合操作。在現(xiàn)有的數(shù)倉體系結構中，單節(jié)點的 MySQL 可能無法承載龐大的事實表體量，于是我們把他放在 TiDB 中，而維度信息，可能存儲在 TiDB 中，也可能存放在外部設備中，如 MySQL 等其他的數(shù)據(jù)庫。通過 Flink，我們可以讀取不同數(shù)據(jù)源的信息，在 Flink 中做預聚合。完成事實表與維表拼接的操作。

來看這個案例，實時表中存儲了身份證編號等信息，維度表在外部設備中，存儲了身份證相關的詳細信息，比如說地址，發(fā)證時間等等。事實表增量的數(shù)據(jù)同步到 Flink 中，在 Flink 中做了預聚合，拼成寬表最終寫入 TiDB 中。

2.4 CDC場景

接下來看一下 CDC 的場景。什么是 CDC 呢？CDC 就是 change data capture。增量數(shù)據(jù)捕獲。通過簡單的配置，我們可以在 cdc 中捕獲 TiKV 的數(shù)據(jù)變化，從而同步到消息隊列中。

2.5 混合場景

除了以上的單一場景，還有很多時候是多種場景融合在一起的復雜場景。比如說增量數(shù)據(jù)從 TiDB 中通過 CDC 同步到消息隊列中。

Flink 消費 Kafka 的增量數(shù)據(jù)的同時，也進行了維表關聯(lián)的操作，最后寫入到 TiDB 中。在這種情況下，我們可以考慮添加 TiFlash 結點，從而擴展 TiDB 的 OLAP 查詢能力。

我們常說，功能不夠，架構來湊。我個人有一種觀點，做開源產(chǎn)品，功能不夠的時候，無非是兩條路來解決：

精力多的可以考慮自己手動修改源碼。
精力少的可以考慮通過不同組件的拼接以搭積木的方式完善功能。

當然，TiDB 是一個以開源為初衷的產(chǎn)品，用戶有什么想法可以直接到 github 上提 PR 或者到我們的開源社區(qū)，提一些建議。

我們來看這種情況，目前來看 TiDB 是沒有提供物化視圖的功能的。那么我們是不是可以通過 Flink 處理流數(shù)據(jù)的方式將數(shù)據(jù)寫到 TiDB 中，生成一張動態(tài)表，模擬物化視圖的場景呢？

再比如說，TiDB 暫時也不提供觸發(fā)器的功能，但是 Flink 提供了比較豐富的窗口操作。Flink 的窗口觸發(fā)器不僅定義了窗口何時被觸發(fā)，也定義了觸發(fā)的行為。那此時，將數(shù)據(jù)回寫到 TiDB 中，是不是可以模擬一些觸發(fā)器的操作呢？

Flink + TiDB 的典型用戶案例

最后，給大家分享幾個比較經(jīng)典的案例。

3.1 360 的實時報表案例

第一個案例是 360 基于 Flink + TiDB 構建的實時報表業(yè)務。利用 Flink 強大的流處理能力，兩小時內大概寫入 1.5 億的數(shù)據(jù)，平均下來 1s 大概是 2W 的 TPS。我們可以看一下整體的架構，上游的數(shù)據(jù)源通過同步工具將數(shù)據(jù)寫入到 Kafka 中，F(xiàn)link 消費 Kafka 中的數(shù)據(jù)，在 Flink 中完成一個輕量級的聚合操作。然后寫入到 TiDB 中。通過 TiFlash 的配置，提高了對于 OLAP 查詢的處理能力。數(shù)據(jù)最終在 TiDB 中完成各種維度的聚合操作，實現(xiàn)了離線報表的在線統(tǒng)計。

3.2 小紅書的物化視圖案例

第二個是小紅書的物化視圖案例。TiDB 的增量數(shù)據(jù)通過 TiCDC 集群寫入到 Kafka 中，再由 Flink 消費 Kafka 中的數(shù)據(jù)。在 Flink 中做了 Join 和聚合操作，最后的數(shù)據(jù)回寫到 TiDB 中。實現(xiàn)了一張通過 Flink 動態(tài)表模擬的 TiDB 物化視圖。最終業(yè)務方通過前端的應用拉去報表。這個案例中，QPS 大概是在 4w 每秒，單表 50 億的數(shù)據(jù)，所以采用分區(qū)表實現(xiàn)。

3.3 貝殼金服的實時維表案例

最后是貝殼金服的實時維表案例。貝殼金服上游的數(shù)據(jù)是存在 MySQL 中的，由 Canal 拉取 MySQL 集群的 Binlog。然后推入到 Kafka 中。Flink 消費 Kafka 中的增量數(shù)據(jù)，進行聚合操作。最后寫入到 TiDB 中，供其他業(yè)務調用。

TiDB + Flink 解決方案正面向社區(qū)招募體驗官！掃碼報名即有機會獲得 TiDB 社區(qū)精美周邊。您在探索實踐過程中遇到任何問題，社區(qū)專家提供技術支持~

?? 更多 TiDB、TiKV、TiSpark、TiFlash 技術問題或生態(tài)應用可點擊「閱讀原文」，登錄 AskTUG.com ，與更多 TiDB User 隨時隨地交流使用心得～

TiDB 數(shù)倉 | Flink + TiDB，體驗實時數(shù)倉之美