Snowflake、Panoply和Repods是三種允許您在託管雲架構中提取、處理、存儲和訪問數據的雲端服務。區別於其他只能提供數據呈現與處理的雲服務，這些平臺能夠為海量的數據提供計算與存儲資源，因此我們常稱之為雲數據倉庫平臺。
以存儲和處理數據為核心功能的數據倉庫服務，為數據的整體性管理與分析提供了堅實的雲平臺基礎。由於這三個平臺的受眾並非完全相同，因此我們可能無法直接對它們的所有方面進行全面比較。特別對於Panoply和Snowflake，我們只是從它們在網上公開的資料來進行分析。
架構
Panoply綜合使用到了Amazon Redshift數據服務、Elasticsearch數據庫、Amazon S3存儲、以及Spark計算架構。Amazon Redshift是一個可擴展的數據庫，它源自Postgres數據庫架構、並增加了集群的功能。不過，它僅能作為Amazon Web Service來運行。
該體系架構能夠通過向群集裡添加更多的節點，以實現在線擴展。由於不同的Panoply客戶端都能夠共享相同的基礎架構，因此在某個客戶端上出現的高流量的查詢負載時，其他客戶端的查詢性能可能會受到影響。通過Panoply，您能夠創建多個Amazon Redshift類型的數據庫。因此從某種意義上說，此類數據庫雖然具有單獨的存儲區域，但是它們仍共享相同的查詢引擎(即DBMS系統)。
Snowflake雖然並未詳細地披露其底層架構，但總體而言，它能夠通過一個在線擴展的平臺，來清晰地分離出存儲和計算資源。Snowflake允許您在同一個帳戶中創建和管理多個數據倉庫。您既可以詳細地配置每個倉庫的計算群集尺寸，又可以為每個倉庫配置好自動在線縮放的規則，即：在不中斷服務的情況下實現縱向擴展(在一臺計算機上使用更多的資源)、以及橫向擴展(引入更多的計算資源)。當然，為了確保每個倉庫具有穩定的性能，Snowflake的數據倉庫並不共享計算資源，而且會使用外部工具來直接訪問數據庫。
Repods的基礎架構包括原生的PostgreSQL(版本在10以上)、以及TimescaleDB。該數據庫可被用於大時間跨度的分區數據，存儲集群管理、擴展存儲、以及許多與數據倉庫相關的服務。目前，雖然Repods能夠提供可靠的I/O速度和PB級的在線擴展，但是其擴展計算資源的過程仍需要幾秒鐘的數據倉庫停機時間，而且並不具有容量彈性。您可以為每個帳戶創建、管理和共享多個數據倉庫。不過，該平臺中的不同數據倉庫實例，主要依賴於那些尚未與群集中的任何其他實例共享的專用資源，並籍此實現穩定的查詢性能。
導入接口
我們將導入接口分為如下四個部分：
- 文件 - 仍然是最常見的數據形式。
- Web服務 - 網上有大量相關的數據。
- 數據庫 – 通常，各類數據存儲在不同組織的傳統數據庫中，而組織對這些數據庫的訪問，一般不會暴露到互聯網上，因此它們無法直接用到雲數據平臺。那麼Web服務可以被放置在內部部署的數據庫、以及雲服務之間，從而處理訪問控制等安全相關問題。當然，另一種方法則是在安全跳轉的主機上使用ssh-tunneling。
- 實時流 - 實時數據流是由各種消息路由器來傳遞的。隨著物聯網的興起，它們將會變得越來越重要。
Panoply在上述四個方面都提供了大量的導入選項。不過，據我們所掌握的信息，Panoply既不能根據自動化計劃，從雲存儲桶(bucket)或SFTP中提取文件;又不能根據計劃去請求RESTful URL。
Snowflake雖然只專注於加載文件(如cat.II)，但是它允許您從雲存儲處加載包括Amazon S3或Microsoft Azure之類的文件。Snowflake可以讓您監控新的文件到達，並及時加載它們。
在Repods中，您可以上載文件，從S3 Buckets處加載文件、或從外部SFTP服務器處加載數據。Repods並不為所有可能的Web服務提供單獨的接口，不過它提供了一個可用於為任何類型的服務(例如Socrata)接受Web請求的通用API。雖然用戶無法在各個數據庫之間導入/出數據，但是他們可以通過Repods，訂閱和接收消息路由器(目前為WAMPonly)上的不同主題，以便以微批次(micro-batches)的方式提取數據。
數據轉換ETL
通常，被導入數據平臺的數據必須經過類型轉換，才能在數據流中被予以分析。該過程通常被稱為ETL(提取、轉換、加載)，包括：為原始數據創建表格，分配數據類型，過濾數值，連接現有的數據，創建派生列/行，以及將各種自定義的邏輯應用到原始數據上。
業界常把創建和管理ETL的過程稱為數據工程。此過程不但耗時，而且耗費管理人員的精力。一些較大的數據倉庫往往會包含數千個具有不同階段、依賴關係、以及處理順序的ETL過程。
在Panoply中，您可以使用代碼來創建數據轉換。針對每一次數據訪問，有的轉換能夠提供重新計算的虛擬結果(“視圖”);有的則能夠保存重新計算的工作量。據我們所知，在Panoply中，如果數據已經實現，則必須手動刷新數據以獲取更新。例如：在出現新的數據時，用戶必須點擊刷新以執行轉換。
根據源的大小和轉換的複雜性，我們可以禁止將中間性的結果，存儲到專門的管理性結果表中。而常見的做法是：將新數據的增量加載到表中已有的數據裡。當然， Panoply並不提供對於歷史記錄的具體支持。
Snowflake在處理數據轉換方面，採用了與Panoply類似的方法。您可以使用Snowflake的SQL語句在表單式SQL查詢中實現數據轉換，然後按需在新的表中予以後期處理。在Snowflake中，您可以對數據對象進行低級別的控制，就像使用Postgres、MySQL、Oracle或DB2之類的傳統數據庫系統一樣，您可以去創建表、索引、視圖、查詢、以及分區等。
另外，Snowflake還允許您查詢在某個特定時間點(最多90天前)的表格狀態。不過，Snowflake並不支持“開箱即用”式的數據自動化歷史記錄。
在Repods中，您可以創建所謂的“管道(Pipe)”，將原始數據轉換為特定的數據倉庫表(如Evo表)。在這些查詢中，由於實際插入的目標表會依靠諸如：刪除重複數據、生產密鑰、記錄歷史日誌、以及控制版本等技術，來實現集成式的後期處理，因此您不必為每一個轉換都重新制定數據的插入策略。
監控
通常，大型數據倉庫系統可以輕鬆地容納幷包含數百個數據表，以及數百個管理數據流的自動ETL過程。不過，它們在運行過程中難免會出現錯誤，而且其中的一些錯誤需要人工進行干預。針對此類複雜性，我們需要通過監控來獲悉平臺的狀況。
在Panoply中，您可以查看到已執行的各種查詢、以及作業的歷史記錄。通過警報視圖，您可以獲悉服務和其他資產的問題、及其來源。各種查詢日誌會根據每隔幾秒的輪詢服務，予以更新(並非實時刷新)。
Snowflake通過監控報告，為您提供在特定時間範圍內，活動查詢的數量、及其資源消耗的彙總信息。在Snowflake中，您可以使用SQL語句來訪問各種內部元數據表(metadata table)，並提取系統中查詢活動的相關信息類型。同時，Snowflake還能在Web界面中顯示曾經執行過的歷史查詢操作。
Repods通過提供實時更新的圖形概覽，以顯示當前和歷史執行過的管道詳細信息。Repods還允許您使用SQL語句來分析系統的日誌，並提取有關管道執行的信息類型。
實用性
在對於用戶、數據倉庫、表格、轉換、報告等對象的創建與管理方面，雲端工具通常會根據目標用戶平衡控制級別與易用水平。此處的三個平臺由於本質上都屬於雲端環境，因此用戶可以使用基於瀏覽器的Web應用，來直接進行訪問與管控。具體而言：
Snowflake為用戶提供了類似數據庫系統的高級可控功能。用戶可以在代碼面板中編寫、導入、製表、視圖、索引之類的處理代碼;並且通過Web表單，來處理諸如創建和刪除整個數據倉庫及其用戶等任務。不過，其Web界面並不能自動響應平臺上的各項活動，用戶需要通過定期刷新其視圖(每10秒刷新一次)，來實現更新。
在Panoply中，用戶通過Web表單來處理對象的創建、以及有關數據導入的設置，而進一步的數據變換與分析，則需要通過代碼面板才能實現。此外，Panoply僅能夠提供英文版的界面。
在Repods中，用戶能夠通過Web表單來處理對象的創建，並且在代碼面板中處理各種自定義的轉換邏輯。就Repods的數據分析而言，用戶既可以使用工作簿樣式(workbook-style)方法，來創建自定義的分析查詢，也可以使用內置的OLAP工具，通過點擊來快速獲悉數據模型。
多用戶工作流程
此處主要比較的是：用戶交互、以及數據與工作內容的共享支持。總的說來，這三個平臺都允許多個用戶在同一個數據環境中開展協同工作。當然，它們都無法提供在線討論或聊天的功能。
Panoply為所有用戶提供了一個基礎架構式的環境，用戶可以在此架構上創建多個Amazon Redshift數據庫。您可以在Panoply上管理“Admin”和“Editor”兩類角色。不過，Panoply平臺的用戶之間並無通信功能，而且關於該平臺中的數據對象和轉換的文檔也比較匱乏。
在Snowflake中，您可以細粒度地管控每一個賬戶，該如何訪問多個數據倉庫。與在傳統數據庫體系上所使用的訪問控制類似，您可以在這些數據倉庫中，自定義所有對象的權限，並創建不同的角色。
在Repods中，您可以讓每個用戶去管理多個數據倉庫(即Data Pods)，併為其他用戶提供類似於GitHub平臺的訪問權限。平臺預設的訪問角色包括：“查看者”、“報告者”、“開發者”、“管理員”和“所有者”。每個用戶都可以在各種pod中被分配到一個角色，而不同的數據表則會按照“標籤”進行分組。當然，每個用戶也可以根據“標籤”被單獨授權。由於該平臺具有實時性，因此用戶間的交互，會立即被所有其他用戶所發現。
數據歷史化(Data Historization)
隨著時間的推移，新生產的數據需要被添加到現有的數據庫存之中，因此數據倉庫往往需要能夠管理具有較長曆史的數據，而且它們需要能夠將單獨的數據塊合併為同質性的數據歷史。同時，為了持續管理和應用數據歷史化，我們可以使用專有的時間區間列(time range column)，來跟蹤不同表格中的時間區間。
Repods支持開箱即用式的數據歷史化。歷史化一般會發生在數據轉換之後、以及插入庫表之前。對於緩慢變化的數據而言，該算法具有最大的空間效率。而這種最小化歷史記錄的方法，則能夠大幅減少表的體積，同時對數據查詢的整體性，產生有利的影響。
其他兩個平臺的數據歷史化時間範圍，是由用戶所提供的轉換邏輯來管理的。其中Panoply提供了一種被稱為“歷史表”的功能，我們下面會做進一步討論。
數據版本控制
通過數據版本化，您可以跟蹤一段時間內數據的修改情況，以便按需恢復到舊的版本狀態，或對現有的數據採取非破壞性的修改。在比較雲數據倉庫的版本控制能力時，您必須考慮創建版本的難易程度，以及恢復或查詢版本的難易程度。版本控制可以在不同的系統級別上進行處理：
- 在存儲子系統上創建版本的快照，就像備份一樣。
- 底層數據庫系統能夠支持版本的跟蹤。
- 版本控制可以交由數據倉庫系統來處理。
- 版本控制可以作為用戶空間中的一種自定義轉換邏輯來實現。
Panoply通過連續備份，來實現內置的版本控制。您可以在已備份時間範圍內，恢復到快照的任意時間點上，不過您無法使用此方法來查詢活動系統中的某個版本。在Panoply中，您還可以通過創建“歷史表”，將伴隨表(companion table)插入到原始表中。
當原始表上發生更新時，系統會自動將相同的記錄插入到，配有表示更改時間區間的伴隨表中。這些歷史表允許您使用SQL語句，查詢相同數據的不同版本。
使用Snowflake，您可以輕鬆地創建所有數據的快照，並獲得數據庫系統提供的“時間旅行”功能，即：允許您使用SQL語句靈活地查詢某個時間點的數據。不過，此功能僅向企業版開放，並只包含有90天的歷史記錄。也就是說，用戶必須自行實現更長時間段的版本控制邏輯。
目前，Repods尚未提供連續備份，以及為每個數據倉庫用例設計的版本跟蹤服務。您可以通過指定“凍結”時間戳，來確保數據的可恢復性。您可以使用簡單的SQL語句，靈活地查詢各種凍結時間(無限天數)的數據。
分析/報告
數據平臺的一項最基本的任務是以各種不同的方式，對大量的原始數據予以分析，進而將數據存儲為更長的歷史記錄。
如今有許多商業化的智能工具，都能夠從大型數據庫中提取並聚合數據，通過自動化分析，進而以可讀的方式展示出相關的報告。
Panoply和Snowflake都能夠為您提供SQL代碼編輯器，以創建數據轉換、分析與聚合。這兩個平臺允許您通過用戶名和密碼的ODBC(和類似工具)工具來進行訪問。因此，您可以使用諸如Jupyter workbooks或PowerBI之類的專用分析工具，來分析自己的數據。不過，您無法使用平臺上的資源，來運行Python或訓練機器學習模型。同時，您也無法將這些workbooks的結果集成到平臺內的數據工作流之中。
目前，Repods雖然不允許用戶使用外部工具來訪問該平臺，但是它為用戶提供了獨有的workbooks類型，可創建各種數據故事(data stories)和分析摘錄(analytical extracts)。此處的workbooks是指由許多SQL代碼面板、以及文檔面板所組成的工作表(用到了“Markdown”)。當然，除了workbooks樣式的分析，Repods還包含一個OLAP(在線分析處理)的界面，您可以使用點擊的方式，來獲悉數據模型、或創建報告結果。
數據科學
創建機器學習模型是數據平臺需要提供的新的服務類型。目前，業界普遍採用帶有numpy、pandas、scikit learn、tensor flow和pytorch等專有庫的Python或R語言來實現。
不過，這些平臺都沒有直接提供在平臺上執行數據科學任務的實現方法。因此，通常的策略是通過指定的工具來訪問平臺，並在平臺之外執行所有與數據科學相關的任務。雖然有許多工具可以選擇，但是我們可能會面臨著需要依靠可託管的計算資源，才能支持那些嚴苛的機器學習任務的挑戰。
外部訪問和API
我們將從如下幾個方面，來比較三個平臺是如何向外部用戶展示其數據內容的：
- SQL訪問。
- API訪問(REST請求)。
- 通過文本推送或電子郵件通知。
- 文件導出。
Panoply允許用戶直接以類似ODBC的方式，訪問由用戶名和密碼保護的平臺。目前幾乎所有標準化的商業智能工具(如Looker或Tableau)，都可以連接到Panoply上，並使用其數據。Panoply雖然能夠跟蹤系統的警報，但是它不會向用戶發送短信或電子郵件。
Snowflake既能夠為其他工具提供SQL訪問及其數據，也可以將文件導入雲存儲桶(AWS S3或MS Azure)。不過，用戶僅能為一般性的Snowflake服務設置可用性的電子郵件通知方式。
在Repods中，您可以創建API訪問密鑰，並控制對於平臺數據的提取訪問。通過將這些訪問密鑰分發給外部使用者，他們能夠使用任何一種編程語言的標準化REST請求，來訪問平臺的數據資源。籍此，您也可以將商業智能化工具PowerBI連接到Repods平臺，以創建各種儀表板，並通過瀏覽器直接導出、下載無限大小的文件。不過，該平臺目前並不提供任何類型的推送通知。
文檔
由於數據工程往往並非一次性的偶然需求，因此各大平臺都需要提供完備的功能介紹和詳盡的信息文檔。
Snowflake提供了豐富的在線文檔。由於大量使用到了SQL語句，因此這些文檔在結構上與數據庫及編程語言的文檔十分相似。而且，其文檔的大部分內容都會涉及到SQL的有關功能。此外，Snowflake還提供了許多指南和YouTube視頻，以幫助用戶更好地熟悉和試用該平臺。
Panoply也提供了在線文檔，不過其詳細程度不及Snowflake。當然，由於Panoply直接向用戶公開了其用以SQL訪問的底層Amazon Redshift，因此用戶可以直接參考Amazon Redshift的SQL文檔。除了提供數據倉庫的通用指南，Panoply也提供了一些YouTube的教程。
Repods只為其Web API的使用，提供了單獨的在線文檔。例如：如何通過Python、JavaScript和PHP，並使用RESTful Web請求，來訪問Repods中的數據。通常，該平臺會將各種使用文檔直接嵌入到其相應的工具之中。與Panoply類似，用戶可以直接參考原始的Postgres文檔，以獲得SQL的支持。此外在Medium.com上，Repods有著一系列的技術文章、以及YouTube類型的詳解視頻。
安全
通常，數據平臺的安全性主要體現在存儲(靜態的數據)、交互(傳輸中的數據)和訪問控制上。目前，這三個平臺都能夠加密靜態與傳輸中的數據。而對於訪問控制而言，它們都提供了基於密碼的用戶身份驗證。
此外，Snowflake還提供了最為安全的雙因素身份認證機制。而Panoply和Snowflake則允許您通過類似於ODBC的接口，來訪問底層的數據庫。為了減少暴露在互聯網上的公開數據庫端口，用戶可以(並且也應該)使用安全的ssh-tunneling、以及專門的跳轉主機(jump-host)方式，來實現訪問。
結論
如果您想構建一個完整的數據倉庫平臺，Snowflake和Panoply需要與其他工具相結合，以實現查缺補漏。由於會涉及到SQL代碼，因此這三個平臺都需要用戶具備基本的數據工程專業知識。
如果您需要用於數據分析的在線數據庫架構，又不想在系統和硬件管理上投入太多的話，那麼Snowflake是一個不錯的選擇，它更適合大型的數據環境，當然也需要數據庫管理員來進行平臺管理。如前所述，Snowflake與常規數據庫十分相似，如果您的數據需求並不特殊的話，則完全可以選擇那些在AWS上託管的數據庫。
Panoply比Snowflake更為簡單，它不需要用戶具備系統、硬件和數據庫管理的專業技術。相對於其他兩個平臺，Panoply更適合於不太複雜的數據環境。
Repods的簡單性、以及對於用戶的技術要求，與Panoply類似。Repods在數據倉庫方面的功能還包括：自動化、歷史記錄、代理鍵(surrogate key)的維護與分析。Repods的管理界面非常適合於面向項目的數據倉庫方法(project-oriented approach)，而不是大型的中央數據倉庫架構。同時，Repods也可以被用於數據編錄。
