2025-年数据专业人士应了解的概念-第一部分

2025 年数据专业人士应了解的概念:第一部分

原文:towardsdatascience.com/the-concepts-data-professionals-should-know-in-2025-part-1-47e7e797801d/

当我浏览 YouTube 或 LinkedIn 并看到 RAG、代理或量子计算等主题时,我有时会感到作为数据专业人士跟上这些创新有些不适。

但当我反思作为 Salesforce 顾问或大学数据科学家每天面对的客户问题时,挑战往往显得更加具体:例如,更快的数据处理、更好的数据质量或提升员工的科技技能。关键问题通常不那么未来化,并且通常可以简化。这正是本文以及下一篇文章的重点:

我整理了 12 个术语,你将在 2025 年作为数据工程师、数据科学家和数据分析师时一定会遇到。为什么它们相关?挑战是什么?你如何将它们应用于一个小项目?

那么——让我们深入探讨。

目录 1 – 数据仓库、数据湖、数据湖屋 2 – 云平台如 AWS、Azure 和谷歌云平台 3 – 优化数据存储 4 – 大数据技术如 Apache Spark、Kafka 5 – 数据集成如何成为实时能力:ETL、ELT 和 Zero-ETL 6 – 事件驱动架构(EDA) 第二部分第 7-12 个术语:数据血缘与 XAI、通用人工智能、代理人工智能、推理时间计算、近乎无限内存、人机交互增强 结语

1 – 数据仓库、数据湖、数据湖屋

我们从数据架构和存储的基础开始,以了解现代数据管理系统。

数据仓库在 20 世纪 90 年代因 Oracle 和 SAP 等商业智能工具而广为人知。公司开始将来自各种来源的结构化数据存储在中央数据库中。例如,在商业智能工具中处理每周的销售数据。

下一个创新是数据湖,它源于灵活存储非结构化或半结构化数据的需求。数据湖是一个用于原始数据的大型、开放空间。它存储结构化和非结构化数据,例如销售数据、社交媒体帖子以及图像。

创新的下一步是将数据湖架构与仓库架构相结合:数据湖屋应运而生。

这个术语是由像 Databricks 这样的公司普及的,当它推出其 Delta Lake 技术时。这个概念结合了先前数据平台的优势。它允许我们在单一系统中存储非结构化数据,同时快速查询结构化数据。这种数据架构的需求主要源于仓库通常过于限制性,而湖仓难以搜索。

为什么这些术语很重要?

我们正处于大数据时代——公司和私人个人正在产生越来越多的数据(包括结构化、半结构化和非结构化数据)。

一个简短的个人轶事:在我 15 岁那年,Facebook 首次突破了 5 亿活跃用户500 million active user的里程碑。同年,Instagram 成立。Instagram was founded。此外,iPhone 4 的发布显著加速了全球智能手机的普及,并塑造了移动时代。同年,微软进一步发展和推广了 Azure(该产品于 2008 年发布),以与谷歌云和 AWS 竞争。从今天的角度来看,我可以看到所有这些事件如何使 2010 年成为数字化的决定性一年:2010 年是数字化和向云技术过渡加速的关键年份。

2010 年,大约产生了 2 泽字节(ZB)的数据,到 2020 年,数据量约为 64 ZB,到 2024 年,我们将达到大约 149 ZB。

参考:Statista

由于近年来数据增长爆炸性,我们需要将数据存储在某个地方——高效地。这就是这三个术语发挥作用的地方。如数据湖仓这样的混合架构解决了大数据的许多挑战。对(近)实时数据分析的需求也在上升(参见第 5 个术语零 ETL)。为了保持竞争力,公司面临着更快、更有效地使用数据的压力。随着它们提供数据湖的灵活性和数据仓库的效率——而无需运行两个独立的系统,数据湖仓变得越来越重要。

面临的挑战有哪些?

  1. 数据集成:由于存在许多不同的数据源(结构化、半结构化和非结构化),需要复杂的 ETL/ELT 流程。

  2. 规模与成本:虽然数据仓库成本高昂,但数据湖如果没有良好的数据治理,很容易导致数据混乱,而湖仓需要技术知识和投资。

  3. 数据访问:如果数据存储在集中式存储中,权限需要明确定义。

一个小项目想法,以更好地理解这些术语:

使用 AWS S3 创建一个迷你数据湖:将 JSON 或 CSV 数据上传到 S3 存储桶,然后使用 Python 处理数据,例如使用 Pandas 进行数据分析。

2 – AWS、Azure 和 Google Cloud Platform 等云平台

现在我们转向实现 1 中概念的平台。

当然,每个人都知道像 AWS、Azure 或 Google Cloud 这样的云平台。这些服务为我们提供了可扩展的基础设施,用于存储大量数据。我们还可以使用它们来实时处理数据,并有效地使用商业智能和机器学习工具。

但为什么这些术语很重要?

我在一家网页设计代理机构工作,我们托管客户的网站在另一个部门。在云平台容易获得之前,这意味着在地下室运行我们自己的服务器——所有这些挑战,如冷却、维护和有限的扩展性。

今天,我们的大部分数据架构和 AI 应用都在云端运行。在过去几十年中,云平台已经改变了我们存储、处理和分析数据的方式。像 AWS、Azure 或 Google Cloud 这样的平台为我们提供了模型训练、实时分析和生成式 AI 的完全新的灵活性和可扩展性。

面临哪些挑战?

  1. 一个快速的个人例子,说明事情变得多么复杂:在准备我的 Salesforce 数据云认证(一个数据湖屋)时,我发现自己陷入了一个新术语的海洋——所有都是 Salesforce 世界的特定术语。每个云平台都有自己的术语和工具,这使得公司员工熟悉它们变得耗时。

  2. 数据安全:敏感数据通常可以存储在云端。访问控制必须明确定义——需要用户管理。

一个小项目想法,以更好地理解这些术语:

创建一个简单的数据管道:使用免费账户在 AWS、Azure 或 GCP 上注册,并上传一个 CSV 文件(例如上传到 AWS S3 存储桶)。然后加载数据到关系型数据库,并使用 SQL 工具进行查询。

3 – 优化数据存储

数据越来越多 = 需要的存储空间越来越多 = 成本越来越高。

使用大量数据和 1 和 2 中的平台和概念,也存在效率和成本管理的问题。为了节省存储空间、降低成本和加快访问速度,我们需要更好的方式来更有效地存储、组织和访问数据。

策略包括通过删除冗余或不必要的数据进行数据压缩(例如 Gzip),通过拆分大型数据集进行数据分区,通过索引加速查询以及选择存储格式(例如 CSV、Parquet、Avro)。

术语为什么重要?

我的 Google Drive 和 One Drive 存储空间几乎已经满了…

…到 2028 年,预计总数据量将达到 394 泽字节。

因此,我们需要能够应对不断增长的数据量和不断上升的成本。此外,大型数据中心消耗了巨大的能源,这在能源和气候危机方面又是一个关键因素。

面临哪些挑战?

  1. 不同的格式针对不同的用例进行了优化。例如,Parquet特别适合分析查询和大数据集,因为它基于列组织,读取访问效率高。Avro另一方面,对于流式数据非常理想,因为它可以快速将数据转换为通过网络发送的格式(序列化),并在接收时同样快速将其转换回原始形式(反序列化)。选择错误的格式可能会通过浪费磁盘空间或增加轮询时间来影响性能。

  2. 成本/效益权衡:压缩和分区可以节省存储空间,但可能会降低计算性能和数据访问速度。

  3. 依赖云服务提供商:由于今天大量数据存储在云端,优化策略通常与特定平台相关联。

小型项目想法以更好地理解这些术语:

比较不同的存储优化策略:生成一个 1GB 的随机数数据集。以 CSV、Parquet & Avro(使用相应的 Python 库)等三种不同的格式保存数据集。然后使用 Gzip 或 Snappy 压缩文件。现在使用 Python 将数据加载到 Pandas DataFrame 中,并比较查询速度。

4 – 大数据技术如 Apache Spark & Kafka

一旦使用第 1-3 节中描述的存储概念存储了数据,我们需要高效处理它的技术

我们可以使用 Apache Spark 或 Kafka 等工具来处理和分析大量数据。它们允许我们实时或批量模式进行操作。

Spark是一个分布式处理大量数据的框架,用于机器学习、数据工程和 ETL 过程等任务。

Kafka是一个实时传输数据流的工具,以便各种应用程序可以立即访问和使用它们。一个例子是在金融交易或物流中处理实时数据流。

为什么这个术语很重要?

除了数据的指数级增长,人工智能和机器学习正变得越来越重要。公司希望能够在(几乎)实时处理数据:这些大数据技术是大量数据实时和批量处理的基础,对于人工智能和流式应用也是必需的。

面临哪些挑战?

  1. 实施复杂性:设置、维护和优化 Apache Spark 和 Kafka 等工具需要深入的技术专业知识。在许多公司,这种专业知识并不容易获得,必须建立或从外部引入。特别是分布式系统可能很难协调。此外,如果需要扩展云中的计算能力,处理大量数据可能会导致高昂的成本。

  2. 数据质量:如果我要指出我客户最大的问题之一,那可能就是数据质量。任何与数据打交道的人都知道,在许多公司中,数据质量通常可以优化……当数据流在实时处理时,这一点变得更加重要。为什么?在实时系统中,数据是即时处理的,结果有时会直接用于决策或随后产生反应。错误或不准确的数据可能导致错误决策。

小型项目想法,以更好地理解这些术语:

使用 Python 开发一个小型管道来模拟、处理和保存实时数据:例如,模拟温度值的实时数据流。然后检查温度是否超过临界阈值。作为一个扩展,你可以实时绘制温度数据。

5 – 如何使数据集成实现实时能力:ETL、ELT 和 Zero-ETL

ETL、ELT 和 Zero-ETL 描述了不同的数据集成和转换方法。

虽然ETL(提取-转换-加载)和ELT(提取-加载-转换)对大多数人来说都很熟悉,但Zero-ETL是 AWS 在 2022 年引入的数据集成概念。它消除了单独提取、转换和加载步骤的需要。相反,数据直接在其原始格式中进行分析——几乎是在实时。这项技术承诺可以减少延迟并简化单一平台内的流程。

让我们来看一个例子:一家使用 Snowflake 作为数据仓库的公司可以创建一个引用 Salesforce 数据云中数据的表。这意味着组织可以直接在 Snowflake 中查询数据,即使它仍然留在数据云中。

为什么这些术语很重要?

我们生活在一个即时化的时代——多亏了 WhatsApp、Netflix 和 Spotify 等平台的成功。

这正是云服务提供商如亚马逊网络服务(Amazon Web Services)、谷歌云(Google Cloud)和微软 Azure 所思考的:数据应该能够几乎在实时且没有重大延迟的情况下进行处理和分析。

面临哪些挑战?

在这里,也面临着与大数据技术相似的一些挑战:数据质量必须足够好,因为错误的数据可以直接导致实时处理过程中的错误决策。此外,集成可能很复杂,尽管不如 Apache Spark 或 Kafka 等工具那么复杂。

让我分享一个快速示例来说明这一点:我们为一位客户实施了数据云——这是 Salesforce 开始提供数据湖解决方案以来,瑞士的首个实施案例。整个知识库必须在客户方构建。这意味着什么?与高级用户的 1:1 培训课程以及编写大量文档。

这展示了公司面临的一个关键挑战:他们必须首先在内部建立这种知识,或者依赖外部资源,如代理或咨询公司。

小型项目想法以更好地理解术语:

使用 MySQL 或 PostgreSQL 创建一个关系型数据库,添加(模拟的)实时订单数据,并使用如 AWS 这样的云服务将数据直接流式传输到分析工具。然后在一个仪表板上可视化数据,并展示新数据如何立即可见。

6 – 事件驱动架构 (EDA)

如果我们能够在(几乎)实时之间传输数据,我们也希望能够在(几乎)实时对其做出反应:这就是事件驱动架构(EDA)术语发挥作用的地方。

EDA 是一种架构模式,其中应用程序由事件驱动。事件是系统中的任何相关变化。例如,当客户登录应用程序或收到付款时。架构的各个组件对这些事件做出反应,而无需直接相互连接。这反过来又增加了应用程序的灵活性和可扩展性。典型技术包括 Apache Kafka 或 AWS EventBridge。

为什么这个术语很重要?

事件驱动架构在实时数据处理中发挥着重要作用。随着对快速和高效系统的需求不断增长,这种架构模式正变得越来越重要,因为它使处理大量数据流变得更加灵活和高效。这对于物联网、电子商务和金融技术尤为重要。

事件驱动架构也解耦了系统:通过允许组件通过事件进行通信,各个组件不必直接相互依赖。

让我们来看一个例子:在线商店中,“订单已发送”事件可以自动启动支付流程或通知仓库管理系统。各个系统不必直接相互连接。

面临哪些挑战?

  1. 数据一致性:事件驱动架构的异步特性使得确保系统所有部分具有一致数据变得困难。例如,一个订单可能在数据库中被保存为成功,但由于网络问题,仓库组件未能正确减少库存。

  2. 基础设施扩展:在高数据量下,扩展消息传递基础设施(例如 Kafka 集群)具有挑战性且成本高昂。

小型项目想法以更好地理解术语:

在 Python 中模拟一个对客户事件做出反应的事件驱动架构:

  1. 首先定义一个事件:一个例子可以是“新订单”。

  2. 然后创建两个响应事件的函数:1) 向客户发送自动消息。2) 将库存水平减少-1。

  3. 一旦触发事件,就依次调用这两个函数。如果你想扩展项目,你可以使用 Flask 或 FastAPI 等框架,通过外部用户输入来触发事件。

最后的想法

在这部分,我们探讨了主要关注数据存储、管理和处理的术语。这些术语为理解现代数据系统奠定了基础。

在第二部分,我们将重点转向 AI 驱动的概念,并探讨一些关键术语,如通用人工智能、基于代理的 AI 和闭环增强。

自己的可视化 - 来自 unDraw.co 的插图

自己的可视化 – 来自unDraw.co的插图

本文中所有信息均基于 2025 年 1 月的当前状态。

posted @ 2026-03-27 09:46  绝不原创的飞龙  阅读(0)  评论(0)    收藏  举报