想象一个你可以几分钟内部署完整的企业级数据平台的世界，这里的数据平台可以赋能你的数据从业者独立编写复杂、端到端的数据管道，以一种标准化和可扩展的方式。这样他们就可以从第一天起就能专注于洞察。

这是Analytics Engineering Framework (AEF)背后的愿景，该框架提供了一套全面且有明确观点的设计和示例代码，用于在Google Cloud Platform (GCP)上构建和部署稳健、灵活且经济高效的数据平台。

虽然 BigQuery 提供了一个综合解决方案来应对现代数据挑战，在单一平台上统一数据管理、治理和分析，但围绕它构建强大的 DataOps 战略常常感觉像是在拼复杂的拼图，需要组织将各种工具拼接在一起，包括 IaaC、CI/CD、数据导入、调度和受治理的目录清单。

这种复杂性导致了巨大的工程成本，包括设置、维护和培训，为希望在Google云端平台上利用数据分析功能的同时按照软件工程的原则来构建一个易于维护的平台的组织设置了很高的门槛。

情况进一步复杂化，因为数据举措的投资回报率（ROI）通常不清楚。在复杂平台上的大量投资尤其风险重重，特别是当数据的价值还不明确时。

• 碎片化开发: 各个数据管道单独构建，导致不一致和重复，且难以快速实现新的用例。
• 集中瓶颈: 这造成了瓶颈并阻碍了敏捷性。
• 有限的可扩展性和灵活性: 扩展和适应新用例的管道充满挑战并耗时。
• 成本效益低: 比如 Apache Airflow 这样的编排工具在大规模操作时成本较高，一些组织需要成本效益更高的替代方案。

数据团队经常遗留围绕CI/CD、IaaS、可观测性和最小权限原则的技术债务。建立一个基础数据平台层，主动填补这些潜在空白，将使团队能够专注于构建他们的数据流。

AEF通过引入数据平台开发的新范式来应对这些挑战。其核心设计原则包括：

AEF采取了多仓库策略，分别为以下设置了专门的仓库：

分别是：

1. 编排框架: 由分析工程师维护，提供无缝、可扩展的编排与执行基础设施。
2. 数据模型: 直接由一线数据工作者使用，以管理数据模型、模式和Dataplex元数据。
3. 数据编排: 直接由一线数据工作者使用，定义和部署数据管道，使用层级、线程及步骤。
4. 数据转换: 直接由一线数据工作者使用，定义及部署数据转换。

这种职责分离使得独立部署、可扩展性和不同平台组件的清晰责任成为可能。每个仓库都应有自己的 CI/CD 流水线，从而实现独立部署，加快迭代周期。

AEF 是基于分析工程的原则构建的，让数据从业者可以独立地用软件工程的最佳实践来构建、组织、转换和记录数据。这促进了一个自助服务的数据平台，在这个平台上，数据从业者可以创建自己的数据产品，同时遵循一个分散的计算治理模型。

AEF旨在与编排工具和数据处理引擎无关。虽然它提供了Cloud Workflows和Cloud Composer的示例编排代码，但它可以与其他工具根据具体需求进行集成。这种灵活性使其能够与现有系统无缝集成，并为未来的数据平台做好了准备。

（Serverless-First）

AEF优先使用无服务器技术，利用Cloud Functions、BigQuery和Cloud Workflows等的扩展性、成本效益和易用性。这减少了长期运行服务器的需求，从而降低了运营开销和成本。

通过采用无服务器技术并为数据管道开发提供标准化的框架，AEF显著降低了构建及运营数据平台的成本。这确保平台的成本效益，并使平台能够被更多组织所使用。

尽管数据模型由于其重大影响很少被改动，但它们需要强大的模式演进控制。相比之下，数据管道更频繁地进行更改，并由不同角色的人员开发。可重用的数据转换还可以在各个团队间共享。

此外，核心能力需要被保障和标准化，以确保多个团队能够使用，并提供自助式数据平台体验。

所以，要创建一个可扩展且稳健的数据平台，职责分离、独立的存储库以及 CI/CD 流水线（持续集成/持续部署）非常重要。

多仓库策略和持续集成/持续交付（CI/CD）策略是AEF设计的核心，使AEF能够实现：

• 清晰的所有权和责任: 不同的团队可以拥有和管理特定的仓库，培养所有权和责任感。
• 独立部署和可扩展性: 每个仓库都有独立的 CI/CD 流水线来实现对部署和扩展的精细化控制，这些组件可以在不同的时间间隔发布。
• 失败隔离: 一个仓库中的失败不太可能影响其他组件，从而保证整体平台的稳定性。
• 更容易进行细粒度的回滚: 更容易在细粒度级别进行回滚，将部署问题的影响降到最低。
• 并行开发: 多个团队可以同时对不同的仓库进行工作，加速开发并促进团队间的协作。

CI/CD通过自动化部署发挥关键作用，从而实现自助式服务并减少错误发生。此外，它支持版本控制和回退，允许在出现问题时轻松恢复。可以将自动化测试整合到CI/CD流程中，以确保代码的质量和完整。通过简化这些流程，CI/CD使迭代更为快速，加快了新功能和错误修复的开发和部署速度。

数据编排 对数据湖和数据仓库至关重要。数据编排是协调和管理数据流的过程，以确保数据在不同系统和应用程序之间顺畅流动。虽然 Composer 有很多好处，但并不能完全解决 Airflow 的运营难题。使用 Cloud Workflows，它具有自动扩展和按需计费的特点，是一个无服务器且成本效益高的替代选择，能够节省资源，降低成本，并加快一些特定场景的价值实现。

AEF 提供灵活性，让每个组织都能根据自己的需求选择最适合的编排工具。关于领域驱动与中心编排的更多细节，可以参考此处。

基于域的编排： 按域隔离编排可能会简化IAM和网络管理，但可能会增加操作开销和复杂性。这种方法更适合多域环境，每个域的数据访问和处理需求各不相同。这在数据编排仓库中有具体展示，每个数据域团队都有自己管理并部署的Composer环境副本。

中央编排: 将编排集中到一个单独的项目中可以集中数据操作，并可能减少管理复杂性。这种方法可能更容易理解与管理，特别是在单一领域环境或具有共享网络的环境中。然而，可能需要调整IAM。使用Cloud Workflows时，这很容易管理，因为无服务器特性允许在所有数据域团队共用的单个集中项目中部署。

这两种方法都是有效的，而“‘权威的’指南”可以根据特定组织的需求和限制进行相应的调整。因素如域的数量、数据访问模式和网络配置应影响决策过程。简化复杂的数据管道的开发过程。

AEF的核心部分之一是其数据管道编排的方式。为了简化但又不失强大的编排抽象，AEF引入了三个核心概念：

• 步骤：表示单个数据转换，例如执行一个 BigQuery 保存的查询，运行一个 Dataflow 或无服务器 Dataproc 任务，甚至触发一次 Dataform 仓库的运行。
• 线程组：将一系列步骤分组，使它们按顺序执行，从而使不同任务集可以并行执行。
• 层级：允许结合顺序和并行执行，同层级内多个线程可并发运行，而下一层级只有在上一层级所有任务完成后才会执行。

有了这三个简单概念，可以轻松地定义为参数文件，数据人员就可以独立定义复杂的数据处理管线。

将翻译成实际的 Cloud Workflows 定义或 Airflow DAGs，并部署这些高级编排配置作为 CI/CD 流水线中的步骤。

类似地，数据处理人员将会编写简单的参数配置文件来描述他们的数据转换。这些配置文件位于对应的仓库中。

同样地，数据模型仓库将存储Dataplex的元数据定义，以便实现数据治理、数据可发现性和访问控制。此外，数据模型仓库还将跟踪DDL、模式（schema）和数据集，包括它们的部署情况和版本控制。

咱们直接上手吧。

此示例（demo）让你可以轻松地部署和测试AEF。它包括你开始使用所需的一切，如示例数据和来源，。你将学会如何：

• 填充示例数据：
  — 部署本地JDBC数据源数据库的模拟版本。(详情)
  — 填充示例GCS 主机文件。
  — 填充示例GCS CSV 文件。
• 部署AEF： 克隆仓库并运行初始的Terraform部署，包括用于以下的示例参数文件：
  — 数据模型DDL和元数据。
  — 数据管道定义。（示例包括Cloud Composer和Cloud Workflows）。
  — 数据转换。
• 在AEF中运行端到端的数据管道： 使用Cloud Composer和Cloud Workflows：
  — 从不同来源提取数据： 这包括使用Dataproc处理主机文件，以及使用Dataflow灵活模板处理数据库中的数据。
  — 处理数据： 使用Biglake读取GCS文件，并对其执行连接和转换操作，使用dataform连接和转换数据。
  — 创建数据产品： 将转换后的数据提供给BigQuery使用。

这个演示案例在一个单一的 Google Cloud 项目中部署整个 AEF 系统，并展示了数据产品从原始数据到最终可用表格的整个过程。

AEF 为在 GCP 上构建现代化、可扩展且成本效益高的数据平台提供了蓝图。其多存储库策略结合了稳健的 CI/CD 流程，使数据从业者能够独立构建和管理复杂的 数据流，加快了从数据中获取见解的速度，并让组织能够更专注于从数据中提取价值。