五月天丁香激情,日本三级韩国三级99久久,av下页,太子妃被强行打开双腿h,欧美乱交,裸体免费视频,成人黄色免费小说,超碰97色色

作者介紹

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

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

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

實(shí)時(shí)數(shù)倉經(jīng)典架構(gòu)

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

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

第二個(gè)分水嶺是從有到全，Lambda 與 Kappa 架構(gòu)的出現(xiàn)，使離線數(shù)倉向?qū)崟r(shí)數(shù)倉邁進(jìn)了一步，而 Lambda 架構(gòu)到 Kappa 架構(gòu)的演進(jìn)，實(shí)現(xiàn)了離線數(shù)倉模型和實(shí)時(shí)數(shù)倉模型的緊密結(jié)合。

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

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

1.1 Storm 架構(gòu)

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

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

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

1.2 Lambda & Kappa 架構(gòu)

Lambda 架構(gòu)可以分解為三層：

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

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

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

Lambda 相對來說需要維護(hù)兩套架構(gòu)，使用成本較高：

Batch enging & Real-time enging 兩路架構(gòu)，相互獨(dú)立。
邏輯完全不同，對齊困難。
技術(shù)棧與模塊多，結(jié)構(gòu)復(fù)雜。

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

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

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

1.3 Flink 架構(gòu)

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

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

我們會(huì)遇到一些問題：

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

此時(shí)我們需要思考兩個(gè)問題：

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

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

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

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

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

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

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

1.4 實(shí)時(shí)數(shù)倉架構(gòu)未來展望

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

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

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

Flink 在 TiDB 上的實(shí)時(shí)讀寫場景

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

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

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

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

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

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

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

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

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

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

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

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

2.2 實(shí)時(shí)寫入場景

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

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

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

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

2.3 實(shí)時(shí)維表場景

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

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

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

2.4 CDC場景

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

2.5 混合場景

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

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

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

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

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

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

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

Flink + TiDB 的典型用戶案例

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

3.1 360 的實(shí)時(shí)報(bào)表案例

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

3.2 小紅書的物化視圖案例

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

3.3 貝殼金服的實(shí)時(shí)維表案例

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

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

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

TiDB 數(shù)倉 | Flink + TiDB，體驗(yàn)實(shí)時(shí)數(shù)倉之美

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