分布式環(huán)境下大規(guī)模維表關(guān)聯(lián)技術(shù)優(yōu)化

趙恒泰，趙宇海+，袁 野，季航旭，喬百友，王國(guó)仁

1.東北大學(xué) 計(jì)算機(jī)科學(xué)與工程學(xué)院，沈陽(yáng)110169

2.北京理工大學(xué) 計(jì)算機(jī)學(xué)院，北京100081

隨著互聯(lián)網(wǎng)的發(fā)展和普及，網(wǎng)絡(luò)中每天產(chǎn)生的數(shù)據(jù)量在迅速增加。傳統(tǒng)的數(shù)據(jù)處理方式已經(jīng)無(wú)法面對(duì)當(dāng)前的數(shù)據(jù)規(guī)模，為了獲取這些海量的數(shù)據(jù)中潛在的價(jià)值，開(kāi)發(fā)者們提出了大數(shù)據(jù)處理技術(shù)。隨著大數(shù)據(jù)處理技術(shù)的不斷發(fā)展和計(jì)算需求的不斷更迭，到現(xiàn)在為止大數(shù)據(jù)處理技術(shù)已經(jīng)經(jīng)歷了三代計(jì)算引擎的變化。第一代大數(shù)據(jù)計(jì)算引擎以Apache Hadoop為代表，利用MapReduce進(jìn)行大數(shù)據(jù)處理。這一代計(jì)算的顯著特點(diǎn)基于物理存儲(chǔ)的計(jì)算模式。這類計(jì)算有著非常高的吞吐量，但由于每一步的計(jì)算操作都要寫(xiě)入到物理存儲(chǔ)中，基于內(nèi)存的計(jì)算速度與磁盤(pán)的I/O 開(kāi)銷的不匹配導(dǎo)致了非常高的處理延遲。這一代計(jì)算引擎適合處理實(shí)時(shí)性要求不高的離線批處理任務(wù)。這個(gè)時(shí)代的大數(shù)據(jù)分析技術(shù)以離線分析為主，需要先統(tǒng)計(jì)和獲取全部數(shù)據(jù)再進(jìn)行分析，對(duì)分析結(jié)果的實(shí)時(shí)性要求不高，更偏重于對(duì)歷史數(shù)據(jù)的總結(jié)。第二代大數(shù)據(jù)計(jì)算引擎以Apache Spark為代表，利用內(nèi)存進(jìn)行批處理計(jì)算。相對(duì)于第一代技術(shù)，這一代的顯著特點(diǎn)是將計(jì)算數(shù)據(jù)移入了內(nèi)存中，基于內(nèi)存的數(shù)據(jù)進(jìn)行計(jì)算。這種基于內(nèi)存的計(jì)算方式大大降低了第一代技術(shù)中每一步計(jì)算都需要把結(jié)果寫(xiě)入磁盤(pán)產(chǎn)生的I/O 開(kāi)銷所帶來(lái)的延遲。但是由于技術(shù)仍然是建立在批處理的計(jì)算模式之上，每一個(gè)批次的數(shù)據(jù)處理都有一定的時(shí)間間隔，在面對(duì)一些實(shí)時(shí)性比較強(qiáng)的計(jì)算任務(wù)時(shí)仍無(wú)法保證極低的延遲。這個(gè)時(shí)代的大數(shù)據(jù)分析技術(shù)逐漸向在線分析靠攏，已經(jīng)有了對(duì)實(shí)時(shí)數(shù)據(jù)處理的需求。第三代大數(shù)據(jù)計(jì)算引擎以Apache Flink為代表，是完全基于流計(jì)算的數(shù)據(jù)處理引擎。Apache Flink 所提供的計(jì)算平臺(tái)可以在實(shí)現(xiàn)毫秒級(jí)的延遲下，每秒處理上億次的消息或者事件。極高的數(shù)據(jù)處理能力和極低的延遲，使以Apache Flink 為代表的流計(jì)算技術(shù)成為了實(shí)時(shí)大數(shù)據(jù)分析的首選。越來(lái)越多的公司使用流計(jì)算技術(shù)構(gòu)建自己的實(shí)時(shí)數(shù)據(jù)分析引擎來(lái)替代傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)分析。在這類數(shù)據(jù)處理和分析過(guò)程中，實(shí)時(shí)產(chǎn)生的流數(shù)據(jù)往往信息量不足，需要與離線存儲(chǔ)的數(shù)據(jù)進(jìn)行關(guān)聯(lián)，擴(kuò)充數(shù)據(jù)屬性。離線存儲(chǔ)的數(shù)據(jù)稱為維表數(shù)據(jù)，流數(shù)據(jù)和維表數(shù)據(jù)進(jìn)行關(guān)聯(lián)的過(guò)程稱為維表關(guān)聯(lián)。

維表關(guān)聯(lián)是當(dāng)前在線大數(shù)據(jù)分析的關(guān)鍵技術(shù)之一。針對(duì)維表關(guān)聯(lián)技術(shù)在分布式環(huán)境下的優(yōu)化，主要是對(duì)維表數(shù)據(jù)查詢進(jìn)行優(yōu)化以降低查詢維表數(shù)據(jù)所帶來(lái)的I/O 開(kāi)銷和延遲。維表關(guān)聯(lián)的數(shù)據(jù)查詢優(yōu)化主要是通過(guò)異步I/O 技術(shù)增加單位時(shí)間的查詢數(shù)量和通過(guò)使用數(shù)據(jù)緩存技術(shù)將查詢到的維表緩存在分布式引擎的計(jì)算節(jié)點(diǎn)的內(nèi)存中加速查詢。通常有緩存查詢結(jié)果和緩存整個(gè)維表兩種緩存模式，其原理如圖1 所示。

圖1 傳統(tǒng)維表關(guān)聯(lián)邏輯Fig.1 Traditional dimension table connection

這兩種基于計(jì)算節(jié)點(diǎn)的優(yōu)化方式，都存在著各自的不足。數(shù)據(jù)全部緩存的方式因?yàn)閮?nèi)存問(wèn)題無(wú)法支持過(guò)大規(guī)模的維表。緩存查詢結(jié)果的方式對(duì)每條未緩存數(shù)據(jù)的處理時(shí)間受限于數(shù)據(jù)庫(kù)I/O 能力，會(huì)隨著維表數(shù)據(jù)規(guī)模的增大而線性上升。當(dāng)數(shù)據(jù)流速處于一個(gè)較低水平，保證數(shù)據(jù)有效性的緩存超時(shí)機(jī)制會(huì)讓每一次數(shù)據(jù)查詢都指向數(shù)據(jù)庫(kù)，使本地緩存無(wú)效化，降低數(shù)據(jù)處理效率。

針對(duì)單節(jié)點(diǎn)優(yōu)化技術(shù)的不足，本文首先提出了一種可以用于離線存儲(chǔ)的數(shù)據(jù)和實(shí)時(shí)生成的數(shù)據(jù)進(jìn)行混合計(jì)算的計(jì)算模型，然后基于該模型設(shè)計(jì)了一種新型的維表關(guān)聯(lián)技術(shù)優(yōu)化方案，其原理如圖2所示。

圖2 優(yōu)化的維表關(guān)聯(lián)邏輯Fig.2 Optimized dimension table connection

該方案單點(diǎn)讀取維表數(shù)據(jù)，將數(shù)據(jù)切分后分發(fā)到計(jì)算節(jié)點(diǎn)，然后與流數(shù)據(jù)進(jìn)行關(guān)聯(lián)。這個(gè)優(yōu)化方案每個(gè)計(jì)算節(jié)點(diǎn)只需緩存部分維表數(shù)據(jù)，提高了維表數(shù)據(jù)的緩存規(guī)模，同時(shí)大幅降低維表數(shù)據(jù)查詢所產(chǎn)生的消耗。該方案將批處理技術(shù)和流計(jì)算技術(shù)進(jìn)行了結(jié)合，同是對(duì)離線的批數(shù)據(jù)和實(shí)時(shí)的流數(shù)據(jù)進(jìn)行混合計(jì)算的一種探究。

本文主要貢獻(xiàn)如下：

（1）提出了一種適用于對(duì)離線的批數(shù)據(jù)和實(shí)時(shí)的流數(shù)據(jù)進(jìn)行混合計(jì)算的計(jì)算模型，該計(jì)算模型可以在一套API（application programming interface）中同時(shí)處理流數(shù)據(jù)和批數(shù)據(jù)，也可以單獨(dú)處理流數(shù)據(jù)或單獨(dú)處理批數(shù)據(jù)。

（2）提出了一種單點(diǎn)讀取維表數(shù)據(jù)，切分后進(jìn)行分發(fā)和計(jì)算的維表關(guān)聯(lián)數(shù)據(jù)緩存方式，降低了維表數(shù)據(jù)查詢對(duì)數(shù)據(jù)庫(kù)產(chǎn)生的壓力并提高了集群環(huán)境中計(jì)算系統(tǒng)對(duì)維表規(guī)模支持的上限。同時(shí)針對(duì)維表關(guān)聯(lián)計(jì)算邏輯進(jìn)行了優(yōu)化，使維表關(guān)聯(lián)技術(shù)不再局限于對(duì)數(shù)據(jù)的連接。

（3）在流計(jì)算引擎Apache Flink 中對(duì)該優(yōu)化的維表關(guān)聯(lián)技術(shù)和傳統(tǒng)的維表關(guān)聯(lián)技術(shù)進(jìn)行了實(shí)現(xiàn)。通過(guò)實(shí)驗(yàn)對(duì)該維表關(guān)聯(lián)技術(shù)進(jìn)行了驗(yàn)證，實(shí)驗(yàn)結(jié)果對(duì)比顯示該方法相對(duì)于同等條件下傳統(tǒng)的維表關(guān)聯(lián)方法，可以使計(jì)算任務(wù)的吞吐量有8～9 倍的提升，同時(shí)在計(jì)算能力滿足的情況下降低40%以上的計(jì)算延遲。

1 相關(guān)工作

在過(guò)去的幾年時(shí)間中，針對(duì)分布式環(huán)境下維表關(guān)聯(lián)操作以及以其為代表的典型的流數(shù)據(jù)與靜態(tài)數(shù)據(jù)交互的計(jì)算的優(yōu)化研究已經(jīng)存在不少的進(jìn)展。

為了解決海量數(shù)據(jù)關(guān)聯(lián)計(jì)算問(wèn)題，文獻(xiàn)[9]提出了一種MESHJOIN 算法，該算法優(yōu)化了單點(diǎn)計(jì)算時(shí)連續(xù)數(shù)據(jù)流和維度數(shù)據(jù)的連接過(guò)程，但該算法對(duì)內(nèi)存分配的方式不夠高效。為此，文獻(xiàn)[10]提出了一種改進(jìn)的算法用于改善內(nèi)存分配問(wèn)題。文獻(xiàn)[11]提出基于分塊思想的算法來(lái)提高M(jìn)ESHJOIN 算法的連接性能。文獻(xiàn)[12]提出MESHJOIN*算法，該算法采用多線程并發(fā)連接技術(shù)，并根據(jù)工程學(xué)原理，實(shí)現(xiàn)了連接操作和關(guān)系R 讀取操作的最佳調(diào)度，保證了連接算法效率的最大化，進(jìn)一步提高連接效率。在MESHJOIN 算法的基礎(chǔ)上，文獻(xiàn)[13]又提出EHJOIN 算法，對(duì)傳統(tǒng)散列連接方法進(jìn)行改進(jìn)，利用索引將部分頻繁使用的主數(shù)據(jù)存儲(chǔ)在內(nèi)存中，解決了高速數(shù)據(jù)流下的磁盤(pán)頻繁訪問(wèn)問(wèn)題。以上的算法都是基于維度數(shù)據(jù)的角度對(duì)維表連接過(guò)程進(jìn)行優(yōu)化，沒(méi)有考慮流數(shù)據(jù)的傾斜問(wèn)題，據(jù)此文獻(xiàn)[14]提出了CSJR（cachedbased stream-relation join）算法，優(yōu)化了在流數(shù)據(jù)傾斜環(huán)境下的數(shù)據(jù)連接效率。

在分布式計(jì)算引擎領(lǐng)域，大量的開(kāi)發(fā)貢獻(xiàn)都來(lái)自于社區(qū)。而主流的分布式系統(tǒng)Apache Spark 和Apache Flink 都針對(duì)維表關(guān)聯(lián)這種場(chǎng)景做出了自己的適配。

Apache Spark 提出了Spark Streaming用以改善計(jì)算延遲并提供流計(jì)算支持，這一計(jì)算模式通過(guò)將無(wú)限的流數(shù)據(jù)拆分成離散流（discretized stream），盡可能縮小每個(gè)彈性分布式數(shù)據(jù)集（resilient distributed dataset，RDD）的大小，構(gòu)建微量批數(shù)據(jù)集，來(lái)達(dá)到近似于流計(jì)算的效果，這個(gè)階段流計(jì)算的延遲在100 ms 級(jí)。在Spark Streaming 的技術(shù)背景下，Apache Spark 可以將維表數(shù)據(jù)定義為一個(gè)獨(dú)立的RDD，并緩存到每一個(gè)關(guān)聯(lián)節(jié)點(diǎn)上，在每一個(gè)批次的微量批數(shù)據(jù)集到達(dá)后，以局部批處理的方式進(jìn)行關(guān)聯(lián)。同時(shí)可以對(duì)RDD 內(nèi)容進(jìn)行更新以達(dá)到和離線維表數(shù)據(jù)相同的狀態(tài)。以上的更新操作需要用戶自己定義更新的邏輯。

由于Spark Streaming 的數(shù)據(jù)傳輸是基于微量批數(shù)據(jù)集的方式進(jìn)行數(shù)據(jù)傳輸而不是真正意義上的持續(xù)傳輸，Spark 又提出了結(jié)構(gòu)化流計(jì)算（structured streaming）。在該計(jì)算模式中引入了連續(xù)處理的概念，將流計(jì)算的延遲降低到了1 ms 級(jí)的層面。同時(shí)Structured Streaming原生地支持了Stream-Static Join，但是其底層的實(shí)現(xiàn)邏輯仍是針對(duì)每個(gè)計(jì)算節(jié)點(diǎn)進(jìn)行獨(dú)立的緩存操作。

Apache Flink 本身是基于流計(jì)算的分布式計(jì)算引擎，但是為了兼容批處理，仍獨(dú)立維護(hù)了一套用于批處理的DataSet API。Apache Flink 在1.8 版本中并未提供對(duì)維表關(guān)聯(lián)計(jì)算的官方支持，需要用戶通過(guò)一些算子手動(dòng)實(shí)現(xiàn)流計(jì)算中對(duì)維表關(guān)聯(lián)計(jì)算的支持。

阿里巴巴公司基于Apache Flink 而構(gòu)建的開(kāi)源引擎Blink 在Table API 的層面上提出了維表關(guān)聯(lián)的操作模式，用戶需要手動(dòng)實(shí)現(xiàn)對(duì)維表數(shù)據(jù)的查詢邏輯。依靠異步查詢維表數(shù)據(jù)并緩存查詢結(jié)果的方式降低數(shù)據(jù)庫(kù)I/O 開(kāi)銷，提高查詢效率。該方案的緩存模式有數(shù)據(jù)全部緩存并定時(shí)更新和LRU Cache兩種，都是基于計(jì)算節(jié)點(diǎn)的緩存方式。

以上的維表關(guān)聯(lián)計(jì)算設(shè)計(jì)，實(shí)質(zhì)上都是在流計(jì)算過(guò)程中直接向數(shù)據(jù)庫(kù)發(fā)起查詢，將查詢邏輯都綁定在每個(gè)獨(dú)立的計(jì)算節(jié)點(diǎn)中，所有的計(jì)算節(jié)點(diǎn)都要同時(shí)訪問(wèn)數(shù)據(jù)源或緩存完整的維表信息。

在面對(duì)高速流數(shù)據(jù)輸入時(shí)，異步查詢數(shù)據(jù)庫(kù)的方式會(huì)對(duì)數(shù)據(jù)庫(kù)造成極大的壓力；在面對(duì)海量的維表數(shù)據(jù)時(shí)，由于每個(gè)計(jì)算節(jié)點(diǎn)的內(nèi)存限制，維表數(shù)據(jù)無(wú)法完整地寫(xiě)入內(nèi)存中并導(dǎo)致執(zhí)行引擎產(chǎn)生內(nèi)存異常。

2 維表關(guān)聯(lián)技術(shù)的設(shè)計(jì)與優(yōu)化

如前所述，現(xiàn)有的大數(shù)據(jù)計(jì)算平臺(tái)并沒(méi)有支持緩存水平擴(kuò)展的維表關(guān)聯(lián)機(jī)制。在面對(duì)大規(guī)模維表數(shù)據(jù)時(shí)，全緩存模式下，維表無(wú)法完整地緩存到每一個(gè)計(jì)算節(jié)點(diǎn)中。而使用異步連接方式則會(huì)在高速計(jì)算時(shí)產(chǎn)生大量數(shù)據(jù)I/O，對(duì)數(shù)據(jù)庫(kù)造成過(guò)大的壓力，甚至導(dǎo)致數(shù)據(jù)庫(kù)連接超時(shí)，失去響應(yīng)。針對(duì)這個(gè)問(wèn)題，本章設(shè)計(jì)并提出了一種面向大規(guī)模分布式計(jì)算的維表關(guān)聯(lián)機(jī)制。

本章介紹了維表關(guān)聯(lián)技術(shù)優(yōu)化的幾個(gè)具體設(shè)計(jì)。首先介紹了一種混合計(jì)算模型，做到了在同一個(gè)計(jì)算任務(wù)中統(tǒng)一批數(shù)據(jù)處理和流數(shù)據(jù)處理。然后介紹了維表關(guān)聯(lián)技術(shù)的緩存優(yōu)化，包含對(duì)維表數(shù)據(jù)源的緩存設(shè)計(jì)以及各個(gè)計(jì)算節(jié)點(diǎn)對(duì)維表數(shù)據(jù)的緩存設(shè)計(jì)。最后介紹了維表關(guān)聯(lián)技術(shù)的計(jì)算設(shè)計(jì)，包含對(duì)并行計(jì)算下的數(shù)據(jù)分發(fā)的處理和每個(gè)計(jì)算節(jié)點(diǎn)對(duì)關(guān)聯(lián)計(jì)算的處理。

2.1 定義和概念

本節(jié)給出了文中所涉及的一些基本定義和概念。

（維表）維表是指存儲(chǔ)在外部數(shù)據(jù)庫(kù)中的，具有數(shù)據(jù)規(guī)模大、更新時(shí)間慢等特征的一類數(shù)據(jù)表。

（算子）算子是指在計(jì)算過(guò)程中對(duì)數(shù)據(jù)處理的最小計(jì)算單位，不同的算子具有不同的計(jì)算邏輯。批處理和流計(jì)算擁有功能相同但運(yùn)行邏輯不同的算子。

（混合計(jì)算）混合計(jì)算是指在同一個(gè)計(jì)算任務(wù)中，同時(shí)存在流計(jì)算算子和批處理算子，也被稱作批流融合計(jì)算。

（維表關(guān)聯(lián)）維表關(guān)聯(lián)指數(shù)據(jù)流和維表之間存在一定關(guān)系，并根據(jù)這種關(guān)系進(jìn)行的數(shù)據(jù)處理，根據(jù)關(guān)系確定連接信息并將數(shù)據(jù)表進(jìn)行組合的過(guò)程稱為連接。從廣義上來(lái)看，維表關(guān)聯(lián)包含但不限于連接操作，通過(guò)維表數(shù)據(jù)計(jì)算分析等操作也屬于維表關(guān)聯(lián)。

（背壓）背壓指當(dāng)某個(gè)計(jì)算節(jié)點(diǎn)數(shù)據(jù)處理速度低于數(shù)據(jù)傳輸速度時(shí)，接收到的數(shù)據(jù)產(chǎn)生積壓。進(jìn)而使單個(gè)計(jì)算節(jié)點(diǎn)的輸入緩存超出限制，拒絕接收新數(shù)據(jù)。最終讓整個(gè)流計(jì)算系統(tǒng)從過(guò)載的節(jié)點(diǎn)開(kāi)始的一系列上游節(jié)點(diǎn)直至數(shù)據(jù)源節(jié)點(diǎn)鏈?zhǔn)骄彺嬉绯鐾Ｖ菇邮諗?shù)據(jù)，等待過(guò)載節(jié)點(diǎn)處理數(shù)據(jù)。

2.2 混合計(jì)算模型

本節(jié)介紹本文所提出的混合計(jì)算模型。傳統(tǒng)的批式計(jì)算架構(gòu)中，計(jì)算的運(yùn)行邏輯如圖3 所示。計(jì)算節(jié)點(diǎn)分階段啟動(dòng)，每一組計(jì)算只有全部完成以后才會(huì)解除同步等待，啟動(dòng)下一組計(jì)算任務(wù)，并將計(jì)算數(shù)據(jù)重新分發(fā)到下一輪的計(jì)算節(jié)點(diǎn)中。

圖3 批式計(jì)算架構(gòu)Fig.3 Batch computing architecture

傳統(tǒng)的流式計(jì)算架構(gòu)中，計(jì)算的運(yùn)行邏輯如圖4所示。所有的計(jì)算節(jié)點(diǎn)在計(jì)算開(kāi)始時(shí)全部創(chuàng)建，然后數(shù)據(jù)在計(jì)算節(jié)點(diǎn)之間不斷流動(dòng)，每個(gè)節(jié)點(diǎn)通過(guò)不斷拉取和消費(fèi)上游計(jì)算節(jié)點(diǎn)的數(shù)據(jù)，來(lái)做到持續(xù)不停的流式處理。流計(jì)算會(huì)盡可能地不進(jìn)行數(shù)據(jù)重新分發(fā)操作，從而讓數(shù)據(jù)連續(xù)處理。

圖4 流式計(jì)算架構(gòu)Fig.4 Stream computing architecture

為了做到在流式計(jì)算中兼容對(duì)批數(shù)據(jù)的處理，本文對(duì)計(jì)算算子進(jìn)行了重新設(shè)計(jì)。在流計(jì)算中構(gòu)建標(biāo)志為批處理的算子，進(jìn)而提出了混合計(jì)算模型，如圖5 所示。該類模型算子分為三類：流計(jì)算算子、批處理算子、混合計(jì)算算子。該模型中的流算子仍和傳統(tǒng)流計(jì)算的計(jì)算邏輯一致，隨著數(shù)據(jù)流入實(shí)時(shí)計(jì)算。批處理算子通過(guò)修改流計(jì)算環(huán)境中的數(shù)據(jù)分發(fā)和計(jì)算邏輯，做到和傳統(tǒng)的批式計(jì)算一樣效果。混合計(jì)算算子用于流數(shù)據(jù)和批數(shù)據(jù)的混合計(jì)算，上游算子分別為流計(jì)算算子和批處理算子?；旌嫌?jì)算算子在批數(shù)據(jù)完全到達(dá)之前，會(huì)阻塞流計(jì)算，等待批數(shù)據(jù)分發(fā)完成以后，開(kāi)始進(jìn)行計(jì)算。

圖5 混合計(jì)算架構(gòu)Fig.5 Mixed computing architecture

2.3 維表關(guān)聯(lián)技術(shù)的緩存優(yōu)化

本節(jié)介紹大規(guī)模維表關(guān)聯(lián)計(jì)算環(huán)境下對(duì)數(shù)據(jù)源節(jié)點(diǎn)緩存和計(jì)算節(jié)點(diǎn)緩存的設(shè)計(jì)和優(yōu)化。

由于維表數(shù)據(jù)也是存在變化的，若每次都將讀取到的數(shù)據(jù)全部發(fā)送給計(jì)算節(jié)點(diǎn)，在更新時(shí)仍會(huì)造成較大的網(wǎng)絡(luò)傳輸開(kāi)銷并阻塞流數(shù)據(jù)的處理。本文參考數(shù)據(jù)庫(kù)操作記錄日志的思想，在數(shù)據(jù)更新時(shí)只分發(fā)需要修改的數(shù)據(jù)，降低網(wǎng)絡(luò)傳輸開(kāi)銷。為了確定數(shù)據(jù)更新的具體內(nèi)容，本文根據(jù)維表變化緩慢的特性，在數(shù)據(jù)源處建立了緩存機(jī)制緩存已分發(fā)數(shù)據(jù)記錄。在緩存機(jī)制的鍵值對(duì)中，Key 值由關(guān)聯(lián)所需主鍵列數(shù)據(jù)合并得出，Value 值則改為數(shù)組，存儲(chǔ)主鍵相同其他數(shù)據(jù)不同的多版本的維表數(shù)據(jù)。但緩存完整的維表數(shù)據(jù)會(huì)占用數(shù)據(jù)源算子過(guò)多的內(nèi)存，無(wú)法支持太大的維表。由于數(shù)據(jù)源并不需對(duì)數(shù)據(jù)進(jìn)行操作，故而將維表數(shù)據(jù)拼接成字符串后計(jì)算哈希值，并存入對(duì)應(yīng)的數(shù)組中，不保存原始數(shù)據(jù)。

每輪讀取維表數(shù)據(jù)時(shí)，將數(shù)據(jù)主鍵和哈希值進(jìn)行緩存，并根據(jù)上次緩存結(jié)果判斷數(shù)據(jù)分發(fā)行為，數(shù)據(jù)存在則跳過(guò)，數(shù)據(jù)不存在則向下游計(jì)算節(jié)點(diǎn)發(fā)送新增行為，具體算法如算法1 所示。首先通過(guò)調(diào)用關(guān)聯(lián)信息選擇函數(shù)構(gòu)建鍵值并構(gòu)建整條數(shù)據(jù)的哈希值，然后將鍵值數(shù)據(jù)和哈希值寫(xiě)入新緩存，最后將鍵值與舊緩存進(jìn)行比較，確定數(shù)據(jù)是否存在，存在則跳過(guò)數(shù)據(jù)并清理對(duì)應(yīng)舊緩存，不存在則發(fā)出新增行為請(qǐng)求。

算法1 源節(jié)點(diǎn)新數(shù)據(jù)分發(fā)算法

輸入：上一次分發(fā)所構(gòu)建的數(shù)據(jù)緩存，本次數(shù)據(jù)分發(fā)所構(gòu)建的數(shù)據(jù)緩存，待判斷數(shù)據(jù)。

輸出：無(wú)。

1.=buildKey();/*計(jì)算緩存主鍵*/

2.=Hash();/*計(jì)算維表哈希值*/

3.將與存入中;

4.If.()

5.If.().()

6.=“”;

7..().();

8.Else

9.Action=“ADD”;

10.End if

11.Else

12.Action=“ADD”;

13.End if

14.If Action==“ADD”;

15.將newData和Action 發(fā)送給下游計(jì)算節(jié)點(diǎn);

16.End if

在第一次數(shù)據(jù)分發(fā)時(shí)舊緩存的初始值為空，因此第一次將會(huì)分發(fā)所有數(shù)據(jù)。在數(shù)據(jù)讀取分發(fā)完成后，由于在數(shù)據(jù)讀取過(guò)程中已經(jīng)將讀取的數(shù)據(jù)和舊緩存進(jìn)行了匹配和刪除操作，仍存在于舊緩存的數(shù)據(jù)則全部是需要?jiǎng)h除的數(shù)據(jù)。此時(shí)執(zhí)行針對(duì)過(guò)期數(shù)據(jù)的數(shù)據(jù)刪除行為的分發(fā)，具體操作如算法2 所示。遍歷數(shù)據(jù)讀取完成后的舊緩存，針對(duì)舊緩存中的每一條數(shù)據(jù)生成數(shù)據(jù)刪除請(qǐng)求并發(fā)送給下游計(jì)算節(jié)點(diǎn)，完成過(guò)期數(shù)據(jù)清理。

算法2 源節(jié)點(diǎn)過(guò)期數(shù)據(jù)刪除算法

輸入：上一次分發(fā)所構(gòu)建的數(shù)據(jù)緩存。

輸出：無(wú)。

1.遍歷,獲取每一個(gè)對(duì)應(yīng)的列表;

2.遍歷列表,獲取存儲(chǔ)在舊緩存中的;

3.針對(duì)每一個(gè),發(fā)送=“”的數(shù)據(jù)刪除行為,通知下游計(jì)算節(jié)點(diǎn)刪除過(guò)期緩存;

4.清空舊緩存,釋放空間.

最后在添加和刪除請(qǐng)求都發(fā)送完成后將當(dāng)前緩存賦值給舊緩存，即可完成一輪數(shù)據(jù)緩存和分發(fā)。

在傳統(tǒng)的維表關(guān)聯(lián)計(jì)算中，對(duì)數(shù)據(jù)的緩存均為Key-Value 的形式，其中Key 值通過(guò)關(guān)聯(lián)的主鍵列計(jì)算得出，Value 值保存維表具體數(shù)據(jù)內(nèi)容。這種傳統(tǒng)的數(shù)據(jù)緩存模式，無(wú)法支持主鍵相同的多版本的維表數(shù)據(jù)緩存，進(jìn)而無(wú)法支持對(duì)歷史維表數(shù)據(jù)的全量緩存和查詢。

本文針對(duì)該問(wèn)題，在計(jì)算節(jié)點(diǎn)中提出了一種二層緩存策略。在原有的Key-Value 緩存模式下，對(duì)Value 格式進(jìn)行優(yōu)化，將Key 值相同的維表數(shù)據(jù)，轉(zhuǎn)換為Json 字符串，并以數(shù)組的形式存儲(chǔ)于Value 中，使緩存結(jié)構(gòu)支持歷史維表數(shù)據(jù)。同時(shí)相較于存儲(chǔ)完整的維表結(jié)構(gòu)，轉(zhuǎn)換為Json 字符串可以降低一定的內(nèi)存存儲(chǔ)需求。

在計(jì)算節(jié)點(diǎn)獲取數(shù)據(jù)的過(guò)程中，為了支持優(yōu)化后的數(shù)據(jù)源節(jié)點(diǎn)的數(shù)據(jù)分發(fā)，數(shù)據(jù)獲取算法也要進(jìn)行重新設(shè)計(jì)，具體算法如算法3 所示。對(duì)數(shù)據(jù)變更的行為進(jìn)行判斷，如果是增加數(shù)據(jù)（ADD）就將數(shù)據(jù)寫(xiě)入緩存，如果是刪除數(shù)據(jù)（DEL）就根據(jù)鍵值對(duì)緩存相關(guān)數(shù)據(jù)進(jìn)行刪除。

算法3 計(jì)算節(jié)點(diǎn)數(shù)據(jù)獲取算法

輸入：節(jié)點(diǎn)數(shù)據(jù)緩存，數(shù)據(jù)主鍵，數(shù)據(jù)文本，數(shù)據(jù)操作。

輸出：更新后的節(jié)點(diǎn)數(shù)據(jù)緩存。

1.If=“”

2.根據(jù)存儲(chǔ)數(shù)據(jù)在中;

3.Else

4.If=“”

5.根據(jù),刪除中數(shù)據(jù);

6.End if

7.End if

8.Return.

2.4 維表關(guān)聯(lián)技術(shù)的計(jì)算設(shè)計(jì)

維表關(guān)聯(lián)技術(shù)的計(jì)算設(shè)計(jì)分為兩部分：數(shù)據(jù)分區(qū)方式設(shè)計(jì)、數(shù)據(jù)計(jì)算模式設(shè)計(jì)。

傳統(tǒng)的維表關(guān)聯(lián)中，維表數(shù)據(jù)在各個(gè)計(jì)算節(jié)點(diǎn)間獨(dú)立存儲(chǔ)，因此流數(shù)據(jù)可以根據(jù)不同計(jì)算系統(tǒng)的分發(fā)策略進(jìn)行分發(fā)，在流經(jīng)計(jì)算節(jié)點(diǎn)時(shí)向遠(yuǎn)程數(shù)據(jù)庫(kù)查詢獲取維表數(shù)據(jù)。全局分發(fā)的維表關(guān)聯(lián)策略中，如果流數(shù)據(jù)分發(fā)規(guī)則與維表數(shù)據(jù)分發(fā)規(guī)則不匹配，則會(huì)導(dǎo)致關(guān)聯(lián)結(jié)果為空。

因此，為了優(yōu)化后的維表關(guān)聯(lián)可以正常執(zhí)行，將對(duì)流數(shù)據(jù)和維表數(shù)據(jù)的數(shù)據(jù)分發(fā)策略進(jìn)行重新設(shè)計(jì)，統(tǒng)一計(jì)算出關(guān)聯(lián)主鍵并對(duì)主鍵進(jìn)行哈希計(jì)算獲得對(duì)應(yīng)的數(shù)據(jù)分區(qū)，計(jì)算分區(qū)方式的算法如算法4 所示。第1 行根據(jù)輸入的記錄通過(guò)調(diào)用關(guān)聯(lián)信息選擇函數(shù)構(gòu)建鍵值，第2、3 行根據(jù)鍵值計(jì)算最終的數(shù)據(jù)分區(qū)。

算法4 Hash 分區(qū)算法

輸入：待分區(qū)的記錄，分區(qū)數(shù)量。

輸出：待分區(qū)記錄的分區(qū)編號(hào)。

1.key=()/*提取記錄的key*/

2.=.;

3.=%;

4.Return.

傳統(tǒng)的維表關(guān)聯(lián)計(jì)算，通過(guò)指定輸入數(shù)據(jù)和維表的主鍵列確定連接信息，輸出的是關(guān)聯(lián)以后的數(shù)據(jù)列集合。本文首先對(duì)數(shù)據(jù)緩存進(jìn)行了重新設(shè)計(jì)，支持了分布式的緩存策略以及多版本的數(shù)據(jù)緩存。為了適配對(duì)多版本數(shù)據(jù)的連接選擇問(wèn)題，本文將數(shù)據(jù)關(guān)聯(lián)計(jì)算模式進(jìn)行了重新的設(shè)計(jì)。將關(guān)聯(lián)邏輯和關(guān)聯(lián)鍵值選擇邏輯進(jìn)行了抽象，獨(dú)立出了用戶可自行定義和實(shí)現(xiàn)的關(guān)聯(lián)計(jì)算函數(shù)和關(guān)聯(lián)鍵值選擇函數(shù)。用戶在連接計(jì)算的基礎(chǔ)上，可以根據(jù)實(shí)際的計(jì)算需求，確定數(shù)據(jù)流和維表的數(shù)據(jù)關(guān)聯(lián)鍵值，并自定義關(guān)聯(lián)的計(jì)算輸出結(jié)果。

由于關(guān)聯(lián)計(jì)算函數(shù)每次的調(diào)用是傳入通過(guò)關(guān)聯(lián)信息選擇函數(shù)所獲取的全部版本維表數(shù)據(jù)，用戶可以做到對(duì)維表關(guān)聯(lián)的靈活處理，以支持指定關(guān)聯(lián)特定歷史版本、計(jì)算特定關(guān)系等需求。

在實(shí)際的生產(chǎn)生活場(chǎng)景中，一個(gè)典型的不是連接的關(guān)聯(lián)場(chǎng)景為商品關(guān)聯(lián)度計(jì)算。通過(guò)在計(jì)算函數(shù)處理輸入商品和歷史訂單中的存在該商品的訂單的相似關(guān)系，計(jì)算出與商品關(guān)聯(lián)的其他商品，從而獲得輸入商品的關(guān)聯(lián)商品。

3 實(shí)驗(yàn)分析

本章針對(duì)前文所提出的優(yōu)化的維表關(guān)聯(lián)技術(shù)在Apache Flink 進(jìn)行了實(shí)現(xiàn)，同時(shí)也實(shí)現(xiàn)了傳統(tǒng)的維表關(guān)聯(lián)技術(shù)。然后對(duì)比和驗(yàn)證了在不同流數(shù)據(jù)和維表數(shù)據(jù)規(guī)模下，優(yōu)化的維表關(guān)聯(lián)技術(shù)和傳統(tǒng)的維表關(guān)聯(lián)技術(shù)的效率差異。

3.1 編碼實(shí)現(xiàn)

編碼實(shí)現(xiàn)分為傳統(tǒng)的維表關(guān)聯(lián)實(shí)現(xiàn)與優(yōu)化后的維表關(guān)聯(lián)實(shí)現(xiàn)。

在Apache Flink 1.8.0 中，DataStream API 并沒(méi)有原生提供對(duì)維表關(guān)聯(lián)計(jì)算的支持。由于傳統(tǒng)的維表關(guān)聯(lián)本質(zhì)上還是流計(jì)算，本文根據(jù)計(jì)算邏輯，對(duì)流計(jì)算中的異步計(jì)算算子進(jìn)行了改造，添加的對(duì)數(shù)據(jù)庫(kù)查詢的支持和基于LRU（least recently used）策略的數(shù)據(jù)緩存機(jī)制。然后對(duì)該算子進(jìn)行了封裝，使算子支持維表的定義和讀取以及連接條件的設(shè)置。

優(yōu)化后的維表關(guān)聯(lián)基于Mixed API 進(jìn)行實(shí)現(xiàn)。通過(guò)設(shè)計(jì)新的雙輸入算子，使一個(gè)輸入為流數(shù)據(jù)，一個(gè)輸入為維表數(shù)據(jù)，做到對(duì)混合計(jì)算的支持。然后單獨(dú)設(shè)計(jì)了維表數(shù)據(jù)的數(shù)據(jù)源方法，并對(duì)系統(tǒng)中原有的數(shù)據(jù)分發(fā)過(guò)程進(jìn)行改造以適應(yīng)新的數(shù)據(jù)分發(fā)邏輯。最后對(duì)整個(gè)過(guò)程進(jìn)行了封裝，對(duì)數(shù)據(jù)連接信息選擇函數(shù)和維表關(guān)聯(lián)計(jì)算函數(shù)進(jìn)行了抽象和默認(rèn)邏輯的實(shí)現(xiàn)。對(duì)于緩存，依托Mixed API 的特性，在批數(shù)據(jù)計(jì)算和分發(fā)完成前，流數(shù)據(jù)處理是阻塞的，保證了維表緩存的完整性。

3.2 數(shù)據(jù)集

本文針對(duì)維表關(guān)聯(lián)這一實(shí)際生產(chǎn)活動(dòng)中所遇到的計(jì)算類型，使用了阿里巴巴“雙十一”中的真實(shí)生產(chǎn)場(chǎng)景進(jìn)行性能測(cè)試。該場(chǎng)景在數(shù)據(jù)脫敏和業(yè)務(wù)簡(jiǎn)化后，共涉及3 個(gè)數(shù)據(jù)表：用戶信息表、商品信息表、用戶點(diǎn)擊數(shù)據(jù)表。本實(shí)驗(yàn)根據(jù)數(shù)據(jù)表格式在MySQL數(shù)據(jù)庫(kù)中建立了對(duì)應(yīng)數(shù)據(jù)表并進(jìn)行相應(yīng)的數(shù)據(jù)生成，數(shù)據(jù)表數(shù)據(jù)記錄數(shù)及數(shù)據(jù)容量如表1所示。同時(shí)根據(jù)該表同比例構(gòu)建了10 萬(wàn)條用戶信息數(shù)據(jù)和100 萬(wàn)條用戶信息數(shù)據(jù)的對(duì)應(yīng)數(shù)據(jù)表，用于進(jìn)行對(duì)比測(cè)試。查詢所需的鍵值列均構(gòu)建了索引，用于保證異步訪問(wèn)時(shí)的查詢效率。

表1 數(shù)據(jù)表大小Table 1 Size of data table

該生產(chǎn)場(chǎng)景的具體業(yè)務(wù)為對(duì)用戶進(jìn)行廣告投放，簡(jiǎn)化業(yè)務(wù)流程為：

（1）向推薦系統(tǒng)流入用戶ID；

（2）系統(tǒng)根據(jù)用戶ID 獲取用戶一天內(nèi)的商品點(diǎn)擊數(shù)據(jù)和用戶信息數(shù)據(jù)，通過(guò)機(jī)器學(xué)習(xí)算法計(jì)算出推薦商品ID；

（3）通過(guò)推薦商品ID 獲取商品具體信息并返回。

本實(shí)驗(yàn)為專注于測(cè)試維表關(guān)聯(lián)效率，簡(jiǎn)化了推薦計(jì)算部分，只保留維表關(guān)聯(lián)部分，修改后的業(yè)務(wù)邏輯如下：

（1）向測(cè)試系統(tǒng)流入用戶ID；

（2）根據(jù)用戶ID，擴(kuò)展出用戶具體信息和用戶點(diǎn)擊商品ID；

（3）對(duì)每個(gè)用戶點(diǎn)擊商品ID 追加一個(gè)隨機(jī)數(shù)作為推薦商品ID；

（4）通過(guò)推薦商品ID 獲取商品具體信息并返回。

3.3 實(shí)驗(yàn)環(huán)境

本文所描述的相關(guān)技術(shù)細(xì)節(jié)，均在Flink 1.8.0 中進(jìn)行實(shí)現(xiàn)，采用Java 語(yǔ)言進(jìn)行編寫(xiě)。實(shí)驗(yàn)的運(yùn)行環(huán)境及軟硬件環(huán)境如下。

（1）硬件環(huán)境。實(shí)驗(yàn)采用的分布式環(huán)境由4 臺(tái)服務(wù)器組成，1 臺(tái)主節(jié)點(diǎn)，3 臺(tái)從節(jié)點(diǎn)。從節(jié)點(diǎn)采用的服務(wù)器配置為：①CPU Intel Xeon E5-2603 V4 *2，核心數(shù)目6 核心；主頻1.7 GHz。②內(nèi)存64 GB，主頻2 400 MHz。③硬盤(pán)400 GB SSD。主節(jié)點(diǎn)配置為：①CPU Intel Xeon E5-2603 V4 *2，核心數(shù)目6 核心；主頻1.7 GHz。②內(nèi)存128 GB，主頻2 400 MHz。③硬盤(pán)400 GB SSD。

（2）軟件環(huán)境。①操作系統(tǒng)Centos 7；②存儲(chǔ)環(huán)境MySQL 5.6.45；③Apache Flink 版本1.8.0，JDK 版本1.8.0。

3.4 實(shí)驗(yàn)結(jié)果與分析

本文通過(guò)使用阿里巴巴所提供的advertising測(cè)試工具，通過(guò)修改其中業(yè)務(wù)計(jì)算部分的邏輯來(lái)進(jìn)行測(cè)試。該測(cè)試會(huì)在計(jì)算開(kāi)始和結(jié)束時(shí)對(duì)數(shù)據(jù)添加時(shí)間戳并寫(xiě)入Redis，然后通過(guò)對(duì)Redis 中的數(shù)據(jù)進(jìn)行分析獲取相關(guān)統(tǒng)計(jì)結(jié)果。本實(shí)驗(yàn)所有計(jì)算的并行度固定為12，忽略維表全緩存的冷啟動(dòng)時(shí)間。生成100 萬(wàn)條流數(shù)據(jù)作為實(shí)驗(yàn)1，生成1 000 萬(wàn)條流數(shù)據(jù)作為實(shí)驗(yàn)2，對(duì)比流數(shù)據(jù)的數(shù)據(jù)量和維表的數(shù)據(jù)量對(duì)計(jì)算吞吐量和延遲的影響。

（1）吞吐量對(duì)比分析

吞吐量（throughput）是指單位時(shí)間內(nèi)計(jì)算引擎所處理的數(shù)據(jù)量，反映了系統(tǒng)的負(fù)載能力。吞吐量越高，系統(tǒng)的極限負(fù)載就越大，有助于在單位時(shí)間內(nèi)處理更多的數(shù)據(jù)。本實(shí)驗(yàn)通過(guò)計(jì)算在Redis 中單位時(shí)間寫(xiě)入的數(shù)據(jù)量來(lái)統(tǒng)計(jì)吞吐，吞吐量計(jì)算公式如下：

其中，代表當(dāng)前讀到的數(shù)據(jù)編號(hào)，表示前一次讀到的數(shù)據(jù)編號(hào)，表示讀取當(dāng)前數(shù)據(jù)表編號(hào)所對(duì)應(yīng)的時(shí)間，表示讀取上一次數(shù)據(jù)編號(hào)所對(duì)應(yīng)的時(shí)間。

在實(shí)驗(yàn)1 中，不同規(guī)模的維表數(shù)據(jù)量所產(chǎn)生的數(shù)據(jù)平均吞吐量如圖6 所示。實(shí)驗(yàn)結(jié)果表明數(shù)據(jù)全量緩存可以有效提升計(jì)算吞吐量，在三種維表規(guī)模下，均有10 倍的提升。異步連接方式隨著維表數(shù)據(jù)增大，吞吐量呈現(xiàn)下降趨勢(shì)。經(jīng)分析得出，這是由于異步連接所構(gòu)建的緩存沒(méi)有被命中，還有大量查詢打入了數(shù)據(jù)庫(kù)中。數(shù)據(jù)查詢所用的時(shí)間延長(zhǎng)了每條數(shù)據(jù)的處理時(shí)間，使單位時(shí)間內(nèi)可以處理的數(shù)據(jù)量減少。

圖6 實(shí)驗(yàn)1 平均吞吐量統(tǒng)計(jì)Fig.6 Statistics of experiment 1 mean throughput

在實(shí)驗(yàn)2 中，不同規(guī)模的維表數(shù)據(jù)量所產(chǎn)生的數(shù)據(jù)平均吞吐量如圖7 所示。與實(shí)驗(yàn)1 相同，全緩存方式吞吐量統(tǒng)計(jì)結(jié)果相似，說(shuō)明數(shù)據(jù)處理效率已經(jīng)和流入數(shù)據(jù)量無(wú)關(guān)，增大并行度可以進(jìn)一步提高吞吐量。隨著維表數(shù)據(jù)增大，異步連接吞吐量趨于穩(wěn)定。這種現(xiàn)象的產(chǎn)生是由于流數(shù)據(jù)量增大，短時(shí)間內(nèi)查詢到的維表數(shù)據(jù)已經(jīng)全部加載到了本地緩存中。異步計(jì)算方式吞吐量仍處于較低水平是異步連接機(jī)制并發(fā)度不足導(dǎo)致的，然而過(guò)高的并發(fā)度會(huì)在計(jì)算初期直接導(dǎo)致存儲(chǔ)系統(tǒng)連接崩潰。

圖7 實(shí)驗(yàn)2 平均吞吐量統(tǒng)計(jì)Fig.7 Statistics of experiment 2 mean throughput

（2）延遲對(duì)比分析

延遲（latency）是指數(shù)據(jù)從進(jìn)入計(jì)算系統(tǒng)到真正被處理并輸出所使用的時(shí)間，單位為毫秒（ms）。延遲的大小反映了系統(tǒng)對(duì)數(shù)據(jù)的處理速度和實(shí)時(shí)性。實(shí)時(shí)推薦的廣告系統(tǒng)對(duì)延遲有較高的需求，延遲越小，用戶體驗(yàn)越好。本實(shí)驗(yàn)通過(guò)在Redis中記錄的每條數(shù)據(jù)的起止時(shí)間戳來(lái)計(jì)算延遲，延遲計(jì)算公式如下：

表示數(shù)據(jù)被處理完成的時(shí)間，指數(shù)據(jù)流入系統(tǒng)后被標(biāo)記的時(shí)間。

在實(shí)驗(yàn)1 中，不同規(guī)模的維表數(shù)據(jù)量所產(chǎn)生的數(shù)據(jù)平均延遲如圖8 所示。全緩存模式下，數(shù)據(jù)都已經(jīng)寫(xiě)入到內(nèi)存中，沒(méi)有數(shù)據(jù)I/O 開(kāi)銷，因此平均延遲沒(méi)有太大的起伏。異步連接的計(jì)算模式由于前期沒(méi)有維表數(shù)據(jù)的緩存，需要與數(shù)據(jù)庫(kù)進(jìn)行大量的交互，隨著維表規(guī)模的增大，單次查詢的處理時(shí)間越來(lái)越高，導(dǎo)致平均延遲越來(lái)越大。

圖8 實(shí)驗(yàn)1 平均延遲Fig.8 Experiment 1 mean delay

在實(shí)驗(yàn)2 中，不同規(guī)模的維表數(shù)據(jù)量所產(chǎn)生的數(shù)據(jù)平均延遲如圖9 所示。全緩存模式下，延遲相對(duì)于實(shí)驗(yàn)1 有所增加是由于為了平攤內(nèi)存壓力，多次維表關(guān)聯(lián)計(jì)算間沒(méi)有共享計(jì)算槽，數(shù)據(jù)分發(fā)需要經(jīng)歷序列化與反序列化。過(guò)高的吞吐量和數(shù)據(jù)量導(dǎo)致數(shù)據(jù)傳輸壓力過(guò)大，從而產(chǎn)生阻塞。同時(shí)由于緩存機(jī)制是手動(dòng)實(shí)現(xiàn)的，沒(méi)有對(duì)接Flink 計(jì)算系統(tǒng)的背壓機(jī)制，導(dǎo)致計(jì)算節(jié)點(diǎn)數(shù)據(jù)過(guò)量積壓。異步連接模式由于計(jì)算前期的大量I/O 已經(jīng)暫時(shí)緩存了所有需要的維表數(shù)據(jù)。多次維表關(guān)聯(lián)共享了計(jì)算槽，數(shù)據(jù)傳輸不需要經(jīng)歷序列化和反序列化過(guò)程，直接發(fā)給下游計(jì)算節(jié)點(diǎn)。同時(shí)由于Apache Flink 的背壓機(jī)制，數(shù)據(jù)實(shí)際被標(biāo)記的流入系統(tǒng)的時(shí)間可能晚于數(shù)據(jù)實(shí)際產(chǎn)生的時(shí)間。

圖9 實(shí)驗(yàn)2 平均延遲Fig.9 Experiment 2 mean delay

4 總結(jié)

本文對(duì)面向分布式流計(jì)算的維表關(guān)聯(lián)技術(shù)進(jìn)行了研究和優(yōu)化。與現(xiàn)有的大數(shù)據(jù)計(jì)算平臺(tái)的關(guān)聯(lián)機(jī)制相比，首先提供了一套可以實(shí)現(xiàn)流批處理一體化的數(shù)據(jù)處理邏輯，其次提供了一種可以支持縱向擴(kuò)展的維表關(guān)聯(lián)數(shù)據(jù)全緩存方案，并對(duì)數(shù)據(jù)分發(fā)進(jìn)行了優(yōu)化。大量實(shí)驗(yàn)結(jié)果表明，該優(yōu)化技術(shù)可以有效提高全緩存條件下對(duì)維表數(shù)據(jù)的加載量，在高速處理環(huán)節(jié)最多可以提高10 倍的吞吐量，顯著降低了數(shù)據(jù)的查詢壓力，提高了任務(wù)的并行度。在維表數(shù)據(jù)量較大的情況下，異步查詢方式在高并行度時(shí)會(huì)有很大概率導(dǎo)致數(shù)據(jù)庫(kù)假死，并且由于數(shù)據(jù)I/O 的關(guān)系，無(wú)法做到很高的吞吐量。普通全量緩存模式則直接會(huì)導(dǎo)致系統(tǒng)產(chǎn)生內(nèi)存溢出異常。本文所提出的維表關(guān)聯(lián)技術(shù)，支持在高并行度下運(yùn)行，并且對(duì)數(shù)據(jù)庫(kù)造成的讀寫(xiě)壓力不隨并行度提高而提升。