部署到gcp_AWS和Snowflake与GCP：构建数据平台时如何选择？

当我们谈论数据时，市场上可用的技术数量不胜枚举，而对于企业和工程师而言，保持最新是一项关键的挑战。

我最近加入Photobox的原因之一是要进入一家数据驱动型公司，面临着使用一些最前沿的可用技术(AWS(亚马逊网络服务)，Snowflake和Looker)构建新数据平台的挑战。

我在职业生涯的最后四年中主要从事GCP(Google云平台)的工作，领导了Telegraph数据平台的开发。 之后，我想离开自己的舒适区，接受新的挑战，开始学习新的技术堆栈。

在本文中，我想分享学习过程中的喜悦和痛苦，我将尝试在GCP和AWS产品之间进行公正的比较。

请记住，这是从最近刚开始使用AWS和Snowflake的数据工程师的角度出发的。 因此，我不可能对亚马逊和谷歌提供的服务进行全面比较，因此，我将把本文限制在我在Photobox中构建和扩展新数据平台时所涉及的领域。

本文的目的不是详细讨论Photobox的数据平台体系结构，但我将尝试提供足够的上下文来证明我们在旅途中所做的决定的合理性。

本文分为三个主要部分，涵盖了我们平台中从摄取到仓库的数据流：

· 事件收集。

· 数据管道编排和执行。

· 数据仓库技术比较。

在每个部分中，我都会(概括性地)描述我们在Photobox中构建的内容，并且为了进行比较，我将练习在GCP方面进行设计。

事件收集

构建新数据平台时，首先要弄清的一件事是如何提取数据。

在Photobox中，我们构建了一个自助服务平台，可以同时接收实时事件和批处理数据。 多个内部和外部客户端可以将事件推送到平台。 如果事件符合预期的架构，则将其摄取，否则将其丢弃。

Photobox中的事件提取流程主要使用以下AWS服务：

· API网关

· SNS(简单通知服务)

· 运动流

· Kinesis Firehose

· AWS Lambda函数

· S3(简单存储服务)

外部事件通过API网关发送并经过验证。 如果有效负载被接受，则事件将发布到Kinesis Stream，并将其传播到Kinesis Firehose。 Firehose通过Lambda函数匿名化有效负载中可能存在的任何PII数据(基于JSON命名约定)，并将匿名化的数据集存储到Snowflake从中提取数据的S3中。

内部事件以类似的方式获取，但是使用我们的数据平台订阅的SNS主题。

图1 Photobox事件收集过程

要使用GCP设计等效过程，我可能会使用以下服务：

· 云端点

· 云功能(GKE或App Engine也是有效选项)

· 发布/订阅

· 数据流

· 谷歌存储

在GCP中，首先使用Cloud端点和Cloud功能中部署的应用程序处理外部事件。 该应用程序会将每个事件发布到发布/订阅主题中。 数据流将订阅该主题并使用对每个记录应用匿名化功能的数据，然后将数据以微批处理的形式存储到Cloud Storage中。

内部事件以类似的方式获取，事件在多个Pub / Sub主题中发布，然后使用Dataflow进行匿名处理并存储在Cloud存储中。

显然，这只是解决问题的一种方法。 我敢肯定，与AWS或GCP专家进行讨论后，可以通过多种不同方式实现相同的结果。

图2使用GCP的Photobox事件收集过程

如果我们开始比较"外部事件提取"分支中的两个解决方案，我们可以看到一方面我们拥有Amazon API Gateway，另一方面我们正在使用两个组件(云终端和云功能)来执行相同的任务 。

对于不熟悉AWS的用户，Amazon API Gateway是一项用于创建，发布，维护，监视和保护各种规模的REST和WebSocket API的服务。 从API网关到Kinesis的路由请求很容易，并且不需要其他组件即可连接这两项服务。

图3 AWS API Gateway POST / event端点，用于在Photobox数据平台中收集外部事件。

查看API网关限制，我们可以看到默认情况下它可以管理惊人的吞吐量-每秒10,000个请求(RPS)，最大有效负载大小为10Mb(有关服务的软限制和硬限制的详细信息，请参见此处)。 在Photobox的高峰时间内，我们每秒收集到的外部事件数可能会超过该配额，但是幸运的是，这是一个软限制，最终可以根据需要增加。

在GCP方面，Cloud Endpoints是NGINX分布式代理即服务，可提供对您的API的访问控制并验证REST请求。 该层可以轻松地与部署在云功能(或其他GCP服务，如GKE)中的应用程序集成，以有效地将事件路由到发布/订阅中。

Google Cloud Functions是一种无服务器执行环境，用于单一目的功能，这些功能附加到GCP云基础架构和服务发出的事件中。 它的作用类似于AWS中的Lambda函数。 云功能每100秒最多可以处理100,000,000个请求，最大有效负载大小为10MB(有关详细限制和配额，请参见此处)。

用于事件收集的GCP和AWS服务都是无服务器的，完全可扩展的并且能够处理大量事件。 两种解决方案之间的主要区别是，用于实现相同结果的组件数量–一个在AWS上，两个在GCP上。 我一直都是简单设计的忠实拥护者，因为减少了维护和监视所需的组件，通常使生活更轻松。

比较图1和图2中的流和匿名化部分，我们可以看到在AWS中，使用Kinesis Stream和Kinesis Firehose(具有Lambda函数)，而在GCP中，Pub / Sub和Dataflow执行相同的任务。

AWS Kinesis Datastream是一项可扩展且持久的实时数据流服务。 在我们的平台中，它被用于Kinesis Firehose的前面，以提供7天的数据保留和读取限制(如果需要)。 数据记录在分片中进行管理。 可以根据需要向上或向下扩展分片。 因为重新分片(增加或减少Kinesis分片的数量)不是自动的，所以Kinesis需要通过CloudWatch进行持续监视以优化分片的数量，以有效地处理数据量。

重新分片支持两种操作：两个分片可以合并为一个，或者一个分片可以分为两个。 Kinesis Stream中的每个分片每秒最多可以管理1000个PUT操作，最大数据斑点大小为1MB。

另一方面，Kinesis Firehose受到完全管理并自动缩放。 在将匿名Lambda函数应用到每组记录之前，我们的平台中使用了这项技术来自动将数据写入S3存储桶。 这样可以确保Photobox的数据平台中不会提取任何PII数据以符合GDPR。

在GCP上，Pub / Sub充当Kinesis Stream的角色。 该技术是可扩展的，持久的事件摄取和交付系统，用于流分析管道。 它提供了多对多异步消息传递，使发送者和接收者分离。 它不需要任何管理，可以处理1,000MB / s的发布吞吐量和2,000MB / s的订阅吞吐量，最大邮件大小为10MB。 详细的配额和限制可在此处获得。

数据流(Apache Beam)与Kinesis Firehose一起使用匿名Lambda扮演相同的角色。 它使用来自Pub / Sub的消息，应用匿名化逻辑，然后将微批写入到存储桶中。

在这种情况下，GCP使用少于AWS的组件即可达到相同的结果。 此外，发布/订阅(不同于Kinesis Stream)不需要任何管理人员即可预先分配碎片或基于监视系统扩展流程。

另一方面，Kinesis Firehose自动将微批处理分区处理到S3中，并支持内联Lambda中定义的功能。 这似乎比在GCP中部署数据流管道以及编写自己的逻辑以将微批记录记录到Cloud Storage中更方便。

在AWS端的内部事件提取分支中，Photobox内部客户端依赖于SNS主题。 记录通过Lambda函数发布到Kinesis Stream中，最后Firehose应用匿名函数并写入S3。

在GCP方面，同一过程将使用两个组件。 一个或多个客户端可以在发布/订阅主题上发布，并且数据流管道可以使用，匿名化记录并将其写入Storage。

第二种方法需要监视的运动部件较少，因此维护起来似乎更简单。

数据管道编排和执行

设计数据平台时，另一个关键点是用于转换数据的工具以及如何编排多个数据管道。

我非常热衷的转换工具是数据构建工具(DBT)，Photobox数据平台中的所有ELT(提取负载转换)都依赖它。 如果您想了解我以前使用DBT的更多信息，请查看我在The Telegraph上撰写的有关DBT的这篇文章。

图4在Photobox数据平台中如何组织DBT管道。

从图4中可以看到，Apache Airflow是Photobox中选择的调度程序，它用于协调我们所有的数据管道。 使用多个Fargate工作者在Amazon ECS中部署了气流。 作为Airflow部署的一部分，AWS RDS用作调度程序元数据存储，ElasticCache支持排队服务。

Airflow有一群轻型工人，他们不执行任何计算密集型工作； 它们的唯一目的是启动ECS任务定义，这是实际的数据管道。 转换逻辑是用DBT编写的，并包装在一个多功能的Python应用程序中，该应用程序允许运行DBT中可能不支持的任何操作。

DBT管道将转换步骤定义为模型(SQL查询)，这些模型在DAG(有向无环图-不要与气流滞后混淆)中链接。 DBT DAG确保按照正确的顺序执行一组查询，以根据需要转换数据。 一旦运行DBT的Fargate工作者执行了任务，便将其释放以释放不需要的计算资源。 这确保了在我们的ECS集群中持续运行的唯一应用程序是Airflow，而所有数据管道均在临时工上运行，这些临时工存活的时间足以执行任务。

图5如何在GCP中设计相同的解决方案

如果我们使用GCP设计相同的流程，那么Cloud composer可以替代自定义Airflow部署。

云作曲家不过是Google托管的Airflow的托管版本，通常只需要最小的调整就可以用于大多数常见用例。 另一方面，如果您习惯完全控制气流，则该产品的限制可能会太大。

要运行数据管道，可以使用Google Kubernetes Engine(GKE)代替ECS，并且Kubernetes Jobs可以代替ECS Task定义。

(让我对此打个小括号。Google通常建议使用Dataflow运行数据转换。我个人认为Dataflow对于数据流确实很有用，而如果您的团队讲SQL，我认为DBT是更好的工具 DBT可以完全释放您的云DW的功能，并且可以可靠地处理运行逻辑的模型之间的依赖关系。)

另一方面，我对ECS感到惊喜。 预配置和取消预配置Fargate工作人员的速度很快。 准备好一个工人来运行您的数据管道大约需要一分钟，而杀死它则需要一分钟。 您可能会达到同时运行多个Fargate工作者的AWS配额限制，但这是一个软限制，可以通过要求AWS增加配额来绕开。

在GCP方面，以我的经验，如果GKE群集中的节点可以分配所需的资源，那么创建Kubernetes作业确实非常快，但是如果GKE群集中没有可用的节点，则必须自动扩展。 该操作通常需要几分钟，从而延迟了数据管道的执行。

根据您期望的使用情况以及运行数据管道时可能遇到的时间限制，一种技术可能比另一种更适合您的需求。

我认为，在这种特定情况下，除非您拥有一个运行时间短且预定的时隙且需要大量计算资源的数据管道，否则您几乎看不到差异。 在这种情况下，您可能必须预先在GKE集群中分配一个节点，以确保在请求时资源准备就绪，或者有一个过程会迫使您的集群在假定使用管道之前几分钟自动扩展 跑步。

使用ECS，您可以在任务定义中指定任务的硬件要求，并且Fargate Worker的供应时间可能相似。

数据仓库比较

本部分很容易成为文章本身。 因此，我将尽量简明扼要，仅突出显示Snowflake(我们在Photobox中使用的DW)和BigQuery(与GCP等效)的主要特征。

Snowflake不在AWS的大伞下，但在我们看来，这是作为平台的第一个构建块的最佳选择。

我们采用Snowflake的原因主要是为了克服您在其他产品(如Athena和Redshift)中可能遇到的限制。 Athena是一种交互式查询服务，在测试时，它不支持对现有表进行任何更新。 像CTAS(Create table as select)这样的基本功能于2018年底推出，允许的并发查询数量不适合我们在数据平台中并行运行的任务数量。 使用Athena，我们还难以处理大量的嵌套JSON记录。

Redshift本身不支持读取架构。

您可以从redshift访问Glue目录，也可以使用Spectrum访问存储在S3上的数据。 但是，频谱或雅典娜表与内部Redshift表之间的联接在Redshift中发生，因此查询性能取决于Redshift集群的大小。

由于上述所有原因，我们决定选择Snowflake，因为它在存储和计算之间具有更好的去耦性。

Snowflake是一种软件即服务(SaaS)，它使用具有专门为云设计的独特体系结构的新SQL数据库引擎，从而可以以惊人的速度处理PB级数据。 假设您有足够的可用资源来处理并发查询，那么它就没有限制，并且只需要对底层基础结构有最少的了解即可。

图6 Snowflake UI

DW提供了一个Web UI(图6)，从权限管理到提高Warehouse性能的所有内容都可以用SQL语句处理。 Snowflake支持通过视图和阶段管理的读取模式架构功能，该功能允许在摄取层中进行平滑的JSON模式更改。 使用Snowflake，原始数据可以存储在S3中，并可以通过外部表进行访问。

在GCP方面，BigQuery是软件即服务(SaaS)，不需要任何基础架构管理。 与Snowflake一样，可以通过Web UI对其进行访问，并且Cloud Storage可以用于通过BigQuery托管原始数据，也可以使用外部表来访问数据。

从速度来看，这并不容易判断。 在我看来，Snowflake在面对面测试中比BigQuery快，而且这一事实似乎得到了不同基准的支持。

另一方面，您可能会发现工程师在某些情况下提到BigQuery优于Snowflake。

事实是，在不同的情况下，您可能会获得不同的性能，这实际上取决于：

· 数据的大小和结构。

· 您正在运行的查询的类型和使用模式。

关于定价模型，使用Snowflake，您需要为每个虚拟仓库/小时支付积分/小时，再加上数据存储成本，该成本通常可以忽略不计，并且与您的云提供商成本保持一致。 基本上，只有在机器启动并运行，执行查询时才需要付费，而总成本主要取决于您的使用模式以及不使用虚拟仓库时将其挂起的事实。

幸运的是，Snowflake提供了一个自动暂停选项，可以在一定时间内没有执行查询时关闭虚拟仓库。

使用Bigquery，您需要支付查询期间读取的数据量($ 5 / TB)，外加存储成本(当前为$ 0.02 / GB /月)。 用户界面会尽可能估算您要查询的数据量，因此定价通常相当透明。

Google还提供了统一费率的定价计划，以代替按查询次数付费的模式。

我可以看到两种模型的优缺点，这实际上取决于您期望在数据仓库上使用哪种使用模式。

如果您不小心将虚拟仓库留在雪地上，或者需要经常使用它，雪花可能会变得非常昂贵。 另一方面，使用BigQuery，如果有一组分析人员查询大量数据，您可能很快就会花大钱。

在这两种情况下，教育都是关键。 如果您不想失去对成本的控制，那么重要的是教育工程师，分析师和任何其他消费者以适当的方式使用这些云数据仓库技术。 必须对数据进行明智地建模和优化以进行使用，在某些情况下，基于角色的限制可能会派上用场。 这可以帮助控制谁正在访问您的DW(以及如何访问)，并防止以错误的方式使用数据。

除了性能和价格之外，我认为Snowflake与BigQuery相比在其他方面还算是学习曲线和它的友好程度(在SQL方面)。

几年前，当我开始使用BigQuery时，我不得不学习BigQuery(传统)SQL，不久之后又学习了BigQuery Standard SQL。 在这两种情况下，我都必须深入阅读文档以了解如何执行简单的转换或查询分区。 如果没有正确阅读，我根本无法开始使用该产品。 由于无法使用某些功能的直接等效项，因此Google必须编写有关如何将代码库从旧版SQL迁移到标准SQL的指南。

第一次访问Snowflake时，我开始编写SQL语句而无需阅读任何文档。 我不知道正确的语法，因此就像查询MySQL数据库一样编写了它。 我知道我的查询可能会引发许多错误(实际上我确实得到了一些错误)，但是修复我的语法是微不足道的，只花了我几分钟就可以运行查询。

我真的很感谢Snowflake团队在不使用任何Snowflake特定功能的情况下所做的努力，以使其易于访问数据仓库，而无需深入研究文档。 有时，我发现自己像在Oracle中一样编写查询，令人惊讶的是，它们工作正常！

结论

在Photobox的头四个月后，我可以说我非常感谢AWS提供的一些工具，并且我完全爱上了Snowflake。 同时，很难不与GCP提供的产品进行比较，有时，我发现自己在思考在AWS方面拥有一些GCP工具会如何。

拥有所有东西显然是不可能的，而真正的更好取决于您拥有的用例以及工程团队对使用哪种工具更有信心。 一种工具在某些情况下可能看起来不错，而在另一种情况下则不太好。 因此，很难说一个云提供商在整体上要比另一个更好。

可以肯定的是，我很高兴有机会与我们在Photobox中拥有的优秀工程师团队一起工作，以及我们尝试新解决方案和学习新技术的自由。 我们构建最前沿的基于云的数据平台之一的使命才刚刚开始，但是每次为难题添加新内容时，我都会感到骄傲。

Stefano Solimito是Photobox的首席数据工程师。 您可以在LinkedIn上关注他。

(本文翻译自Stefano Solimito的文章《AWS & Snowflake vs GCP: how do they stack up when building a data platform?》，参考：https://medium.com/photobox-technology-product-and-design/aws-snowflake-vs-gcp-how-do-they-stack-up-when-building-a-data-platform-45edbdd615ff)