【51CTO.com快譯】介紹

Snowflake、Panoply和Repods是三種允許您在托管云架構(gòu)中提取、處理、存儲和訪問數(shù)據(jù)的云端服務(wù)。區(qū)別于其他只能提供數(shù)據(jù)呈現(xiàn)與處理的云服務(wù)，這些平臺能夠為海量的數(shù)據(jù)提供計算與存儲資源，因此我們常稱之為云數(shù)據(jù)倉庫平臺。

以存儲和處理數(shù)據(jù)為核心功能的數(shù)據(jù)倉庫服務(wù)，為數(shù)據(jù)的整體性管理與分析提供了堅實的云平臺基礎(chǔ)。由于這三個平臺的受眾并非完全相同，因此我們可能無法直接對它們的所有方面進行全面比較。特別對于Panoply和Snowflake，我們只是從它們在網(wǎng)上公開的資料來進行分析。

架構(gòu)

Panoply綜合使用到了Amazon Redshift數(shù)據(jù)服務(wù)、Elasticsearch數(shù)據(jù)庫、Amazon S3存儲、以及Spark計算架構(gòu)。Amazon Redshift是一個可擴展的數(shù)據(jù)庫，它源自Postgres數(shù)據(jù)庫架構(gòu)、并增加了集群的功能。不過，它僅能作為Amazon Web Service來運行。

該體系架構(gòu)能夠通過向群集里添加更多的節(jié)點，以實現(xiàn)在線擴展。由于不同的Panoply客戶端都能夠共享相同的基礎(chǔ)架構(gòu)，因此在某個客戶端上出現(xiàn)的高流量的查詢負載時，其他客戶端的查詢性能可能會受到影響。通過Panoply，您能夠創(chuàng)建多個Amazon Redshift類型的數(shù)據(jù)庫。因此從某種意義上說，此類數(shù)據(jù)庫雖然具有單獨的存儲區(qū)域，但是它們?nèi)怨蚕硐嗤牟樵円?即DBMS系統(tǒng))。

Snowflake雖然并未詳細地披露其底層架構(gòu)，但總體而言，它能夠通過一個在線擴展的平臺，來清晰地分離出存儲和計算資源。Snowflake允許您在同一個帳戶中創(chuàng)建和管理多個數(shù)據(jù)倉庫。您既可以詳細地配置每個倉庫的計算群集尺寸，又可以為每個倉庫配置好自動在線縮放的規(guī)則，即：在不中斷服務(wù)的情況下實現(xiàn)縱向擴展(在一臺計算機上使用更多的資源)、以及橫向擴展(引入更多的計算資源)。當然，為了確保每個倉庫具有穩(wěn)定的性能，Snowflake的數(shù)據(jù)倉庫并不共享計算資源，而且會使用外部工具來直接訪問數(shù)據(jù)庫。

Repods的基礎(chǔ)架構(gòu)包括原生的PostgreSQL(版本在10以上)、以及TimescaleDB。該數(shù)據(jù)庫可被用于大時間跨度的分區(qū)數(shù)據(jù)，存儲集群管理、擴展存儲、以及許多與數(shù)據(jù)倉庫相關(guān)的服務(wù)。目前，雖然Repods能夠提供可靠的I/O速度和PB級的在線擴展，但是其擴展計算資源的過程仍需要幾秒鐘的數(shù)據(jù)倉庫停機時間，而且并不具有容量彈性。您可以為每個帳戶創(chuàng)建、管理和共享多個數(shù)據(jù)倉庫。不過，該平臺中的不同數(shù)據(jù)倉庫實例，主要依賴于那些尚未與群集中的任何其他實例共享的專用資源，并籍此實現(xiàn)穩(wěn)定的查詢性能。

導入接口

我們將導入接口分為如下四個部分：

[[276650]]

• 文件 - 仍然是最常見的數(shù)據(jù)形式。
• Web服務(wù) - 網(wǎng)上有大量相關(guān)的數(shù)據(jù)。
• 數(shù)據(jù)庫 – 通常，各類數(shù)據(jù)存儲在不同組織的傳統(tǒng)數(shù)據(jù)庫中，而組織對這些數(shù)據(jù)庫的訪問，一般不會暴露到互聯(lián)網(wǎng)上，因此它們無法直接用到云數(shù)據(jù)平臺。那么Web服務(wù)可以被放置在內(nèi)部部署的數(shù)據(jù)庫、以及云服務(wù)之間，從而處理訪問控制等安全相關(guān)問題。當然，另一種方法則是在安全跳轉(zhuǎn)的主機上使用ssh-tunneling。
• 實時流 - 實時數(shù)據(jù)流是由各種消息路由器來傳遞的。隨著物聯(lián)網(wǎng)的興起，它們將會變得越來越重要。

Panoply在上述四個方面都提供了大量的導入選項。不過，據(jù)我們所掌握的信息，Panoply既不能根據(jù)自動化計劃，從云存儲桶(bucket)或SFTP中提取文件;又不能根據(jù)計劃去請求RESTful URL。

Snowflake雖然只專注于加載文件(如cat.II)，但是它允許您從云存儲處加載包括Amazon S3或Microsoft Azure之類的文件。Snowflake可以讓您監(jiān)控新的文件到達，并及時加載它們。

在Repods中，您可以上載文件，從S3 Buckets處加載文件、或從外部SFTP服務(wù)器處加載數(shù)據(jù)。Repods并不為所有可能的Web服務(wù)提供單獨的接口，不過它提供了一個可用于為任何類型的服務(wù)(例如Socrata)接受Web請求的通用API。雖然用戶無法在各個數(shù)據(jù)庫之間導入/出數(shù)據(jù)，但是他們可以通過Repods，訂閱和接收消息路由器(目前為WAMPonly)上的不同主題，以便以微批次(micro-batches)的方式提取數(shù)據(jù)。

數(shù)據(jù)轉(zhuǎn)換ETL

通常，被導入數(shù)據(jù)平臺的數(shù)據(jù)必須經(jīng)過類型轉(zhuǎn)換，才能在數(shù)據(jù)流中被予以分析。該過程通常被稱為ETL(提取、轉(zhuǎn)換、加載)，包括：為原始數(shù)據(jù)創(chuàng)建表格，分配數(shù)據(jù)類型，過濾數(shù)值，連接現(xiàn)有的數(shù)據(jù)，創(chuàng)建派生列/行，以及將各種自定義的邏輯應(yīng)用到原始數(shù)據(jù)上。

業(yè)界常把創(chuàng)建和管理ETL的過程稱為數(shù)據(jù)工程。此過程不但耗時，而且耗費管理人員的精力。一些較大的數(shù)據(jù)倉庫往往會包含數(shù)千個具有不同階段、依賴關(guān)系、以及處理順序的ETL過程。

在Panoply中，您可以使用代碼來創(chuàng)建數(shù)據(jù)轉(zhuǎn)換。針對每一次數(shù)據(jù)訪問，有的轉(zhuǎn)換能夠提供重新計算的虛擬結(jié)果(“視圖”);有的則能夠保存重新計算的工作量。據(jù)我們所知，在Panoply中，如果數(shù)據(jù)已經(jīng)實現(xiàn)，則必須手動刷新數(shù)據(jù)以獲取更新。例如：在出現(xiàn)新的數(shù)據(jù)時，用戶必須點擊刷新以執(zhí)行轉(zhuǎn)換。

根據(jù)源的大小和轉(zhuǎn)換的復(fù)雜性，我們可以禁止將中間性的結(jié)果，存儲到專門的管理性結(jié)果表中。而常見的做法是：將新數(shù)據(jù)的增量加載到表中已有的數(shù)據(jù)里。當然， Panoply并不提供對于歷史記錄的具體支持。

Snowflake在處理數(shù)據(jù)轉(zhuǎn)換方面，采用了與Panoply類似的方法。您可以使用Snowflake的SQL語句在表單式SQL查詢中實現(xiàn)數(shù)據(jù)轉(zhuǎn)換，然后按需在新的表中予以后期處理。在Snowflake中，您可以對數(shù)據(jù)對象進行低級別的控制，就像使用Postgres、MySQL、Oracle或DB2之類的傳統(tǒng)數(shù)據(jù)庫系統(tǒng)一樣，您可以去創(chuàng)建表、索引、視圖、查詢、以及分區(qū)等。

另外，Snowflake還允許您查詢在某個特定時間點(最多90天前)的表格狀態(tài)。不過，Snowflake并不支持“開箱即用”式的數(shù)據(jù)自動化歷史記錄。

在Repods中，您可以創(chuàng)建所謂的“管道(Pipe)”，將原始數(shù)據(jù)轉(zhuǎn)換為特定的數(shù)據(jù)倉庫表(如Evo表)。在這些查詢中，由于實際插入的目標表會依靠諸如：刪除重復(fù)數(shù)據(jù)、生產(chǎn)密鑰、記錄歷史日志、以及控制版本等技術(shù)，來實現(xiàn)集成式的后期處理，因此您不必為每一個轉(zhuǎn)換都重新制定數(shù)據(jù)的插入策略。

監(jiān)控

通常，大型數(shù)據(jù)倉庫系統(tǒng)可以輕松地容納并包含數(shù)百個數(shù)據(jù)表，以及數(shù)百個管理數(shù)據(jù)流的自動ETL過程。不過，它們在運行過程中難免會出現(xiàn)錯誤，而且其中的一些錯誤需要人工進行干預(yù)。針對此類復(fù)雜性，我們需要通過監(jiān)控來獲悉平臺的狀況。

在Panoply中，您可以查看到已執(zhí)行的各種查詢、以及作業(yè)的歷史記錄。通過警報視圖，您可以獲悉服務(wù)和其他資產(chǎn)的問題、及其來源。各種查詢?nèi)罩緯鶕?jù)每隔幾秒的輪詢服務(wù)，予以更新(并非實時刷新)。

Snowflake通過監(jiān)​​控報告，為您提供在特定時間范圍內(nèi)，活動查詢的數(shù)量、及其資源消耗的匯總信息。在Snowflake中，您可以使用SQL語句來訪問各種內(nèi)部元數(shù)據(jù)表(metadata table)，并提取系統(tǒng)中查詢活動的相關(guān)信息類型。同時，Snowflake還能在Web界面中顯示曾經(jīng)執(zhí)行過的歷史查詢操作。

Repods通過提供實時更新的圖形概覽，以顯示當前和歷史執(zhí)行過的管道詳細信息。Repods還允許您使用SQL語句來分析系統(tǒng)的日志，并提取有關(guān)管道執(zhí)行的信息類型。

實用性

在對于用戶、數(shù)據(jù)倉庫、表格、轉(zhuǎn)換、報告等對象的創(chuàng)建與管理方面，云端工具通常會根據(jù)目標用戶平衡控制級別與易用水平。此處的三個平臺由于本質(zhì)上都屬于云端環(huán)境，因此用戶可以使用基于瀏覽器的Web應(yīng)用，來直接進行訪問與管控。具體而言：

Snowflake為用戶提供了類似數(shù)據(jù)庫系統(tǒng)的高級可控功能。用戶可以在代碼面板中編寫、導入、制表、視圖、索引之類的處理代碼;并且通過Web表單，來處理諸如創(chuàng)建和刪除整個數(shù)據(jù)倉庫及其用戶等任務(wù)。不過，其Web界面并不能自動響應(yīng)平臺上的各項活動，用戶需要通過定期刷新其視圖(每10秒刷新一次)，來實現(xiàn)更新。

在Panoply中，用戶通過Web表單來處理對象的創(chuàng)建、以及有關(guān)數(shù)據(jù)導入的設(shè)置，而進一步的數(shù)據(jù)變換與分析，則需要通過代碼面板才能實現(xiàn)。此外，Panoply僅能夠提供英文版的界面。

在Repods中，用戶能夠通過Web表單來處理對象的創(chuàng)建，并且在代碼面板中處理各種自定義的轉(zhuǎn)換邏輯。就Repods的數(shù)據(jù)分析而言，用戶既可以使用工作簿樣式(workbook-style)方法，來創(chuàng)建自定義的分析查詢，也可以使用內(nèi)置的OLAP工具，通過點擊來快速獲悉數(shù)據(jù)模型。

多用戶工作流程

此處主要比較的是：用戶交互、以及數(shù)據(jù)與工作內(nèi)容的共享支持。總的說來，這三個平臺都允許多個用戶在同一個數(shù)據(jù)環(huán)境中開展協(xié)同工作。當然，它們都無法提供在線討論或聊天的功能。

Panoply為所有用戶提供了一個基礎(chǔ)架構(gòu)式的環(huán)境，用戶可以在此架構(gòu)上創(chuàng)建多個Amazon Redshift數(shù)據(jù)庫。您可以在Panoply上管理“Admin”和“Editor”兩類角色。不過，Panoply平臺的用戶之間并無通信功能，而且關(guān)于該平臺中的數(shù)據(jù)對象和轉(zhuǎn)換的文檔也比較匱乏。

在Snowflake中，您可以細粒度地管控每一個賬戶，該如何訪問多個數(shù)據(jù)倉庫。與在傳統(tǒng)數(shù)據(jù)庫體系上所使用的訪問控制類似，您可以在這些數(shù)據(jù)倉庫中，自定義所有對象的權(quán)限，并創(chuàng)建不同的角色。

在Repods中，您可以讓每個用戶去管理多個數(shù)據(jù)倉庫(即Data Pods)，并為其他用戶提供類似于GitHub平臺的訪問權(quán)限。平臺預(yù)設(shè)的訪問角色包括：“查看者”、“報告者”、“開發(fā)者”、“管理員”和“所有者”。每個用戶都可以在各種pod中被分配到一個角色，而不同的數(shù)據(jù)表則會按照“標簽”進行分組。當然，每個用戶也可以根據(jù)“標簽”被單獨授權(quán)。由于該平臺具有實時性，因此用戶間的交互，會立即被所有其他用戶所發(fā)現(xiàn)。

數(shù)據(jù)歷史化(Data Historization)

隨著時間的推移，新生產(chǎn)的數(shù)據(jù)需要被添加到現(xiàn)有的數(shù)據(jù)庫存之中，因此數(shù)據(jù)倉庫往往需要能夠管理具有較長歷史的數(shù)據(jù)，而且它們需要能夠?qū)为毜臄?shù)據(jù)塊合并為同質(zhì)性的數(shù)據(jù)歷史。同時，為了持續(xù)管理和應(yīng)用數(shù)據(jù)歷史化，我們可以使用專有的時間區(qū)間列(time range column)，來跟蹤不同表格中的時間區(qū)間。

Repods支持開箱即用式的數(shù)據(jù)歷史化。歷史化一般會發(fā)生在數(shù)據(jù)轉(zhuǎn)換之后、以及插入庫表之前。對于緩慢變化的數(shù)據(jù)而言，該算法具有最大的空間效率。而這種最小化歷史記錄的方法，則能夠大幅減少表的體積，同時對數(shù)據(jù)查詢的整體性，產(chǎn)生有利的影響。

其他兩個平臺的數(shù)據(jù)歷史化時間范圍，是由用戶所提供的轉(zhuǎn)換邏輯來管理的。其中Panoply提供了一種被稱為“歷史表”的功能，我們下面會做進一步討論。

數(shù)據(jù)版本控制

通過數(shù)據(jù)版本化，您可以跟蹤一段時間內(nèi)數(shù)據(jù)的修改情況，以便按需恢復(fù)到舊的版本狀態(tài)，或?qū)ΜF(xiàn)有的數(shù)據(jù)采取非破壞性的修改。在比較云數(shù)據(jù)倉庫的版本控制能力時，您必須考慮創(chuàng)建版本的難易程度，以及恢復(fù)或查詢版本的難易程度。版本控制可以在不同的系統(tǒng)級別上進行處理：

• 在存儲子系統(tǒng)上創(chuàng)建版本的快照，就像備份一樣。
• 底層數(shù)據(jù)庫系統(tǒng)能夠支持版本的跟蹤。
• 版本控制可以交由數(shù)據(jù)倉庫系統(tǒng)來處理。
• 版本控制可以作為用戶空間中的一種自定義轉(zhuǎn)換邏輯來實現(xiàn)。

Panoply通過連續(xù)備份，來實現(xiàn)內(nèi)置的版本控制。您可以在已備份時間范圍內(nèi)，恢復(fù)到快照的任意時間點上，不過您無法使用此方法來查詢活動系統(tǒng)中的某個版本。在Panoply中，您還可以通過創(chuàng)建“歷史表”，將伴隨表(companion table)插入到原始表中。

當原始表上發(fā)生更新時，系統(tǒng)會自動將相同的記錄插入到，配有表示更改時間區(qū)間的伴隨表中。這些歷史表允許您使用SQL語句，查詢相同數(shù)據(jù)的不同版本。

使用Snowflake，您可以輕松地創(chuàng)建所有數(shù)據(jù)的快照，并獲得數(shù)據(jù)庫系統(tǒng)提供的“時間旅行”功能，即：允許您使用SQL語句靈活地查詢某個時間點的數(shù)據(jù)。不過，此功能僅向企業(yè)版開放，并只包含有90天的歷史記錄。也就是說，用戶必須自行實現(xiàn)更長時間段的版本控制邏輯。

目前，Repods尚未提供連續(xù)備份，以及為每個數(shù)據(jù)倉庫用例設(shè)計的版本跟蹤服務(wù)。您可以通過指定“凍結(jié)”時間戳，來確保數(shù)據(jù)的可恢復(fù)性。您可以使用簡單的SQL語句，靈活地查詢各種凍結(jié)時間(無限天數(shù))的數(shù)據(jù)。

分析/報告

數(shù)據(jù)平臺的一項最基本的任務(wù)是以各種不同的方式，對大量的原始數(shù)據(jù)予以分析，進而將數(shù)據(jù)存儲為更長的歷史記錄。

[[276651]]

如今有許多商業(yè)化的智能工具，都能夠從大型數(shù)據(jù)庫中提取并聚合數(shù)據(jù)，通過自動化分析，進而以可讀的方式展示出相關(guān)的報告。

Panoply和Snowflake都能夠為您提供SQL代碼編輯器，以創(chuàng)建數(shù)據(jù)轉(zhuǎn)換、分析與聚合。這兩個平臺允許您通過用戶名和密碼的ODBC(和類似工具)工具來進行訪問。因此，您可以使用諸如Jupyter workbooks或PowerBI之類的專用分析工具，來分析自己的數(shù)據(jù)。不過，您無法使用平臺上的資源，來運行Python或訓練機器學習模型。同時，您也無法將這些workbooks的結(jié)果集成到平臺內(nèi)的數(shù)據(jù)工作流之中。

目前，Repods雖然不允許用戶使用外部工具來訪問該平臺，但是它為用戶提供了獨有的workbooks類型，可創(chuàng)建各種數(shù)據(jù)故事(data stories)和分析摘錄(analytical extracts)。此處的workbooks是指由許多SQL代碼面板、以及文檔面板所組成的工作表(用到了“Markdown”)。當然，除了workbooks樣式的分析，Repods還包含一個OLAP(在線分析處理)的界面，您可以使用點擊的方式，來獲悉數(shù)據(jù)模型、或創(chuàng)建報告結(jié)果。

數(shù)據(jù)科學

創(chuàng)建機器學習模型是數(shù)據(jù)平臺需要提供的新的服務(wù)類型。目前，業(yè)界普遍采用帶有numpy、pandas、scikit learn、tensor flow和pytorch等專有庫的Python或R語言來實現(xiàn)。

不過，這些平臺都沒有直接提供在平臺上執(zhí)行數(shù)據(jù)科學任務(wù)的實現(xiàn)方法。因此，通常的策略是通過指定的工具來訪問平臺，并在平臺之外執(zhí)行所有與數(shù)據(jù)科學相關(guān)的任務(wù)。雖然有許多工具可以選擇，但是我們可能會面臨著需要依靠可托管的計算資源，才能支持那些嚴苛的機器學習任務(wù)的挑戰(zhàn)。

外部訪問和API

我們將從如下幾個方面，來比較三個平臺是如何向外部用戶展示其數(shù)據(jù)內(nèi)容的：

• SQL訪問。
• API訪問(REST請求)。
• 通過文本推送或電子郵件通知。
• 文件導出。

Panoply允許用戶直接以類似ODBC的方式，訪問由用戶名和密碼保護的平臺。目前幾乎所有標準化的商業(yè)智能工具(如Looker或Tableau)，都可以連接到Panoply上，并使用其數(shù)據(jù)。Panoply雖然能夠跟蹤系統(tǒng)的警報，但是它不會向用戶發(fā)送短信或電子郵件。

Snowflake既能夠為其他工具提供SQL訪問及其數(shù)據(jù)，也可以將文件導入云存儲桶(AWS S3或MS Azure)。不過，用戶僅能為一般性的Snowflake服務(wù)設(shè)置可用性的電子郵件通知方式。

在Repods中，您可以創(chuàng)建API訪問密鑰，并控制對于平臺數(shù)據(jù)的提取訪問。通過將這些訪問密鑰分發(fā)給外部使用者，他們能夠使用任何一種編程語言的標準化REST請求，來訪問平臺的數(shù)據(jù)資源。籍此，您也可以將商業(yè)智能化工具PowerBI連接到Repods平臺，以創(chuàng)建各種儀表板，并通過瀏覽器直接導出、下載無限大小的文件。不過，該平臺目前并不提供任何類型的推送通知。

文檔

由于數(shù)據(jù)工程往往并非一次性的偶然需求，因此各大平臺都需要提供完備的功能介紹和詳盡的信息文檔。

Snowflake提供了豐富的在線文檔。由于大量使用到了SQL語句，因此這些文檔在結(jié)構(gòu)上與數(shù)據(jù)庫及編程語言的文檔十分相似。而且，其文檔的大部分內(nèi)容都會涉及到SQL的有關(guān)功能。此外，Snowflake還提供了許多指南和YouTube視頻，以幫助用戶更好地熟悉和試用該平臺。

Panoply也提供了在線文檔，不過其詳細程度不及Snowflake。當然，由于Panoply直接向用戶公開了其用以SQL訪問的底層Amazon Redshift，因此用戶可以直接參考Amazon Redshift的SQL文檔。除了提供數(shù)據(jù)倉庫的通用指南，Panoply也提供了一些YouTube的教程。

Repods只為其Web API的使用，提供了單獨的在線文檔。例如：如何通過Python、JavaScript和PHP，并使用RESTful Web請求，來訪問Repods中的數(shù)據(jù)。通常，該平臺會將各種使用文檔直接嵌入到其相應(yīng)的工具之中。與Panoply類似，用戶可以直接參考原始的Postgres文檔，以獲得SQL的支持。此外在Medium.com上，Repods有著一系列的技術(shù)文章、以及YouTube類型的詳解視頻。

安全

通常，數(shù)據(jù)平臺的安全性主要體現(xiàn)在存儲(靜態(tài)的數(shù)據(jù))、交互(傳輸中的數(shù)據(jù))和訪問控制上。目前，這三個平臺都能夠加密靜態(tài)與傳輸中的數(shù)據(jù)。而對于訪問控制而言，它們都提供了基于密碼的用戶身份驗證。

此外，Snowflake還提供了最為安全的雙因素身份認證機制。而Panoply和Snowflake則允許您通過類似于ODBC的接口，來訪問底層的數(shù)據(jù)庫。為了減少暴露在互聯(lián)網(wǎng)上的公開數(shù)據(jù)庫端口，用戶可以(并且也應(yīng)該)使用安全的ssh-tunneling、以及專門的跳轉(zhuǎn)主機(jump-host)方式，來實現(xiàn)訪問。

結(jié)論

如果您想構(gòu)建一個完整的數(shù)據(jù)倉庫平臺，Snowflake和Panoply需要與其他工具相結(jié)合，以實現(xiàn)查缺補漏。由于會涉及到SQL代碼，因此這三個平臺都需要用戶具備基本的數(shù)據(jù)工程專業(yè)知識。

如果您需要用于數(shù)據(jù)分析的在線數(shù)據(jù)庫架構(gòu)，又不想在系統(tǒng)和硬件管理上投入太多的話，那么Snowflake是一個不錯的選擇，它更適合大型的數(shù)據(jù)環(huán)境，當然也需要數(shù)據(jù)庫管理員來進行平臺管理。如前所述，Snowflake與常規(guī)數(shù)據(jù)庫十分相似，如果您的數(shù)據(jù)需求并不特殊的話，則完全可以選擇那些在AWS上托管的數(shù)據(jù)庫。

Panoply比Snowflake更為簡單，它不需要用戶具備系統(tǒng)、硬件和數(shù)據(jù)庫管理的專業(yè)技術(shù)。相對于其他兩個平臺，Panoply更適合于不太復(fù)雜的數(shù)據(jù)環(huán)境。

Repods的簡單性、以及對于用戶的技術(shù)要求，與Panoply類似。Repods在數(shù)據(jù)倉庫方面的功能還包括：自動化、歷史記錄、代理鍵(surrogate key)的維護與分析。Repods的管理界面非常適合于面向項目的數(shù)據(jù)倉庫方法(project-oriented approach)，而不是大型的中央數(shù)據(jù)倉庫架構(gòu)。同時，Repods也可以被用于數(shù)據(jù)編錄。

原文標題：A Cloud Data Warehouse Comparison，作者：Melissa Rojas Tänzer

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】