云数据仓库Snowflake、Panoply和Repods的全面大比拼

【51CTO.com快译】介绍

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更适合于不太复杂的数据环境。