云数据仓库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级的在线扩展,但是其扩展计算资源的过程仍需要几秒钟的数据仓库停机时间,而且并不具有容量弹性。您可以为每个帐户创建、管理和共享多个数据仓库。不过,该平台中的不同数据仓库实例,主要依赖于那些尚未与群集中的任何其他实例共享的专用资源,并籍此实现稳定的查询性能。

导入接口

我们将导入接口分为如下四个部分:

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

  • 文件 - 仍然是最常见的数据形式。
  • 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语句,灵活地查询各种冻结时间(无限天数)的数据。

分析/报告

数据平台的一项最基本的任务是以各种不同的方式,对大量的原始数据予以分析,进而将数据存储为更长的历史记录。

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

如今有许多商业化的智能工具,都能够从大型数据库中提取并聚合数据,通过自动化分析,进而以可读的方式展示出相关的报告。

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

相关推荐