ＨａｄｏｏｐＤＢ的核心思想是利用Ｈａｄｏｏｐ作為調度層和網絡溝通層，關系數據庫作為執行引擎，盡可能地將查詢壓入數據庫層處理，目標是想借助Ｈａｄｏｏｐ框架來獲得較好的容錯性和對異構環境的支持；通過將查詢盡可能推入數據庫中執行來獲得關系數據庫的性能優勢，ＨａｄｏｏｐＤＢ的思想是深遠的，但目前尚無應用案例，原因在于：
（１）其數據預處理代價過高：數據需要進行兩次分解和一次數據庫加載操作后才能使用；
（２）將查詢推向數據庫層只是少數情況，大多數情況下，查詢仍由Ｈｉｖｅ完成，因為數據倉庫查詢往往涉及多表連接，由于連接的復雜性，難以做到在保持連接數據局部性的前提下將參某種模式劃分；
（３）維護代價過高，不僅要維護Ｈａｄｏｏｐ系統，還要維護每個數據庫節點；
（４）目前尚不支持數據的動態劃分，需要手工方式將數據一次性劃分好，總的來說，ＨａｄｏｏｐＤＢ在某些情況下，可以同時實現關系數據庫的高性能特性和ＭａｐＲｅｄｕｃｅ的擴展性、容錯性，但同時也喪失了關系數據庫和ＭａｐＲｅｄｕｃｅ的某些優點，比如ＭａｐＲｅｄｕｃｅ較低的預處理代價和維護代價、關系數據庫的動態數據重分布等。
Ｖｅｒｔｉｃａ采用的是共存策略：根據Ｈａｄｏｏｐ和Ｖｅｒｔｉｃａ各自的處理優勢，對數據處理任務進行劃分，比如Ｈａｄｏｏｐ負責非結構化數據的處理，Ｖｅｒｔｉｃａ負責結構化數據的處理；Ｈａｄｏｏｐ負責耗時的批量復雜處理，Ｖｅｒｔｉｃａ負責高性能的交互式查詢等，從而將兩者結合起來，Ｖｅｒｔｉｃａ實際采用的是兩套系統，同時支持在ＭａｐＲｅｄｕｃｅ任務中直接訪問Ｖｅｒｔｉｃａ數據庫中的數據，由于結構化數據仍在Ｖｅｒｔｉｃａ中處理，在處理結構化大數據上的查詢分析時，仍面臨擴展性問題；如果將查詢推向Ｈａｄｏｏｐ進行，又將面臨性能問題，因此，Ｖｅｒｔｉｃａ的擴展性問題和Ｈａｄｏｏｐ的性能問題在該系統中共存。
與前兩者相比，Ｔｅｒａｄａｔａ的集成相對簡單，Ｔｅｒａｄａｔａ采用了存儲層的整合：ＭａｐＲｅｄｕｃｅ任務可以從Ｔｅｒａｄａｔａ數據庫中讀取數據，Ｔｅｒａｄａｔａ數據庫也可以從Ｈａｄｏｏｐ分布式文件系統上讀取數據，同樣，Ｔｅｒａｄａｔａ和Ｈａｄｏｏｐ各自的根本性問題都未解決。
６ 研究現狀
對并行數據庫來講，其最大問題在于有限的擴展能力和待改進的軟件級容錯能力；ＭａｐＲｅｄｕｃｅ的最大問題在于性能，尤其是連接操作的性能；混合式架構的關鍵是，如何能盡可能多地把工作推向合適的執行引擎（并行數據庫或ＭａｐＲｅｄｕｃｅ），本節對近年來在這些問題上的研究做一分析和歸納。
６．１ 并行數據庫擴展性和容錯性研究
華盛頓大學在文獻［２３］中提出了可以生成具備容錯能力的并行執行計劃優化器，該優化器可以依靠輸入的并行執行計劃、各個操作符的容錯策略及查詢失敗的期望值等，輸出一個具備容錯能力的并行執行計劃，在該計劃中，每個操作符都可以采取不同的容錯策略，在失敗時僅重新執行其子操作符（在某節點上運行的操作符）的任務來避免整個查詢的重新執行。
ＭＩＴ于２０１０年設計的Ｏｓｐｒｅｙ系統基于維表在各個節點全復制、事實表橫向切分并冗余備份的數據分布策略，將一星型查詢劃分為眾多獨立子查詢，每個子查詢在執行失敗時都可以在其備份節點上重新執行，而不用重做整個查詢，使得數據倉庫查詢獲得類似ＭａｐＲｅｄｕｃｅ的容錯能力，數據倉庫擴展性方面的研究較少，中國人民大學的ＬｉｎｅａｒＤＢ原型屬于這方面的研究，詳細參見７．１節。
６．２ＭａｐＲｅｄｕｃｅ性能優化研究
ＭａｐＲｅｄｕｃｅ的性能優化研究集中于對關系數據庫的先進技術和特性的移植上。
Ｆａｃｅｂｏｏｋ和俄亥俄州立大學合作，將關系數據庫的混合式存儲模型應用于Ｈａｄｏｏｐ平臺，提出了ＲＣＦｉｌｅ存儲格式。與之不同，文獻［２６］將列存儲技術引入Ｈａｄｏｏｐ平臺，Ｈａｄｏｏｐ＋＋系統運用了傳統數據庫的索引技術，并通過分區數據并置（ＣｏＰａｒｔｉｔｉｏｎ）的方式來提升性能，文獻［２８２９］基于ＭａｐＲｅｄｕｃｅ實現了以流水線方式在各個操作符間傳遞數據，從而縮短了任務執行時間；在線聚集（ｏｎｌｉｎｅａｇｇｒｅｇａｔｉｏｎ）的操作模式使得用戶可以在查詢執行過程中看到部分較早返回的結果，兩者的不同之處在于前者仍基于ｓｏｒｔｍｅｒｇｅ方式來實現流水線，只是將排序等操作推向了ｒｅｄｕｃｅｒ，部分情況下仍會出現流水線停頓的情況；而后者利用ｈａｓｈ方式來分布數據，能實現更好的并行流水線操作，文獻［３０］提出了ＭＲＳｈａｒｅ架構，對批量查詢進行轉換，將可共享掃描、共享Ｍａｐ輸出結果等的一組任務合并為一個，以提升性能，新加坡國立大學對影響Ｈａｄｏｏｐ性能的因素做了深入分析，并提出了５項有效的優化技術，使得Ｈａｄｏｏｐ的性能提升了近３倍，逼近關系數據庫的性能。
近年的研究熱點是基于ＭａｐＲｅｄｕｃｅ的連接操作的性能優化，文獻［３１］對ＭａｐＲｅｄｕｃｅ平臺的兩表連接算法做了總結，提出了Ｍａｐ端連接、Ｒｅｄｕｃｅ端連接及廣播式連接等算法，文獻［３２］對ＭａｐＲｅｄｕｃｅ框架進行了擴展，在Ｒｅｄｕｃｅ步驟后添加了一Ｍｅｒｇｅ步驟來完成連接操作，提出的ＭａｐＲｅｄｕｃｅＭｅｒｇｅ框架可以同時處理兩個異構數據源的數據，對于多表連接，當前主流的研究集中于僅通過一個任務來完成連接操作，文獻提出了一對多復制的方法，在Ｍａｐ階段結束后，為保證連接操作的局部性，元組會被復制到多個節點，但在節點數和數據量增大的情況下，會帶來Ｉ／Ｏ量及網絡傳輸量的巨大增長，Ｌｌａｍａ通過預排序和按連接屬性劃分數據的方式來降低星型連接的代價，但要付出可觀的預處理代價和空間代價，不同于以上等值連接優化，文獻［３６］提出了針對任意連接條件的優化模型，以上連接方式都是先執行連接，然后在連接后的數據上執行聚集操作，而中國人民大學的Ｄｕｍｂｏ系統卻采用了另一種更適應于ＭａｐＲｅｄｕｃｅ平臺的思路：先執行過濾聚集操作，再基于聚集的數據執行連接，詳細參考７．２節。
６．３ＨａｄｏｏｐＤＢ的改進
ＨａｄｏｏｐＤＢ于２０１１年針對其架構提出了兩種連接優化技術和兩種聚集優化技術。
兩種連接優化的核心思想都是盡可能地將數據的處理推入數據庫層執行，第１種優化方式是根據表與表之間的連接關系，通過數據預分解，使參與連接的數據盡可能分布在同一數據庫內（參照分解法），從而實現將連接操作下壓進數據庫內執行，該算法的缺點是應用場景有限，只適用于鏈式連接，第２種連接方式是針對廣播式連接而設計的，在執行連接前，先在數據庫內為每張參與連接的維表建立一張臨時表，使得連接操作盡可能在數據庫內執行，該算法的缺點是較多的網絡傳輸和磁盤Ｉ／Ｏ操作。
兩種聚集優化技術分別是連接后聚集和連接前聚集，前者是執行完Ｒｅｄｕｃｅ端連接后，直接對符合條件的記錄執行聚集操作；后者是將所有數據先在數據庫層執行聚集操作，然后基于聚集數據執行連接操作，并將不符合條件的聚集數據做減法操作，該方式適用的條件有限，主要用于參與連接和聚集的列的基數相乘后小于表記錄數的情況。
總的來看，ＨａｄｏｏｐＤＢ的優化技術大都局限性較強，對于復雜的連接操作（如環形連接等）仍不能下推至數據庫層執行，并未從根本上解決其性能問題。
７ ＭａｐＲｅｄｕｃｅ和關系數據庫技術的融合
綜上所述，當前研究大都集中于功能或特性的移植，即從一個平臺學習新的技術，到另一平臺重新實現和集成，未涉及執行核心，因此也沒有從根本上解決大數據分析問題，鑒于此，中國人民大學高性能數據庫實驗室的研究小組采取了另一種思路：從數據的組織和查詢的執行兩個核心層次入手，融合關系數據庫和ＭａｐＲｅｄｕｃｅ兩種技術，設計高性能的可擴展的抽象數據倉庫查詢處理框架，該框架在支持高度可擴展的同時，又具有關系數據庫的性能，我們團隊嘗試過兩個研究方向：
（１）借鑒ＭａｐＲｅｄｕｃｅ的思想，使ＯＬＡＰ查詢的處理能像ＭａｐＲｅｄｕｃｅ一樣高度可擴展（ＬｉｎｅａｒＤＢ原型）；
（２）利用關系數據庫的技術，使ＭａｐＲｅｄｕｃｅ在處理ＯＬＡＰ查詢時，逼近關系數據庫的性能（Ｄｕｍｂｏ原型）。
７．１ ＬｉｎｅａｒＤＢ
ＬｉｎｅａｒＤＢ①原型系統沒有直接采用基于連接的星型模型（雪花模型），而是對其進行了改造，設計了擴展性更好的、基于掃描的無連接雪花模型ＪＦＳＳ（ＪｏｉｎＦｒｅｅＳｎｏｗｆｌａｋｅＳｃｈｅｍａ），該模型的設計借鑒了泛關系模型的思想，采用層次編碼技術［４０］將維表層次信息壓縮進事實表，使得事實表可以獨立執行維表上的謂詞判斷、聚集等操作，從而使連接的數據在大規模機群上實現局部性，消除了連接操作，圖４是一個星型模型和無連接雪花模型的對應示意圖。
在執行層次上，ＬｉｎｅａｒＤＢ吸取了ＭａｐＲｅｄｕｃｅ處理模式的設計思想，將數據倉庫查詢的處理抽象為Ｔｒａｎｓｆｏｒｍ、Ｒｅｄｕｃｅ、Ｍｅｒｇｅ３個操作（ＴＲＭ執行模型）：
（１）Ｔｒａｎｓｆｏｒｍ，主節點對查詢進行預處理，將查詢中作用于維表的操作（主要是謂詞判斷，ｇｒｏｕｐｂｙ聚集操作等）轉換為事實表上的操作；
（２）Ｒｅｄｕｃｅ，每個數據節點并行地掃描、聚集本地數據，然后將處理結果返回給主節點；
（３）Ｍｅｒｇｅ，主節點對各個數據節點返回的結果進行合并，并執行后續的過濾、排序等操作，基于ＴＲＭ執行模型，查詢可以劃分為眾多獨立的子任務在大規模機群上并行執行，執行過程中，任何失敗子任務都可以在其備份節點重新執行，從而獲得較好的容錯能力。ＬｉｎｅａｒＤＢ的執行代價主要取決于對事實表的Ｒｅｄｕｃｅ（主要是掃描）操作，因此，ＬｉｎｅａｒＤＢ可以獲得近乎線性的大規模可擴展能力。
實驗表明，其性能比ＨａｄｏｏｐＤＢ至少高出一個數量級。
ＬｉｎｅａｒＤＢ的擴展能力、容錯能力和高性能在于其巧妙地結合了關系數據庫技術（層次編碼技術、泛關系模式）和ＭａｐＲｅｄｕｃｅ處理模式的設計思想，由此，可以看出，結合方式的不同可以導致系統能力的巨大差異。
７.２Ｄｕｍｂｏ
Ｄｕｍｂｏ的核心思想是根據ＭａｐＲｅｄｕｃｅ的“過濾－＞聚集”的處理模式，對ＯＬＡＰ查詢的處理進行改造，使其適應于ＭａｐＲｅｄｕｃｅ框架，Ｄｕｍｂｏ采用了類似于ＬｉｎｅａｒＤＢ的數據組織模式———利用層次編碼技術將維表信息壓縮進事實表，區別在于Ｄｕｍｂｏ采用了更加有效的編碼方式，并針對Ｈａｄｏｏｐ分布式文件系統的特點對數據的存儲進行了優化。
在執行層次上，Ｄｕｍｂｏ對ＭａｐＲｅｄｕｃｅ框架進行了擴展，設計了新的ＯＬＡＰ查詢處理框架———ＴＭＲＰ（Ｔｒａｎｓｆｏｒｍ－＞Ｍａｐ－＞Ｒｅｄｕｃｅ－＞Ｐｏｓｔｐｒｏｃｅｓｓ）處理框架（如圖５所示），在該框架中，主節點首先對查詢進行轉換，生成一個ＭａｐＲｅｄｕｃｅ任務來執行查詢，該任務在Ｍａｐ階段以流水線方式掃描、聚集本地數據，并只將本地的聚集數據傳至Ｒｅｄｕｃｅ階段，來進行數據的合并及聚集、排序等操作，在Ｐｏｓｔｐｒｏｃｅｓｓ階段，主節點在數據節點上傳的聚集數據之上執行連接操作，實驗表明，Ｄｕｍｂｏ性能遠超Ｈａｄｏｏｐ和ＨａｄｏｏｐＤＢ。
由此我們可以看出，復雜的ＯＬＡＰ查詢在ＭａｐＲｅｄｕｃｅ框架下也可以獲得接近甚至超越關系數據庫的性能，其關鍵在于如何有效地結合關系數據庫和ＭａｐＲｅｄｕｃｅ兩種技術，僅僅停留于表層的移植和集成是難以從根本上解決大數據分析問題的，我們在文獻［４１］的研究中也展示了如何基于這種新的數據組織方式來實現復雜分析操作———百分位數的高效計算問題。
ＬｉｎｅａｒＤＢ和Ｄｕｍｂｏ雖然基本可以達到預期的設計目標，但兩者都需要對數據進行預處理，其預處理代價是普通加載時間的７倍左右，因此其應對變化的能力還較弱，這是我們未來的工作內容之一。
圖４ 對比：一個典型星型模型與其對應的無連接雪花模型
８ 研究展望
當前３個方向的研究都不能完美地解決大數據分析問題，也就意味著每個方向都有極具挑戰性的工作等待著我們。
對并行數據庫來說，其擴展性近年雖有較大改善（如Ｇｒｅｅｎｐｌｕｍ和ＡｓｔｅｒＤａｔａ都是面向ＰＢ級數據規模設計開發的），但距離大數據的分析需求仍有較大差距，因此，如何改善并行數據庫的擴展能力是一項非常有挑戰的工作，該項研究將同時涉及數據一致性協議、容錯性、性能等數據庫領域的諸多方面。
圖５ Ｄｕｍｂｏ架構（深灰色部分是新增模塊，剩余部分是Ｈａｄｏｏｐ自帶模塊）
混合式架構方案可以復用已有成果，開發量較小，但只是簡單的功能集成似乎并不能有效解決大數據的分析問題，因此該方向還需要更加深入的研究工作，比如從數據模型及查詢處理模式上進行研究，使兩者能較自然地結合起來，這將是一項非常有意義的工作，中國人民大學的Ｄｕｍｂｏ系統即是在深層結合方向上努力的一個例子。
相比于前兩者，ＭａｐＲｅｄｕｃｅ的性能優化進展迅速，其性能正逐步逼近關系數據庫，該方向的研究又分為兩個方向：理論界側重于利用關系數據庫技術及理論改善ＭａｐＲｅｄｕｃｅ的性能；工業界側重于基于ＭａｐＲｅｄｕｃｅ平臺開發高效的應用軟件，針對數據倉庫領域，我們認為如下幾個研究方向比較重要，且目前研究還較少涉及：
（１）多維數據的預計算，ＭａｐＲｅｄｕｃｅ更多針對的是一次性分析操作，大數據上的分析操作雖然難以預測，但傳統的分析，如基于報表和多維數據的分析仍占多數，因此，ＭａｐＲｅｄｕｃｅ平臺也可以利用預計算等手段加快數據分析的速度，基于存儲空間的考慮（可以想象，在爆炸數據之上計算數據立方體需要付出昂貴的存儲空間代價），ＭＯＬＡＰ是不可取的，混合式ＯＬＡＰ（ＨＯＬＡＰ）應該是ＭａｐＲｅｄｕｃｅ平臺的優選ＯＬＡＰ實現方案，具體研究如：①基于ＭａｐＲｅｄｕｃｅ框架的高效Ｃｕｂｅ計算算法；②物化視圖的選擇問題，即物化哪些數據；③不同分析操作的物化手段（比如預測分析操作的物化）及如何基于物化的數據進行復雜分析操作（如數據訪問路徑的選擇問題）。
（２）各種分析操作的并行化實現，大數據分析需要高效的復雜統計分析功能的支持，ＩＢＭ將開源統計分析軟件Ｒ集成進Ｈａｄｏｏｐ平臺，增強了Ｈａｄｏｏｐ的統計分析功能，但更具挑戰性的問題是，如何基于ＭａｐＲｅｄｕｃｅ框架設計可并行化的、高效的分析算法，尤其需要強調的是，鑒于移動數據的巨大代價，這些算法應基于移動計算的方式來實現。
（３）查詢共享，ＭａｐＲｅｄｕｃｅ采用步步物化的處理方式，導致其Ｉ／Ｏ代價及網絡傳輸代價較高，一種有效的降低該代價的方式是在多個查詢間共享物化的中間結果，甚至原始數據，以分攤代價并避免重復計算，因此如何在多查詢間共享中間結果將是一項非常有實際應用價值的研究。
（４）用戶接口，如何較好地實現數據分析的展示和操作，尤其是復雜分析操作的直觀展示。
（５）Ｈａｄｏｏｐ可靠性研究，當前Ｈａｄｏｏｐ采用主從結構，由此決定了主節點一旦失效，將會出現整個系統失效的局面，因此，如何在不影響Ｈａｄｏｏｐ現有實現的前提下，提高主節點的可靠性，將是一項切實的研究。
（６）數據壓縮，ＭａｐＲｅｄｕｃｅ的執行模型決定了其性能取決于Ｉ／Ｏ和網絡傳輸代價，文獻［１１］在比較并行數據庫和ＭａｐＲｅｄｕｃｅ基于壓縮數據的性能時，發現壓縮技術并沒有改善Ｈａｄｏｏｐ的性能①，但實際情況是，壓縮不僅可以節省空間，節省Ｉ／Ｏ及網絡帶寬，還可以利用當前ＣＰＵ的多核并行計算能力，平衡Ｉ／Ｏ和ＣＰＵ的處理能力，從而提高性能，比如并行數據庫利用數據壓縮后，性能往往可以大幅提升，此后，文獻［２５、２６］的研究成功地利用壓縮技術提升了Ｈａｄｏｏｐ的性能，但這些研究都基于各自的存儲模型，而非Ｈａｄｏｏｐ的默認存儲模式（行存模型），因此，ＭａｐＲｅｄｕｃｅ上的壓縮是一個尚待研究的重要問題。
（７）多維索引研究，如何基于ＭａｐＲｅｄｕｃｅ框架實現多維索引，加快多維數據的檢索速度。
當然，仍有許多其它研究工作，比如基于Ｈａｄｏｏｐ的實時數據分析、彈性研究、數據一致性研究等，都是非常有挑戰和意義的研究，限于篇幅我們不再贅述。
９ 總結
本文對大數據分析的主流實現平臺（并行數據庫、ＭａｐＲｅｄｕｃｅ及兩者的混合架構）進行了評價、歸納與對比分析，介紹了中國人民大學在大數據分析方面的研究，并對當前的研究進行了歸納，從文中可以看出，每種分析平臺都不是完美的，在大數據面前，都有很長的路要走，大數據分析迫使我們反思傳統的數據倉庫架構，虛心地研究ＭａｐＲｅｄｕｃｅ等新生平臺，以站在更高的層次來思考問題，從而找到適應時代需求的數據倉庫架構。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://m.hanmeixuan.com/
本文標題：架構大數據：挑戰、現狀與展望(下)
相關文章
