１ 引言
最近幾年，數據倉庫又成為數據管理研究的熱點領域，主要原因是當前數據倉庫系統面臨的需求在數據源、需提供的數據服務和所處的硬件環境等方面發生了根本性的變化（詳見１．１節），這些變化是我們必須面對的。
本文在大數據的時代背景下，對現有數據倉庫系統實現方案（主要是并行數據庫和ＭａｐＲｅｄｕｃｅ）進行重新審視，期望能為設計滿足時代需求的數據倉庫系統提供理論參考，限于篇幅，本文主要關注不同數據倉庫實現方案的主體架構及其缺陷在最近幾年的改進情況，依據研究立足點的不同，本文將該領域的研究歸為三大類：并行數據庫、ＭａｐＲｅｄｕｃｅ、并行數據庫和ＭａｐＲｅｄｕｃｅ技術的混合架構，其中第三類研究又細分為：并行數據庫主導型、ＭａｐＲｅｄｕｃｅ主導型、并行數據庫和ＭａｐＲｅｄｕｃｅ集成型三種，文第１節分析大數據時代，數據倉庫所面臨的問題及挑戰；第２節列出大數據時代的數據倉庫平臺需具備的幾個重要特性；第３節到第５節就這幾個特性對各類平臺進行歸納分析；第６節對最新研究做一跟蹤歸納；第７節介紹中國人民大學在大數據分析方面的研究工作；第８節對未來研究做出展望；第９節總結全文。
１．１ 三個變化
（１）數據量。由ＴＢ級升至ＰＢ級，并仍在持續爆炸式增長，根據ＷｉｎｔｅｒＣｏｒｐ的調查顯示，最大的數據倉庫中的數據量，每兩年增加３倍［１］（年均增長率為１７３％），其增長速度遠超摩爾定律增長速度，照此增長速度計算，２０１５年最大數據倉庫中的數據量將逼近１００ＰＢ。
（２）分析需求。由常規分析轉向深度分析（ＤｅｅｐＡｎａｌｙｔｉｃｓ），數據分析日益成為企業利潤必不可少的支撐點，根據ＴＤＷＩ對大數據分析的報告（如圖１），企業已經不滿足于對現有數據的分析和監測，而是更期望能對未來趨勢有更多的分析和預測，以增強企業競爭力，這些分析操作包括諸如移動平均線分析、數據關聯關系分析、回歸分析、市場籃分析等復雜統計分析，我們稱之為深度分析，值得補充的是，本文中的大數據分析不僅僅指基于大數據上的深度分析，也包括常規分析。
圖１ 分析的趨勢
（３）硬件平臺。由高端服務器轉向由中低端硬件構成的大規模機群平臺，由于數據量的迅速增加，并行數據庫的規模不得不隨之增大，從而導致其成本的急劇上升，出于成本的考慮，越來越多的企業將應用由高端服務器轉向了由中低端硬件構成的大規模機群平臺。
１.２ 兩個問題
圖２是一個典型的數據倉庫架構，從圖中我們可以看出，傳統的數據倉庫將整個實現劃分為４個層次，數據源中的數據首先通過ＥＴＬ工具被抽取到數據倉庫中進行集中存儲和管理，再按照星型模型或雪花模型組織數據，然后ＯＬＡＰ工具從數據倉庫中讀取數據，生成數據立方體（ＭＯＬＡＰ）或者直接訪問數據倉庫進行數據分析（ＲＯＬＡＰ），在大數據時代，此種計算模式存在兩個問題：
問題１，數據移動代價過高，在數據源層和分析層之間引入一個存儲管理層，可以提升數據質量并針對查詢進行優化，但也付出了較大的數據遷移代價和執行時的連接代價：數據首先通過復雜且耗時的ＥＴＬ過程存儲到數據倉庫中，在ＯＬＡＰ服務器中轉化為星型模型或者雪花模型；執行分析時，又通過連接方式將數據從數據庫中取出，這些代價在ＴＢ級時也許可以接受，但面對大數據，其執行時間至少會增長幾個數量級，更為重要的是，對于大量的即席分析，這種數據移動的計算模式是不可取的。
圖２ 一個典型的數據倉庫架構
問題２，不能快速適應變化，傳統的數據倉庫假設主題是較少變化的，其應對變化的方式是對數據源到前端展現的整個流程中的每個部分進行修改，然后再重新加載數據，甚至重新計算數據，導致其適應變化的周期較長，這種模式比較適合對數據質量和查詢性能要求較高、而不太計較預處理代價的場合，但在大數據時代，分析處在變化的業務環境中，這種模式將難以適應新的需求。
１．３ 一個鴻溝
在大數據時代，巨量數據與系統的數據處理能力之間將會產生一個鴻溝：一邊是至少ＰＢ級的數據量，另一邊是面向傳統數據分析能力設計的數據倉庫和各種ＢＩ工具，如果這些系統或工具發展緩慢，該鴻溝將會隨著數據量的持續爆炸式增長而逐步拉大。
雖然，傳統數據倉庫可以采用舍棄不重要數據或者建立數據集市的方式來緩解此問題，但畢竟只是權益之策，并非系統級解決方案，而且，舍棄的數據在未來可能會重新使用，以發掘更大的價值。
２ 期望特性
本節我們列出對大數據進行分析時，數據倉庫系統需具備的幾個重要特性（表１所示）。
表１ 大數據分析平臺需具備的特性
高度可擴展性，一個明顯的事實是，數據庫不能依靠一臺或少數幾臺機器的升級（ｓｃａｌｅｕｐ縱向擴展）滿足數據量的爆炸式增長，而是希望能方便地做到橫向可擴展（ｓｃａｌｅｏｕｔ）來實現此目標，普遍認為ｓｈａｒｅｄｎｏｔｈｉｎｇ無共享結構（每個節點擁有私有內存和磁盤，并且通過高速網絡同其它節點互連）具備較好的擴展性，分析型操作往往涉及大規模的并行掃描、多維聚集及星型連接操作，這些操作也比較適合在無共享結構的網絡環境運行，Ｔｅｒａｄａｔａ即采用此結構，Ｏｒａｃｌｅ在其新產品Ｅｘａｄａｔａ中也采用了此結構。
高性能，數據量的增長并沒有降低對數據庫性能的要求，反而有所提高，軟件系統性能的提升可以降低企業對硬件的投入成本、節省計算資源，提高系統吞吐量，巨量數據的效率優化，并行是必由之路，１ＰＢ數據在５０ＭＢ／ｓ速度下串行掃描一次，需要２３０天；而在６０００塊磁盤上，并行掃描１ＰＢ數據只需要１個小時。
高度容錯，大數據的容錯性要求在查詢執行過程中，一個參與節點失效時，不需要重做整個查詢，而機群節點數的增加會帶來節點失效概率的增加，在大規模機群環境下，節點的失效將不再是稀有事件（Ｇｏｏｇｌｅ報告，平均每個ＭａｐＲｅｄｕｃｅ數據處理任務就有１.２個工作節點失效），因此在大規模機群環境下，系統不能依賴于硬件來保證容錯性，要更多地考慮軟件級容錯。
支持異構環境，建設同構系統的大規模機群難度較大，原因在于計算機硬件更新較快，一次性購置大量同構的計算機是不可取的，而且也會在未來添置異構計算資源，此外，不少企業已經積累了一些閑置的計算機資源，此種情況下，對異構環境的支持可以有效地利用這些閑置計算資源，降低硬件成本的投入，還需特別關注的是，在異構環境下，不同節點的性能是不一樣的，可能出現“木桶效應”，即最慢節點的性能決定整體處理性能，因此，異構的機群需要特別關注負載均衡、任務調度等方面的設計。
較低的分析延遲，分析延遲指的是分析前的數據準備時間，在大數據時代，分析所處的業務環境是變化的，因此也要求系統能動態地適應業務分析需求，在分析需求發生變化時，減少數據準備時間，系統能盡可能快地做出反應，快速地進行數據分析。
易用且開放的接口，ＳＱＬ的優點是簡單易用，但其主要用于數據的檢索查詢，對于大數據上的深度分析來講，是不夠的，原因在于：（１）其提供的服務方式依賴于數據移動來實現：將數據從數據庫中取出，然后傳遞給應用程序，該實現方式在大數據時代代價過高；（２）復雜的分析功能，如Ｒ或Ｍａｔｌａｂ中的分析功能，ＳＱＬ是難以勝任的，因此，除對ＳＱＬ的支持外，系統還應能提供開放的接口，讓用戶自己開發需要的功能，設計該接口時，除了關注其易用性和開放性，還需要特別注意兩點隱藏的要求：（１）基于接口開發的用戶自定義函數，能自動在機群上并行執行；（２）分析在數據庫內進行，即分析盡可能靠近數據。
較低的成本，在滿足需求的前提下，某技術成本越低，其生命力就越強，需要指出的是成本是一個綜合指標，不僅僅是硬件或軟件的代價，還應包括日常運維成本（網絡費用、電費、建筑等）和管理人員成本等，據報告，數據中心的主要成本不是硬件的購置成本，而是日常運維成本，因此，在設計系統時需要更多地關注此項內容。
向下兼容性，數據倉庫發展的３０年，產生了大量面向客戶業務的數據處理工具（如Ｉｎｆｏｒｍａｃｔｉｃａ、ＤａｔａＳｔａｇｅ等）、分析軟件（如ＳＰＳＳ、Ｒ、Ｍａｔｌａｂ等）和前端展現工具（如水晶報表）等，這些軟件是一筆寶貴的財富，已被分析人員所熟悉，是大數據時代中小規模數據分析的必要補充，因此，新的數據倉庫需考慮同傳統商務智能工具的兼容性，由于這些系統往往提供標準驅動程序，如ＯＤＢＣ、ＪＤＢＣ等，這項需求的實際要求是對ＳＱＬ的支持。
總之，以較低的成本投入、高效地進行數據分析，是大數據分析的基本目標。
３ 并行數據庫
并行數據庫起源于２０世紀８０年代，當前主流的并行數據庫都同早期的Ｇａｍｍａ和Ｇｒａｃｅ等并行數據庫類似，這些數據庫都支持標準ＳＱＬ，并且實現了數據庫界過去３０年提出的許多先進技術，其主要采用ｓｈａｒｅｄｎｏｔｈｉｎｇ結構，將關系表在節點間橫向劃分，并且利用優化器來對執行過程進行調度和管理，其目標是高性能和高可用性。
并行數據庫的最大優勢在于性能，這主要得益于數據庫界近幾十年的研究成果———許多先進的技術手段及算法，如索引、數據壓縮、物化視圖、結果緩沖、Ｉ／Ｏ共享、優化的數據連接等，但是在大數據時代，如前言所述，數據移動的實現方式將影響其性能。
并行數據庫通過ＳＱＬ向外提供數據訪問服務，ＳＱＬ因其簡單易用的特點而被廣泛使用，因此，大多ＢＩ工具都支持基于標準ＳＱＬ的數據交互方式，使得關系數據庫能較好地兼容當前多數ＢＩ工具，某些數據庫，如ＩＢＭＤＢ２還針對一些ＢＩ工具進行了優化，但在大數據分析面前，ＳＱＬ接口面臨巨大挑戰，ＳＱＬ的優勢源于其對底層數據訪問的封裝，但封裝在一定程度上影響了其開放性，而且并行數據庫提供的用戶自定義函數大都是基于單數據庫實例設計的，從而不能在機群上并行執行，也即意味著傳統的實現方式不適合大數據的處理及分析，而且，在并行數據庫中實現用戶自定義函數往往需要經過復雜的系統交互，甚至要熟悉數據庫的內部結構及系統調用等，從而難以使用。
并行數據庫在擴展性、容錯性、成本、對異構環境的支持等幾項上有所欠缺，這幾項實際是相互影響的，我們以其最大問題———擴展性為主線展開討論，并行數據庫大多支持有限擴展，一般可擴至數百節點的規模，尚未有數千節點規模的應用案例，并行數據庫擴展性有限主要因為如下幾點：（１）并行數據庫軟件級容錯能力較差，并行數據庫基于高端硬件設計，并且假設查詢失敗屬于稀有事件，因此當查詢失敗時，一般采取重做查詢的方式，而在大規模機群環境下，查詢失敗將會變為一個普通事件，極端情況下，并行數據有可能出現不停重做查詢的局面；（２）并行數據庫對異構硬件的支持非常有限，且對于處理較慢的節點反應敏感，容易出現“木桶效應”，如第２節中所論述的，完全基于同構硬件搭建大規模機群在現實中是較難實現的，因而，對異構硬件的支持能力影響了其擴展性；（３）并行數據庫若做到大規模可擴展，其代價將會較高（需基于高端硬件來保證可靠性，需購買昂貴的軟件系統），從而限制了其擴展性；（４）根據ＣＡＰ理論①，在分布式系統中，數據一致性（Ｃｏｎｓｉｓｔｅｎｃｙ）、可用性（Ａｖａｉｌａｂｉｌｉｔｙ）、子網可分解性（ＮｅｔｗｏｒｋＰａｒｔｉｔｉｏｎｉｎｇ）不可同時兼得，選擇其中任兩項，便會損害另一項，并行數據庫追求的是數據一致性和系統的可用性，從而影響了它的擴展能力。
此外，如１.２節所討論的，基于并行數據庫實現的傳統數據倉庫借助于外圍工具（ＥＴＬ工具、ＯＬＡＰ產品、ＢＩ報表工具、統計分析軟件等）來完成數據的預處理和分析展現任務，導致其數據處理及分析過程涉及大量的數據遷移和計算，分析延遲往往較高。
４MapReduce
ＭａｐＲｅｄｕｃｅ是２００４年由Ｇｏｏｇｌｅ提出的面向大數據集處理的編程模型，起初主要用作互聯網數據的處理，例如文檔抓取、倒排索引的建立等，但由于其簡單而強大的數據處理接口和對大規模并行執行、容錯及負載均衡等實現細節的隱藏，該技術一經推出便迅速在機器學習、數據挖掘、數據分析等領域得到廣泛應用。
ＭａｐＲｅｄｕｃｅ將數據處理任務抽象為一系列的Ｍａｐ（映射）Ｒｅｄｕｃｅ（化簡）操作對，Ｍａｐ主要完成數據的過濾操作，Ｒｅｄｕｃｅ主要完成數據的聚集操作，輸入輸出數據均以〈ｋｅｙ，ｖａｌｕｅ〉格式存儲，用戶在使用該編程模型時，只需按照自己熟悉的語言實現Ｍａｐ函數和Ｒｅｄｕｃｅ函即可，ＭａｐＲｅｄｕｃｅ框架會自動對任務進行劃分以做到并行執行。
下面本文將以基于ＭａｐＲｅｄｕｃｅ的開源實現Ｈａｄｏｏｐ為主，對其主要特性進行介紹。
ＭａｐＲｅｄｕｃｅ是面向由數千臺中低端計算機組成的大規模機群而設計的，其擴展能力得益于其ｓｈａｒｅｄｎｏｔｈｉｎｇ結構、各個節點間的松耦合性和較強的軟件級容錯能力：節點可以被任意地從機群中移除，而幾乎不影響現有任務的執行，該技術被稱為ＲＡＩＮ（Ｒｅｄｕｎｄａｎｔ／ＲｅｌｉａｂｌｅＡｒｒａｙｏｆＩｎｄｅｐｅｎｄｅｎｔ（ａｎｄＩｎｅｘｐｅｎｓｉｖｅ）Ｎｏｄｅｓ），ＭａｐＲｅｄｕｃｅ卓越的擴展能力已在工業界（Ｇｏｏｇｌｅ、Ｆａｃｅｂｏｏｋ、Ｂａｉｄｕ、Ｔａｏｂ等）得到了充分驗證，ＭａｐＲｅｄｕｃｅ對硬件的要求較低，可以基于異構的廉價硬件來搭建機群，且免費開源，因此其構建成本低于并行數據庫，但基于ＭａｐＲｅｄｕｃｅ的應用軟件相對較少，許多數據分析功能需要用戶自行開發，從而會導致使用成本的增加。
作為開源系統，ＭａｐＲｅｄｕｃｅ具有完全的開放性：其〈ｋｅｙ，ｖａｌｕｅ〉存儲模型具有較強的表現力，可以存儲任意格式的數據；Ｍａｐ和Ｒｅｄｕｃｅ兩個基本的函數接口也給用戶提供了足夠的發揮空間，可以實現各種復雜的數據處理功能，但這種開放性也帶來一個問題，就是將本來應由數據庫管理系統完成的工作，諸如文件存儲格式的設計、模式信息的記錄、數據處理算法的實現等，轉移給了程序員，從而導致程序員負擔過重，程序員水平對系統處理性能起決定性作用，在某些情況下，寫ＭａｐＲｅｄｕｃｅ程序的時間遠大于寫ＳＱＬ語句的時間，部分復雜的ＢＩ報表分析，可能僅程序的編寫和調試就要耗費幾天的時間。
基于ＭａｐＲｅｄｕｃｅ平臺的分析，無需復雜的數據預處理和寫入數據庫的過程，而是可以直接基于平面文件進行分析，并且其采用的計算模式是移動計算而非移動數據，因此可以將分析延遲最小化。
在同等硬件條件下，ＭａｐＲｅｄｕｃｅ性能遠低于并行數據庫，這是由其最初的設計定位決定的，ＭａｐＲｅｄｕｃｅ的設計初衷是面向非結構化數據的處理，這些數據具有數據量大，處理復雜等特點，而且往往是一次性處理，為了獲得較好的擴展能力和容錯能力，ＭａｐＲｅｄｕｃｅ采取了基于掃描的處理模式和對中間結果步步物化的執行策略，從而導致較高的Ｉ／Ｏ代價，為了減少數據預處理時間，ＭａｐＲｅｄｕｃｅ沒有使用模式、索引、物化視圖等技術手段，其數據預處理僅是一次數據加載操作，但由此導致了一個問題———較高的元組解析代價。ＭａｐＲｅｄｕｃｅ環境下，每個查詢都是直接從文件系統中讀入原始數據文件，而非傳統的從數據庫中讀入經處理過的文件，因此其元組解析代價遠高于關系數據庫，對數據分析領域來說，連接是關鍵操作（如傳統的星型查詢和雪花查詢均是依賴于連接來處理查詢），但ＭａｐＲｅｄｕｃｅ處理連接的性能尤其不盡如人意，原因在于ＭａｐＲｅｄｕｃｅ最初是針對單數據集設計的處理模型，而連接操作往往涉及多個數據集，在利用ＭａｐＲｅｄｕｃｅ實現連接時，最直接的方式是每個任務執行一個屬性上的連接操作，然后將多個ＭａｐＲｅｄｕｃｅ任務通過物化的中間結果串接起來，這種實現方式往往涉及中間結果的讀寫，從而導致大量的Ｉ／Ｏ操作和網絡傳輸。
ＭａｐＲｅｄｕｃｅ目前基本不兼容現有的ＢＩ工具，原因在于其初衷并不是要成為數據庫系統，因此它并未提供ＳＱＬ接口，但已有研究致力于ＳＱＬ語句與ＭａｐＲｅｄｕｃｅ任務的轉換工作（例如Ｈｉｖｅ），進而有可能實現ＭａｐＲｅｄｕｃｅ與現存ＢＩ工具的兼容。
５ 并行數據庫和ＭａｐＲｅｄｕｃｅ的混合架構
基于以上分析，我們可以清楚地看出，基于并行數據庫和ＭａｐＲｅｄｕｃｅ實現的數據倉庫系統都不是大數據分析的理想方案，針對兩者哪個更適合時代需求的問題，業界近年展開了激烈爭論，當前基本達成如下共識：并行數據庫和ＭａｐＲｅｄｕｃｅ是互補關系，應該相互學習，基于該觀點，大量研究著手將兩者結合起來，期望設計出兼具兩者優點的數據分析平臺，這種架構又可以分為三類：并行數據庫主導型、ＭａｐＲｅｄｕｃｅ主導型、ＭａｐＲｅｄｕｃｅ和并行數據庫集成型（表２對３種架構進行了對比分析）。
表２ 混合架構型解決方案對比分析
５．１ 并行數據庫主導型
該種方式關注于如何利用ＭａｐＲｅｄｕｃｅ來增強并行數據庫的數據處理能力，代表性系統是Ｇｒｅｅｎｐｌｕｍ（已被ＥＭＣ收購）和ＡｓｔｅｒＤａｔａ（已被Ｔｅｒａｄａｔａ收購），ＡｓｔｅｒＤａｔａ將ＳＱＬ和ＭａｐＲｅｄｕｃｅ進行結合，針對大數據分析提出了ＳＱＬ／ＭａｐＲｅｄｕｃｅ框架。
該框架允許用戶使用Ｃ＋＋、ｊａｖａ、Ｐｙｔｈｏｎ等語言編寫ＭａｐＲｅｄｕｃｅ函數，編寫的函數可以作為一個子查詢在ＳＱＬ中使用，從而同時獲得ＳＱＬ的易用性和ＭａｐＲｅｄｕｃｅ的開放性，不僅如此，ＡｓｔｅｒＤａｔａ基于ＭａｐＲｅｄｕｃｅ實現了３０多個統計軟件包，從而將數據分析推向數據庫內進行（數據庫內分析），大大提升了數據分析的性能。
Ｇｒｅｅｎｐｌｕｍ也在其數據庫中引入了ＭａｐＲｅｄｕｃｅ處理功能，其執行引擎可以同時處理ＳＱＬ查詢和ＭａｐＲｅｄｕｃｅ任務，這種方式在代碼級整合了ＳＱＬ和ＭａｐＲｅｄｕｃｅ：ＳＱＬ可以直接使用ＭａｐＲｅｄｕｃｅ任務的輸出，同時ＭａｐＲｅｄｕｃｅ任務也可以使用ＳＱＬ的查詢結果作為輸入。
總的來說，這些系統都集中于利用ＭａｐＲｅｄｕｃｅ來改進并行數據庫的數據處理功能，其根本性問題———可擴展能力和容錯能力并未改變。
５．２ＭａｐＲｅｄｕｃｅ主導型
該方向的研究主要集中于利用關系數據庫的ＳＱＬ接口和對模式的支持等技術來改善ＭａｐＲｅｄｕｃｅ的易用性，代表系統是Ｈｉｖｅ、ＰｉｇＬａｔｉｎ等。
Ｈｉｖｅ是Ｆａｃｅｂｏｏｋ提出的基于Ｈａｄｏｏｐ的大型數據倉庫，其目標是簡化Ｈａｄｏｏｐ上的數據聚集、ａｄｈｏｃ查詢及大數據集的分析等操作，以減輕程序員的負擔，它借鑒關系數據庫的模式管理、ＳＱＬ接口等技術，把結構化的數據文件映射為數據庫表，提供類似于ＳＱＬ的描述性語言ＨｉｖｅＱＬ供程序員使用，可自動將ＨｉｖｅＱＬ語句解析成一優化的ＭａｐＲｅｄｕｃｅ任務執行序列，此外，它也支持用戶自定義的ＭａｐＲｅｄｕｃｅ函數。
ＰｉｇＬａｔｉｎ是Ｙａｈｏｏ！提出的類似于Ｈｉｖｅ的大數據集分析平臺，兩者的區別主要在于語言接口。
Ｈｉｖｅ提供了類似ＳＱＬ的接口，ＰｉｇＬａｔｉｎ提供的是一種基于操作符的數據流式的接口，圖３是ＰｉｇＬａｔｉｎ在處理查詢時的一個操作實例，該查詢的目的是找出“年齡在１８～２５周歲之間的用戶（Ｕｓｅｒｓ）最頻繁訪問的５個頁面（Ｐａｇｅｓ）”，從圖３可以看出，Ｐｉｇ提供的操作接口類似于關系數據庫的操作符（對應圖中右側部分中的每一行命令），用戶查詢的腳本類似于邏輯查詢計劃（對應圖中左側部分），因此，也可以說Ｐｉｇ利用操作符來對Ｈａｄｏｏｐ進行封裝，Ｈｉｖｅ利用ＳＱＬ進行封裝。
５．３ＭａｐＲｅｄｕｃｅ和并行數據庫集成型
該方向的代表性研究是耶魯大學提出的ＨａｄｏｏｐＤＢ（已于２０１１年商業化為Ｈａｄａｐｔ）Ｓｔｏｎｅｂｒａｋｅｒ等人設計的Ｖｅｒｔｉｃａ數據庫和ＮＣＲ公司的Ｔｅｒａｄａｔａ數據庫。
圖３ ＰｉｇＬａｔｉｎ的一個查詢示例（右邊為實際腳本）
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://m.hanmeixuan.com/
本文標題：架構大數據：挑戰、現狀與展望(上)
相關文章
