由 Blake Im 和 Corey Cheung 共同创作。

· 引言
· 旧世界
· 新世界
· 移民
∘ 存储层
∘ 处理层
∘ 使用层和变更管理
· 结论

在2024年第四季度，Lyka的数据分析团队从Google BigQuery数据仓库迁移到了AWS上的湖仓架构。我们的新栈包括存储在S3中的Iceberg表、用Glue作为目录、使用dbt进行转换、Snowflake和Athena作为查询引擎，以及使用Airflow进行编排。本文将重点介绍我们如何迁移约400个dbt模型和约90个Omni仪表板，同时引入这些新技术。

但首先，让我们了解一下背景……

Lyka（https://lyka.com.au/）是一家直销的电子商务品牌，销售符合人类食用标准的狗粮。我们在悉尼和墨尔本的工厂进行生产，并送货到您的家门口。Lyka的分析团队旨在通过融入各个业务领域来建立一个以数据驱动的文化。这使我们能构建数据产品，提供前瞻性见解，并有效管理关键指标。要做得好，数据平台是我们运营的关键。

我们的先前数据平台是一个相当标准的“现代数据栈”实现——这是一种 ELT 模式，已经在过去十年左右的时间里被许多数据团队验证过了。我们使用了如 Fivetran 和 Segment 等工具将分散的数据源集中起来，并将数据摄入到我们的 BigQuery 仓库中。接下来，dbt 会将原始数据转换为我们的“展示层”（金质架构）。接着，Omni 将利用这些数据进行 BI 报告，而 Hightouch 则用于反向 ETL（即反向数据提取和加载）——标准做法。

我们的旧数据处理任务主要涉及运行每天的批处理任务以进行报告，以及在HubSpot和CustomerIO中的数据激活和临时的数据探索分析。这套技术栈对我们来说非常适合这些简单的流程——它在我们心中永远占有一席之地。

Lyka的老式现代数据栈

那我们为什么建了个数据湖呢？

首先，我们做出了一个重要决定，将我们的云服务提供商进行整合。由于我们的工程团队使用AWS，而数据团队使用GCP，统一技术栈可以促进更紧密的合作。此外，我们内部推动制造与供应链运营向工业4.0发展的倡议，需要处理低延迟的半结构化物联网数据。营销技术栈的改进进一步要求下游工具所需的数据增强要达到低延迟。我们相信湖仓架构可以满足我们的多样化需求，但我知道这并非唯一的选择——毕竟，构建数据栈的方法不止一种。

一个湖仓结合了数据湖和数据仓库的功能，成为一个统一的平台——多亏了夏洛克。在这个架构中，我们可以存储原始的结构化、半结构化和非结构化数据在我们自己的管理型存储中，如数据湖。借助我们选定的处理引擎，我们能够实现强大的查询性能和ACID事务支持，以满足分析需求，就像使用数据仓库那样。

来自Databricks的一张照片

我们新的数据湖仓

让我们概述一下平台中保持不变的部分。我们的数据摄入和rETL工具将保持不变——不过，我们很快就会用低延迟的数据摄入工具来代替Fivetran，用于事务型数据库。而Omni和dbt core仍然负责BI和数据转换。

所以有什么不同？我们的新湖屋将 S3 作为数据湖，数据以 Parquet 文件的形式存储在 Iceberg 表格式中。Snowflake 是主要的查询引擎，通过 外部 Iceberg 表 直接从 S3 读取数据。当费用过高时，Athena 也直接查询数据湖（目前主要用于我们的低延迟工作流程）。所有流程都由 Airflow 在 MWAA 中编排，而 Terraform 负责管理 Snowflake 的基础设施。

让我们看看我们是怎么迁移的。

Lyka的新湖屋（对，它叫杰夫）

为了使我们的云服务提供商与我们的工程团队保持一致，我们选择了AWS作为新的云提供商，并将数据存储在S3中是一个显然的选择。由于Fivetran仍然是我们的主要数据导入工具，迁移数据源主要涉及到收集来自公司各处的各种凭证。在我们完成了这个追查凭证的过程后，我们就准备开始迁移数据了。

文件格式、表格样式和文件目录

存储在没有表格式的 parquet 文件中的数据存在固有的局限性。例如，parquet 文件是不可变的，意味着它们默认情况下不支持 更新 或 删除 操作。此外，没有原生的方式来索引数据或分区数据，这可能导致查询变慢。基于 Athena 的外部表可以通过支持分区和模式管理来解决其中的一些问题，但是它们并不能解决所有的问题。肯定有更好的办法。

如果你从事数据领域的工作，你肯定经常听到 Apache Iceberg 这个词了。简单来说，Iceberg 是一种开源的表格式，它通过添加一个元数据层来将你的 Parquet 文件转换成一个表。这个元数据由一个数据目录进行管理和组织（我们使用的是 Glue 目录）。Iceberg 的几个主要优点包括：

• 模式演进 — 可以添加、删除和重命名列，这意味着我们可以灵活地管理数据结构。
• ACID 事务 — 提供原子性、一致性、隔离性和持久性，从而确保数据的完整性。
• 分区和时间旅行 — 提高查询性能，并允许您查询历史数据。
• 扩展性 — 可以高效地处理 PB 级数据。

你可能在想，我在 Snowflake、BigQuery 和 Redshift 都能获得这些东西。你是对的。但是关于 Iceberg 最重要的一点是，以及为什么你可能需要一个湖仓，是它开源且可以在多个引擎上运行。这意味着你不会被某个供应商捆绑，并且你可以用你喜欢的查询引擎处理数据。

换句话说，Snowflake 是我们主要的查询引擎，用于批处理分析任务。为了使 Snowflake 查询我们的 Iceberg 表格，我们首先配置一个外部存储，以便它可以访问 AWS。配置完成后，我们只需使用 DDL（数据定义语言）创建 Iceberg 表格。

完成这一步后，我们就可以像查询Snowflake中的本地表一样查询外部Iceberg表了。除了它可以存放在我们自己的存储中，我们还可以使用任何想要的查询引擎！当我们想减少延迟并且持续运行Snowflake仓库成本太高时，这时我们通常使用Athena来进行查询。

让我们继续沿着DAG往下，讨论数据转换。使用dbt，我们的转换逻辑是平台独立的，独立地存在于Github中。这大大简化了迁移步骤——只要SQL语法正确，dbt项目应该可以在不同的供应商间无缝运行……只要源表具有相同的模式。从理论上讲，剩下的主要任务是从BigQuery SQL转换到Snowflake SQL。到这个时候，我们已经有超过400个dbt模型（SQL文件），这促使我们寻找自动化的方法来完成转换。

用 Claude 3.5 Sonnet 翻译 SQL 语句

为了将我们所有的dbt模型进行转译，我们测试了SQLGlot和多种大型语言模型（LLM）。我们发现Claude 3.5 Sonnet（某个特定版本）的效果最好，并编写了一个Python脚本来程序化转译我们的dbt模型——这通常工作得很好。但就像许多LLM应用场景一样，它几乎总是正确的，但并非总是百分之百准确。由于令牌限制，较大的dbt模型需要拆分成200到300行的块来处理，这让模型感到困惑。

这是我们决定进一步自动化将不再有回报的时刻。

鉴于这是一次性的高风险迁移，而且虽然艰难但仍可以手动处理的大约 400 个 dbt 模型，我们使用脚本帮助迁移，但未完全自动化。这意味着我们手动检查了每个迁移脚本的输出，确保其结果合理（稍后会详细讨论测试）。在此期间，数据团队被要求冻结 dbt 代码。

适应不同的成本模型和处理方式

一个意想不到的挑战是在使用过程中我们发现BigQuery和Snowflake在处理更大查询时的扩展方式不同。在我们的BigQuery定价模型中，计算资源会根据查询需求动态调整，我们则按处理的字节数付费。在Snowflake中，通过其计算仓库的概念，可以更精细地控制每个查询的处理能力。

当我们第一次天真地将所有内容都放在最小的计算集群上时，一些较大的模型会出现超时的情况。我们重构了一些明显的低效之处，并为较大的模型引入了不同的集群大小，使用了 dbt 预处理钩子。虽然这些改进很简单，但了解并提前考虑这种成本差异是值得的。

测试一下DBT的输出

为了确保dbt代码翻译的准确性，我们采用了自动化和手动测试相结合的方式。我们发现单一的方法不足以涵盖所有情况，但不同测试方法的结合让我们感到相当放心。

• dbt 测试：在我们项目中已经存在主键测试、业务逻辑测试和参照完整性测试，这些测试抓住了最明显的错误。尽管我们还没有实现新的dbt 单元测试，但这些测试在这里会很有用。
• 行级测试：通过主键匹配并测试行级差异。我们编写了一个 Python 脚本来完成这个任务，但也遇到了一些挑战。由于刷新时间不一致，数据从来无法做到100%匹配；由于缺乏主键标记，需要手动输入；Snowflake 和 BigQuery 之间数据类型的不一致导致了假阴性。在这些限制下，这更多地起到了高层次的检查作用。
• 聚合测试：我们列出了最重要的业务关键指标的详尽清单，并确保了正确的输出（例如，过去 24 个月的月活跃客户数（MAU））。

就关键学习而言，开发新的dbt单元测试并为重要模型保持主键标记和行级版本的一致性，这将使测试过程更加稳健和自动化。

最后一步是让所有使用Lyka数据的工具和人员访问我们迁移的数据——我们首先从我们的BI工具[Omni]开始着手。这真正考验了迁移是否成功，因为大多数利益相关者主要是通过这种方式与我们的数据平台交互。

迁移仪表板是一项耗时的任务，但也为我们提供了清理不再维护的冗余报告的机会。我们首先只专注于核心的公司范围仪表板，然后与各个业务领域合作，识别其他关键的业务领域仪表板。最后，我们淘汰了那些不再使用的仪表板，大大减少了迁移的工作量，这使我们有了一个治理更佳的崭新起点。

仪表板迁移的技术方面遇到了一些独特的挑战，因为Omni是一个相对较新的工具，在迁移功能上还比较有限。简而言之，我们不得不重新制作这些仪表板，并将它们指向Snowflake连接，使用了Omni团队提供的内部API。另外，我们将所有Python脚本和rETL管道重新指向新的数据。

传达这些变化

一旦新的Snowflake仪表板经过测试并准备好，我们开始归档旧的BigQuery报告并完成切换。从大多数利益相关者的角度来看，迁移被认为已经完成。这时，迁移的后果开始影响实际的业务操作和财务状况。这是一个非常敏感的阶段，我们不得不时刻与利益相关者保持紧密沟通。我们学到的关键几点是：

• 沟通永远不会过多——在某个随机的 Slack 频道上发一次帖子并不意味着你已经完成了沟通！在整个迁移过程中保持所有利益相关者的同步信息是成功的重要部分。
• 不管你沟通得多好，硬性控制才是引导人们正确行为的有效方式。尽快从旧平台移除访问旧数据的权限——你会惊讶于有多少人能找到继续使用旧数据的途径。
• 即便经过了所有测试，仍然会有一些问题出现的可能。所有利益相关者都应该明白这一点，并应该保持一定的怀疑态度，以便尽早发现问题并及时解决。

我们将 BigQuery 和 Snowflake 实例运行了几周，以应对任何紧急问题，确保冗余。

就这样，我们在一个季度内完成了整个数据栈的迁移。从数据存储、调度和处理，到测试和结果的传达，我们每个阶段都学到了很多。数据的世界发展得非常快，我们很期待看到我们的数据平台未来会如何变化。