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