Mapsidejoin是什麼？最詳細的應用介紹在這裏

咱們知道數據分析的第一步是準備數據，因此在前面的課程裏，咱們介紹了元數據。今天這篇文章，主要介紹大數據量組合數據集在永洪中的應用實例：Mapsidejoin。

什麼是Mapsidejoin？按照字面意思，Mapsidejoin就是M—節點—組合 。在瞭解Mapsidejoin以前，首先咱們要了解一下MapReduce模型以及產品的四個節點CNMR的做用，經過MapReduce模型中，Mapsidejoin和Reducesidejoin的對比，瞭解在大數據量數據集進行組合時，Mapsidejoin的優勢。

Yonghong中集羣節點介紹

Client Node —C節點是客戶端訪問節點，客戶經過訪問C節點來提交任務。

Naming Node —N節點至關於集羣的大腦，除了監控集羣其餘節點外，還要收集客戶經過C節點提交的任務進行分配等等。

Map Node — M節點是存儲數據文件的節點

Reduce Node —R節點是用來作彙總計算的計算

MapReduce模型介紹

百度百科對MapReduce的定義感受仍是比較全面的，簡單的歸納一下：MapReduce是一個基於集羣的計算平臺，是一個簡化分佈式編程的計算框架，是一個將分佈式計算抽象爲Map和Reduce兩個階段的編程模型。而Yonghong在進行組合數據集計算時用到的就是MapReduce模型。

適用場景:多M節點的分佈式集羣，大數據量數據的組合包括大表join小表，大表join大表。

一、爲何要使用Mapsidejoin
在MapReduce模型中，對於組合計算能夠分爲Map-side-join 和Reduce-side-join兩種，下面用一個例子簡單介紹一下：

假設咱們有兩張表：表1人員表爲大表，表2地區表爲小表，以下圖所示：

咱們想經過id把表1的name和表2的Address鏈接起來 ，那麼就須要以id爲鏈接列，作inner join， 鏈接對應的id爲id=1,id=2,id=3,id=4。

假如如今咱們的集羣裏面有Map1和Map2兩個Map節點，那麼當咱們將表1和表2入集市之後，通過數據的拆分存儲，咱們可能會出現如下狀況：

► 狀況1：能夠進行Mapsidejoin

如上圖所示，通過拆分後的表1和表2，鏈接列id=1-4 對應的數據存放在了同一個節點，在join時，Map節點會檢測鏈接列數據是否已經完成對應，若是此時數據對應後就能夠在Map節點上進行join，Map節點將join後的結果發送給Reduce節點，Reduce節點將結果進行彙總計算就能夠了。

► 狀況2：不能進行Mapsidejoin時會進行Reducesidejoin

上圖所示， 通過拆分存儲後的數據顯示錶1的id1，2存放在了Map1節點；而表2的id1，2 存放在了Map2 節點上面；這個時候在join時Map節點檢測到對應的數據不在同一個節點上，就會將全部的數據拿到Reduce節點從新進行全量的join。

以上兩種狀況簡單的說明了Mapsidejoin 和 Reducesidejoin。

二、Mapsidejoin和Reducesidejoin的優勢

Map端join的好處是能夠提早過濾掉join中須要排除的大量數據，會減小數據的傳輸，所以Mapsidejoin 適用於大數據量join的場景。
Reduce端作join優勢是比較靈活，缺點是須要作大量數據傳輸和整個join過程都比較耗時，所以Reducesidejoin適用於小數據量的場景。
此外， 因爲當數據量巨大時，作join是很是消耗資源的，對於非Mapsidejoin的形式，不管是直連數據庫壓到數據庫作join，仍是數據集市的形式去作Reducesidejoin，都會對節點形成極大壓力，容易形成產品很卡的狀況，再嚴重就會形成OOM，宕機等。因此咱們須要使用Mapsidejoin來規避這種場景， 當數據量大的時候，咱們能夠部署多個M節點，經過將數據先導入集市，存放在集羣中的多個M節點，而後在M節點上面進行計算來實現Mapsidejoin，這樣能把C,R節點的壓力平均分到M節點上面，解決大數據量join可能帶來的使用壓力，讓資源的利用更加高效。

那麼咱們怎麼實現Mapsidejoin呢 ？如何保證數據通過拆分後，鏈接列對應的數據必定存放在同一個Map節點上面呢？下面介紹永洪Mapsidejoin的兩種實現方式。

永洪Mapsidejoin的兩種形式

事實表——維度表

適用場景（大表join小表）

在分佈式系統中，當有星形數據（一個大表，若干個小表）須要join的時候，能夠將小表的數據複製到每一個Map節點，執行Mapsidejoin, 而無須到Reduce節點進行鏈接操做，從而提高錶鏈接的效率。

在MPP集市中，咱們將大表以普通的增量導入形式入集市，將全部小表在增量導入時勾選維度表的形式，以下圖所示：

此時勾選維度表的小表會全量生成在每個Map節點。

以上面表1人員表，表2地區表的爲例：表1增量導入正常拆分，表2以增量導入維度表形式入集市。

如圖所示，此時在每個M節點上，由於表2全量存儲，因此表1和表2對應的id數據就必定能在同一個M節點找到。

可是事實表——維度表的形式也有侷限性，好比兩個以上的大表作join時，就須要將其中的一個或多個大表，存放到每個M節點上，大數據量的大表進行維度表存儲原本就會加大資源消耗，並且大表做爲維度表，沒法壓到內存中進行計算，所以沒法使用Mapsidejoin。

因此針對這種狀況，咱們採起分片列來支持大表join大表的使用場景。

分片列

適用場景（大表join大表）

在8.5.1版本以前，咱們只能用維度表join事實表的形式去作Mapsidejoin，在一些用戶場景中，沒法提早進行數據表關聯作成寬表模型入集市，同時也不知足Mapsidejoin（或broadcast join）計算的要求，所以須要在集市中作分佈式join的計算支持。

具體場景有：

1）業務上須要，好比：部分彙總後再進行關聯，某時間段內產品銷售額大於特定值時的產品報修批次分佈；特定值進行關聯，選擇某個時間段裏面最後出現的數據和另外的表關聯；自關聯，本月數據和上月數據關聯計算等等；這些場景下（通常是雪花模型或更復雜）若是提早join會致使數據膨脹，從而產生很是多的冗餘數據，但實際使用時由於有過濾條件則不會產生太多數據；

2）數據量較大的事實表須要頻繁增量更新，且全量數據join成寬表入集市的時間開銷太大；

3）自服務場景下，是否要關聯表，以及關聯什麼字段存在不肯定性，須要保留原始細節表來進行自助查詢。

分片列的Mapsidejoin實現邏輯其實和上面狀況1的圖片相似。

咱們經過增量導入分片列的形式將表1和表2的關聯列使用hash算法，保證兩張表的id對應的數據通過拆分後必定會存儲在同一個Map節點上面，這樣通過拆分的大表就能夠壓到內存中計算。

操做步驟：

一、將須要組合的大表以增量導入的形式入集市，同時須要勾選分片列屬性，選擇分片列爲連接列。好比表1在增量導入集市時要勾選分片列爲id ，表2也須要一樣的操做。

二、將生成的數據集市數據集進行組合，Map節點在檢測數據時會自動使用Mapsidejoin形式鏈接。

小結

必定要記住使用Mapsidejoin的前提是分佈式集羣多M節點且大數據量數據集市的數據集作join。

最後咱們用一張圖片來簡單的回顧一下Mapsidejoin的兩種形式。

大表join大表用分片列
大表join小表用事實表——維度表

以上就是咱們對於Mapsidejoin的應用介紹。