怎樣解決從OLTP到OLAP實(shí)時(shí)流轉(zhuǎn)缺失問(wèn)題

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)怎樣解決從OLTP到OLAP實(shí)時(shí)流轉(zhuǎn)缺失問(wèn)題，文章內(nèi)容豐富且以專(zhuān)業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

我們首先從兩個(gè)維度介紹實(shí)時(shí)數(shù)據(jù)平臺(tái)：從現(xiàn)代數(shù)倉(cāng)架構(gòu)角度看待實(shí)時(shí)數(shù)據(jù)平臺(tái)，從典型數(shù)據(jù)處理角度看待實(shí)時(shí)數(shù)據(jù)處理;接著我們會(huì)探討實(shí)時(shí)數(shù)據(jù)平臺(tái)整體設(shè)計(jì)架構(gòu)、對(duì)具體問(wèn)題的考量以及解決思路。

一、相關(guān)概念背景

1從現(xiàn)代數(shù)倉(cāng)架構(gòu)角度看實(shí)時(shí)數(shù)據(jù)平臺(tái)

現(xiàn)代數(shù)倉(cāng)由傳統(tǒng)數(shù)倉(cāng)發(fā)展而來(lái)，對(duì)比傳統(tǒng)數(shù)倉(cāng)，現(xiàn)代數(shù)倉(cāng)既有與其相同之處，也有諸多發(fā)展點(diǎn)。首先我們看一下傳統(tǒng)數(shù)倉(cāng)(圖1)和現(xiàn)代數(shù)倉(cāng)(圖2)的模塊架構(gòu)：

傳統(tǒng)數(shù)倉(cāng)大家都很熟悉，這里不做過(guò)多介紹，一般來(lái)說(shuō)，傳統(tǒng)數(shù)倉(cāng)只能支持T+1天時(shí)效延遲的數(shù)據(jù)處理，數(shù)據(jù)處理過(guò)程以ETL為主，最終產(chǎn)出以報(bào)表為主。

現(xiàn)代數(shù)倉(cāng)建立在傳統(tǒng)數(shù)倉(cāng)之上，同時(shí)增加了更多樣化數(shù)據(jù)源的導(dǎo)入存儲(chǔ)，更多樣化數(shù)據(jù)處理方式和時(shí)效(支持T+0天時(shí)效)，更多樣化數(shù)據(jù)使用方式和更多樣化數(shù)據(jù)終端服務(wù)。

現(xiàn)代數(shù)倉(cāng)是個(gè)很大的話(huà)題，在此我們以概念模塊的方式來(lái)展現(xiàn)其新的特性能力。

首先我們先看一下圖3中Melissa Coates的整理總結(jié)：

在圖3 Melissa Coates的總結(jié)中我們可以得出，現(xiàn)代數(shù)倉(cāng)之所以“現(xiàn)代”，是因?yàn)樗卸嗥脚_(tái)架構(gòu)、數(shù)據(jù)虛擬化、數(shù)據(jù)的近實(shí)時(shí)分析、敏捷交付方式等等一系列特性。

在借鑒Melissa Coates關(guān)于現(xiàn)代數(shù)倉(cāng)總結(jié)的基礎(chǔ)上，加以自己的理解，我們也在此總結(jié)提取了現(xiàn)代數(shù)倉(cāng)的幾個(gè)重要能力，分別是：

• 數(shù)據(jù)實(shí)時(shí)化(實(shí)時(shí)同步和流式處理能力)

• 數(shù)據(jù)虛擬化(虛擬混算和統(tǒng)一服務(wù)能力)

• 數(shù)據(jù)平民化(可視化和自助配置能力)

• 數(shù)據(jù)協(xié)作化(多租戶(hù)和分工協(xié)作能力)

(1)數(shù)據(jù)實(shí)時(shí)化(實(shí)時(shí)同步和流式處理能力)

數(shù)據(jù)實(shí)時(shí)化，是指數(shù)據(jù)從產(chǎn)生(更新至業(yè)務(wù)數(shù)據(jù)庫(kù)或日志)到最終消費(fèi)(數(shù)據(jù)報(bào)表、儀表板、分析、挖掘、數(shù)據(jù)應(yīng)用等)，支持毫秒級(jí)/秒級(jí)/分鐘級(jí)延遲(嚴(yán)格來(lái)說(shuō)，秒級(jí)/分鐘級(jí)屬于準(zhǔn)實(shí)時(shí)，這里統(tǒng)一稱(chēng)為實(shí)時(shí))。這里涉及到如何將數(shù)據(jù)實(shí)時(shí)的從數(shù)據(jù)源中抽取出來(lái);如何實(shí)時(shí)流轉(zhuǎn);為了提高時(shí)效性，降低端到端延遲，還需要有能力支持在流轉(zhuǎn)過(guò)程中進(jìn)行計(jì)算處理;如何實(shí)時(shí)落庫(kù);如何實(shí)時(shí)提供后續(xù)消費(fèi)使用。實(shí)時(shí)同步是指多源到多目標(biāo)的端到端同步，流式處理指在流上進(jìn)行邏輯轉(zhuǎn)換處理。

但是我們要知道，不是所有數(shù)據(jù)處理計(jì)算都可以在流上進(jìn)行，而我們的目的，是盡可能的降低端到端數(shù)據(jù)延遲，這里就需要和其他數(shù)據(jù)流轉(zhuǎn)處理方式配合進(jìn)行，后面我們會(huì)進(jìn)一步討論。

(2)數(shù)據(jù)虛擬化(虛擬混算和統(tǒng)一服務(wù)能力)

數(shù)據(jù)虛擬化，是指對(duì)于用戶(hù)或用戶(hù)程序而言，面對(duì)的是統(tǒng)一的交互方式和查詢(xún)語(yǔ)言，而無(wú)需關(guān)注數(shù)據(jù)實(shí)際所在的物理庫(kù)和方言及交互方式(異構(gòu)系統(tǒng)/異構(gòu)查詢(xún)語(yǔ)言)的一種技術(shù)。用戶(hù)的使用體驗(yàn)是面對(duì)一個(gè)單一數(shù)據(jù)庫(kù)進(jìn)行操作，但其實(shí)這是一個(gè)虛擬化的數(shù)據(jù)庫(kù)，數(shù)據(jù)本身并不存放于虛擬數(shù)據(jù)庫(kù)中。

虛擬混算指的是虛擬化技術(shù)可以支持異構(gòu)系統(tǒng)數(shù)據(jù)透明混算的能力，統(tǒng)一服務(wù)指對(duì)于用戶(hù)提供統(tǒng)一的服務(wù)接口和方式。

注：圖1-4均選自“Designing a Modern Data Warehouse + Data Lake” - Melissa Coates, Solution Architect, BlueGranite

(3)數(shù)據(jù)平民化(可視化和自助配置能力)

普通用戶(hù)(無(wú)專(zhuān)業(yè)大數(shù)據(jù)技術(shù)背景的數(shù)據(jù)從業(yè)人員)，可以通過(guò)可視化的用戶(hù)界面，自助的通過(guò)配置和SQL方式使用數(shù)據(jù)完成自己的工作和需求，并無(wú)需關(guān)注底層技術(shù)層面問(wèn)題(通過(guò)計(jì)算資源云化，數(shù)據(jù)虛擬化等技術(shù))。以上是我們對(duì)數(shù)據(jù)平民化的解讀。

對(duì)于Data Democratization的解讀，還可以參見(jiàn)以下鏈接：

https://www.forbes.com/sites/bernardmarr/2017/07/24/what-is-data-democratization-a-super-simple-explanation-and-the-key-pros-and-cons

文中提到技術(shù)層面如何支持?jǐn)?shù)據(jù)平民化，并給出了幾個(gè)例子：

• Data virtualization software;

• Data federation software;

• Cloud storage;

• Self-service BI applications等。

其中數(shù)據(jù)虛擬化和數(shù)據(jù)聯(lián)邦本質(zhì)上是類(lèi)似技術(shù)方案，并且提到了自助BI這個(gè)概念。

(4)數(shù)據(jù)協(xié)作化(多租戶(hù)和分工協(xié)作能力)

技術(shù)人員應(yīng)該多了解業(yè)務(wù)，還是業(yè)務(wù)人員應(yīng)該多了解技術(shù)?這一直是企業(yè)內(nèi)爭(zhēng)論不休的問(wèn)題。而我們相信現(xiàn)代BI是一個(gè)可以深度協(xié)作的過(guò)程，技術(shù)人員和業(yè)務(wù)人員可以在同一個(gè)平臺(tái)上，發(fā)揮各自所長(zhǎng)，分工協(xié)作完成日常BI活動(dòng)。這就對(duì)平臺(tái)的多租戶(hù)能力和分工協(xié)作能力提出了較高要求，一個(gè)好的現(xiàn)代數(shù)據(jù)平臺(tái)是可以支持更好的數(shù)據(jù)協(xié)作化能力的。

我們希望可以設(shè)計(jì)出一個(gè)現(xiàn)代實(shí)時(shí)數(shù)據(jù)平臺(tái)，滿(mǎn)足以上提到的實(shí)時(shí)化、虛擬化、平民化、協(xié)作化等能力，成為現(xiàn)代數(shù)倉(cāng)的一個(gè)非常重要且必不可少的組成部分。

2從典型數(shù)據(jù)處理角度看實(shí)時(shí)數(shù)據(jù)處理

典型的數(shù)據(jù)處理，可分為OLTP、OLAP、Streaming、Adhoc、Machine Learning等。這里給出OLTP和OLAP的定義和對(duì)比：

注：圖5選自文章“Relational Databases are not Designed for Mixed Workloads”-Matt Allen

從某種角度來(lái)說(shuō)，OLTP活動(dòng)主要發(fā)生在業(yè)務(wù)交易庫(kù)端，OLAP活動(dòng)主要發(fā)生在數(shù)據(jù)分析庫(kù)端。那么，數(shù)據(jù)是如何從OLTP庫(kù)流轉(zhuǎn)到OLAP庫(kù)呢?如果這個(gè)數(shù)據(jù)流轉(zhuǎn)時(shí)效性要求很高，傳統(tǒng)的T+1批量ETL方式就無(wú)法滿(mǎn)足了。

我們將OLTP到OLAP的流轉(zhuǎn)過(guò)程叫Data Pipeline(數(shù)據(jù)處理管道)，它是指數(shù)據(jù)的生產(chǎn)端到消費(fèi)端之間的所有流轉(zhuǎn)和處理環(huán)節(jié)，包括了數(shù)據(jù)抽取、數(shù)據(jù)同步、流上處理、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)查詢(xún)等。這里可能會(huì)發(fā)生很復(fù)雜的數(shù)據(jù)處理轉(zhuǎn)換(如重復(fù)語(yǔ)義多源異構(gòu)數(shù)據(jù)源到統(tǒng)一Star Schema的轉(zhuǎn)換，明細(xì)表到匯總表的轉(zhuǎn)換，多實(shí)體表聯(lián)合成寬表等)。如何支持實(shí)時(shí)性很高的Pipeline處理能力，就成了一個(gè)有挑戰(zhàn)性的話(huà)題，我們將這個(gè)話(huà)題描述為“在線(xiàn)管道處理”(OLPP, Online Pipeline Processing)問(wèn)題。

因此，本文所討論的實(shí)時(shí)數(shù)據(jù)平臺(tái)，希望可以從數(shù)據(jù)處理角度解決OLPP問(wèn)題，成為OLTP到OLAP實(shí)時(shí)流轉(zhuǎn)缺失的課題的解決方案。下面，我們會(huì)探討從架構(gòu)層面，如何設(shè)計(jì)這樣一個(gè)實(shí)時(shí)數(shù)據(jù)平臺(tái)。

二、架構(gòu)設(shè)計(jì)方案

1定位和目標(biāo)

實(shí)時(shí)數(shù)據(jù)平臺(tái)(Real-time Data Platform，以下簡(jiǎn)稱(chēng)RTDP)，旨在提供數(shù)據(jù)端到端實(shí)時(shí)處理能力(毫秒級(jí)/秒級(jí)/分鐘級(jí)延遲)，可以對(duì)接多數(shù)據(jù)源進(jìn)行實(shí)時(shí)數(shù)據(jù)抽取，可以為多數(shù)據(jù)應(yīng)用場(chǎng)景提供實(shí)時(shí)數(shù)據(jù)消費(fèi)。作為現(xiàn)代數(shù)倉(cāng)的一部分，RTDP可以支持實(shí)時(shí)化、虛擬化、平民化、協(xié)作化等能力，讓實(shí)時(shí)數(shù)據(jù)應(yīng)用開(kāi)發(fā)門(mén)檻更低、迭代更快、質(zhì)量更好、運(yùn)行更穩(wěn)、運(yùn)維更簡(jiǎn)、能力更強(qiáng)。

2整體設(shè)計(jì)架構(gòu)

概念模塊架構(gòu)，是實(shí)時(shí)數(shù)據(jù)處理Pipeline的概念層的分層架構(gòu)和能力梳理，本身是具備通用性和可參考性的，更像是需求模塊。圖6給出了RTDP的整體概念模塊架構(gòu)，具體每個(gè)模塊含義都可自解釋?zhuān)@里不再詳述。

下面我們會(huì)根據(jù)上圖做進(jìn)一步設(shè)計(jì)討論，給出從技術(shù)層面的高階設(shè)計(jì)思路。

由圖7可以看出，我們針對(duì)概念模塊架構(gòu)的四個(gè)層面進(jìn)行了統(tǒng)一化抽象：

• 統(tǒng)一數(shù)據(jù)采集平臺(tái)

• 統(tǒng)一流式處理平臺(tái)

• 統(tǒng)一計(jì)算服務(wù)平臺(tái)

• 統(tǒng)一數(shù)據(jù)可視化平臺(tái)

同時(shí)，也對(duì)存儲(chǔ)層保持了開(kāi)放的原則，意味著用戶(hù)可以選擇不同的存儲(chǔ)層以滿(mǎn)足具體項(xiàng)目的需要，而又不破壞整體架構(gòu)設(shè)計(jì)，用戶(hù)甚至可以在Pipeline中同時(shí)選擇多個(gè)異構(gòu)存儲(chǔ)提供支持。下面分別對(duì)四個(gè)抽象層進(jìn)行解讀。

(1)統(tǒng)一數(shù)據(jù)采集平臺(tái)

統(tǒng)一數(shù)據(jù)采集平臺(tái)，既可以支持不同數(shù)據(jù)源的全量抽取，也可以支持增強(qiáng)抽取。其中對(duì)于業(yè)務(wù)數(shù)據(jù)庫(kù)的增量抽取會(huì)選擇讀取數(shù)據(jù)庫(kù)日志，以減少對(duì)業(yè)務(wù)庫(kù)的讀取壓力。平臺(tái)還可以對(duì)抽取的數(shù)據(jù)進(jìn)行統(tǒng)一處理，然后以統(tǒng)一格式發(fā)布到數(shù)據(jù)總線(xiàn)上。這里我們選擇一種自定義的標(biāo)準(zhǔn)化統(tǒng)一消息格式UMS(Unified Message Schema)做為統(tǒng)一數(shù)據(jù)采集平臺(tái)和統(tǒng)一流式處理平臺(tái)之間的數(shù)據(jù)層面協(xié)議。

UMS自帶Namespace信息和Schema信息，這是一種自定位自解釋消息協(xié)議格式，這樣做的好處是：

• 整個(gè)架構(gòu)無(wú)需依賴(lài)外部元數(shù)據(jù)管理平臺(tái);

• 消息和物理媒介解耦(這里物理媒介指如Kafka的Topic, Spark Streaming的Stream等)，因此可以通過(guò)物理媒介支持多消息流并行，和消息流的自由漂移。

• 平臺(tái)也支持多租戶(hù)體系，和配置化簡(jiǎn)單處理清洗能力。

(2)統(tǒng)一流式處理平臺(tái)

統(tǒng)一流式處理平臺(tái)，會(huì)消費(fèi)來(lái)自數(shù)據(jù)總線(xiàn)上的消息，可以支持UMS協(xié)議消息，也可以支持普通JSON格式消息。同時(shí)，平臺(tái)還支持以下能力：

• 支持可視化/配置化/SQL化方式降低流式邏輯開(kāi)發(fā)/部署/管理門(mén)檻

• 支持配置化方式冪等落入多個(gè)異構(gòu)目標(biāo)庫(kù)以確保數(shù)據(jù)的最終一致性

• 支持多租戶(hù)體系，做到項(xiàng)目級(jí)的計(jì)算資源/表資源/用戶(hù)資源等隔離

(3)統(tǒng)一計(jì)算服務(wù)平臺(tái)

統(tǒng)一計(jì)算服務(wù)平臺(tái)，是一種數(shù)據(jù)虛擬化/數(shù)據(jù)聯(lián)邦的實(shí)現(xiàn)。平臺(tái)對(duì)內(nèi)支持多異構(gòu)數(shù)據(jù)源的下推計(jì)算和拉取混算，也支持對(duì)外的統(tǒng)一服務(wù)接口(JDBC/REST)和統(tǒng)一查詢(xún)語(yǔ)言(SQL)。由于平臺(tái)可以統(tǒng)一收口服務(wù)，因此可以基于平臺(tái)打造統(tǒng)一元數(shù)據(jù)管理/數(shù)據(jù)質(zhì)量管理/數(shù)據(jù)安全審計(jì)/數(shù)據(jù)安全策略等模塊。平臺(tái)也支持多租戶(hù)體系。

(4)統(tǒng)一數(shù)據(jù)可視化平臺(tái)

統(tǒng)一數(shù)據(jù)可視化平臺(tái)，加上多租戶(hù)和完善的用戶(hù)體系/權(quán)限體系，可以支持跨部門(mén)數(shù)據(jù)從業(yè)人員的分工協(xié)作能力，讓用戶(hù)在可視化環(huán)境下，通過(guò)緊密合作的方式，更能發(fā)揮各自所長(zhǎng)來(lái)完成數(shù)據(jù)平臺(tái)最后十公里的應(yīng)用。

以上是基于整體模塊架構(gòu)之上，進(jìn)行了統(tǒng)一抽象設(shè)計(jì)，并開(kāi)放存儲(chǔ)選項(xiàng)以提高靈活性和需求適配性。這樣的RTDP平臺(tái)設(shè)計(jì)，體現(xiàn)了現(xiàn)代數(shù)倉(cāng)的實(shí)時(shí)化/虛擬化/平民化/協(xié)作化等能力，并且覆蓋了端到端的OLPP數(shù)據(jù)流轉(zhuǎn)鏈路。

3具體問(wèn)題和考量思路

下面我們會(huì)基于RTDP的整體架構(gòu)設(shè)計(jì)，分別從不同維度討論這個(gè)設(shè)計(jì)需要面對(duì)的問(wèn)題考量和解決思路。

(1)功能考量

功能考量主要討論這樣一個(gè)問(wèn)題：實(shí)時(shí)Pipeline能否處理所有ETL復(fù)雜邏輯?

我們知道，對(duì)于Storm/Flink這樣的流式計(jì)算引擎，是按每條處理的;對(duì)于Spark Streaming流式計(jì)算引擎，按每個(gè)mini-batch處理;而對(duì)于離線(xiàn)跑批任務(wù)來(lái)說(shuō)，是按每天數(shù)據(jù)進(jìn)行處理的。因此處理范圍是數(shù)據(jù)的一個(gè)維度(范圍維度)。

另外，流式處理面向的是增量數(shù)據(jù)，如果數(shù)據(jù)源來(lái)自關(guān)系型數(shù)據(jù)庫(kù)，那么增量數(shù)據(jù)往往指的是增量變更數(shù)據(jù)(增刪改，revision);相對(duì)的批量處理面向的則是快照數(shù)據(jù)(snapshot)。因此展現(xiàn)形式是數(shù)據(jù)的另一個(gè)維度(變更維度)。

單條數(shù)據(jù)的變更維度，是可以投射收斂成單條快照的，因此變更維度可以收斂成范圍維度。所以流式處理和批量處理的本質(zhì)區(qū)別在于，面對(duì)的數(shù)據(jù)范圍維度的不同，流式處理單位為“有限范圍”，批量處理單位為“全表范圍”?！叭矸秶睌?shù)據(jù)是可以支持各種SQL算子的，而“有限范圍”數(shù)據(jù)只能支持部分SQL算子，具體支持情況如下：

join：

• left join：支持?！跋拗品秶笨梢詌eft join外部lookup表(通過(guò)下推，類(lèi)似hashjoin效果)

• right join：不支持。每次從lookup拿回所有l(wèi)ookup表數(shù)據(jù)，這個(gè)計(jì)算是不可行的也是不合理的

• inter join：支持?？梢赞D(zhuǎn)化為left join +filter，可以支持

• outer join：不支持。存在right join，因此不合理

• union：支持。可以應(yīng)用在拉回局部范圍數(shù)據(jù)做窗口聚合操作。

• agg：不支持。可以借助union做局部窗口聚合，但無(wú)法支持全表聚合操作。

• filter：支持。沒(méi)有shuffle，非常適合。

• map：支持。沒(méi)有shuffle，非常適合。

• project：支持。沒(méi)有shuffle，非常適合。

Join往往需要shuffle操作，是最費(fèi)計(jì)算資源和時(shí)間的操作，而流上join(left join)將join操作轉(zhuǎn)化成hashjoin的隊(duì)列操作，將批量處理join的集中數(shù)據(jù)計(jì)算資源和時(shí)間平攤在數(shù)據(jù)流轉(zhuǎn)過(guò)程中，因此在流上做left join是最劃算的計(jì)算方式。

復(fù)雜的ETL并不是單一算子，經(jīng)常會(huì)是由多個(gè)算子組合而成，由上可以看出單純的流式處理并不能很好的支持所有ETL復(fù)雜邏輯。那么如何在實(shí)時(shí)Pipeline中支持更多復(fù)雜的ETL算子，并且保持時(shí)效性?這就需要“有限范圍”和“全表范圍”處理的相互轉(zhuǎn)換能力。

設(shè)想一下：流式處理平臺(tái)可以支持流上適合的處理，然后實(shí)時(shí)落不同的異構(gòu)庫(kù)，計(jì)算服務(wù)平臺(tái)可以定時(shí)批量混算多源異構(gòu)庫(kù)(時(shí)間設(shè)定可以是每隔幾分鐘或更短)，并將每批計(jì)算結(jié)果發(fā)送到數(shù)據(jù)總線(xiàn)上繼續(xù)流轉(zhuǎn)，這樣流式處理平臺(tái)和計(jì)算服務(wù)平臺(tái)就形成了計(jì)算閉環(huán)，各自做擅長(zhǎng)的算子處理，數(shù)據(jù)在不同頻率觸發(fā)流轉(zhuǎn)過(guò)程中進(jìn)行各種算子轉(zhuǎn)換，這樣的架構(gòu)模式理論上即可支持所有ETL復(fù)雜邏輯。

圖8給出了數(shù)據(jù)處理架構(gòu)的演化，和OLPP的一種架構(gòu)模式。其中wormhole和moonbox分別是我們開(kāi)源的流式處理平臺(tái)和計(jì)算服務(wù)平臺(tái)，后面會(huì)具體介紹。

(2)質(zhì)量考量

上面的圖也引出了兩個(gè)主流實(shí)時(shí)數(shù)據(jù)處理架構(gòu)：Lambda架構(gòu)和Kappa架構(gòu)，具體兩個(gè)架構(gòu)的介紹網(wǎng)上有很多資料，這里不再贅述。Lambda架構(gòu)和Kappa架構(gòu)各有其優(yōu)劣勢(shì)，但都支持?jǐn)?shù)據(jù)的最終一致性，從某種程度上確保了數(shù)據(jù)質(zhì)量，如何在Lambda架構(gòu)和Kappa架構(gòu)中取長(zhǎng)補(bǔ)短，形成某種融合架構(gòu)，這個(gè)話(huà)題會(huì)在新起文章中詳細(xì)探討。

當(dāng)然數(shù)據(jù)質(zhì)量也是個(gè)非常大的話(huà)題，只支持重跑和回灌并不能完全解決所有數(shù)據(jù)質(zhì)量問(wèn)題，只是從技術(shù)架構(gòu)層面給出了補(bǔ)數(shù)據(jù)的工程方案。關(guān)于大數(shù)據(jù)數(shù)據(jù)質(zhì)量問(wèn)題，我們也會(huì)起一個(gè)新的話(huà)題討論。

(3)穩(wěn)定考量

這個(gè)話(huà)題涉及但不限于以下幾點(diǎn)，這里簡(jiǎn)單給出應(yīng)對(duì)的思路：

高可用HA

整個(gè)實(shí)時(shí)Pipeline鏈路都應(yīng)該選取高可用組件，確保理論上整體高可用;在數(shù)據(jù)關(guān)鍵鏈路上支持?jǐn)?shù)據(jù)備份和重演機(jī)制;在業(yè)務(wù)關(guān)鍵鏈路上支持雙跑融合機(jī)制

SLA保障

在確保集群和實(shí)時(shí)Pipeline高可用的前提下，支持動(dòng)態(tài)擴(kuò)容和數(shù)據(jù)處理流程自動(dòng)漂移

彈性反脆弱

基于規(guī)則和算法的資源彈性伸縮;支持事件觸發(fā)動(dòng)作引擎的失效處理。

監(jiān)控預(yù)警

集群設(shè)施層面，物理管道層面，數(shù)據(jù)邏輯層面的多方面監(jiān)控預(yù)警能力

自動(dòng)運(yùn)維

能夠捕捉并存檔缺失數(shù)據(jù)和處理異常，并具備定期自動(dòng)重試機(jī)制修復(fù)問(wèn)題數(shù)據(jù)

上游元數(shù)據(jù)變更抗性

上游業(yè)務(wù)庫(kù)要求兼容性元數(shù)據(jù)變更;實(shí)時(shí)Pipeline處理顯式字段。

(4)成本考量

這個(gè)話(huà)題涉及但不限于以下幾點(diǎn)，這里簡(jiǎn)單給出應(yīng)對(duì)的思路：

人力成本

通過(guò)支持?jǐn)?shù)據(jù)應(yīng)用平民化降低人才人力成本

資源成本

通過(guò)支持動(dòng)態(tài)資源利用降低靜態(tài)資源占用造成的資源浪費(fèi)

運(yùn)維成本

通過(guò)支持自動(dòng)運(yùn)維/高可用/彈性反脆弱等機(jī)制降低運(yùn)維成本

試錯(cuò)成本

通過(guò)支持敏捷開(kāi)發(fā)/快速迭代降低試錯(cuò)成本

(5)敏捷考量

敏捷大數(shù)據(jù)是一整套理論體系和方法學(xué)，在前文已有所描述，從數(shù)據(jù)使用角度來(lái)看，敏捷考量意味著：配置化、SQL化、平民化。

(6)管理考量

數(shù)據(jù)管理也是一個(gè)非常大的話(huà)題，這里我們會(huì)重點(diǎn)關(guān)注兩個(gè)方面：元數(shù)據(jù)管理和數(shù)據(jù)安全管理。如果在現(xiàn)代數(shù)倉(cāng)多數(shù)據(jù)存儲(chǔ)選型的環(huán)境下統(tǒng)一管理元數(shù)據(jù)和數(shù)據(jù)安全，是一個(gè)非常有挑戰(zhàn)的話(huà)題，我們會(huì)在實(shí)時(shí)Pipeline上各個(gè)環(huán)節(jié)平臺(tái)分別考慮這兩個(gè)方面問(wèn)題并給出內(nèi)置支持，同時(shí)也可以支持對(duì)接外部統(tǒng)一的元數(shù)據(jù)管理平臺(tái)和統(tǒng)一數(shù)據(jù)安全策略。

上述就是小編為大家分享的怎樣解決從OLTP到OLAP實(shí)時(shí)流轉(zhuǎn)缺失問(wèn)題了，如果剛好有類(lèi)似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。