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

来源:互联网 / 作者:SKY / 2019-09-12 15:16 / 点击:
您在找合适的云数据仓库平台吗?本文为您比较三种常见的平台,全面为你分析它们在不同方面的优缺点。

【Chinaz.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表)。在这些查询中,由于实际插入的目标表会依靠诸如:删除重复数据、生产密钥、记录历史日志、以及控制版本等技术,来实现集成式的后期处理,因此您不必为每一个转换都重新制定数据的插入策略。

监控

1
3