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请求