作者 | Romit Mehta、Vaishali Walia 和 Bala Natarajan
译者 | 王强
策划 | 蔡芳芳
这是我们在 Google Cloud Platform 上长期旅程的第一步。
前 言
自全球疫情爆发以来，PayPal 经历了创纪录的增长。为了跟上暴涨的需求，我们决定将 PayPal Analytics 分析平台迁移到公共云上。第一波大迁移是将一个仓库负载迁移到 Google Cloud 中的 BigQuery，耗时不到一年。在此过程中 PayPal 团队还构建了一个平台，可以支持其他很多用例。
这篇文章回顾了这次里程碑式的迁移体验。我们将一半的数据和处理从 Teradata 系统迁移到了 Google Cloud Platform 的 BigQuery 上。
介 绍
由于组织和消费者在疫情期间踊跃采用新的业务手段，PayPal 的交易量创下了历史新高。这给我们用于合规、风险处理、产品和财务分析、营销、客户成功和欺诈保护的离线分析系统带来了很大压力。这些分析系统之前都运行在本地数据中心，以 Teradata 和 Hadoop 为核心，并配备了额外的软件和工作流来管理系统中的资源。
数据的处理需求远远超过了本地现有的容量。在疫情期间快速扩容也绝非易事。为了应对危机，数据平台团队开始人工干预，优先处理需要额外处理时间的各种负载。鉴于持续增长的业务前景，PayPal 意识到分析生态系统需要变革。
此外，我们意识到我们可以根据更好的敏捷性、可发现性、可共享性和生态系统集成的理念对我们的数据战略进行现代化改造。BigQuery 使我们能够中心化我们的数据平台，而不会牺牲 SQL 访问、Spark 集成和高级 ML 训练等能力。此外，BigQuery 还具有机器学习和实时分析等高级特性，无需将数据移到另一个系统即可利用这些能力。
PayPal 之所以选择了云而非本地扩展是考虑到了多个因素。PayPal 的数据团队绘制了迁移到公有云的蓝图，以基于 Google Cloud Platform 的能力来满足未来五年的数据需求。
上下文
PayPal 的分析基础设施是基于适用于各种用例的一系列技术构建的。数据分析师和部分数据科学家主要依赖一个数据仓库来完成数据工作。仓库中的数据是半结构化的，便于团队分析和报告。
下图提供了数据流的简化视图。来自站点数据库的数据首先进入数据仓库。来自仓库的一些数据的副本被制作成一个由开源技术提供支持的数据湖。然后，数据会使用其他数据源修饰，例如跟踪、实验和来自 PayPal 邻接源的数据，以进行变换并加载回分析仓库供消费。
图 1：PayPal 分析环境中的数据流高层视图
PayPal 在本地管理两个基于供应商的数据仓库集群，总存储量超过 20PB，为 3,000 多个用户提供服务。随着数据在业务决策中的分量愈来愈重，容量需求也在不断增长。分析仓库的瓶颈是存储和 CPU，主仓库瓶颈是 IO 和存储。
仓库用例可以大致分为交互式负载和批处理负载。交互式负载包括来自使用 Jupyter 笔记本的用户即席查询，以及使用 Tableau 和 Qlikview 等 BI 工具的报告和仪表板。批处理负载使用 Airflow 和 UC4 调度。负载大多用 SQL 编写，并使用 shell 或 Python 脚本执行。
由于流量增长带来的挑战，许多变换作业和批量加载都落后于计划。PayPal 分析师和数据科学家发现数据远远达不到他们的服务级别协议（SLA）标准，随之而来的是体验下降，并拖累了决策速度。在两大仓库中，PayPal 决定首先将分析仓库迁移到 BigQuery，获得使用该服务作为 Teradata 替代品的经验，并在此过程中为 PayPal 的数据用户构建一个围绕 Google Cloud Platform 服务的平台。之后我们将总结分析仓库的迁移和使用经验来迁移主仓库。
挑 战
技术挑战
要改善 PayPal 数据用户的体验，我们需要解决以下技术挑战：
- 安全性：由于 PayPal 处理 PII 和 PCI 数据，因此任何数据基础设施都需要完整的补丁、强化的系统配置、为敏感数据配置的加密和解密密钥、通过 TLS 访问数据以及用于数据访问的基于角色的良好访问控制（RBAC）。
- 按需弹性扩展：及时访问容量是满足负载限制的关键。因此，分析数据基础设施需要随着需求的增长和收缩而扩大和缩小。
- 高性能 SQL 访问：为数据类型和访问模式提供高性能 ANSI SQL 接口，可以提高分析师和数据科学家的工作效率。
- 从 BI 工具访问：由于业务智能是传达洞察力的关键，因此分析基础架构应与现有工具（如 Jupyter 笔记本、Tableau 和 Qlikview）以及现代 BI 工具（如 Looker 和 ThoughtSpot）很好地集成，实现即插即用。应用在分析基础设施上的 RBAC 需要由 BI 工具统一支持，以实现简单和标准化的数据访问管理。
- Showback：数据用户对他们的资源消费情况没有清晰的视图。新的基础设施都应该有能力让我们的团队向用户提供这些高价值信息。
采用挑战
基础设施的变革需要克服以下采用挑战：
- 标准化：数据用户过去曾被非标准基础设施拖累，这些基础设施要么减慢了他们的速度，要么限制了使用模式。用户更喜欢标准化的东西，这样他们就可以使用现有的人才库和他们喜欢的工具。
- 迁移路径：数据用户更喜欢一种可以轻松迁移笔记本、仪表板、批处理和计划作业中现有工件的技术。将他们的负载重写到一个新目标上的预期投入是非常大的，从一开始就可能失败。
- 容易培训：用户更喜欢方便自己在线学习的技术，不喜欢专门的培训和特意安排的学习时间。
- 访问灵活性：用于探索数据和建模的工具经历了各种各样的变化。用户更喜欢随着技术的发展而前进的基础设施。举个例子：尽管 PayPal 的大多数消费者在使用 SQL，但仍有许多用户在分析和机器学习用例中使用 Python、Spark、PySpark 和 R。此外，用户希望看到基础设施不断更新，以利用新特性或根据行业趋势以新的方式处理数据。
- 灾难恢复：任何基础设施都应该有明确的灾难恢复选项，可以在 30 分钟内触发，为用户的工作铺平道路。
我们做出的选择
鉴于 PayPal 必须解决这么多挑战，很明显，创建新的本地解决方案是没什么出路的。稳健解决方案的构建块大都针对云端设计，对本地基础设施的支持较少。此外，系统扩展需要购买新的硬件，而漫长的交付周期会成为业务的瓶颈。PayPal 已经将大量负载转移到了 Google Cloud Platform，所以分析平台转移到 Google Cloud Platform 是更顺其自然的选项。我们评估了在 Google Cloud Platform 上提供服务的各个供应商，看看他们是否可以解决前面提到的一些技术挑战，然后我们将选择范围缩小到了 BigQuery。我们对 BigQuery 进行了为期 12 周的评估，以涵盖不同类型的用例。它在我们设定的成功标准下表现良好。下面提供了评估结果的摘要。
我们将在单独的文章中介绍评估过程、成功标准和结果。
图 2：BigQuery 评估结果摘要
作为我们蓝图的一部分，我们决定处理图 1 中所示的“分析仓库”。
我们使用的方法
我们选择了要探索的云和仓库后就确定了以下路径并开始进入下一阶段。
客户联系
我们根据过去 12 个月的使用统计数据联系了仓库用户，以及该集群中的数据提供者。我们安排了时间，引导他们做出决定，并寻求他们对这次迁移的支持。这种利益相关者的支持对我们的成功迁移是很重要的。我们向他们解释了基本原理，告诉他们我们计划如何解决这个问题。一些用户很兴奋，并希望深度参与迁移工作。我们选择了一个业务部门中的一个团队作为早期采用者，并将我们的迁移工作重点放在他们的用例和数据要求上。
安全基础设施建设
我们构建了一个安全的基础设施来将数据移动到云端。我们将 BigQuery 中的数据保存为美国的多区域数据，以便从美国的其他区域访问。我们在数据中心和 Google Cloud Platform 中离分析仓库最近的区域之间实现了安全的私有互联。由于我们希望以混合模式运营（在可见的未来，其他连接系统仍保留在本地），因此没有出口成本的私有互联是更好的选择。
我们决定在 Google Cloud Platform 提供的服务范围内，在 BigQuery 中使用 PayPal 提供的私钥来保护我们的数据。这确保了数据的安全性，保证数据位于无法从外部访问的范围内。我们部署了自动化操作以防止意外创建缺少加密密钥的数据集。通过这种方式，我们为存储在 Google Cloud Platform 中的所有数据启用了默认加密，这符合我们的内部政策和外部规范。
我们已使用这一基础架构将超过 15PB 的数据复制到了 BigQuery 中，并将 80 多 PB 数据复制到了 Google Cloud Services 中，用于各种用例。我们使用同一套网络基础架构，让用户通过 Jupyter 笔记本、Tableau 或从他们的计划作业访问 BigQuery。
合规和渗透测试
PayPal 是一个金融科技组织，在我们的数据集中会处理 PCI 和 PII 数据元素，因此我们与各种监管机构合作，提交了我们将数据移至云端的意图。PayPal 的信息安全、区域业务部门和法律团队与我们的团队一起，加班为监管机构准备文书工作。我们进行了多轮渗透测试，以确保没有漏洞可利用。这一过程帮助我们验证了基础设施中的数据保护和访问设计。
DDL（数据定义语言）和 SQL 转换
因为我们要使用新技术将数据用户带到云端，我们希望减轻从 Teradata 过渡到 BigQuery 的阵痛。为了实现这一点，我们评估了各种选项并从 CompilerWorks 选择了一个工具。它的转译器让我们可以在 BigQuery 中创建 DDL，并使用该模式（schema）将 DML 和用户 SQL 从 Teradata 风味转为 BigQuery。PayPal 努力强化了转译器配置，以生成高性能、干净的 BigQuery 兼容 SQL。
这种自动代码转换对我们来说是非常关键的一步，因为我们希望为用户简化迁移工作。除了代码转换之外，我们还从 CompilerWorks 的工具中提取了有价值的血统（lineage）数据。我们创建了一个自动化框架以及一个用于交互式使用和自助代码转换的门户。自动化框架不断轮询本地基础架构的更改，并在创建新工件时在 BigQuery 中创建等效项。我们要求用户使用这个门户将他们现有或已知的 SQL 转换为与 BigQuery 兼容的 SQL，以进行测试和验证。我们还利用这一框架来转换用户的作业、Tableau 仪表板和笔记本以进行测试和验证。这种自动化框架帮助我们转换了超过 1 万条 SQL。
负载、模式和表标识
为了确定负载的范围，该团队检查了我们存储库中的所有笔记本、Tableau 仪表板和 UC4 日志。根据我们确定的表，我们创建了一个血统图来制订一个包含所使用的表和模式、活跃计划作业、笔记本和仪表板的列表。我们与用户一起验证了工作范围，确认它的确可以代表集群上的负载。这帮助团队大大减少了我们需要迁移的负载数量。以下是从总体清单中弃用的内容细节。
图 3：在迁移过程中弃用的负载
对自动化框架的投入帮助我们区分了用过 / 未使用的内容，并在最后一步获得用户的验证。让用户手工确认会很枯燥，且容易出错。
数据移动、加载和验证
在我们完成这个项目的过程中，很明显数据移动与我们的设置高度相关，并且要使用现有的工具将数据无缝复制到 Google Cloud Platform 会出一些问题。这是整个项目中最难的部分。它的难点在于偶然出现的复杂性，而非容量。以下是我们遇到的问题：
- 资源可用性和使用情况：由于我们是从一个本地仓库中提取数据的，因此我们的提取速度受到源上可用能力的限制。我们的仓库使用率存在季节性波动，在高峰时期运行数据提取会非常缓慢。如果我们为提取过程分配更多容量来加速数据传输，就需要一天或整个周末来人工操作。
- 源上的数据操作：由于我们在提取数据时本地系统还在运行，因此我们必须将所有增量更改连续复制到 BigQuery 中的目标。对于小表，我们可以简单地重复复制整个表。对于每天添加新行且没有更新或删除的较大表，我们可以跟踪增量更改并将其复制到目标。对于在源上更新行，或行被删除和重建的表，复制操作就有点困难了。
- 源中的 DDL 更改：为支持业务用例而更改源表是不可避免的。由于 DDL 更改已经仅限于批处理，因此我们检测了批处理平台，以发现更改并与数据复制操作同步。
- 数据类型：虽然 Teradata 和兼容的 BigQuery 数据类型之间的映射很简单，但我们还要设法处理很多隐式行为。例如，我们在应用程序依赖的源数据中包含带有隐式时区的时间戳，并且必须将其转换为 Datetime（而非 Timestamp）才能加载到 BigQuery。同样，在复制到 BigQuery 之前，必须修剪源系统中的字符串值，才能让使用相等运算符的查询返回与 Teradata 相同的结果。
- 数据加载：一次性加载到 BigQuery 是非常简单的。但要定期将源上的更改复制到 BigQuery，过程就变复杂了。这需要从源上跟踪更改，并在 BigQuery 中重放它们。为这些极端情况处理大量积压的自动数据加载过程是非常有挑战性的。由于我们正在逐步切换用户，因此我们必须意识到 BigQuery 中的表需要具有生产级质量。
- 数据验证：在数据发布给数据用户之前，需要对数据进行多种类型的数据验证。这包括行计数、分区计数、列聚合和抽样检查。
- BigQuery 的细微差别：BigQuery 对单个查询可以触及的分区数量的限制，意味着我们需要根据分区拆分数据加载语句，并在我们接近限制时调整拆分。
干运行和湿运行
干运行，指的是没有数据的执行，可以确保变换的查询没有语法错误。如果干运行成功，我们会将数据加载到表中并要求用户进行湿运行。湿运行是一次性执行，用来测试结果集是否全部正确。我们为用户创建了用于湿运行的测试数据集，在湿运行后再验证他们的生产负载。所有这些都是为使用我们的应用程序生命周期管理门户的用户设计的，我们的用户习惯用这个门户部署应用程序。我们非常重视将我们的测试融入用户习惯的生态系统的理念。
进展的可见性
上述活动中很多是同时进行的。这就需要沟通协调，但人类或协作电子表格是很难做好这一工作的。我们跟踪 BigQuery 中的所有数据，这些数据会在执行发生时自动更新。我们创建了一些仪表板来跟踪活动的顺序，并向我们的高管和利益相关者一致地报告进展情况。这些仪表板跟踪多个里程碑的数据复制进度、负载合理化以及笔记本、计划作业和干湿运行的 BI 仪表板的准备进度。示例报告如下所示。用户可以通过数据库名称和表名称来搜索以检查状态。
图 4：数据复制仪表板示例
进展顺利
团队合作成就梦想。
在我们的案例中这句话非常正确，因为这个里程碑是 PayPal 的许多团队齐心协力打造的。我们相信是下面这些理念让我们的故事与众不同，帮助我们取得了成功：
- 了解你的客户：这在我们的整个旅程中是非常重要的思想。我们的产品团队在了解客户如何使用和处理数据方面做得非常出色。产品团队也非常了解数据用户用来处理数据的工作流程。这有助于工程团队确定需要解决哪些问题。
- 经常和尽早互动：我们从旅程的第一天起就与我们的用户互动，与他们分享我们所看到的成果，告诉他们我们计划如何取得进展。我们与用户分享了我们的计划、创建了工作组并集思广益。让我们的用户参与旅程对我们的成功至关重要。
- 自动化带来严谨性：这一点很重要，但在大型项目中却往往被忽视。即使最终产品是一次性使用的，如果我们必须从头开始重做，自动化也有助于提高性能。自动化在很大程度上提升了可重复性和可恢复性。
- 项目管理：我们有一个非常优秀的项目团队，分布在全球各地。项目团队确保每条轨道都针对常见的里程碑报告和跟踪进度。所有进度都在一个通用仪表板中进行跟踪，每个人都可以查看和验证它们。
- 利益相关者审查：我们邀请我们的用户和利益相关者（包括 Google Cloud Platform 客户团队）进行定期审查，以跟踪风险、寻求帮助并对我们所做的事情保持透明。由于我们以透明的方式管理和跟踪项目，因此我们得到了行政层面的支持。
- 完美是优秀的敌人：鉴于这一变革的规模之大，我们明白我们不可能做到完美。我们制定了要遵守的基本规则。在我们完成项目的过程中，我们发现了多个需要重新设计或重新架构的地方。我们没有添加轨道，而是专注于我们的主要目标，并在短期内解决了这些设计挑战。
- 与 Google Cloud Platform 的关系：这一点也很关键。我们与 Google Cloud Platform 专业服务、客户工程、客户和执行团队建立了良好的关系。我们邀请这些团队参与我们的设计讨论、审查工作项目、审查积压工作、寻求帮助并在遇到问题时共同解决。这还帮助 Google Cloud Platform 针对我们的用例尽早启用特性，并快速响应我们的错误。我们将 GCP 帐户和 PSO 团队视为我们的合作伙伴，当然也得到了回报。
总结与后续
目前，PayPal 的用户社区已经顺利过渡到了 BigQuery。用户需要项目约定方面的上手帮助（与 Teradata 相比，这对他们来说是新的概念）；在一些帮助下，他们很快就提高了工作效率。用户非常喜欢 BigQuery 日志的查询性能优势、更快的数据加载时间和完全可见性。
带领 PayPal 完成这次迁移，帮助我们评估和观察了 BigQuery 和 Google Cloud Platform 可以为 PayPal 带来哪些收益。数据用户现在使用 SQL，以及通过笔记本使用的 Spark 和通过 BigQuery 使用的 Google Dataproc。这有助于我们维护数据的单一副本，以及 Google 数据目录为我们的数据提供的可见性。
我们正在计划将来自财务、人力资源、营销和第三方系统（如 Salesforce）以及站点活动的多个数据集整合到 BigQuery 中，以实现更快的业务建模和决策制定流程。团队正在研究流式传输能力，以将站点数据集直接注入 BigQuery，让我们的分析师近乎实时地使用。除了 BigQuery，我们的一些团队还利用 Google DataProc 和 Google CloudStorage 来整合我们基于开源的数据湖中的许多部分，如图 1 所示。
致 谢
PayPal 有许多员工直接或间接参与了这项工作。我们印度办事处的许多员工在应对肆虐的疫情同时还花很多时间投入这项工作。我们对他们所有人表示感谢！
非常感谢领导该项目的 Vaishali Walia，以及帮助保持迁移正常进行的整个德勤团队。
还要感谢为本文提供意见的 Bala Natarajan，以及帮助撰写本文的 Melissa O'Malley、Michael Davis 和 Parviz Deyhim。
原文链接：
https://medium.com/paypal-tech/400-days-paypals-data-warehouse-migration-to-google-bigquery-8c3b845eb6c9
