构建可扩展的数据平台（数据平台设计中的数据网格趋势）

添加图片注释，不超过 140 字（可选）

欢迎来到雲闪世界。在本文中，我旨在深入研究各种类型的数据平台架构，更好地了解它们的演变、优势、劣势和实际应用。重点是数据网格架构、它在现代数据堆栈 (MDS) 中的作用以及当今的数据驱动格局。

众所周知，数据平台的架构对其性能和可扩展性有深远影响。挑战通常在于选择最符合您特定业务需求的架构。

鉴于当今市场上有如此多的数据工具，人们很容易迷失方向。我时不时看到的有关这个主题的互联网文章往往具有高度推测性。关于哪些工具最好、谁引领行业以及如何做出正确选择的问题可能会让人非常沮丧。本文面向希望进一步了解数据平台设计以及在每种情况下应选择哪种平台的数据从业者。

现代数据堆栈

我在互联网上几乎每个与数据相关的网站上都听到过这个术语。每个 LinkedIn 数据组都提供了十几个关于这个主题的帖子。然而，其中大多数只涉及数据工具，并没有强调与数据平台设计过程相关的战略考虑的重要性。

那么什么是“现代数据堆栈”以及它有多现代？

本质上，它是一套旨在帮助您处理数据的工具。根据您的业务目标，这些工具可能包括托管的ETL/ELT 数据连接器、商业智能(BI) 解决方案、数据建模工具（Dataform、DBT 等），有时，重点不一定是这些工具有多现代，而是它们如何有效地满足您的需求。

当数据流经管道时，它会被处理、输入数据仓库或数据湖、进行转换和可视化。所有这些步骤都有助于决策者获取数据视图并迅速采取行动——无论是用户保留故事 [1] 还是银行系统中的欺诈检测算法。

添加图片注释，不超过 140 字（可选）

可扩展性

现代数据堆栈 (MDS) 的核心是简单性、终端用户的便利性和可扩展性。事实上，如果您的主要利益相关者不喜欢或不知道如何使用您的 BI 工具功能，那么无论您的 BI 工具功能有多强大，都没有意义。除了其他出色的功能外，它可能还具有 Git 集成和用于数据管道的强大 CI/CD [2] 功能，但最终，如果您无法将您的仪表板或报告呈现为 PDF 文档，那也没关系。数据建模很重要，我们使用 DBT 和 Dataform (GCP) 等现代工具创建数据模型。不要重复自己——尽可能使用 DRY [2] 方法。

如果以错误的方式进行数据建模，那么它就是无用的。

这些数据模型必须可重用且经过单元测试。根据 DBT

DRY 是软件开发原则，代表“不要重复自己”。遵循这一原则意味着您的目标是减少重复模式和重复代码和逻辑，转而使用模块化和可引用的代码。

DRY 方法不仅可以节省您的时间和精力，还可以增强代码的可维护性和可扩展性。也许最重要的是，掌握这一原则是让您从一名优秀的分析工程师晋升为一名真正优秀的分析工程师的关键因素。这一原则是我始终致力于实现的。它使我的代码可重用且可靠。

数据湖、数据仓库和数据网格

以我的经验来看，它从来都不是单一类型的数据平台架构。数据湖更适合具有编码技能的用户，通常是非结构化和半结构化数据处理的理想选择。图像、文本文档、语音消息等——所有内容都可以存储在数据湖中，因此可以进行处理。这使得这种架构非常有用。

在数据湖中处理大数据通常更容易，这使其成为超大数据量的最佳选择。

缺点是我们的数据用户必须能够使用流行的数据湖工具之一——Dataproc、EMR、Databricks 或 Galaxy。通常，公司很难找到具有出色 Python、SQL 和数据建模技能的优秀数据开发人员。这就是数据工程师如此受欢迎的原因

这些分布式计算工具可以很好地适应不断增长的数据工作负载，并能扩展以确保在需要时处理数据。

对于数据管道设计相当简单且数据量足够的公司来说，融合数据仓库和数据湖元素的混合架构可能是最佳选择。

它结合了每个数据平台架构的优点，在我的项目中，我最常使用它。数据分析师很高兴，因为它提供了执行交互式 SQL 查询的能力，同时保持了高度的定制灵活性，以防我的数据管道需要扩展处理资源。现代数据仓库解决方案通常支持对存储在数据湖中的数据进行交互式查询，例如通过外部表。例如，数据管道可能设计如下：

添加图片注释，不超过 140 字（可选）

这对于数据迁移也有很大帮助。事实上，任何数据模型都可以建立在数据湖之上。DBT 和 Dataform 等工具最终仍使用 ANSI-SQL 方言，迁移任务将是数据适配器中的简单更改。

数据网格平台旨在支持无缝地跨不同部门共享数据。这是正在经历合并或收购过程的公司的一个典型用例场景。事实上，假设一家公司拥有一个数据仓库，数据从数据湖中提取，并使用 DBT 进行处理以在 Looker 中可视化报告。现在假设它被一家更大的公司收购，该公司的数据堆栈主要是带有流式组件的数据湖。数据在 Airflow 管道（批处理）和实时独立数据服务（流式传输）中进行处理。

数据网格有助于整合不同的平台和数据域。

数据网格架构代表一种分散的数据管理方法，使您的公司能够自主处理数据并进行跨团队和跨领域的分析。

在数据网格设置中，每个业务部门可能拥有多种编程技能，例如 SQL 或 Python，并且具有不同的数据处理需求，从灵活的数据处理到交互式 SQL 查询。因此，每个部门都可以自由选择适合其特定需求的首选数据仓库或数据湖解决方案。尽管存在这些个人选择，但该架构有助于跨部门无缝共享数据，而无需移动数据，从而确保数据在整个组织内保持可访问和集成。

说起来容易做起来难。

我们可以看到，自 2014 年（Airflow 被引入更广泛的社区）以来，数据工程格局发生了重大变化，现在可以解决更复杂的用例和要求，包括支持多种编程语言、集成和增强的可扩展性。

这种协作的“数据网格”设置至关重要，因为它允许每个团队在同一环境中操作，同时避免中断彼此的工作流程，从而促进更加集成和高效的数据处理和分析方法。

我的研究强调了数据管道编排中几个关键趋势的重要性。这些趋势包括关注异构性、支持多种编程语言、有效利用元数据以及采用数据网格架构。拥抱这些趋势对于开发能够适应不同需求并有效扩展的数据平台至关重要。

异构性对于创建现代、强大且可扩展的数据平台至关重要。

实现数据网格架构

实现数据网格的最简单方法是遵循以下原则：

• 使用微服务：数据网格从定义上来说就是分布式的，它不是单片的。创建专用的 API 服务/编排器非常有意义。它可以充当所有其他数据处理服务的数据中心。它们可以在需要时调用数据中心服务，反之亦然。

• 拆分数据环境：为开发、生产和自动化测试创建单独的环境非常重要。它简化了新的数据模型和管道部署，并使我们的代码经过测试和可重复使用。

• 始终考虑“DRY”方法：使用其他数据项目及其存储库作为包可以让生活更轻松。

• 使用基础设施即代码：这是必须的，有助于维护我们的管道 [4]。基础设施即代码正成为一种管理数据平台资源的越来越流行的方法。在软件工程师中，这几乎是当今的标准。

请考虑以下示例以及我如何使用 Mage 编排工具实现数据网格。我创建了一项服务，负责对我拥有的其他数据项目中的所有数据管道进行数据编排。

例如，它在我的一个数据管道中实现，其中它提取了另一个包含 DBT 项目的 GitHub 存储库。然后，这个项目成为我在编排器中使用的包：

添加图片注释，不超过 140 字（可选）

然后，如果我运行我的管道，它将把该erd项目作为依赖项安装：

添加图片注释，不超过 140 字（可选）

这种方法可以帮助我在 Data Hub 项目中使用其他 DBT 项目。每次我运行数据管道执行时，它都会从包存储库中提取代码以确保所有内容都是最新的。

我们如何部署它？

好的，我们在本地运行了它，但是我们如何部署它呢？

虽然这项任务可能很复杂，但采用基础设施即代码可以显著提高代码的可扩展性和可维护性。我之前在一篇教程中介绍过这个主题

这代表了许多公司的典型数据流或数据平台设置。真正的挑战在于部署数据管道并有效管理相关资源。例如，在生产和暂存环境中部署机器学习管道需要谨慎的资源管理。

我使用 Terraform [6] 部署了我的数据中心项目。下面这个简单的命令就可以完成这项工作：

terraform init初始化 地形计划 - out =PLAN_dev 地形应用 -input= false PLAN_dev

输出将会像这样：

应用完成！资源：已添加 16 个，已更改 0 个，已销毁 0 个。 输出： load_balancer_dns_name = “http://datahub-dev-alb-123.eu-west-1.elb.amazonaws.com”

如您所见，基础设施即代码使得部署所需的资源（包括 VPC、子网、负载均衡器等）变得非常容易。

例如，我描述所需资源的 Terraform 文件夹结构如下：

. ═── PLAN_dev ═── alb.tf.tf ═── 后端.tf ═── efs .tf ═── env_vars .json ═── iam .tf ═──主要.tf ═── 提供商.tf ═── 变量.tf └── 版本.tf

我的主要 Terraform 定义文件main.tf如下所示。它创建 ECS 集群、任务定义和所有其他所需资源：

资源“aws_ecs_cluster” “aws-ecs-cluster” {"aws_ecs_cluster" "aws-ecs-cluster" { name = " ${var.app_name} - ${var.env} -cluster" 设置 { name = "containerInsights" 值 = "enabled" } tags = { Name = " ${var.app_name} -ecs" Environment = var .env } } // 要删除现有日志组，请运行 cli 命令： // aws logs delete-log-group --log-group-name app-name-production-logs resource "aws_cloudwatch_log_group" "log-group" { name = " ${var.app_name} - ${var.env} -logs" tags = { Application = var .app_name Environment = var .env } } resource "aws_ecs_task_definition" "aws-ecs-task" { family = " ${var.app_name} -task" container_definitions = <<DEFINITION [ { “名称”：“ ${var.app_name} - ${var.env} -container”， “图像”：“ ${var.docker_image} ”， “环境”：[ { “名称”：“ENV”，“值”：“dev” }， { “名称”：“MAGE_EC2_SUBNET_ID”，“值”：“ ${var.mage_ec2_subnet_id} ” } ]， “命令”：[ “mage”，“start”，“datahub” ]， “必需”：true， “mountPoints”：[ { “readOnly”：false， “containerPath”：“/ home / src”， “sourceVolume”：“ ${var.app_name} -fs” } ]， “logConfiguration”：{ “logDriver”：“awslogs”， “options”：{ “awslogs-group”：“ ${aws_cloudwatch_log_group.log-group.id} ”， “awslogs-region”：“ ${var.aws_region} ”， “awslogs-stream-prefix”：“ ${var.app_name} - ${var.env} ” } ， “portMappings”：[ { “containerPort”：6789， “hostPort”：6789 } ]， “cpu”：${ var .ecs_task_cpu}， “memory”：${ var .ecs_task_memory}， “networkMode”：“awsvpc”， “ulimits”：[ { “name”：“nofile”， “softLimit”：16384， “hardLimit”：32768 } ]， “healthCheck”：{ “command”：[ “CMD-SHELL”，“curl -f http://localhost:6789/api/status ||退出 1” ]、 “间隔”：30、 “超时”：5、 “重试”：3、 “startPeriod”：10 } } ] 定义 require_compatibilities = [ “FARGATE” ] network_mode = “awsvpc” 内存 = var .ecs_task_memory cpu = var .ecs_task_cpu 执行角色_arn = aws_iam_role.ecsTaskExecutionRole.arn 任务角色_arn = aws_iam_role.ecsTaskExecutionRole.arn 卷{ 名称 = “ ${var.app_name} -fs” efs_volume_configuration { file_system_id = aws_efs_file_system.file_system.id transit_encryption = “ENABLED” } } 标签 = { 名称 = “ ${var.app_name} -ecs-td” 环境 = var .env } #depends_on = [aws_lambda_function.terraform_lambda_func] } 数据 “aws_ecs_task_definition” “main” { task_definition = aws_ecs_task_definition.aws-ecs-task。家庭 } 资源“aws_ecs_service” “aws-ecs-service” { 名称 = “ ${var.app_name}- ${var.env} -ecs-service” cluster = aws_ecs_cluster.aws-ecs-cluster.id task_definition = “ ${aws_ecs_task_definition.aws-ecs-task.family} : ${max(aws_ecs_task_definition.aws-ecs-task.revision, data.aws_ecs_task_definition.main.revision)} “ launch_type = “FARGATE” scheduling_strategy = “REPLICA” desire_count = 1 force_new_deployment = true network_configuration { # subnets = aws_subnet. public .*.id subnets = var .public_subnetsassign_public_ip = true security_groups = [ aws_security_group.service_security_group.id, aws_security_group.load_balancer_security_group.id ] } load_balancer { target_group_arn = aws_lb_target_group.target_group.arn container_name = “ ${var.app_name} - ${var.env} -container” container_port = 6789 } depending_on = [aws_lb_listener.listener] } 资源“aws_security_group” “service_security_group” { # vpc_id = aws_vpc.aws-vpc.id vpc_id = var .vpc_id 入口{ from_port = 6789 to_port = 6789 协议 = “tcp” cidr_blocks = var .allowed_ips security_groups = [aws_security_group.load_balancer_security_group.id] } 出口{ from_port = 0 to_port = 0 协议 = “-1” cidr_blocks = [ “0.0.0.0/0” ] ipv6_cidr_blocks = [ "::/0" ] } tags = { 名称 = " ${var.app_name} -service-sg" 环境 = var .env } }

更多详情请点击这里 [7]。

主项目有一个基于我所有项目中使用的 ENV 环境变量的数据环境拆分。从包存储库运行 DBT 模型将如下所示：

--选择my_second_dbt_model --target {{ env_var ('ENV') }}

这才是它真正强大的地方。现在，不同部门的数据分析师和数据科学家可以无缝协作，在统一的环境中运行 SQL、Python 和 R。这种集成使他们能够将开发工作集中在一起，简化工作流程并提高生产力。

这个例子突出了不同数据域的集成。

下一步

下一步是进一步扩展这种方法，并开始将数据连接器和管道集成到一个地方。现代数据驱动的应用程序需要一个强大的事务数据库来管理当前的应用程序数据。在实现此类应用程序时，请考虑使用 OLTP 和 RDS 架构。数据网格也有助于整合这些资源。在我们的示例中，我们希望创建一个 Python 数据连接器来从 RDS 中提取数据。

数据平台生态系统中的每个组件（数据湖、数据仓库、湖屋和数据库）都具有独特的优势并服务于不同的用途，但很少是唯一的。

通常，最佳选择取决于成本效率和与开发堆栈的兼容性。

测试各种选项可以揭示数据源或项目与数据平台（无论是数据湖还是数据仓库）的集成程度。无论底层架构如何，都可以轻松使用数据网格工具管理大量数据连接器，以实现无缝数据提取。

然而，有几个考虑因素至关重要：

• 与业务需求的契合度：评估数据工具与特定业务需求的契合度。例如，某些商业智能 (BI) 工具可能采用按用户付费的定价模式，这可能不适合与外部用户共享仪表板。

• 功能重叠：评估工具之间的功能是否存在重叠。例如，确定您是否需要一个在其自己的 OLAP 多维数据集内执行数据建模的 BI 解决方案（而这已由您的数据仓库处理）。

• 成本效益：如果节省成本是优先考虑的问题，那么选择由与您的开发堆栈相同的云供应商提供的数据工具可能会更有利。

• 数据建模的重要性：高效的数据建模至关重要，因为它会影响数据处理的频率，进而影响处理成本。

数据湖和数据仓库之间的选择通常取决于用户的技能组合。数据仓库解决方案通常提供更高的交互性，适合以 SQL 为中心的产品，例如 Snowflake 或 BigQuery。相反，数据湖非常适合具有编程专业知识的用户，因此以 Python 为中心的平台（例如 Databricks、Galaxy、Dataproc 或 EMR）更适合。

结论

在数据网格时代，成功的协作对于数据领域的蓬勃发展至关重要。现代数据堆栈源自我们的数据平台架构，它在这里发挥着基础作用。简而言之，现代数据堆栈通常被描述为一组协助管理和处理数据的工具。这是您在网上许多文章中都能找到的典型解释。然而，这种说法忽视了战略的关键作用，而一个清晰的数据平台设计战略远比任何给定数据工具的单个功能更为重要。我总是通过全面的规划和设计会议来开始一个新的数据仓库项目。

正确组织数据环境还支持自动测试和持续集成 (CI) 管道，确保您的数据转换脚本根据业务需求中概述的逻辑正确执行。部署数据平台资源的方法多种多样，这些资源会将数据输入到您的数据平台中，使用元数据记录这些方法是有益的。这种方法有助于在整个项目中保持清晰度和效率。

我的经验表明，最适合您的业务目标的数据平台架构类型绝不止一种，而是三者的组合。

感谢关注雲闪世界。（Aws解决方案架构师vs开发人员&GCP解决方案架构师vs开发人员）