规模化设计数据管道所面临的挑战

169 阅读9分钟

目前数据世界的挑战不再是在数据量的处理能力。由于当前现代流媒体平台的性能,以及由于新一代的数据存储库允许计算与存储层解耦,我们可以用非常低的操作努力来提高可扩展性。

然而,如果我们记得著名的大数据5V(数量、价值、种类、速度和真实性),真实性和价值对今天的大多数公司来说仍然是一个挑战。

数据管道是解决这一挑战的根本。设计和构建规模化的数据管道不仅可以带来更多的速度,而且这样做是可以通过整个团队来维护和理解的。

数据量的处理能力

几年前,主要的技术挑战是在以下几个方面。

  • 数据存储库(数量和速度) - 摄取和管理巨大的数据量。
  • 数据处理计算层(速度)--拥有一个高性能的计算层来启动成千上万的数据管道,允许以非常快的方式摄取大量的数据。
  • 集成适配器(多样性)--开发适配器,与不同的组件集成。

IT团队在开始开发第一个数据管道之前,花了数年时间建立允许这些能力的数据平台。之后,所有的努力都投入到在短时间内摄取大量的数据。但这一切都发生在没有关注真正的商业价值。此外,操作这些数据平台需要大量的努力。

现在,随着云计算的采用,开源社区,最新一代的云计算软件,以及新的数据架构模式,实现这些功能不再是一个挑战。

数据存储库

有多种方法可以提供高性能的数据存储库,以较低的操作难度实时管理大量的数据。

  • 数据仓库--新一代的数据仓库将存储与计算层解耦,提供基于不同技术的新的、可扩展的功能,如NoSQL、数据湖或具有AI功能的关系型数据仓库。
  • 关系型数据库--最新的关系型数据库,使用分片和内存功能,提供OLTP和OLAP功能。
  • 流媒体平台--Apache KafkaApache Pulsar等平台提供每秒处理数百万事件的能力,并建立实时管道。

在这种情况下,成功的关键是为你的使用情况选择最佳方案。

计算层

以下能力能够执行大量的并发管道。

  • 无服务器- 云平台提供方便的按需扩展。
  • 新的数据存储库的计算层--与存储脱钩,允许将很大一部分操作委托给数据库执行,而不会像老式的内部系统那样,有影响其他负载或扩展限制的风险。
  • Kubernetes- 我们可以使用Kubernetes API来动态创建工作容器作为Kubernetes pods。

集成适配器

开源社区与新的云计算软件供应商一起,提供了各种数据适配器,以快速提取和加载数据。这简化了不同软件组件之间的整合,如数据存储库、ERP和许多其他组件。

当前的数据挑战

目前的挑战是以更全面和可靠的方式提供数据。数据流程是造成复杂性的主要因素之一。作为一个数据或业务分析师,除了在正确的时间拥有信息之外,我们还需要了解我们所分析的数据的元数据,以便做出决策。

  • 数据意味着什么,它能提供什么价值?(价值)
  • 数据是如何计算的?(价值)
  • 数据的来源是什么?(价值)
  • 数据是如何更新的?(真实性)
  • 数据的质量是什么?(真实性)

在大型企业中,有大量的数据,但也有很多部门有时会处理类似但不同的数据。例如,零售公司有两种库存。

  • 可计算的库存 - 这种库存是理论上的,基于采购订单和交货单。
  • 真实库存- 这种库存代表他们在仓库和商店中的物品。

通常情况下,由于许多原因,如交货延迟或其他人为错误,这些数值并不一致。然而,库存数据是计算指标的来源,如销售、销售预测或库存补货。根据理论上的库存决定购买一批新的物品,可能会造成数千美元的损失,并导致世界的可持续性降低。我们可以想象这些决定对其他部门的影响,如医疗保健。

当分析师做出决定时,他们需要知道他们在用什么数据来评估风险并做出有意识的选择。归根结底,我们谈论的是将数据转化为商业价值。

数据管道扮演什么角色?

当我们想象数据或阅读高水平的文章时,我们会想象一个非常简单的世界,只有几个数据域

但现实比这更复杂。

在大数据场景中,有数以千计的不同层次的数据管道在数据域或数据存储库之间不断摄取和整合数据。数据管道是提供一个成功的数据平台的最重要的组成部分之一,但似乎即使在今天,我们在大规模构建数据管道时也面临着一些多年前的挑战,包括。

  • 以动态和敏捷的方式提供元数据,如数据脉络

  • 使得数据分析师、数据工程师和商业利益相关者之间的协作变得容易。

  • 轻松为数据分析师和利益相关者提供有关数据质量和新鲜度的信息

构建大规模数据管道的挑战是什么?

似乎数据管道的目标主要集中在四个方面。

  • 团队协作和理解力
  • 动态数据脉络
  • 可观察性
  • 数据质量

团队协作和理解力

规则变化很快,公司必须快速适应。数据和信息比以往更加重要。

为了快速提供价值,我们需要一个由数据科学家、数据工程师、分析师和商业利益相关者组成的异质团队一起工作。他们需要用相似的语言来表达,以达到敏捷的目的。当我们所有的数据管道都是用Spark或Kafka流等技术构建的时候,技术人员和非技术人员之间的敏捷沟通就显得过于复杂。

从数据到信息的旅程从数据管线开始。

数据脉络

元数据对于允许将数据转化为商业信息非常重要。它提供了一个每个人都可以访问的概要脉络,增加了数据的可见性、理解力和信心。我们必须动态地提供这些信息,而不是通过永远不会改变的静态文档或永远不会结束的复杂检查过程。

可观察性

数据管道的可观察性是一个重大挑战。通常,可观察性是面向技术团队的,但我们需要将这种可见性提高到所有利益相关者(业务分析师、数据分析师、数据科学家等)。

数据质量

我们需要发展我们处理数据的方式,并开始应用传统软件开发的最佳实践。从数据到数据即代码,我们可以使用版本控制、持续集成或测试等方法论。

数据管道是如何发展的?

当我们观察新的数据趋势时,我们可以看到开源社区的倡议或具有商业软件的初创公司,如AirbyteMeltanodbt-labsDataHubOpenLineage

这些例子显示了数据处理的世界是如何发展到。

  • 利用新的数据存储库的增强功能,从ETL(提取、转换、加载)转向ELT(提取、加载、转换)模式
  • 提供管理数据即代码的能力
  • 提高数据的理解力和可观察性

这些能力是让我们在提供商业价值的同时,还能大规模地建立数据管道的关键。

从数据准备到数据理解的旅程

理解是将数据转换成信息的第一步。转化层在这个过程中起着关键作用。通常情况下,转换层是瓶颈,因为数据工程师和业务分析师没有相同的语言,所以合作是复杂的。然而,像dbt这样的新工具正试图改善这一状况。

什么是dbt?

dbt(数据构建工具)是一个用于转换层的开源CLI工具,它使业务数据分析师和工程师在数据生命周期中使用一种共同的语言以及软件开发的最佳实践,如版本控制、持续集成/部署和持续测试进行协作。

公司范围内的通用语言

SQL是整个公司的通用语言,它允许所有利益相关者在整个数据生命周期中进行讨论。SQL使数据和业务分析员能够通过使用版本控制工具的SQL语句协作编写或修改转换。

ELT

数据的世界已经发生了很大的变化。现在,大多数数据存储库是高性能和可扩展的。新的场景已经改变了转换过程的规则。在许多情况下,数据存储库比外部流程更适合这项工作。dbt执行ELT流程的转换,利用新的数据存储库的功能,在你的数据仓库内运行数据转换查询。

数据即代码

dbt允许在你的Git存储库中作为代码管理数据转换,并应用持续集成的最佳实践。它提供了测试功能,包括基于SQL查询的单元测试模块,或用宏来扩展它们,以增加更复杂场景的覆盖率。

血统和元数据

dbt允许我们在数据转换的每次运行中动态地生成数据线和元数据。有许多与平台的集成,如DataHub或OpenLineage,提供企业可见性。

结论

近年来,人们在提高数据处理性能和摄取能力方面投入了大量的精力,但质量和理解力仍然是有问题的地方,使决策变得困难。如果我们不能理解大量的数据,或者数据的质量很差,那么我们很快收到大量的数据也没有关系。为了提供增加商业价值的信息,拥有一个可扩展、可维护和可理解的数据管道层是必须的

请记住。不做决定比根据不准确的数据做决定要好--特别是当你不知道数据是错误的时候。