面向 AWS 专业人员的 Google Cloud 指南:大数据

更新时间:2019 年 10 月 30 日

本文将 Amazon 通过 Amazon Web Services (AWS) 提供的大数据服务与 Google 通过 Google Cloud 提供的大数据服务进行比较。

本文讨论以下几种服务类型:

  • 提取服务,用于将来源环境的数据提取到可靠且稳定的目标环境或数据类型。
  • 转换和准备服务,允许您过滤、提取数据,并将数据从一种数据类型或模型转换为另一种数据类型或模型。
  • 仓储和分析服务,允许您存储、分析和直观呈现处理后的数据,并与其进行交互。

提取服务

本部分比较了在 AWS 和 Google Cloud 中提取数据的方法。

连接

对于某些初始迁移,尤其是持续进行的数据提取,您通常会在目标云与其他网络之间使用高带宽网络连接。下表汇总了 AWS 和 Google Cloud 的连接选项。

功能 AWS Google Cloud
虚拟专用网 站点到站点 VPN Cloud VPN
与 VPC 的专用连接 Direct Connect 专用互连
合作伙伴互连
与其他云服务的高速连接 Direct Connect 直接对等互连
运营商对等互连

如需详细了解 Google Cloud 选项,请参阅面向 AWS 专业人员的 Google Cloud 指南:网络中的与其他网络的专用连接部分。

数据流提取

Amazon Kinesis Data StreamsGoogle Pub/Sub 均可用于将数据流提取到各自的云环境中。不过,这两项服务完成该任务所用的服务模式有所不同。

服务模型比较

下表比较了 Amazon Kinesis Data Streams 和 Pub/Sub 的特性。

功能 Amazon Kinesis Data Streams Pub/Sub
部署单元 数据流 主题
预配单元 分片 不适用(完全托管)
数据单元 记录 消息
数据源 制作者 发布者
数据目的地 使用者 订阅者
数据分区 用户提供的分区键 不适用(完全托管)
保留期限 最长 7 天 最长 7 天
数据传输顺序 服务提供的序列键(尽量遵循) 服务提供的发布时间(尽量遵循)
数据大小上限 1 MB 10 MB
部署位置 区域 全球
价格模式 按分片小时、PUT 负载单元和可选的数据保留期限 按消息提取和传输以及可选的消息保留期限
Amazon Kinesis Data Streams

Amazon Kinesis Data Streams 使用流式模型来提取数据。在该模型中,制作者将数据发送到您通过分片创建和预配的数据流中。数据流中的每个分片最多可提供每秒 1 MiB 的输入带宽和每秒 1000 次数据放置。

用户通过使用低级别 REST API 或更高级别的 Kinesis Producer Library (KPL) 将数据发送到 Amazon Kinesis Data Streams。该数据存储在数据记录中,数据记录包括以下信息:

  • 递增序列号
  • 用户提供的分区键
  • 数据 blob

分区键用于跨可用分片对记录执行负载平衡。默认情况下,记录会保留 24 小时。但是,用户最多可将该保留期限延长至 7 天。

用户可设置一个使用者应用,该应用按分片从数据流中检索数据记录,然后对其进行处理。应用负责处理跨可用分片的多路复用。将 Amazon 的 Kinesis 客户端库集成到您的应用可简化跨分片的多路复用,并可跨使用者应用节点的集群管理负载平衡和故障管理工作。

发布/订阅

Pub/Sub 是一种使用发布者/订阅者模型的消息传递服务。创建 Pub/Sub 主题后,您可以将数据发布到该主题,订阅该主题的每个应用可以从主题中检索提取的数据。这种方法无需定义具体容量,例如分片数量。

通过 Pub/Sub 注册的每个应用均可使用推送模型或拉取模型来检索消息:

  • 推送模型中,Pub/Sub 服务器在预配置网址端点向订阅者应用发送请求。
  • 拉取模型中,订阅者应用从服务器请求消息,然后在消息送达时确认收到。拉取订阅者可以异步或同步检索消息。

发布到主题的每条数据消息必须采用 base64 编码,并且大小不得超过 10 MiB。在提取时,Pub/Sub 会向每条数据消息添加 messageId 特性和 publishTime 特性。messageId 特性是一个消息 ID,该 ID 保证在该主题中是唯一的;publishTime 特性是提取数据时系统添加的时间戳。发布者可以通过键值对的形式向数据添加特性。

数据顺序

本部分介绍 Amazon Kinesis Data Streams 和 Pub/Sub 如何管理使用者或订阅者应用所请求数据的顺序。

Amazon Kinesis Data Streams

默认情况下,Amazon Kinesis Data Streams 通过使用分区键和序列号来维持数据顺序。当制作者向数据流添加记录时,会提供一个分区键,用于确定记录将发送到哪个分片。分片会向记录添加递增序列号,然后以可靠的方式存储记录。

使用者应用按分片请求记录,并按照序列号的顺序接收记录。此模型有助于按分片排序,但如果使用者应用跨分片发出请求,则无法保证排序。此外,一条记录可多次传递给使用者,因此应用必须强制执行“正好一次”语义。如需了解详情,请参阅 Amazon Kinesis Data Streams 文档中的处理重复记录

发布/订阅

Pub/Sub 会尽最大努力,使用系统提供的 publishTime 特性,按消息的发布顺序传送消息。Pub/Sub 不保证仅一次或按顺序传送:有时,它可能会不按顺序地多次传送消息。处理消息时,您的订阅者应该具有幂等性,并且必要时还应能够处理不按顺序接收的消息。

您可以使用应用提供的序列号和缓冲已处理的消息来实现更严格的排序。如果数据的最终目标是支持基于时间查询的持久存储服务(如 Firestore 或 BigQuery),则您也可以按时间戳对查询进行排序,从而以更严格的顺序查看数据。如果您的目标是 Dataflow,则可以使用记录 ID 来设定正好一次处理。

运营

本部分介绍每项服务上生产工作负载的操作和维护开销。

Amazon Kinesis Data Streams

由于 Amazon Kinesis Data Streams 的用户必须手动增加或减少分片,因此他们可能需要通过 Amazon CloudWatch 监控使用情况,并根据需要进行扩缩。该扩缩过程称为重新分片,只能逐个分片执行。重新分片支持两种操作:可以将一个分片拆分成两个分片,或者将两个分片合并成一个分片。因此,要将 N 个分片的容量加倍,需要进行 N 次分片拆分操作。

由于分片具有固定性,因此您应该逐个设计每个分片的容量。例如,如果您选用一个会将某个流量峰值指向单个分片的分区键,该峰值可能会远超单个分片的提取能力。简单的重新分片可能无法避免以后再出现此问题。在这种情况下,只有重新设计应用,使用不同的分区键,才能彻底解决问题。

您可以使用 Kinesis Data Firehose 来避免 Kinesis Data Streams 的分片管理工作。Kinesis Data Firehose 可为一个具体使用场景自动执行 Kinesis 数据流的管理、监控与扩缩:将数据流中的数据汇总到 Amazon S3 或 Amazon Redshift 中。用户指定 S3 存储分区或 Redshift 集群,然后 Kinesis Firehose 代表用户创建和管理数据流,按指定时间间隔将数据存放到指定的位置。

Amazon Kinesis 是区域级服务,数据流的范围限于特定区域。因此,提取的所有数据必须传送到定义了数据流的区域。

发布/订阅

Pub/Sub 不需要进行预配,它可以处理分片、复制和扩缩。

此外,您无需使用分区键,Pub/Sub 会代表您管理数据分区。虽然这些功能可显著减少管理开销,但也意味着 Pub/Sub 保证消息排序的能力也会下降。

Pub/Sub 使用 Google 的 HTTP(S) 负载平衡器跨所有 Google Cloud 区域在全球支持数据提取。当发布者将数据发布到 Pub/Sub 时,Google 的 HTTP(S) 负载平衡器可自动将流量定向到位于适当区域的 Pub/Sub 服务器,从而最大限度减少延迟时间。

费用

Amazon Kinesis Data Streams 按分片小时、数据量以及数据保留期限计费。默认情况下,数据会保留 24 小时。若延长保留期限,将产生额外的费用。由于 Amazon Kinesis Data Streams 使用的是预配的模型,因此即使您不使用预配的资源,也必须为之付费。

Amazon Kinesis Data Firehose 按数据量计费。

Pub/Sub 按数据量计费。由于 Pub/Sub 不需要进行资源预配,因此您只需为自己使用的资源付费。

批量提取

AWS Snowball 和 Google Transfer Appliance 都可用于将数据批量提取到各自的云环境。

AWS Snowball 提供 50 TB(仅限北美地区)和 80 TB 版本。Transfer Appliance 提供 100 TB 的版本(称为 TA100),以及 480 TB 的版本(称为 TA480)。

汇总比较

下表比较了 AWS Snowball 和 Google Transfer Appliance 的功能。

功能 AWS Snowball Transfer Appliance
每个设备的容量 50 TB 或 80 TB 100 TB 或 480 TB
最大传输速率 10 Gbps TA100 的速率为 20 Gbps
TA480 的速率为 40 Gbps
两者均支持自动链路聚合
是否支持电子邮件状态更新?
是否支持机架安装? TA100 支持
TA480 不支持
使用费 50 TB 版的费用为 $200
80 TB 版的费用为 $250
TA100 的费用为 $300
TA480 的费用为 $1800
每日费用 使用 10 天后每天需支付 $15 TA100:使用 10 天后每天需支付 $30
TA480:使用 25 天后每天需支付 $90
传输模式 推送 推送或拉取
是否支持传出对象存储空间中的数据?

运营

这两种服务具有相似的工作流(接收设备、设置、传输数据和寄回),但在设置和向其加载数据方面存在一些重要差异。

AWS Snowball 不支持机架安装。相反,它是独立设备,类似于 ATX PC 机箱。Transfer Appliance TA100 型号支持 2U 机架安装,可用于数据中心。TA480 型号配备脚轮;不支持机架安装

AWS Snowball 和 Transfer Appliance 之间的最大差异在于网络吞吐能力。使用 RJ-45 连接时,两者均支持 1 Gbps 或 10 Gbps;使用光纤连接时,两者均支持 10 Gbps。不过,Transfer Appliance 的两个型号均提供 4 个带有自适应负载平衡链路聚合功能的 10 Gbps 以太网端口,其多重数据流吞吐量远超 10 Gbps。

Snowball 采用触摸式电子墨水屏幕。Transfer Appliance 则需要有 VGA 显示屏和 USB 键盘才能访问其控制台,您可以在其中配置一个 Web 控制台。在 Web 控制台中,您可以使用网络浏览器远程执行所有管理操作。

为将数据提取到设备,Snowball 和 Transfer Appliance 均提供工作站客户端推送模型。Snowball 还提供 Amazon S3 API 推送功能。Transfer Appliance 提供 NFS Pull(自身充当 NFS 客户端)和 NFS Push(自身充当 NFS 服务器)传输模式。

Snowball 和 Transfer Appliance 都需要通过货运公司寄回设备。

最后,当您的数据加载到对象存储设备中时,AWS 和 Google 设备之间存在一个重要区别。对于 Snowball,服务中包含设备数据解密功能。而 Transfer Appliance 客户必须使用 rehydrator Compute Engine 虚拟设备来解密设备数据;常规 Compute Engine 虚拟机价格适用于 rehydrator 实例。

对象存储传输

您可能正在考虑将大数据工作负载从 AWS 迁移到 Google Cloud,Google 的 Storage Transfer Service 可能对您有所帮助。您可以使用 Storage Transfer Service 创建一次性作业或周期性作业,将 Amazon S3 存储分区中的数据复制到 Google Cloud Storage 存储分区。此服务也支持其他数据源。

转换和准备

提取数据并将数据导入云环境后,您可以根据需要对数据进行转换、过滤和处理。

本文档介绍了三种执行此任务的服务类别:部分托管式 ETL、完全托管式 ETL 和数据流转换。

部分托管式 ETL

执行数据转换任务的一种常用方法是使用基于 Apache-Hadoop 的工具,这些工具通常提供灵活且可扩缩的批处理功能。Google Cloud 和 AWS 均提供托管式 Hadoop 服务。Google DataprocAmazon Elastic MapReduce (EMR) 均提供自动预配和配置、简单的作业管理、精密的监控和灵活的价格。对于基于数据流的数据,Dataproc 和 Amazon EMR 均支持 Apache Spark Streaming

此外,Google Cloud 提供基于 Apache Beam(而非 Hadoop)的 Dataflow。虽然 Apache Spark Streaming 将流式数据视为小批量作业,但 Dataflow 是专注于数据流的原生处理引擎。

服务模型比较

下表比较了 Amazon EMR、Dataproc 和 Dataflow 的功能。

功能 Amazon Elastic MapReduce Google Dataproc Google Dataflow
开源库 Apache Hadoop 和 Apache Spark Apache Hadoop 和 Apache Spark Apache Beam
扩缩 手动或自动 手动或自动 手动或自动
部署单元 集群 集群 流水线
扩缩单元 节点(主实例、核心和任务) 节点(主实例和工作器) 工作器
工作单元 步骤 作业 作业
编程模型 MapReduce、Apache Hive、Pig、Flink、Spark、Spark SQL、PySpark MapReduce、Apache Hive、Pig、Flink、Spark、Spark SQL、PySpark Apache Beam
Dataproc 和 Amazon EMR

Dataproc 和 Amazon EMR 采用的服务模式非常相似。它们都是可扩缩的平台,可用于过滤和汇总数据,而且它们与 Apache 的大数据工具和服务紧密集成,包括 Apache Hadoop、Apache Spark、Apache Hive 和 Apache Pig。

在 Dataproc 和 Amazon EMR 中,您创建的集群由多个节点组成。服务会创建单个主实例节点和数量不定的工作器节点。Amazon EMR 会将工作器节点进一步分类为核心节点和任务节点。

预配了集群后,用户提交应用(在 Dataproc 和 Amazon EMR 中均称为“作业”)以供集群执行。用户通常使用自定义 Bash 脚本(在 Dataproc 中称为“初始化操作”,在 Amazon EMR 中称为“引导操作”)将应用依赖项添加到集群节点。应用通常从 Amazon S3、Cloud Storage 或 HDFS 等稳定存储空间中读取数据,然后使用 Apache 数据处理工具或服务处理数据。处理完数据后,可对最终数据执行进一步处理或将其推送回稳定存储空间。

数据流

Dataflow 使用 Apache Beam 编程模型执行批处理和流处理。与 Amazon EMR 和 Dataproc 使用的 Apache Spark 模型相比,该模型可提供更强的灵活性和表现力,对实时数据处理来说尤其如此。

在 Dataflow 中,您使用 Dataflow SDK 库为并行处理和聚合提供基本功能,从而指定抽象流水线。在指定流水线时,用户需要定义一组转换,随后将其提交,以便在流水线中执行。然后,这些转换被会映射到一组由 Dataflow 预配和配置以用于执行的工作器节点。一些节点可能会用于从 Pub/Sub 读取数据,其他节点则可能会执行其他下游转换,具体细节由 Dataflow 运行时管理。

Dataflow 模型、SDK 和流水线运行程序已获批作为 Apache Beam 加入 Apache 开源孵化器。这项进展意味着,Dataflow 应用也可以在 FlinkSpark 集群中执行,或在本地开发环境中执行。

如需查看 Apache Beam 和 Apache Spark 编程模型的详细比较,请参阅 《Dataflow/Beam 和 Spark:编程模型比较》

扩缩

本部分介绍如何使用 Amazon EMR、Dataproc 和 Dataflow 管理扩缩。

Dataproc 和 Amazon EMR

Amazon EMR 和 Dataproc 都允许您在集群启动后手动或自动调整集群中的节点数。对于手动扩缩,您可以通过监控集群的性能和使用情况来决定集群大小和扩缩操作,从而确定如何管理集群。在这两项服务中,用户都需要为预配的节点数付费。

数据流

使用 Dataflow 时,默认情况下会启用自动扩缩功能。您可以指定最大数量的节点,Dataflow 运行时系统会自动扩缩节点,根据需要主动管理节点预配并将其分配到流水线中的不同部分。您还可以选择手动管理扩缩。

费用

本部分介绍如何评估 Amazon EMR、Dataproc 和 Dataflow 的费用。

Amazon EMR 和 Dataproc

Amazon EMR 和 Dataproc 均支持按需计费,并提供短期和长期使用折扣。这两种服务均按秒计费。为了降低节点费用,Amazon EMR 用户可以预先购买预留实例。Dataproc 自动提供持续使用折扣。

此外,每项服务都提供购买折扣价剩余计算容量的选项。Amazon EMR 支持使用 Amazon EC2 Spot 实例预配节点,其中未使用的容量以短期增量方式竞卖给用户。EC2 可以回收这些节点,但在添加或移除节点时,集群会继续处理。同样,Dataproc 支持可随时回收的抢占式虚拟机。抢占式虚拟机不通过市场竞卖,而是为每个 Compute Engine 机器类型提供固定的每小时折扣。

如需查看常见云环境(包括 Google Cloud 和 AWS)中的托管式 Hadoop 价格之间的详细比较,请参阅了解云服务价格:大数据处理引擎

数据流

Dataflow 按小时计费,具体取决于 Dataflow 工作器类型。如需了解详情,请参阅 Dataflow 价格

完全托管式 ETL

AWS 和 Google Cloud 均提供可自动执行大部分工作并生成转换流水线以减少配置转换工作的服务。

在 AWS 中,您可以使用 AWS Glue,这是一个完全托管式 AWS 服务,它将数据编目和数据准备工作整合到单一服务中。AWS Glue 采用用户定义的抓取工具,自动从各种数据源填充 AWS Glue 数据目录。填充数据目录后,您可以定义 AWS Glue 作业。创建作业会生成与 Apache Spark 兼容的 Python 或 Scala 脚本,您可以稍后对其进行自定义。AWS Glue 作业可以根据基于时间的调度表运行,也可以根据事件启动。

Google Dataprep 是由 Trifacta 运营的完全托管式服务,可与您的 Google Cloud 项目和数据轻松集成。您可以使用 Dataprep 探索和清理已识别的数据,以便进一步分析。您的数据可以是结构化数据,也可以是非结构化数据,可以来自 Google Cloud Storage、BigQuery 或上传的文件。处理过程是围绕“流程”来组织的,这些流程表示一个或多个源数据集、转换及已准备好的数据集。Dataprep 提供用于发现信息和规划转换流程的 GUI。这些转换是使用特定于网域的 Wrangle 语言指定的,并且可以通过 GUI 手动指定。您的流程在完全托管式 Dataflow 上运行,以执行转换。

数据流转换

AWS 和 Google Cloud 中有多项服务可用于转换数据流。

Dataproc 和 Amazon EMR

Amazon EMR 支持使用 Amazon Kinesis Data Streams 来提取数据,能以原生方式实现流式数据模型。在该模型中,应用读取存储在数据流中的可用数据,直到没有读取到新数据的时间达到某个时长阈值为止。读取过所有分片后,操作的规约步骤即开始,并进行数据汇总。通过 Apache Spark Streaming 的本机实现,Amazon EMR 还支持从 Apache Kafka 等第三方服务进行流式处理。

虽然 Dataproc 无法直接从 Pub/Sub 读取流式数据,但所有 Dataproc 集群都已预装 Apache Spark,这让您可以使用 Dataproc 从 Apache Kafka 读取流式数据。另外,您可以使用 Dataflow 从 Pub/Sub 读取和处理流式数据。

Google Dataflow 和 Amazon Kinesis Data Firehose

如前所述,除了批处理之外,Dataflow 还支持流处理。流式引擎运行 Apache Beam,就像批处理一样,您无需更改任何代码即可对批量数据源和流式数据源应用转换。Pub/Sub 是 Dataflow 在流式模式下使用的唯一事件源,Pub/Sub 可以处理最大 10 MB 的消息。与批量转换一样,Dataflow 流式转换是完全托管且自动扩缩的,转换流水线中各个组件的扩缩彼此独立。

Amazon Kinesis Data Firehose 可以将 AWS Lambda 函数附加到数据流,从而执行数据流转换。此函数最多可以处理 6 MB 的输入数据,最多可返回 6 MB 的数据。您可以使用 Pub/Sub 和 Cloud Functions 在 Google Cloud 中镜像此方法。

仓储和分析

提取并转换了数据之后,您可以执行数据分析,并根据数据创建可视化图表。通常情况下,可供分析的数据最终会输出到以下两个位置之一:

  • 对象存储服务,如 Amazon S3 或 Google Cloud Storage。
  • 托管式数据仓库,如 Amazon Redshift 或 Google BigQuery。

托管式数据仓库

本部分重点介绍 Amazon Redshift 和 Google BigQuery 的本地存储。

服务模式比较

下表比较了 Amazon Redshift 和 Google BigQuery 的功能。

功能 Amazon Redshift Google BigQuery
部署单元 集群 不适用(完全托管)
预配单元 节点 不适用(完全托管)
节点存储类型 HDD/SSD 不适用(完全托管)
计算扩缩 手动扩缩,最多 128 个节点 自动扩缩,无限制
查询扩缩 所有用户定义的队列中最多可同时处理 50 个查询 最多同时处理 1000 个查询
表扩缩 大型节点类型最多包含 20000 个表 无限制。每个数据集包含 50000 个表可达到最佳性能。数据集无限制。
备份管理 快照 不适用(完全托管)
部署位置 地区 区域
价格模式 按小时 按存储空间和查询量
查询语言 与 PostgreSQL 兼容 旧版 BigQuery SQL 或标准 SQL
是否内置机器学习功能?
Amazon Redshift

Amazon Redshift 跨一个预配节点集群使用大规模并行处理架构来提供高性能 SQL 执行。使用 Amazon Redshift 时,您的数据存储在列式数据库中,该数据库跨集群的各个节点自动复制。您的数据位于集群内,因此集群必须保持运行以保留数据。(不过,您可以将数据从 Amazon Redshift 导出至 Amazon S3,然后重新载入 Amazon Redshift 集群以供日后查询)。Amazon Redshift 的扩展程序 Spectrum 提供了另一种选择,可让您直接查询以 Amazon S3 支持的格式存储的数据。

如上所述,Amazon Redshift 使用的是预配的模型。在此模型中,您可以选择实例类型,然后根据需要配置特定数量的节点。完成预配后,您可以使用您选择的与 PostgreSQL 兼容的连接器连接到集群,然后加载和查询数据。

Amazon Redshift 是部分托管式服务。如果要扩大或缩小集群(例如,在低使用量期间减少费用,或在高使用量期间增加资源),必须手动执行操作。此外,使用 Amazon Redshift 时,您必须定义和管理您的分布键与排序键,并手动执行数据清理和碎片整理过程。

Google BigQuery

BigQuery 是完全托管的。您不需要预配资源,而只需要将数据推送到 BigQuery 中,即可查询数据。BigQuery 会管理所需的资源,并根据需要自动扩缩。BigQuery 还支持联合查询,对象可包括 Cloud Storage 或 Google 云端硬盘中以开源格式存储的数据,以及以本地形式存储在 Cloud Bigtable 中的数据。

在后台,BigQuery 使用强大的全球规模服务,与 Google 在内部使用的服务相同。

  • 它使用 Google 的最新一代分布式文件系统 Colossus 存储、加密和复制数据。
  • 它使用 Google 的大型集群管理系统 Borg 处理任务。
  • 它使用 Google 的内部查询引擎 Dremel 执行查询。

如需了解详情,请参阅 Google Cloud 博客中的博文:BigQuery 底层探秘

BigQuery 表仅限追加,仅支持通过有限的删除操作来修复错误。用户既可以执行交互式查询,也可以创建和执行批量查询作业。BigQuery 支持两种查询语言:

  • 旧版 SQL,这是特定于 BigQuery 的 SQL 方言。
  • 标准 SQL,符合 SQL 2011 标准,包含用于对嵌套和重复数据进行查询的扩展程序。

此外,BigQuery 支持与许多第三方工具、连接器和合作伙伴服务集成,以进行提取、分析、直观呈现和开发。

机器学习

BigQuery 包含对机器学习的原生支持。BigQuery ML 提供多种模型来解决常见的业务问题。示例包括用于销售预测的线性回归,以及用于分类的二元逻辑回归,例如确定客户是否会购买。您可以使用多个 BigQuery 数据集进行模型训练和预测。

扩缩

对于不同的节点类型,Amazon Redshift 可以从单个节点扩增至最多 32 或 128 个节点。Redshift 使用密集存储节点,其数据存储(包括复制的数据)的最大容量为 2 PB。Amazon Redshift 的提取和查询机制使用相同的资源池,这意味着,当您加载大量数据时,查询性能可能会降低。

Amazon Redshift Spectrum 扩充了此容量。但是,当您使用 Redshift Spectrum 时,必须运行 Amazon Redshift 集群才能针对这些数据运行查询。查询在两层之间进行处理(Amazon Redshift 和 Redshift Spectrum),您必须构建查询以便最高效地使用每一层。

相比之下,BigQuery 对所存储数据集的大小没有实际限制。提取资源可快速扩缩,并且提取操作本身十分快速。使用 BigQuery API,您每秒可以将数百万行提取到 BigQuery 中。此外,提取资源与查询资源相分离,因此提取负载不会导致查询负载的性能降低。BigQuery 还可以对存储在 Google Cloud Storage 中的数据执行查询。这些联合查询不需要更改查询的编写方式,因为数据只是以另一个表的形式被查看。

操作

本部分比较使用 Amazon Redshift 和 Google BigQuery 时的操作注意事项。

Amazon Redshift

Amazon Redshift 为部分托管式,可处理运行数据仓库所需的许多操作细节,包括数据备份、数据复制、故障管理、软件部署和配置。但是,若干操作细节仍需由您负责处理,包括性能管理、扩缩和并发。

为了获得良好的性能,您必须在创建表时定义静态分布键。然后,系统使用这些分布键跨节点对数据进行分片,以便可以并行执行查询。由于分布键对查询性能有显著影响,因此您必须谨慎选择这些键。定义了分布键后,便无法更改这些键;如需使用其他键,您必须使用新键创建新表,并从旧表中复制数据。

此外,Amazon 建议您定期执行维护,以确保一致的查询性能。更新和删除操作不会自动压缩磁盘上的数据,因此这两种操作最终可导致性能瓶颈。如需了解详情,请参阅 Amazon Redshift 文档中的对表执行 vacuum 操作

使用 Amazon Redshift 时,您必须小心管理最终用户和应用。例如,用户必须调整他们执行的并发查询的数量。默认情况下,Amazon Redshift 最多执行 5 个并发查询。您最多可以将并发查询的数量增加到 50 个。但由于资源是提前预配的,因此当您提高此限额时,性能和吞吐量将会受到影响。如需了解详情,请参阅 Amazon Redshift 文档中实现手动 WLM“并发级别”部分

您还必须调整集群的大小,以支持总数据大小、查询性能和并发用户数量。您可以扩大集群;但由于是预配的模型,因此无论您是否使用预配的资源,都必须为之付费。

最后,默认情况下,Amazon Redshift 集群限于单个地区。如需创建高度可用的多区域 Amazon Redshift 架构,您必须在其他地区创建额外的集群,然后构建一种机制来实现多个集群之间的一致性。如需了解详情,请参阅 Amazon Big Data 博客中的博文:构建多可用性地区或多区域 Amazon Redshift 集群

如需详细了解其他 Amazon Redshift 配额和限制,请参阅 Amazon Redshift 中的限制

BigQuery

BigQuery 是完全托管的,用户基本没有操作开销。

  • BigQuery 自动处理分片。您无需创建和维护分布键。
  • BigQuery 是按需服务,而不是预配的服务。您无需担心可能导致瓶颈问题的预配不足,或可能产生不必要费用的过度预配。
  • BigQuery 提供全局托管式数据复制。您无需设置和管理多个部署。
  • BigQuery 支持多达 50 个并发交互式查询,且不会影响性能或吞吐量。

如需详细了解 BigQuery 的配额和限制,请参阅 BigQuery 文档中的配额政策页面

费用

Amazon Redshift 提供两种价格类型:按需价格和预留实例价格。价格由已预配实例的数量和类型决定。您可通过预先购买预留实例获得折扣价格。Amazon 提供一年期和三年期两种预留期限。如需了解详情,请参阅 Amazon Redshift 价格页面

BigQuery 按使用量收费。价格由数据存储空间大小、查询计算费用和流式插入次数决定。如果一个表连续 90 天未更新,则数据存储价格会减半。查询以所处理数据的 TB 数为单位计费。BigQuery 支持按需计费和按固定费率计费,因此可以大幅节省可预测的工作负载的费用。BigQuery 提供大量免费使用量,每月最多可免费使用 20 GB 存储空间和 1 TB 查询读取量。如需了解详情,请参阅 BigQuery 价格页面

对象存储仓库

对象存储是另一种常见的大数据存储机制。Amazon S3 和 Google Cloud Storage 类似,都是完全托管式对象存储服务。如需详细了解这两项服务,请参阅存储比较文档中的分布式对象存储部分

与 Amazon Glacier 存储服务相比,Google Cloud Storage Coldline 适用于不经常访问的大量数据。如需详细了解这两项服务,请参见面向 AWS 专业人员的 Google Cloud 指南:存储

对象存储的分析

本部分重点介绍 Amazon Athena 和 Google BigQuery 与对象存储的兼容性。

服务模式

AWS Athena 是一种无服务器对象存储分析服务。它可让您针对在 Amazon S3 中定义架构的数据运行 SQL 查询。BigQuery 联合查询可与之相媲美,此服务支持 Google Cloud Storage、Google 云端硬盘和 Bigtable 数据。

Athena 和 Cloud Storage 上的 BigQuery 都是完全托管的,包括自动扩缩功能,因此二者的服务模式类似。

规模

就数据规模而言,Amazon S3 和 Cloud Storage 均提供 EB 级的存储空间。Amazon S3 限制每个帐号可创建 100 个存储分区。Cloud Storage 限制每两秒创建一个存储分区,但不限制项目、文件夹或组织中的存储分区数量。

就查询规模而言,Athena 查询会在 30 分钟后超时,而 BigQuery 查询会在 6 小时后超时。Athena 具有软性限制,其最多可同时处理 20 个 DDL 查询和 20 个 DML 查询。BigQuery 支持多达 50 个并发交互式查询,且不会影响性能或吞吐量。试运行查询不计入此限制。您可以在项目级层提高此限制。

Athena 查询字符串的长度上限为 262144 字节。BigQuery 旧版 SQL 未解析查询的上限为 256 KB,而标准 SQL 未解析查询的上限为 1 MB。解析可将查询引用的视图和通配符表扩展为总查询大小,这两种 BigQuery SQL 方言的上限均为 12 MB。

操作

Athena 和 BigQuery 都是完全托管的,用户基本没有操作开销。

费用

在存储费用方面,Google Cloud Storage 和 Amazon S3 类型,大部分费用来自传输和存储费用。对费用稳定性有要求的 Cloud Storage 客户可以加入存储空间增长方案,使每个月的费用保持一致。

AWS Athena 和 BigQuery 均采用按需计费,每 TB 的查询费用为 $5。不过,这两项服务对于 1 TB 的度量不同。Athena 根据从 Amazon S3 读取的字节数计费,即查询压缩数据的费用低于未压缩数据。BigQuery 按处理后的字节数计费,无论数据存储位置及存储方式如何,费用均相同。

这两种服务每次查询最低均按 10 MB 收费。失败的查询不会产生任何费用,但这两项服务均对已取消的查询中已完成的部分收费。

Athena 没有免费层级。BigQuery 在帐号有效期内提供每月 1 TB 的免费查询额度。

直观呈现数据

如果您使用 AWS QuickSight,您可以在 Google 数据洞察中找到类似功能。主要区别在于价格。数据洞察是免费的,而 QuickSight 按会话计费。另外,数据洞察与 G Suite 集成,您可在组织内轻松共享,就像共享文档、表格和幻灯片一样。

为提供更好的控制或者用于科学工作,Google 还提供了 Colaborator,这是一项无需设置的免费服务,使用 Jupyter 笔记本与 BigQuery 集成。