数据工程解决的十大数据生命周期问题

欢迎来到雲闪世界。解决关键痛点的明确策略

使用Kandinsky 的AI 生成图像

在本文中，我想解决数据工程师在整个数据生命周期中使用管道时面临的一些最大挑战。了解如何管理数据生命周期是我们不断变化的领域的关键。作为一名数据工程师，我经常处理大量不同类型的数据，包括来自数据库、数据湖和第三方 API 等各种来源的非结构化数据。这些因素可能使管理关键数据变得非常困难。我们将介绍数据处理的所有重要阶段，从收集和分析到存储和销毁，我将分享我每天使用的最佳实践。

数据生命周期管理

数据生命周期管理使企业能够采用战略性和规范性的方法来组织和管理数据，从源头到目的地或最终状态（例如存档或销毁）。

本质上，这是一套政策，旨在在数据的整个使用寿命期间（从数据创建到数据过时或由于合规性法规而需要销毁）最大化数据的价值。

典型的数据生命周期遵循众所周知的 ETL 模式。

数据源：数据正在某处创建。这是一个数据创建阶段。它可以是外部和内部数据源 — API（CRM 系统、会计软件等）、关系数据库（MySQL、Postgres）、云存储以及我们可能想要自己创建的许多其他数据源。
数据收集：提取（ETL 中的“E”）。我们希望从数据源中提取数据并对其进行处理 — 要么“按原样”加载，要么先转换然后加载。
数据提取：（ETL 中的“T”和“L”）。我们讨论的是可以转换数据、处理不同文件格式并将数据提取协调到数据仓库解决方案 (DWH) 或数据湖中的 ELT/ETL 服务。
数据存储：这一切都取决于我们的数据管道设计模式 [2]，可以是数据湖、DWH 或 OLAP 数据库。它通常执行存储功能，即数据文件的着陆区，并作为许多其他管道的代理阶段。
数据治理：一套战略政策，确保我们的数据始终安全、准确地可供最终用户使用。
商业智能和报告——创建报告显然是另一项具有挑战性的任务。BI 开发人员通常会做这件事。
数据编排：最后，我们希望有效地编排所有这些疯狂的事情。

据此，我们的数据平台基础设施通常看起来非常复杂：

简化的数据平台蓝图。图片由作者提供。

数据创建阶段

痛点一：数据源管理和数据可观测性

数据沿袭看起来没问题，但是这些数据来自哪里？

在协调从众多来源提取数据时，管理多个数据源可能成为一项重大挑战。考虑将来自十几个 API、关系数据库和原生平台（如 Google Analytics 4）的数据通过 Firebase 集成到数据仓库的复杂性。有效管理这些不同的输入至关重要，我们应该专注于这些数据库实体的细致声明。

这一切都与数据源及其声明有关。

解决方案：

使用 Git 和元数据来声明源。
添加数据源描述、数据来源和所有者。
将来源添加到数据沿袭图，以便每个人都能找到有关它们的信息。
使用现代数据建模工具为所有数据管道创建单一真实来源。
部署数据可观察性测试以更好地了解数据健康状况。

Dataform（由 Google 提供）和 DBT 等高级工具提供了全面的功能，可简化和优化这些数据源的管理，确保高效、有序的数据集成。请考虑以下代码片段：

sources:
  - name: sales_data
    description: Data source description and origins of data.
    owner: data source owner
    database: analytics
    schema: raw_sales
    tables:
      - name: transactions
      - name: orders
          columns:
            - name: order_id
              tests:
                - unique
                - not_null
            - name: status
              tests:
                - accepted_values:
                    values: ['placed', 'shipped', 'completed', 'returned']
            - name: customer_id
      - name: customers

数据收集和摄取

事实上，这两个步骤通常会结合在一起，因为它们是由同一个数据服务执行的。它可以是任何能够执行高效数据操作的东西，例如内置在 Databricks 或 AWS Glue 服务中的 PySpark 应用程序。它也可以是由消息队列事件（Rabbit、SQS、Pub/Sub、Kafka 等）调用的小型云函数。

痛点2：

市场上的开箱即用 (OOTB) 解决方案缺乏功能。

在数据收集或提取过程中，我们总是可以使用 Fivetran 或 Stitch 等托管工具，但有时它们不具备您需要的功能。

例如，考虑一个使用 DWH 销售数据生成发票的数据管道。这些发票必须上传到您的会计系统中。这不是 OOTB 集成，而且不存在。您需要构建自己的数据服务并根据需要协调发票上传。您需要保持其处于热状态并不断刷新访问令牌，以便能够成功验证服务。

解决方案：

如果您是数据工程师，那么您就是解决方案。

如果有人拥有具备相关编程技能的数据工程师，为什么还需要为第三方服务付费呢？看看我每天用来设计和部署持久数据管道的这些 ETL 技术。

痛点三：

第三方工具太贵

无论是 Fivetran、Stitch 还是其他产品，它们的定价模型通常都是基于我们需要提取的数据的行。这通常会导致每月产生数千美元的账单。

解决方案：

构建强大、耐用且经济高效的数据管道，并对副作用进行单元测试。
确保您的代码是幂等的、可重用的并且易于维护。
使用基础设施即代码有效地配置资源。

痛点 4：可扩展性、洞察延迟和运营开销

为数据管道选择正确的架构是成功的关键

设计强大的数据管道是一项复杂的任务，需要进行彻底的需求分析。关注业务需求，确定数据处理的“内容”和“原因”。通过与技术团队合作开发的功能需求来定义“如何”处理。例如，如果业务部门需要实时分析，那么数据的新鲜度将决定是使用批处理还是流处理。

深入了解业务逻辑对于选择合适的工具至关重要。考虑一个简单的管道，将数据从数据仓库业务或集市模型传输到 Google 电子表格中——这对任何数据工程师来说都很简单。

然而，在处理交易监控合规管道中的高度敏感数据时，需要更复杂的解决方案来满足个人身份信息 (PII) 的监管要求并有效管理数据输入/输出功能。

解决方案：

在第一个计划中重点关注高级业务需求，以项目为中心并了解局限性和截止日期。
收集所有功能需求以满足业务需求。
确保您了解最终用户和主要利益相关者的技能——这将定义数据工具。
最后，选择最适合该框架的数据管道设计模式。

数据存储

在许多公司中，数据存储是数据平台的关键组件，用于暂存、保存、分类和存档我们从其他系统提取并用于分析的数据。

数据管道示例。图片由作者提供。

痛点五：

存储成本、模式漂移、文件格式和分区布局——如何优化以及使用哪些？

即使是数据仓库解决方案也有一个存储组件，这会产生相关成本。众所周知，现代 DWH 工具已将计算和存储资源分离。尽管存储成本相对较低，但随着时间的推移，成本可能会累积。考虑一个具有活动模式的超大数据集，其中每天生成数 TB 的用户参与事件。现在想象一下将其加载到您的 BigQuery 数据仓库中。好处是三个月的数据被优化为接近冷线存储类，而且相当便宜，但此后的所有其他数据都进入标准存储类，而且价格要贵得多。

数据湖架构。图片由作者提供。

ORC 与 Parquet 与 AVRO。没有 JSON？

在应用程序世界中，大量数据以 JSON 格式收集和保存。那么为什么不将其存储在 JSON 中呢？因为 JSON 不携带任何架构信息，所以在处理大数据时，Hadoop 工具可能会很慢。基本上，它不适合大数据处理框架。这是创建 Parquet 和 ORC 格式的主要原因。

解决方案：

将数据存储在优化的存储类中对于提高效率至关重要。利用云存储可以灵活地使用 Spark、AWS Glue 或 Databricks 在数据湖内的各个平台上处理数据。如果需要，它有助于将数据重新加载到数据仓库中。
Parquet 和 ORC将数据存储在列中，并提供比AVRO更高的压缩率。如果您的数据结构可能会随时间而变化，并且您需要架构演变支持，那么请选择AVRO。ORC通常被认为是HIVE的最佳文件格式选项，而 Parquet 被认为是整个 Hadoop 生态系统的最佳解决方案。
使用主要云提供商之一（Google、AWS 或 Azure）为具有 HIVE 分区布局的存档创建云存储存储桶。
建立例行程序来监控和卸载过时数据，并将其归档以降低成本。

考虑下面的代码。它显示了卸载数据然后重新加载是多么容易：

-- export data from BigQuery to GCP
EXPORT DATA
  OPTIONS (
    uri = 'gs://events-export/public-project/events.json',
    format = 'Parquet', -- or CSV, JSON, Parquet
    overwrite = true
)
AS (
SELECT *
FROM `firebase-public-project.analytics_153293282.events_20181001`
);

如果需要的话加载数据：

LOAD DATA INTO source.json_external_test
FROM FILES(
  format='JSON',
  uris = ['gs://events-export/public-project/*']
)

痛点六：

安全、主要访问控制和数据保留政策

如果我们处理的是敏感的公司数据，那么就必须对其进行保护。我们希望确保只有授权用户才能访问，并且我们拥有的数据可以被视为我们拥有的任何数据集和模型的唯一真实来源。

解决方案：

使用 VPC 限制访问。虚拟私有云是一种很好的做法，可以确保您的数据与外界隔离。
对数据应用版本控制。这旨在确保数据一致性，以防任何可能使用数据湖数据的用户或服务对我们的数据进行任何潜在更改。
定期备份数据并引入数据丢失预防政策。

考虑下面的 Terraform 示例。它将在 AWS S3 存储桶上启用版本控制。这很简单，但它有助于保持数据沿袭的清洁和保护，确保数据湖是单一事实来源，包括任何潜在的数据库复制管道，其中可以轻松操作、更新或删除数据。

<span style="color:rgba(0, 0, 0, 0.8)"><span style="background-color:#ffffff"><span style="background-color:#f9f9f9"><span style="color:#242424">资源<span style="color:#c41a16">“aws_s3_bucket” </span> <span style="color:#c41a16">“示例”</span> { 
  bucket = <span style="color:#c41a16">“example-bucket”</span>
 }

资源<span style="color:#c41a16">“aws_s3_bucket_acl” </span> <span style="color:#c41a16">“示例”</span> { 
  bucket = aws_s3_bucket.example.id <span style="color:#5c2699">acl</span>
   = <span style="color:#c41a16">“private”</span>
 }

资源<span style="color:#c41a16">“aws_s3_bucket_versioning” </span> <span style="color:#c41a16">“versioning_example”</span> { 
  bucket = aws_s3_bucket.example.id <span style="color:#5c2699">versioning_configuration</span>
   { 
    status = <span style="color:#c41a16">“Enabled”</span>
   } 
}</span></span></span></span>

数据治理

数据治理就是要确保数据准确、安全并可供主要利益相关者使用。

痛点七：主要利益相关者和数据可用性的细粒度访问控制。

有时将 DWH 解决方案放入单独的数据处理阶段是个好主意。事实上，数据管理、基于角色的访问控制和强大的数据治理功能——所有这些都使这些工具在现代数据堆栈中非常实用 [3]。我在这里讨论过：

解决方案：

如果不使用数据仓库，则对数据湖数据集应用基于身份的访问控制。
在需要时对 DWH 数据应用基于行/列的访问控制。
应用对象标记和基于标签的屏蔽策略。
使用访问历史记录实现警报。如果您是 DBA，那么您必须掌控它。
定期进行数据质量检查。可以安排检查或在 CI 中针对每个拉取请求运行检查。

例如，DBT 有一组通用和单一测试，我们可能希望定期对数据运行这些测试。这很容易实现，如下所示：

resource "aws_s3_bucket" "example" {
  bucket = "example-bucket"
}

resource "aws_s3_bucket_acl" "example" {
  bucket = aws_s3_bucket.example.id
  acl    = "private"
}

resource "aws_s3_bucket_versioning" "versioning_example" {
  bucket = aws_s3_bucket.example.id
  versioning_configuration {
    status = "Enabled"
  }
}

痛点八：

数据质量和测试

这才是数据开发中最重要的。您需要使用“不重复自己”（DRY）模块化方法，并创建模板化、易于维护、重用和单元测试的数据模型。

在 DWH 和数据湖解决方案中引入单独的数据环境和单独的生产、开发和测试区域。
使用数据建模和数据沿袭图作为数据管道。
对每个数据转换运行单元测试。

拆分数据环境非常合理，因为您不希望暂存数据与生产数据混淆。从这个角度来看，最好设计数据平台以拆分数据环境层，如下例所示：

<span style="color:rgba(0, 0, 0, 0.8)"><span style="background-color:#ffffff"><span style="background-color:#f9f9f9"><span style="color:#242424">DATABASE_NAME SCHEMA_NAME      
<span style="color:#007400">-------------------------------</span>
 RAW_DEV SERVER_DB_1      <span style="color:#007400">-- 模拟数据</span>
RAW_DEV SERVER_DB_2      <span style="color:#007400">-- 模拟数据</span>
RAW_DEV EVENTS           <span style="color:#007400">-- 模拟数据</span>
RAW_PROD SERVER_DB_1      <span style="color:#007400">-- 来自管道的实际生产数据</span>
RAW_PROD SERVER_DB_2      <span style="color:#007400">-- 来自管道的实际生产数据</span>
RAW_PROD EVENTS           <span style="color:#007400">-- 来自管道的实际生产数据</span>
...                              
BASE_PROD EVENTS           <span style="color:#007400">-- 丰富数据</span>
BASE_DEV EVENTS           <span style="color:#007400">-- 丰富数据</span>
...                              
ANALYTICS_PROD REPORTING   <span style="color:#007400">-- 具体化查询和聚合</span>
ANALYTICS_DEV REPORTING   
ANALYTICS_PROD AD_HOC      <span style="color:#007400">-- 即席查询和视图</span></span></span></span></span>

SQL 单元测试非常有用，如果您想确保数据转换逻辑持久且保持不变，除非您有意更改它，那么这就是您要做的事情。

将数据治理视为一套政策和工具，旨在指导关键数据利益相关者（尤其是管理层）正确使用数据。一些数据仓库解决方案（如 Snowflake）为潜在的个人或敏感数据提供对象分类。此功能可在必要时帮助确保遵守隐私法规。

商业智能和报告

这是最有趣的一点，因为我不断看到 BI 工具越来越多地注入通常在以前的数据生命周期阶段实现的功能。

痛点9：

我的 BI 工具太贵了

确实，现代报告解决方案价格昂贵，尤其是针对企业级公司。如果我们是中小企业，该怎么办？

嗯，我想说一个数据工程师可以取代现代 BI 工具中的许多功能。

解决方案：

优化 数据建模：在 DBT 时代，具有数据建模功能的 BI 似乎有点矫枉过正。所有 SQL 数据转换都应在到达 BI 解决方案之前实施。在这种情况下，为 Looker 中的两个实例（开发和生产）付费对我来说没有多大意义，我们可以节省很多钱。
BI 和 专用 OLAP 多维数据集：为什么您需要在数据仓库之外处理数据的东西？使用具有此功能的 BI 工具支付双倍价格是没有意义的。
缓存和数据新鲜度：即使是免费的社区型 BI 解决方案（如Looker Studio）也具有此功能。可以使用行条件或 DBT 通用测试来实现数据新鲜度测试。数据工程师将安排分析数据模型更新实现，并在需要时实现完整的数据刷新。
语义层：这是一个很好的例子。可以将其视为一个模型，每个维度都有维度、指标或度量，以及关于它们如何连接的明确说明。这就是我喜欢 Looker 的原因；它将数据建模提升到了一个新的水平。但如果我告诉你你可以免费获得它呢？试试 DBT 语义层，dbt-metricflow你就会明白自己做并不难。
Git 和源代码控制：这是我最喜欢的。目前只有少数 BI 工具具有此功能。最受欢迎的是 Looker 和 Sisense，但如果我告诉你我们可以开源并自己做呢？尝试Apache Superset，创建虚拟数据集，在存储库中对其进行源代码控制，最后使用 API 部署它们。

数据管道编排

现在我们需要协调我们构建的所有现代数据堆栈和精美的管道。

痛点10：

编排

我之前的研究表明，强调异构性、支持多种编程语言、有效使用元数据以及采用数据网格架构是构建现代、强大且可扩展的数据平台的数据管道编排的基本趋势。

解决方案：

如果您依赖使用 AWS Step Functions 的 Apache Airflow 构建的旧架构，那么我建议使用该堆栈。但是，如果您正在寻找更强大和异构的解决方案，那么 Mage 编排器可能更适合。
如果您需要协调大量机器学习管道，我强烈建议您尝试 Flyte。

预计对多种编程语言的支持将成为未来几年的重要趋势。例如，Temporal 可容纳各种语言和运行时，而 Airflow 主要强调 Python。

结论

第三方数据提取工具通常无法满足特定需求，而且其定价模型（通常基于提取的数据量）可能非常昂贵。作为一名数据工程师，了解如何构建和部署持久、经济高效的数据管道非常重要。

数据存储带来了另一个可能并不立即显现的挑战。利用更高效的存储类别至关重要。云存储提供了在数据湖内各种环境（例如 Spark、AWS Glue 或 Databricks）中处理数据的灵活性，并在必要时方便将数据重新加载到数据仓库中。为数据湖存储桶实施版本控制和保护是一种最佳实践，建立数据保留策略来指定应存档哪些数据以及存档多长时间也是一种最佳实践。确保存档数据以标准大数据格式存储，以便在技术发展过程中保持可访问性。

数据治理应被视为一套全面的政策和工具，用于指导关键数据利益相关者（尤其是管理层）正确使用数据。该策略可确保所有相关方都能获得高质量的数据。

在 DBT 时代，具有数据建模功能的商业智能 (BI) 工具似乎有些多余。所有 SQL 数据转换都应在到达 BI 解决方案之前完成，这符合在部署之前应进行单元测试的原则。这种方法体现了数据治理和数据建模的精髓。

感谢关注雲闪世界。（亚马逊aws和谷歌GCP服务协助解决云计算及产业相关解决方案）

订阅频道(https://t.me/awsgoogvps_Host)
TG交流群(t.me/awsgoogvpsHost)