介绍
雪花、Panoply 和 Repods 是云服务，允许您在托管云基础架构中引入、处理、存储和访问数据。特别是，每个服务都为数据提供计算和存储资源。这些被视为我们所称的云数据仓库平台的决定性功能，并使它们与其他云数据服务区分开来，这些服务允许您在云中显示或处理数据，但不允许大量存储数据。
尽管存储和处理数据是数据仓库的核心，但它并没有止步于此。数据仓库要作为分析的长期可管理基础，需要更多的功能。为了很好地了解总体数据管理任务，我们从有关数据工程和分析生命周期的相当完整的标准列表开始。这三个平台的目标不是完全相同的受众和功能集，因此，并非所有平台都具有直接的可比性。关于Panoply和雪花，比较仅基于他们在互联网上公开分享的信息。
建筑
Panoply使用亚马逊红移数据服务以及弹性搜索数据库和 Amazon S3 存储和Spark 计算架构。Amazon 红移是一个可扩展的数据库，其根位于 Postgres 数据库体系结构中，并添加了群集功能;它仅作为亚马逊网络服务运行。
此体系结构允许通过将更多的节点添加到群集进行联机扩展。不同的 Panoply 客户端共享相同的基础结构，因此一个客户端的查询负载要求很高，可能会影响另一个客户端的查询性能。（事实上，Panoply 会管理数据库在引擎盖下的位置，并有可能将数据库定位在单独的 Redshift 群集上。使用 Panoply，您应该能够创建多个数据库，然后这些数据库只是 Amazon Redshift 数据库。从这个意义上说，数据库具有单独的存储区域，但共享相同的查询引擎（即 DBMS 系统）。
Snowflake没有详细披露 Snowflake 的基础体系结构层，但总体而言，它们还使用具有明确存储和计算资源分离的在线扩展平台。Snowflake 允许您在一个帐户中创建和管理多个数据仓库。您可以详细配置每个仓库的计算群集大小，甚至可以为每个仓库配置联机自动缩放。在 Snowflake 中，您可以进行扩展（在一台计算机上提供更多资源）以及横向扩展（更多计算机），而不会中断任何服务。Snowflake 中的数据仓库不共享计算资源以确保每个仓库的稳定性能。Snowflake 使用外部工具提供直接数据库访问，就像它们是数据库的本地工具一样。
Repods基础体系结构由本机PostgreSQL（版本>10）和 TimescaleDB 组成，用于处理大量时间分区数据以及许多其他与数据仓库相关的服务。通过专用存储群集管理和扩展存储，提供可靠的 IO 速度和在线 PB 扩展您可以创建、管理和共享每个帐户的多个数据仓库。平台中的不同数据仓库实例依赖于未与群集中任何其他实例共享的专用资源，以便获得稳定的查询性能。
导入接口
我们将导入接口分为四个不同的部分。
-
文件– 仍然是最常见的数据形式。
-
Web 服务– 网上提供大量相关数据。
-
数据库– 尽管数据存储在许多组织中的传统 d 数据库中，但在大多数情况下，直接数据库访问不会暴露给 Internet，因此不适用于云数据平台。Web 服务可以放置在内部数据库和云服务之间，以处理安全方面和访问控制。另一种选择是在安全跳转主机上使用ssh隧道。
-
实时流– 实时数据流由消息传送路由器传送，如今并未被大量使用，但随着 IoT 的兴起，这些数据流将变得更加重要。
Panoply在所有四个类别中都具有大量的导入选项。但是，根据我们的信息，Panoply 既不能根据自动计划从云存储桶或 SFTP 中提取文件，也不能根据计划请求 RESTful URL。
雪花专注于只加载文件（猫。II），但它允许您从云存储加载文件，包括 Amazon S3 或 Microsoft Azure。Snowflake 允许您观察新文件到达的源并自动加载它们。
在Repods中，您可以上传文件、从 S3 存储桶加载文件，或从外部 SFTP 服务器加载数据，包括自动加载新文件。Repods 不为您提供 Web 上所有可能服务的单独接口，但它为您提供了一个通用 API 来安排来自任何类型的服务的 Web 请求（例如Socrata）。Repods 不允许从数据库导入数据。使用 Repods，您可以订阅和侦听有关消息路由器（当前为 WAMPonly）的主题，以在可配置的微批处理中引入数据。
数据转换 ETL
导入到数据平台的数据通常必须经过一些数据转换才能用于流下分析。此过程传统上称为ETL（提取、转换、加载）。这些进程通常从原始数据创建表、分配数据类型、筛选值、联接现有数据、创建派生列/行以及将所有类型的自定义逻辑应用于原始数据。
创建和管理 ETL 进程有时称为数据工程，是任何数据环境中最耗时的任务。在大多数情况下，此任务占整个人类努力的 80%。较大的数据仓库可以包含数千个具有不同阶段、依赖项和处理序列的 ETL 进程。
在Panoply中，您可以使用代码创建数据转换。这些转换要么提供虚拟数据结果，每次访问数据（”视图”）时都会重新计算，要么实现，以保存每次访问的重新计算工作量例如，如果源中有新数据，您必须点击刷新才能执行转换。
根据源的大小和转换的复杂性，不将中间结果存储在专用和托管的结果表中可能令人望而却步。一个非常常见的模式是将新数据正确增量加载到表中现有的数据中。根据要求，这可能涉及非常复杂的转换。Panoply 不为组织化提供具体支持。（请参阅下面的组织化部分。
Snowflake在处理数据转换方面与 Panoply 有着类似的方法。您可以使用 Snowflake SQL 方言在形式 SQL 查询中实现数据转换，然后根据您认为合适的方式将它们具体化到新表中。在 Snowflake 中，您可以对数据对象进行低级控制，这使得它可与使用纯数据库相媲美。您可以创建表、索引、视图、查询、分区等，就像在许多其他传统数据库系统中（如 Postgres、MySQL、Oracle 或 DB2）中一样。
Snowflake 包括一个高级时间旅行功能，允许您查询在特定时间点（最多 90 天）看到的表。在 Postgres 数据库中，由于高性能开销和复杂性，此功能早已停止。雪花不支持开箱即用的自动数据进行系统化。
在Repods中，您可以创建所谓的”Pipes”，将原始数据转换为特定的数据仓库表 （Evo 表）。转换也使用 Postgres SQL 查询创建。在这些查询中，您不必为每个转换重新实现数据插入策略，因为实际插入到目标表中始终由集成的后处理处理，该流程应用重复数据消除、密钥生成、密钥生成、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据消除、重复数据消除、重复数据、重复数据、重复数据、重复数据、重复数据、重复数据、重复、再给、重复、转换、转换和版本控制。
监测
较大的数据仓库系统可以轻松包含数百个表，其中包含数百个管理数据流的自动化 ETL 流程。运行时的错误几乎是不可避免的，其中许多错误必须通过手动干预来处理。有了这种复杂性，您肯定需要一种方法来监视平台中发生的情况。
在Panoply中，您可以查看已执行查询和执行作业的历史记录。您会收到一个警报视图，其中列出了源、服务和其他资产中的问题。查询日志每隔几秒钟轮询服务器以获取更新（没有实时刷新）。
Snowflake附带了监视报告，可汇总有关特定时间范围内活动查询数及其资源消耗的信息。在 Snowflake 中，您可以使用 SQL 访问内部元数据表，以提取系统中查询活动的任何类型的信息。Snowflake 还会在 Web 界面中显示历史性的查询执行。
Repods提供实时更新的图形概述，显示当前和历史上执行的每个管道的详细信息。此概述允许您在方便的历史上下文中钻取数千个管道执行。您还可以在搜索抽屉中搜索特定的管道执行。Repods 还允许您使用 SQL 分析系统日志，以提取有关管道执行的任何类型的信息。
可用 性
这些工具的可用性在很大程度上取决于每个工具的目标受众。可用性是一个非常广泛和主观的类别，它考虑诸如在平台中创建和管理对象（用户、数据仓库、表、转换、报表等）是多么容易。通常，在用户获得的控制级别和简单级别之间存在权衡。
控制越简单，控制越少所有三个平台也遵循有关点和点击界面和使用代码的混合方法。
Snowflake为用户提供了与裸机数据库系统类似的显著控制级别。大多数此控件通过在代码面板（导入、表、视图、索引等）中编写代码来处理;创建和删除整个数据仓库和用户等主要任务可以通过 Web 窗体进行处理。Web 界面不响应平台上的活动，并通过定期刷新其视图来处理更新。（查询历史记录每 10 秒刷新一次。
在Panoply中，对象的创建通过 Web 窗体进行处理。导入的设置也可通过 Web 窗体进行处理，而转换和分析则通过代码面板输入。Panoply 只提供英文版本。
在Repods中，自定义转换逻辑在代码面板中处理，对象的创建通过 Web 窗体处理。对于 Repods 中的分析，可以使用工作簿样式的方法创建自定义分析查询，也可以使用内置 OLAP 工具使用点钻取数据模型，然后单击以快速洞察。
多用户工作流
此类别评估对用户交互以及工作和数据共享的支持。所有三个平台都允许多个用户在数据环境中协同工作。所有三个平台均没有讨论或聊天功能。
Panoply为所有用户提供了一个基础结构环境，但用户可以在此基础结构上创建多个 Amazon Redshift 数据库。Panoply 在平台上的用户之间没有通信功能，因此很少有机会为平台中的数据对象和转换提供文档。您可以在 Panoply 上使用角色”管理员”和”编辑”来管理团队。
在雪花中，每个帐户可以管理具有细粒度访问控制的多个数据仓库。与通常对数据库体系结构的访问控制类似，您可以创建具有数据仓库中所有对象自定义权限的自定义角色。
在Repods中，您可以管理每个用户中的多个数据仓库（”数据箱”），并为其他用户提供类似于 GitHub 平台的组织方式的访问。该平台是实时的，因为用户交互对所有其他用户都立即可见。访问角色有”查看器”、”报告人”、”开发人员”、”管理员”和”所有者”。每个用户可以在每个窗格中分配一个这些角色。在窗格中，可以使用”标签”对表进行分组，并且每个用户都可以在标签上单独授权。
数据数据化
管理较长的数据历史记录是每个数据仓库工作的核心。事实上，数据仓库任务本身可以概括为将单独的数据块合并到同质数据历史记录中的任务。数据是随着时间推移自然生成的，因此，需要增加现有数据库存，增加新数据。
为了有效地管理数据历史记录，使用了数据历史记录化。从技术上讲，使用专用的时间范围列跟踪表中的时间范围。当新数据到达时，有效地管理这些时间范围称为数据数据聚合)
Repods支持开箱即用的数据的分类。在插入到数据仓库表中之前，将在数据转换后应用数据化。该算法具有最大的空间效率，因为它最大限度地减少了表示历史记录的记录数。对于缓慢更改的数据，此方法可以大大减少表的大小，因此会对整体查询性能产生较大的有利影响。
在其他两个平台中，企业化时间范围由用户提供的转换逻辑管理。Panoply提供了一个他们称之为”历史记录表”的功能，根据我们的定义，将在下面的”数据版本控制”部分中讨论。
数据版本控制
通过对数据进行版本控制，您可以跟踪数据更正，以便以后恢复旧分析。版本控制允许您对现有数据应用非破坏性更正。在比较版本控制功能时，必须考虑创建版本的易用性以及恢复或查询版本的便利性。可以在系统的不同级别上处理版本控制：
-
在存储子系统上创建版本快照 ， 类似于备份。
-
基础数据库系统可能附带对版本跟踪的支持。
-
版本控制可能由数据仓库系统处理。
-
版本控制可以作为用户空间中的自定义转换逻辑实现。
最后一个变式是一个技术性和复杂的过程，但可以在所有三个系统中实施。
Panoply提供连续备份作为内置版本控制选项。您可以在备份时间范围内的任何时间恢复时间点快照，但不能使用此方法查询活动系统中的版本。在 Panoply 中，您还可以创建将配套表插入原始表的”历史记录表”。
当原始表上发生更新时，系统会自动将相同的记录插入到包含时间范围的配套表中，这些记录丰富了表示更改的时间范围。我们将此过程视为一个版本控制过程，因为托管时间范围基于技术插入时间戳，而不是业务有效性时间戳。这些历史记录表允许您使用 SQL 查询同一数据的不同版本。
使用Snowflake，您可以轻松创建所有数据的快照，并获得数据库系统提供的时间旅行功能。以后允许您使用 SQL 灵活地查询数据，如特定时间点所示。此功能仅在企业版中可用，涵盖 90 天的历史记录。用户必须实现较长期的版本控制逻辑。
Repods尚未提供连续备份，并附带针对每个数据仓库用例设计的版本跟踪。您可以指定”冻结”时间戳，以确保数据的可恢复性，如冻结时所示。您可以灵活地查询数据，就像使用简单的 SQL（无限天）在旧冻结时间所看到的那样。
版本控制通常伴随着在加载期间过度创建版本记录，从而吹大了表大小，从而对查询性能产生负面影响。为了避免这种情况，您可以指定第二个日期，以防止对比另一个日期更新的数据进行版本控制。例如，通过此功能，您可以在 10 月之前冻结所有数据，同时加载 10 月数据。
分析/报告
数据平台的目的是准备原始数据进行分析，并将此数据存储为较长的历史记录。分析可以以许多不同的方式进行。
分析和报告
有许多工具称为”商业智能工具”，仅涉及创建分析和人类可读的数据数据提取。为了准备用于表示的消耗性数据块，数据平台提供功能，以便从较大的数据库存创建数据提取和聚合。
Panoply和Snowflake为您提供 SQL 代码编辑器，用于创建用于创建数据转换的分析聚合。”雪花”将查询结果保存 24 小时。此外，这两个平台允许您通过由用户名和密码保护的 ODBC（和类似）使用其他工具访问平台。
因此，您可以使用各种专用分析工具（如 Jupyter 工作簿或 PowerBI）来分析您的数据。但是，不能使用平台资源来运行 Python 或训练机器学习模型。此外，您无法将这些工作簿的结果集成到平台内的数据工作流中。
Repods当前不允许使用外部工具访问平台。但是，Repods 为您提供了自己的工作簿样式来创建数据故事和分析数据提取。工作簿是由许多 SQL 代码面板和文档面板（使用”标记”）组成的工作表。除了工作簿样式分析外，Repods 还包含一个 OLAP（在线分析处理）界面，允许您使用点和单击方法钻取数据模型以创建报告结果。
数据科学
如今，创建机器学习模型是数据平台必须服务的新要求。大多数方法都是使用 Python 或 R 实现的，具有各种专用库，如 numpy、PANDAS、scikit 学习、张量流和 pytorch。
目前，没有任何平台能够直接在平台上执行数据科学任务。当前策略是使用指定的工具访问平台，并在平台之外执行所有与数据科学相关的任务。虽然这提供了一个伟大的工具选择，您可以选择，你再次面临着托管和管理计算资源，以支持可能非常苛刻的机器学习作业的挑战。
外部访问和 API
在这里，我们要比较三个平台如何向外部消费者展示其内容。此处考虑的可能通道包括
- SQL 访问。
- API 访问（REST 请求）。
- 通过文本推送或电子邮件发送通知。
- 文件导出。
Panoply提供对由用户名和密码保护的平台的直接 ODBC（或类似）访问。这使得几乎所有标准商业智能工具（如 Looker 或 Tableau）都能够连接到 Panoply 并使用数据。Panoply 跟踪系统警报，但不会为此向您的手机或电子邮件发送通知。
雪花还提供 SQL 访问，用于其他工具使用雪花内部的数据。此外，Snowflake 还提供了将文件导出到云存储桶（AWS S3 或 MS Azure）的可能性。”雪花”允许用户仅针对一般雪花服务可用性设置电子邮件通知。例如，如果法国的客户数量超过 1，000，则既不能设置系统推送通知，也不能设置基于内容的通知来提醒您。
在Repods中，您可以创建 API 访问密钥并控制对平台准备的数据提取的访问。然后，您可以将这些访问密钥分发到外部使用者，以便通过任何编程语言的标准 REST 请求访问这些资源。例如，通过这种方式，您可以将商业智能工具 PowerBI 连接到 Repods 平台以创建仪表板当前不支持任何类型的推送通知。
文档
所有三个平台都需要用户达到一定水平。数据工程不是一项临时任务。因此，专业使用平台时需要有关平台功能详细信息的适当文档。
雪花提供了最广泛的在线文档。它与数据库或编程语言的记录方式相当。对于雪花来说，这是必要的，因为大多数功能都是通过使用雪花自己的 SQL 方言提供的。因此，文档的大部分内容与雪花 SQL 功能有关。此外，Snowflake 还提供许多指南和 YouTube 视频，帮助您开始了解平台的整体使用情况。
Panoply还提供在线文档，但它不像雪花那样详细。部分地，这也是没有必要的，因为 Panoply 直接向用户公开基础 Amazon Redshift 表以进行 SQL-Access，因此 Amazon Redshift SQL 文档是 Panoply SQL 方言的有效参考。Panoply 还提供数据仓库的一般指导概念，并在 YouTube 上提供一些教程。
Repods仅对其 Web API 使用具有单独的联机文档。（即如何通过从 Python、JavaScript 和 PHP 的 RESTful Web 请求通过卷曲访问 Repods 中的数据。常规使用文档直接嵌入到工具中。与 Panoply 类似，SQL 代码方言的文档也没有必要，因为用户可以参考维护良好的原始 Postgres 文档。
对象的详细说明位于 Web 应用中管理对象的位置。此外，Repods 还有一系列关于Medium.com的文章和一些 YouTube 解说器视频。
安全
安全性通常可以在存储安全性（静止数据）、交互（传输中的数据）和访问控制中分离。所有三个平台都在静态和传输中加密数据。在访问控制方面，所有三个平台都提供基于密码的用户身份验证。雪花还提供了三个平台中最安全的双因素身份验证机制。
Panoply和Snowflake允许您通过具有直接服务器连接的类似于 ODBC 的接口访问基础数据库。公开 Internet 上的数据库端口可被视为安全风险，为了减轻此风险，在我看来，您可以使用具有专用跳转主机的安全 ssh 隧道来访问这些平台。
结论
为了构建一个完整的数据仓库平台，Snowflake 和 Panoply 需要与其他工具相结合，以涵盖数据仓库的缺失方面。最值得注意的是，数据转换的自动化是每个数据仓库体系结构的重要要求。根据组织上下文，数据仓库中通常限制的资源是需要提供信息的团队的技术熟练程度。
在这些情况下，需要管理和使用更多工具通常不是理想的解决方案。所有三个平台都需要用户提供基本的数据工程知识，因为所有三个平台都允许用户在平台的重要点使用 SQL 代码。
如果您正在寻找一个主要用于分析上下文的在线数据库体系结构，并且不想在系统和硬件管理方面进行投资，则Snowflake可能是一个不错的选择。Snowflake 明确要求数据库管理员管理平台，并解决更大的数据环境由于 Snowflake 的使用模式似乎与通用数据库非常相似，因此，如果您没有仅由 Snowflake 产品满足的特殊要求，则也可以选择在 AWS 上使用托管数据库。
泛光是一个比雪花更简单的平台。使用 Panoply 不需要系统、硬件和数据库管理知识。与雪花一样，Panoply 也遗漏了区分数据仓库和数据库的许多方面。目前，Panoply 似乎比其他两个平台更适合不太复杂的数据环境。
Repods比 Snowflake 更简单，因为它不需要用户提供任何管理硬件、系统或数据库知识。Repods 还涵盖了自动化、数据化、代理密钥维护和分析等主要数据仓库方面。Repods 管理接口非常适合面向项目的数据仓库方法，而不是大型中央数据仓库体系结构;Repods 可以描述为由数据仓库组成的数据目录。