IBM-数据工程-VIII-笔记-全-

IBM 数据工程 VIII 笔记（全）

001：使用Shell、Airflow和Kafka的ETL和数据管道 🚀

在本课程中，我们将学习如何使用Shell、Airflow和Kafka构建ETL和数据管道。本课程适合有志于成为大数据工程师、机器学习工程师、数据仓库专家以及开发者的学员。你将掌握多种ETL和数据管道工具与技术，包括使用Bash脚本，以及Apache Airflow和Apache Kafka等前沿开源工具，在数据平台的各个系统之间构建用于处理和移动数据的数据管道。每个模块都包含实践实验室，你将通过一个受现实世界启发的最终项目来展示新掌握的技能。

课程讲师介绍 👨‍🏫

本课程由四位讲师共同授课：Yanlo、Jeff Grosman、Sabrina Spilner和Rammesh Santi。

  • Yanlo博士是IBM加拿大的数据科学家和开发者。他曾在多个领域构建创新的AI和认知应用，例如软件仓库挖掘、个性化健康管理、无线网络和数字银行。他获得了西安大略大学的机器学习博士学位。
  • Jeff Grosman博士拥有纯数学、地球物理信号与图像处理、医学成像以及数据科学与工程背景。他是617 Data Solutions Inc.的创始人，并作为主题专家任职于Skill Up Technologies，开发数据相关的教育内容。他还是加拿大阿尔伯塔省Camdia Digital Forum的志愿者兼副会员。
  • Sabrina Spilner是Skill Up Technologies的高级教学设计师和内容开发者。在过去的18年里，她一直是一位开拓者，采用新方法和技术来创建创新的学习解决方案。她曾与Orbis、剑桥大学、毕马威英国及毕马威下海湾地区合作。
  • Rammesh Santi拥有Bla Institute of Technology Piolai的信息系统学士学位。他在信息技术、基础设施管理、数据管理、信息集成和自动化方面拥有25年的经验。他曾为Intergraph、GenPAact、HCL和微软等公司工作。目前，他是一名自由职业者，并致力于教学，教授数据科学、机器学习、编程和数据库。

课程内容概述 📚

在本课程中，你将探索ETL和ELT流程背后的基本原理和技术。

模块1：数据处理技术 🛠️

在模块1中，你将学习数据处理的基础知识。

以下是本模块的核心学习目标：

  • 描述什么是ETL管道。
  • 描述为什么ELT是一种新兴趋势。
  • 定义从ETL到ELT的趋势转变。
  • 列举原始数据源的例子。
  • 命名数据加载技术。
  • 区分批量加载与流式加载。

此外，你将探索如何使用批处理Shell脚本从头开始构建一个基本的ETL数据管道，并探索数据管道工程中两种主要范式（批处理和流式数据管道）的用例。

模块2：ETL与数据管道工具和技术 ⚙️

上一节我们介绍了数据处理的基础概念，本节中我们来看看具体的工具和技术。

在模块2中，你将深入学习数据管道的实现。

以下是本模块的核心学习目标：

  • 定义如何使用Shell脚本来实现ETL管道。
  • 定义什么是数据管道。
  • 描述用于缓解数据流瓶颈的数据管道解决方案。
  • 区分批处理与流式数据管道。
  • 讨论数据管道技术。

你还将通过探索和应用一个名为Kafka的流行开源数据管道工具来进一步巩固这些知识。

模块3：使用Airflow构建数据管道 🪂

了解了基础工具后，我们将进入更高级的编排工具。

在模块3中，你将学习使用Apache Airflow来编排复杂的工作流。

以下是本模块的核心学习目标：

  • 列举Apache Airflow的主要原则。
  • 将Airflow管道解释为Python脚本，以定义Airflow DAG对象。
  • 列举将工作流定义为代码的关键优势。
  • 识别你环境中的当前DAG。
  • 在任务之间设置依赖关系。
  • 使用日志记录功能来监控任务状态并诊断DAG运行中的问题。

模块4：使用Kafka构建流式管道 🌊

上一节我们学习了如何编排批处理任务，本节中我们来看看如何处理实时数据流。

在模块4中，你将专注于构建实时数据流管道。

以下是本模块的核心学习目标：

  • 列举事件流平台的主要组件。
  • 将Apache Kafka识别为一个事件流平台。
  • 定义一个端到端的事件流管道示例。
  • 描述Kafka Streams API是什么。

模块5：最终项目 🏆

最后，你将通过一个综合项目来测试你的实践知识。

你的任务将是完成一个项目，使用Airflow DAG创建一个ETL管道，并使用Kafka构建一个流式ETL管道。

学习建议 💡

为了从本课程中获得最大收益，请观看每一段视频并通过完成所有测验来检查学习效果。使用讨论论坛与同学和助教交流。最重要的是，确保你完成实践实验室，以练习新技能并展示你的能力。

祝贺你踏上这段激动人心的旅程的下一步，祝你好运！

总结 ✨

本节课中我们一起学习了《使用Shell、Airflow和Kafka的ETL和数据管道》课程的总体介绍。我们了解了课程目标、四位讲师的背景、五个核心模块的主要内容（从数据处理基础到使用Airflow和Kafka构建复杂的批处理及流式管道），以及最终的综合实践项目。课程强调动手实践，旨在帮助你掌握构建现代数据管道的关键技能。现在，你已经为开始这段学习之旅做好了准备。

002：ETL与数据管道基础 🧱

在本节课中，我们将要学习ETL（提取、转换、加载）过程的基础知识。我们将了解ETL是什么，以及它的三个核心阶段：数据提取、数据转换和数据加载各自意味着什么。最后，我们还会探讨ETL管道的常见应用场景。

什么是ETL过程？ 🔄

ETL是提取（Extract）、转换（Transform）、加载（Load）的缩写。它是一种自动化的数据管道工程方法，通过该方法获取数据并为其在分析环境（如数据仓库或数据集市）中的后续使用做好准备。

ETL指的是从多个来源整理数据，使其符合统一的数据格式或结构，然后将转换后的数据加载到新环境中的过程。

  • 提取过程从一个或多个来源获取或读取数据。
  • 转换过程将数据整理成适合其目标环境和预期用途的格式。
  • 最后的加载过程将转换后的数据加载到其新环境中，为可视化、探索、进一步转换和建模做好准备。整理后的数据也可用于支持自动化和决策制定。

什么是数据提取？ 📥

提取数据意味着配置对数据的访问权限，并将其读入应用程序。这通常是一个自动化过程。

以下是数据提取的一些常见方法：

  • 网络爬取：使用Python或R等应用程序解析底层HTML代码，从网页中提取数据。
  • 使用API：通过编程方式连接到数据并进行查询。

源数据可能是相对静态的，例如数据存档，在这种情况下，提取步骤将是批处理流程中的一个阶段。另一方面，数据也可能是实时流式传输的，并且来自许多位置。例子包括气象站数据、社交网络信息流和物联网设备数据。

什么是数据转换？ 🛠️

数据转换，也称为数据整理，是指处理数据以使其符合目标系统和整理数据预期用例的要求。

转换可以包括以下任何一种处理过程：

  • 数据清洗：修复错误或填补缺失值。
  • 数据过滤：仅选择所需的数据。
  • 数据连接：合并来自不同来源的相关数据。
  • 特征工程：例如为仪表板或机器学习创建关键绩效指标。
  • 格式化和数据类型转换：使数据与其目标环境兼容。

什么是数据加载？ 📤

数据加载通常意味着将数据写入某个新的目标环境。典型的目标包括数据库、数据仓库和数据集市。

数据加载的关键目标是使数据能够随时被分析应用程序摄取，以便最终用户能够从中获得价值。这些应用程序包括仪表板、报告以及高级分析（如预测和分类）。

ETL管道的应用场景 📊

ETL管道有许多应用场景。有大量信息要么已被记录，要么正在生成，但尚未被捕获或作为数字文件访问。例子包括纸质文档、照片和插图以及模拟音频和录像带。数字化模拟数据包括通过某种形式的扫描进行提取、模拟到数字的转换，最后存储到存储库中。

在线事务处理系统不保存历史数据。因此，ETL过程捕获交易历史，并为其在在线分析处理系统中的后续分析做好准备。

其他应用场景包括：

  • 从数据源中设计特征或关键绩效指标，为运营、销售和市场营销、客户和高管使用的仪表板摄取数据做准备。
  • 训练和部署机器学习模型，用于预测和增强决策制定。

总结 📝

本节课中，我们一起学习了ETL的基础知识。

我们了解到，ETL是一种自动化的数据管道工程方法，用于获取数据并为其在分析环境中的使用做好准备。其核心是三个步骤：提取数据、转换数据以符合目标要求，以及加载数据到新环境。

最后，ETL用于整理数据并使其可供最终用户访问，例如训练和部署用于预测和增强决策制定的机器学习模型。

003：ELT基础知识

在本节课中，我们将要学习ELT（提取、加载、转换）流程的基础知识。我们将了解ELT是什么，它与ETL的区别，以及它为何在现代数据工程中成为一种新兴趋势。

什么是ELT流程？🔍

上一节我们介绍了数据管道的基本概念，本节中我们来看看ELT流程的具体定义。

ELT 是 提取（Extract）、加载（Load）、转换（Transform） 的缩写。它是一种特定的自动化数据管道工程方法。

ELT与ETL类似，都涉及相似的阶段，但执行顺序不同。

ELT流程详解 ⚙️

了解了ELT的基本定义后，我们来详细分解它的三个核心阶段。

对于ELT流程，数据被获取后，会直接以其原始形式加载到目标环境（通常是像数据湖这样的复杂分析平台）中。然后，数据可以根据用户的需求按需进行转换。

  • 提取阶段：此过程从所有数据源获取数据，并通常以异步方式将数据读入应用程序。
  • 加载阶段：此过程获取原始数据，并将其原样加载到新的环境中，之后现代分析工具可以直接使用这些数据。
  • 转换阶段：ELT的转换过程比传统的ETL动态得多。目标环境中的现代分析工具支持对数据进行交互式、按需的探索和可视化，包括建模和预测等高级分析。

ELT的适用场景 📈

现在我们已经清楚了ELT的工作流程，接下来看看它在哪些场景下最能发挥优势。

ELT流程的典型用例通常属于高性能计算和大数据领域。

以下是ELT的主要应用场景：

  • 处理实施大数据产品时带来的大规模波动和扩展。
  • 对海量流数据进行实时分析计算。
  • 整合全球范围内高度分布式的数据源。

在速度方面，移动数据通常比处理数据更易成为瓶颈，因此移动得越少越好。所以，当你想从相同的数据源灵活构建一系列数据产品时，ELT可能是最佳选择。

ELT为何成为新兴趋势？☁️

我们看到了ELT的诸多优势，那么推动它成为趋势的背后力量是什么呢？主要是云计算的发展。

首先，由于大数据的需求，云计算解决方案正在以惊人的速度发展。它们可以轻松处理海量的异步数据，这些数据可能分布在世界各地。

其次，云计算资源几乎是无限的，并且可以按需扩展。与传统的本地硬件不同，你只需为使用的计算资源付费，不必担心资源利用率不足或设备上的过度支出。

使用ELT，你可以在移动数据和处理数据之间实现清晰的分离。当然，云计算同样有能力处理这两项任务中最具挑战性的情况。

最后，ELT提供了灵活性。转换数据的原因和方式可能有很多种。因此，ELT是一种灵活的选择，能够从同一数据源支持多种应用。因为你处理的是源数据的副本，所以没有信息丢失。许多类型的转换都可能导致信息丢失，如果这种情况发生在管道上游，可能需要很长时间才能提出变更请求。更糟糕的是，如果原始数据没有被存储，信息可能会永远丢失。

总结 📝

本节课中我们一起学习了ELT流程的核心知识。

你了解到：

  • ELT流程适用于灵活性、速度和可扩展性至关重要的场景。
  • 基于云的分析平台非常适合以经济高效的方式处理大数据和ELT流程。
  • ELT之所以成为新兴趋势，主要是因为云平台技术正在推动它成为可能。

004：ETL与ELT比较详解

在本节课中，我们将学习ETL（提取、转换、加载）与ELT（提取、加载、转换）这两种数据处理架构的核心区别。我们将探讨ELT如何作为ETL的演进，并分析当前从ETL向ELT转变的趋势。

🔍 ETL与ELT的关键区别

ETL和ELT在数据处理流程上存在几个根本性的差异。

以下是它们之间的主要区别：

  • 转换发生的顺序不同：在ETL流程中，数据转换发生在数据管道内部，在数据到达目标存储之前完成。而在ELT流程中，转换与数据管道解耦，在目标存储环境中按需进行。
  • 使用灵活性不同：ETL通常是一个固定的流程，旨在服务于非常特定的功能。ELT则更为灵活，使数据能够随时可用于自助式分析。
  • 处理大数据的能力不同：传统的ETL流程处理结构化的关系型数据，并依赖本地计算资源来处理工作流，因此可扩展性可能成为问题。相比之下，ELT可以处理任何类型的数据（结构化和非结构化），并利用云计算服务提供的按需扩展能力来解决大数据带来的可扩展性挑战。
  • 数据发现与洞察速度不同：修改ETL管道需要时间和精力，这意味着用户必须等待开发团队实施所请求的更改。ELT则提供了更高的敏捷性，用户经过一些现代分析应用的培训后，可以轻松连接并试验原始数据、创建自己的仪表板并自行运行预测模型。

🚀 ELT：ETL的自然演进

上一节我们介绍了ETL与ELT的核心区别，本节中我们来看看ELT如何成为ETL的自然演进。

推动这一演进的主要因素是企业需要将原始数据释放给更广泛的用户群体使用。传统上，ETL流程包含一个称为“暂存区”的中间存储设施。这是一个存放原始提取数据的区域，在将转换后的结果数据加载到数据仓库或数据集市之前，可以在此运行处理过程。

这听起来很像ELT流程，而暂存区也符合数据湖的描述——数据湖是一个用于存储和操作原始数据的现代自助式存储库。然而，传统的暂存区通常不是在公司范围内共享的。它是一个私有的、孤立的区域，专门用于开发、监控和性能调优数据管道及其内置的转换。

随着分析工具的使用和连接能力日益便捷，原始数据源对技术背景较弱的终端用户来说变得更容易访问。因此，范式正在向自助式数据平台转变。

📈 当前趋势：从ETL到ELT

尽管传统的ETL在开发数据管道中仍有一席之地，不会很快消失，但目前存在一个趋势，即现代ELT正逐渐超越传统ETL。

这一趋势是由ELT所解决的痛点所驱动的，主要包括：

  • 获取洞察的周期漫长
  • 大数据带来的挑战（例如可扩展性）
  • 数据传统的孤岛性质

✅ 课程总结

本节课中，我们一起学习了ETL与ELT的核心知识。

我们了解到，ETL与ELT的关键区别在于转换发生的位置、灵活性、对大数据支持以及获取洞察的速度。推动从ETL向ELT演进的因素之一，是企业需要向更广泛的用户群提供原始数据。传统ETL仍有许多应用场景并保有它的地位，而ELT比ETL更灵活，使终端用户能够实时执行临时的、自助式的数据分析。

005：数据提取技术 📊

在本节课中，我们将学习数据提取技术。你将能够列举原始数据源的例子，描述数据提取技术，并将使用场景与数据源和提取技术联系起来。

原始数据源示例 📁

数据无处不在，它们以多种形式存在。以下是原始数据源的一些例子。

以下是原始数据源的具体示例：

  • 来自纸质文档和PDF的归档文本和图像。
  • 网页，包括文本、表格、图像和链接。
  • 模拟音频和视频，可以记录在磁带等介质上或实时流式传输。
  • 调查数据、统计和经济数据。
  • 来自商业、金融、房地产和销售点（POS）的交易数据。

上一节我们介绍了几种常见的原始数据源，接下来我们看看更多现代和特定领域的数据源。

以下是更多原始数据源的例子：

  • 基于事件的数据，例如社交媒体流。
  • 来自气象站网络的天气数据。
  • 物联网（IoT）传感器流。
  • 医疗记录，如处方历史、医疗处理和医学影像。
  • 编码在DNA和RNA样本中的个人基因数据。

显然，许多数据是高度敏感和私人的，出于隐私和其他考虑，需要非常谨慎地保护。

数据提取技术 🛠️

了解了数据从哪里来之后，我们来看看如何将它们提取出来。根据数据源的类型和数据的预期用途，存在许多数据提取技术。

以下是几种关键的数据提取技术：

  • 光学字符识别（OCR）：用于解释和数字化从纸质文档扫描的文本，以便将其存储为计算机可读文件。
  • 模数转换器（ADC）：可以数字化模拟音频记录和信号。
  • 电荷耦合器件（CCD）：捕获和数字化图像。
  • 通过民意调查和人口普查方法获得的意见、问卷和重要统计数据。
  • Cookie、用户日志和其他用于跟踪人类和系统行为的方法。

上一节介绍了一些基础物理和数字转换技术，本节中我们来看看更多与网络和数据库相关的提取方法。

以下是更多数据提取技术：

  • 网络爬虫：用于抓取网页，搜索文本、图像、表格和超链接。
  • 应用程序编程接口（API）：可随时用于从各种在线数据存储库和源（如政府统计局、图书馆、天气网络、在线购物和社交网络）提取数据。
  • SQL语言：用于查询关系型数据库。
  • NoSQL：用于查询文档、键值、图或其他非结构化数据存储库。
  • 边缘计算设备：例如具有内置处理功能的摄像机，可以从原始数据中提取特征。
  • 生物医学设备：例如可以提取DNA序列的微流控阵列。

使用场景、数据源与技术的关联 🔗

我们已经了解了数据源和提取技术，现在来看看它们在实际场景中是如何结合应用的。

以下是几个高级使用场景示例，以及它们对应的原始数据源和提取技术：

  • 你可以使用API从多个结构化数据源提取数据，以便集成到中央存储库中。
  • 你也可以使用API捕获周期性或异步事件，将它们存储在历史档案中。
  • 为了不传输来自物联网设备可能非常庞大的冗余数据量，你可以使用边缘计算通过从原始数据中提取感兴趣的特征来减少数据量。通常，这种在源头的提取并不实际，因此数据会原样迁移到存储中，以供进一步处理、分析或建模。
  • 此外，你可以使用医学成像设备和生物特征传感器来获取用于诊断目的的数据。

总结 📝

本节课中我们一起学习了数据提取技术。

你了解到，原始数据源的例子包括来自纸质文档和PDF的归档文本和图像，以及包含文本、表格、图像和链接的网页。

许多提取技术依赖于复杂的技术来从原始数据中捕获信息。

SQL、NoSQL、网络爬虫和API是提取数据的重要技术。

你可以使用医学成像设备和生物特征传感器来获取用于诊断目的的数据。

006：数据转换技术介绍 📊

在本节课中，我们将要学习数据转换技术。我们将了解数据转换的主要类型，比较“写时模式”与“读时模式”这两种不同的数据处理理念，并列举在转换过程中可能导致信息丢失的几种方式。

什么是数据转换？🔄

数据转换的核心目的是将数据格式化为适合目标应用程序使用的形式。这涉及到多种操作。

以下是常见的数据转换类型：

  • 数据类型转换：将数据转换为适当的类型，例如整数（int）、浮点数（float）、字符串（str）、对象或类别。
  • 数据结构化：将一种数据格式转换为另一种格式，例如将 JSON、XML 或 CSV 文件转换为数据库表。
  • 匿名化与加密：对数据进行处理以保护隐私和安全。
  • 数据清洗：包括删除重复记录和填充缺失值等操作。
  • 数据规范化：确保数据单位具有可比性，例如将所有货币金额统一为一种通用货币。
  • 数据筛选、排序、聚合与分箱：这些操作用于在合适的细节层次和合理的顺序下访问正确的数据。
  • 数据连接或合并：将来自不同来源的数据整合在一起。

写时模式 vs. 读时模式 ⚖️

上一节我们介绍了数据转换的常见操作，本节中我们来看看两种不同的数据处理策略。

写时模式 是传统 ETL（提取、转换、加载）管道中使用的方法。在这种方法中，数据在加载到目标系统（如关系型数据库）之前，必须符合预先定义好的模式。这种做法的优势在于数据结构一致，系统稳定，且后续查询速度更快。但其代价是限制了数据的多样性和灵活性。

读时模式 则与现代的 ELT（提取、加载、转换）方法相关。在这种方法中，模式是在从原始数据存储中读取数据之后才应用的。这种方法非常灵活，因为它可以使用临时定义的模式从同一源数据中获得多种视图。同时，由于数据不需要经过严格的预处理步骤，用户有可能访问到更多的原始数据。

转换中的信息丢失 ⚠️

无论是写时模式还是读时模式，数据转换都可能导致信息丢失。接下来，我们探讨信息是如何在转换过程中丢失的。

无论是故意还是无意，在转换过程中信息都可能以多种方式丢失。我们可以将这种丢失可视化如下：原始数据通常比转换后的数据大得多，因为数据通常包含噪声和冗余。我们可以将数据的信息内容视为数据本身的一个真子集。相应地，我们可以看到，缩小数据量也可能意味着缩小信息内容。

对于 ETL 过程，任何丢失的信息可能无法恢复。而对于 ELT，所有原始信息内容都保持完整，因为数据是按原样复制的。

以下是在转换过程中可能导致信息丢失的几种方式：

  • 有损数据压缩：例如，将浮点数值转换为整数，或降低音频、视频的比特率。
  • 数据筛选：筛选通常是临时选择数据子集，但当筛选是永久性时，信息很容易被丢弃。
  • 数据聚合：例如，使用年平均销售额代替日或月平均销售额。
  • 边缘计算设备：例如，某些监控设备设计为仅流式传输警报信号，而不传输原始数据，这可能导致漏报（假阴性）。

总结 📝

本节课中我们一起学习了数据转换技术。我们了解到，数据转换主要是为了将数据格式化为满足目标应用的需求。常见的转换技术包括类型转换、结构化、规范化、聚合和清洗。

我们比较了 写时模式（传统 ETL 方法）和 读时模式（现代 ELT 方法）。最后，我们列举了在转换过程中可能导致信息丢失的几种方式，包括筛选、聚合、使用边缘计算设备和有损数据压缩。

007：数据加载技术

在本节课中，我们将学习数据加载的各种技术。我们将探讨批量加载与流式加载的区别，解释推送与拉取模式，并描述并行加载的概念。掌握这些技术对于设计和实施高效的数据管道至关重要。

🎯 概述

数据加载是将数据从源系统移动到目标存储系统的过程。有多种技术可以实现这一目标，每种技术都有其适用的场景和优势。理解这些技术有助于我们根据数据的特点和业务需求选择最合适的加载策略。

📦 数据加载技术概览

有多种数据加载技术。其中一些是全量加载。你可以将初始历史数据加载到数据库中，之后应用增量加载来插入新数据或更新已加载的数据。你可以安排数据加载定期进行，也可以根据需要按需加载。数据可以批量加载，也可以持续流式传输到目的地。数据可以被推送到服务器，也可以由服务器推送到客户端。数据通常串行加载，但也可以并行加载。

🔄 全量加载与增量加载

全量加载指的是将数据一次性大批量加载。例如，当组织希望在新的数据仓库中开始跟踪交易时，他们会将现有交易历史从旧系统复制到新系统。之后，随着新交易的出现，以增量方式加载交易，从而确保交易历史被跟踪。

对于增量加载，目标数据存储会被追加，只加载变更部分。这对于累积历史数据（如交易记录、天气和浏览历史）非常有用。

数据的量级、速度和需求决定了数据是批量加载还是实时流式加载。

⏰ 计划加载与按需加载

数据加载过程可以按计划执行，也可以按需启动。数据通常按计划加载。例如，每日的销售点交易可以在每天非高峰时段结束时加载到数据库中。加载任务可以使用诸如Windows任务计划程序或类Unix系统上的Cron等工具进行调度。

按需加载也非常常见，它依赖于触发机制，例如：

  • 当源数据达到指定大小时。
  • 当源系统检测到事件时（如运动、声音或温度变化）。
  • 当用户请求数据时（如在线视频、音乐或网页）。

📊 批量加载与流式加载

批量加载和流式加载是加载方法频谱的两个端点。批量加载指的是按照数据源积累的某个时间窗口（通常是数小时到数天）定义的数据块进行加载。

在频谱的另一端，我们有流式加载，它在数据可用时实时加载数据。

在批量加载和流式加载之间，我们还有微批量加载。当紧急处理过程需要访问一小段近期数据窗口时，会使用这种方法。

📡 推送与拉取加载

推送和拉取数据加载方法基于客户端-服务器模型。拉取指的是客户端发起从服务器请求数据。服务器随后响应客户端的请求并交付数据。拉取技术的例子包括RSS订阅和电子邮件。

对于推送技术，客户端订阅服务器提供的服务，以便服务器在数据可用时将其推送给客户端。例子包括推送通知和即时消息服务。

⚡ 并行加载

可以在多个数据流上采用并行加载来提高加载效率，特别是在数据量大或需要长距离传输时。

类似地，通过将单个文件分割成更小的块，这些块可以同时加载。

📝 总结

本节课我们一起学习了多种数据加载技术。我们了解到数据加载可以是计划的或按需的、增量的。数据可以批量加载，也可以持续流式传输到目的地。服务器可以在数据可用时将其推送给订阅者，客户端也可以发起从服务器拉取数据的请求。此外，我们可以采用并行加载来提高大数据量的加载效率。

008：使用Shell脚本进行ETL 🛠️

在本节课中，我们将学习如何使用Shell脚本构建一个ETL（提取、转换、加载）数据管道，并了解如何通过调度任务使其自动化运行。

概述

我们将通过一个具体场景来学习：从一个远程传感器获取温度读数，计算每小时的平均、最低和最高温度，并将结果加载到报告系统中。整个过程将使用Bash Shell脚本实现，并通过Cron调度器每分钟自动执行。

工作流程设计

上一节我们介绍了课程目标，本节中我们来看看如何设计ETL管道的工作流程。

工作流程始于气象站及其数据接口。提取步骤涉及使用提供的 GetTemp API 从传感器获取当前温度读数。您可以将读数追加到一个日志文件中，例如 temperature.log。由于只需要保留最近一小时的读数，因此可以缓冲最后60个读数，然后用缓冲的读数覆盖日志文件。

接下来，调用一个程序（例如，一个名为 get_stats.py 的Python脚本）。该脚本从60分钟的日志中计算温度统计数据，并使用 load_stats API 将结果统计信息加载到报告系统中。然后，这些统计数据可用于显示实时图表，展示每小时的最低、最高和平均温度。您还需要将工作流程安排为每分钟运行一次。

创建Shell脚本

现在，我们开始创建实现上述流程的Shell脚本。

首先，创建一个名为 temperature_etl.sh 的Shell脚本。您可以使用 touch 命令创建该文件。

touch temperature_etl.sh

接下来，使用任何文本编辑器（如 gedit）打开该文件。在编辑器中，键入 #!/bin/bash 将您的文件转变为Bash Shell脚本。

现在，您可以添加以下注释来帮助概述您的任务：

  • 使用提供的 get_temp API 从传感器提取温度读数。
  • 将读数追加到日志文件，例如 temperature.log。
  • 您只需要保留最近一小时的读数，因此缓冲最后60个读数。
  • 调用一个程序，例如名为 get_stats.py 的Python脚本，该脚本从60分钟的日志中计算温度统计数据，并使用提供的API将结果统计信息加载到报告系统中。

编写完ETL Bash脚本后，您需要将其调度为每分钟运行一次。

填充脚本细节

上一节我们创建了脚本框架，本节中我们来填充具体的实现细节。

首先，在命令行中使用 touch 命令初始化您的温度日志文件。

touch temperature.log

在文本编辑器中，输入命令以调用API读取温度，并将读数追加到 temperature.log 中。

# 调用API获取温度并追加到日志
get_temp >> temperature.log

现在，通过用其最后60行覆盖 temperature.log，仅保留最后一小时（或60行）的日志文件。这完成了数据提取步骤。

# 仅保留最后60行数据
tail -n 60 temperature.log > temp_buffer.log
mv temp_buffer.log temperature.log

假设您已经编写了一个名为 get_stats.py 的Python脚本，该脚本从日志文件读取温度，计算温度统计数据，并将结果写入输出文件。输入和输出文件名被指定为命令行参数。

您可以在ETL脚本中添加以下行，该行调用Python 3并调用您的Python脚本 get_stats.py，使用 temperature.log 中的读数，并将温度统计数据写入名为 temperature_stats.csv 的CSV文件。这完成了ETL脚本的转换组件。

# 调用Python脚本进行数据转换
python3 get_stats.py temperature.log temperature_stats.csv

最后，您可以通过调用API并指定温度统计CSV作为命令行参数，将结果统计信息加载到报告系统中。

# 调用API加载数据
load_stats temperature_stats.csv

接下来，不要忘记设置权限以使您的Shell脚本可执行。

chmod +x temperature_etl.sh

调度ETL任务

脚本编写完成后，我们需要让它自动运行。

现在，是时候调度您的ETL作业了。打开Cron选项卡编辑器。

crontab -e

将您的作业调度为每天每分钟运行。

* * * * * /path/to/your/temperature_etl.sh

关闭编辑器并保存您的编辑。您的新ETL作业现在已被调度并在生产环境中运行。

总结

本节课中我们一起学习了如何使用基本的Bash脚本构建ETL管道，以及如何通过为您的Bash脚本创建Cron作业来调度ETL任务运行。通过这个实践，您掌握了实现自动化数据流程的核心步骤。

009：数据流水线简介 📊

在本节课中，我们将要学习数据流水线的基本概念、性能指标以及常见应用场景。通过本课，你将能够理解数据流水线如何工作，并掌握评估其性能的关键因素。

什么是流水线？ 🔄

流水线的概念广泛适用于任何一组按顺序连接的过程。这意味着一个过程的输出会作为链中下一个过程的输入传递下去。

例如，将箱子从一个地方搬到另一个地方的一种方法是让一群朋友排成一列，每个人将箱子一个接一个地传递给最近的下一个人。

数据流水线 📈

数据流水线是专门用于移动或修改数据的流水线。数据流水线的目的是将数据从一个地方或形式移动到另一个地方或形式。一个数据流水线是一个系统，它提取数据并将其传递到可选的转换阶段，最终进行加载。

这包括低层次的硬件架构，但我们在这里的重点是由软件进程驱动的数据流水线架构，例如命令、程序和处理线程。Linux中简单的bash管道命令可以用作连接这些进程的“粘合剂”。

数据包与流动 📦

我们可以将流经流水线的数据视为数据包的形式。“数据包”这个术语我们将广泛地用来指代数据的单位。数据包的大小范围可以从单个记录或事件到大型数据集合。

在这里，我们有数据包排队等待被流水线摄取。

流水线性能指标 ⚙️

数据流水线的长度代表单个数据包遍历整个流水线所需的时间。数据包之间的箭头代表吞吐量延迟，即连续数据包到达之间的时间间隔。

延迟

你刚刚了解了关于数据流水线的两个关键性能考量。第一个是延迟，它是指单个数据包通过整个流水线所需的总时间。

等效地说，延迟是数据包在流水线内每个处理阶段所花费的个体时间的总和。因此，总体延迟受限于流水线中最慢的进程。

例如，无论你的互联网服务有多快，加载网页的时间将由服务器的速度决定。

吞吐量

第二个性能考量称为吞吐量。它指的是单位时间内可以通过流水线传输的数据量。单位时间内处理更大的数据包可以提高吞吐量。

回到我们朋友传递箱子的例子，我们可以在右侧的图片中看到，在限度内，传递更大的箱子可以提高生产力。

数据流水线的应用场景 🌐

让我们从众多的用例中列举一些数据流水线的应用。

以下是一些常见的应用场景：

  • 数据备份：最简单的流水线没有转换步骤，仅用于将数据从一个位置复制到另一个位置，例如文件备份。
  • 数据湖集成：将不同的原始数据源集成到一个数据湖中。
  • 数据仓库迁移：将事务记录移动到数据仓库。
  • 物联网数据流：将来自物联网设备的数据流式传输，以便以仪表板或警报系统的形式提供信息。
  • 机器学习数据准备：为机器学习开发或生产准备原始数据。
  • 消息传递：例如电子邮件、短信或在线视频会议中的消息发送和接收。

总结 📝

本节课中我们一起学习了数据流水线的基础知识。我们了解到，数据流水线的目的是将数据从一个地方或形式移动到另一个地方或形式。我们可以将流经流水线的数据可视化为一系列逐个流入和流出的数据包。

延迟和吞吐量是设计数据流水线时的关键考量因素。数据流水线的用例非常多，范围从简单的复制粘贴式数据备份到在线视频会议。

010：关键的数据流水线过程 🚀

在本节课中，我们将要学习数据流水线的核心过程、监控要点以及如何缓解数据流瓶颈的解决方案。

概述

数据流水线是现代数据工程的核心，它负责将数据从源头高效、可靠地传输到目的地。一个设计良好的流水线不仅能处理数据，还能确保数据的完整性和时效性。本节我们将深入探讨流水线的关键阶段、监控策略以及优化技术。

数据流水线的关键阶段

上一节我们介绍了数据流水线的基本概念，本节中我们来看看一个典型数据流水线包含哪些共同阶段。

数据流水线过程通常包含以下共同阶段：

  • 从一个或多个数据源提取数据。
  • 将提取的数据摄取到流水线中。
  • 流水线内部可选的数据转换阶段。
  • 最终将数据加载到目标设施中。
  • 用于调度或触发作业运行的机制。
  • 监控整个工作流。
  • 根据需要进行维护和优化，以保持流水线平稳运行。

数据流水线监控要点

了解了流水线的构成阶段后，确保流水线在生产环境中稳定运行至关重要。接下来，我们将探讨监控数据流水线时需要考虑的关键因素。

数据流水线投入生产后需要进行监控，以确保数据完整性。

以下是关键监控注意事项：

  • 延迟：数据包流经流水线所需的时间。
  • 吞吐量需求：随时间通过流水线的数据量。
  • 错误和故障：由网络过载、源系统或目标系统故障等因素引起。
  • 利用率：流水线资源被利用的充分程度，这会影响成本。
  • 日志与告警：流水线还应具备记录事件的系统，并在发生故障时向管理员发出警报。

缓解数据流瓶颈的解决方案

监控可以帮助我们发现流水线的问题，其中最常见的挑战之一是数据流瓶颈。本节中，我们来看看如何识别和解决这些瓶颈。

理想情况下，当一个阶段完成对一个数据包的处理时，队列中的下一个数据包刚好可供其使用。在这种情况下，流水线运行时该阶段永远不会闲置，并且不存在上游瓶颈。

将这一概念扩展到流水线的所有阶段，意味着所有阶段处理一个数据包应花费相同的时间。这意味着没有瓶颈，我们可以说整个流水线已经实现了负载均衡。

深入理解负载均衡

让我们更仔细地看看这个想法。假设您的流水线在其中一个阶段存在瓶颈，例如图中这个更长的红色部分，它比流水线中的其他阶段具有更高的延迟。

如果该阶段可以并行化，例如通过将数据拆分为两个并发阶段，那么您就可以减少此阶段的延迟。

管理并行化以及将输出重新组合回流水线会产生少量开销，但总体延迟将会降低。

由于时间和成本的考虑，流水线很少能完美地实现负载均衡。这意味着数据流中几乎总是存在成为瓶颈的阶段。如果这样的阶段可以并行化，则可以加速它以更好地匹配流速率。

实现并行化

并行化进程的一个简单方法是，在多个CPU、核心或线程上复制该进程，并在数据包到达时以交替方式在复制的通道之间分配它们。

包含并行性的流水线被称为动态或非线性的，这与适用于串行流水线的静态特性相对。阶段之间的进一步同步可能仍然需要，典型的解决方案是根据需要包含输入和输出缓冲区，以平滑数据流。

使用I/O缓冲区

I/O缓冲区是位于处理阶段之间的数据暂存区。缓冲区也可用于调节具有可变处理速率的阶段的输出，从而可用于提高吞吐量。

单个输入和输出缓冲区也用于在并行阶段上分配和收集负载。

总结

本节课中我们一起学习了数据流水线的核心知识。

  • 除了提取、转换和加载，数据流水线过程还包括调度、触发、监控、维护和优化。
  • 流水线监控需要考虑跟踪延迟、吞吐量、资源利用率和故障。
  • 最后，可以通过在瓶颈处引入并行化和I/O缓冲区来缓解不平衡或变化的负载。

011：批处理与流式数据流水线的用例 📊

在本节课中，我们将学习批处理与流式数据流水线的核心概念、区别以及各自的典型应用场景。我们还将了解微批处理和Lambda架构这两种混合模式。

概述

数据流水线根据数据处理和传输的时效性，主要分为批处理和流式处理两种模式。选择哪种模式取决于业务对数据准确性和延迟的不同要求。本节课程将详细解析这两种模式及其变体。

批处理数据流水线

上一节我们介绍了数据流水线的基本概念，本节中我们来看看批处理流水线。

当数据集需要作为一个完整的单元被提取和操作时，会使用批处理数据流水线。批处理过程通常按固定周期运行，间隔时间从几小时到几周不等。它也可以基于触发器启动，例如当源端积累的数据达到特定大小时。

批处理适用于不依赖数据最新性的场景。当准确性至关重要但对延迟要求不高时，通常会采用批处理数据流水线。尽管关键任务的流式技术正在迅速成熟，但批处理在需要高精度的场景中依然占有一席之地。

流式数据流水线

了解了批处理之后，我们再来看看它的对应模式——流式处理。

流式数据流水线旨在快速、连续地逐个摄取信息包，例如单笔信用卡交易或社交媒体活动。当业务要求结果具有最低延迟（本质上是实时）时，会使用流式处理。

在流式流水线中，记录或事件在发生时立即被处理。这些事件流也可以被追加到存储中，以构建历史记录供后续使用。其他软件系统可以发布（或写入）和订阅（或读取）这些事件流。

微批处理：一种混合方法

有时，我们希望在批处理的可靠性和流式处理的低延迟之间取得平衡。微批处理就是这样一种折中方案。

通过减小批处理的大小并提高单个批处理过程的刷新频率，可以使用微批处理来实现近实时处理。微批处理也可能有助于负载均衡，从而降低整体延迟。这在转换仅需要非常短时间窗口的数据时非常有用。

批处理和流式处理在用例上的差异，归根结底是准确性和延迟要求之间的权衡。例如，批处理可以对数据进行清洗，从而获得更高质量的输出，但这是以增加延迟为代价的。如果你要求低延迟，那么你对错误的容忍度可能就必须提高。

Lambda架构

为了同时利用批处理和流式处理的优势，业界提出了Lambda架构。

Lambda架构是一种为处理大数据而设计的混合架构。Lambda架构结合了批处理和流式数据流水线方法：历史数据以批处理形式交付给批处理层，实时数据则流式传输到速度层。然后，这两层在服务层进行集成。

数据流用于填补批处理层处理所造成的延迟间隙。Lambda架构可用于需要访问早期数据但同时速度也很重要的场景。这种方法的缺点在于设计上的复杂性。当你追求准确性和速度时，通常会选择Lambda架构。

批处理流水线用例

以下是批处理数据流水线的一些典型用例：

  • 定期数据备份和交易历史加载。
  • 客户订单和账单的处理。
  • 对缓慢变化的数据进行数据建模，用于长期销售预测和天气预报。
  • 历史数据分析和诊断性医学图像处理。

流式处理流水线用例

流式数据流水线的用例正在不断增长，以下是一些例子：

  • 观看电影、听音乐或播客等媒体流。
  • 社交媒体信息流和情感分析。
  • 欺诈检测。
  • 用户行为分析和定向广告。
  • 股票市场交易。
  • 实时产品定价。
  • 推荐系统。

总结

本节课中，我们一起学习了数据流水线的两种核心模式。

你了解到，批处理流水线提取并操作批量数据。当准确性至关重要或不需要最新数据时，会使用批处理。流式数据流水线则快速连续地逐个摄取数据包。当需要最新数据时，会使用流式流水线。微批处理可用于模拟实时数据流。而Lambda架构可用于需要访问早期数据但同时速度也很重要的场景。

012：数据流水线工具与技术 🛠️

在本节课中，我们将学习数据流水线相关的工具与技术。我们将探讨现代企业级数据流水线工具的特点，并列举一系列开源和商业的ETL、ELT工具以及流数据处理工具。

🎯 概述

观看本视频后，你将能够：

  • 讨论数据流水线技术。
  • 列举开源和企业级的ETL与ELT工具。
  • 列举流数据流水线工具。

🔧 现代企业级数据流水线工具特点

市面上有许多开源和商业的数据流水线工具及云服务可供选择。现代企业级ETL和ELT产品的典型特点包括以下方面：

以下是其主要特点列表：

  • 全自动化流水线创建：支持从数据提取到加载至目标端的全流程自动化。
  • 易于使用：提供用于提取、转换和加载数据的规则建议。部分工具甚至能自动探查你的数据。
  • 拖拽式图形用户界面：用于指定规则和数据流水线流程，也称为“无代码ETL”。
  • 复杂转换支持：支持并协助完成复杂的数据转换，例如流操作、计算和数据合并。
  • 安全与合规：现代工具会对传输中和静态的数据进行加密，并符合行业和政府法规（如HIPAA和GDPR）的认证要求。

🐍 开源工具：Python与Pandas

上一节我们介绍了企业级工具的特点，本节中我们来看看一些流行的开源工具。Python及其pandas库是一个非常流行且功能强大的编程环境，用于构建数据流水线。

pandas使用一种名为数据框的数据结构来处理类似Excel或CSV的表格数据。其核心概念可以表示为：

import pandas as pd
# 创建一个数据框
df = pd.DataFrame(data)
# 进行数据转换操作
df_transformed = df[df['column'] > value]

它是一个用于原型设计ETL流水线和进行探索性数据分析的优秀工具。但由于数据框操作必须在内存中进行，要扩展到大数据场景可能具有挑战性。

具有类似数据框API的库包括Dask、Vaex和Apache Spark，它们都能帮助你扩展到大数据处理。为了获得更好的可扩展性，也可以考虑使用类似SQL的替代方案，例如PostgreSQL。

✈️ 开源工具：Apache Airflow

另一个基于Python编程语言的包是Apache Airflow，它是一个功能极为丰富且知名的“代码即配置”开源数据流水线平台范例。

Apache Airflow由Airbnb开源，旨在通过编程方式编写、调度和监控数据流水线工作流。它被设计为可扩展的，能够处理任意数量的并行计算节点。Airflow与大多数云平台集成，包括AWS、IBM Cloud、Google Cloud和Microsoft Azure。

🎨 开源工具：Talend Open Studio

Talend Open Studio是另一个开源的数据流水线开发和部署平台。它支持大数据迁移、数据仓库和分析，并包含协作、监控和调度功能。

它同样拥有一个交互式的拖拽式图形用户界面，允许你创建ETL流水线，无需编写代码，因为Java代码会自动生成。它还能连接到许多数据仓库，如Google Sheets、RDBMS、IBM DB2和Oracle。

☁️ 企业级工具：AWS Glue

在众多企业级数据流水线工具中，AWS Glue是一项完全托管的ETL服务，可让你轻松准备和加载数据以进行分析。

AWS Glue会探查你的数据源以发现数据格式，并建议存储数据的模式。你可以使用AWS控制台快速创建并运行ETL作业。

🔄 企业级工具：Panoply

Panoply是另一个企业级解决方案，但其侧重点在于ELT而非ETL。它无需代码即可处理数据连接和集成，并自带SQL功能，因此你可以生成数据的视图。这使你能够将时间专注于数据分析，而非优化数据流水线。

Panoply还与许多仪表板和商业智能工具集成，包括Tableau和Power BI。

📊 企业级工具：Alteryx

Alteryx是另一个知名的商业数据流水线工具。它也是一个功能丰富的自助式数据分析平台，拥有多款产品。

它提供拖拽式访问内置的ETL工具，你无需了解SQL或编程即可创建和维护复杂的数据流水线。

💼 企业级工具：IBM InfoSphere DataStage

IBM InfoSphere DataStage 是一款数据集成工具，用于设计、开发和运行ETL及ELT流水线。它是IBM InfoSphere Information Server的数据集成组件。

与许多其他平台一样，它也提供了一个用于开发工作流的拖拽式框架。InfoSphere DataStage还利用并行处理和企业级连接性，提供了一个真正可扩展的平台。

🌊 流处理工具：IBM Streams

上一节我们介绍了批处理工具，本节我们转向实时数据处理。IBM Streams 是一种流数据流水线技术，使你能够使用流处理语言（SPL）以及Java、Python或C++构建实时分析应用程序。

你可以用它来混合动态数据和静态数据，以实时提供持续的情报分析。Streams驱动着一项流分析服务，允许你以亚毫秒级的延迟每秒摄取和分析数百万个事件。

IBM Streams还附带了IBM Streams Flows工具，它允许你将操作符拖放到画布上，并通过内置的设置面板修改参数。

⚡ 其他流处理技术

还有许多其他流处理技术值得考虑，包括：

以下是部分主流流处理技术列表：

  • Apache Storm
  • SQL Stream
  • Apache Samza
  • Apache Spark
  • Azure Stream Analytics
  • Apache Kafka

📝 总结

本节课中，我们一起学习了以下内容：

  • 现代企业级数据流水线工具包含诸如转换支持、拖拽式图形界面以及安全与合规等功能。
  • Pandas、Vaex和Dask是用于原型设计和构建数据流水线的有用开源Python库。
  • Apache Airflow和Talend Open Studio允许你以编程方式编写、调度和监控大数据工作流。
  • Panoply专门用于ELT流水线，而像Alteryx和IBM InfoSphere DataStage这样的工具可以处理ETL和ELT两种工作流。
  • 流处理技术包括Apache Kafka、IBM Streams、SQL Stream和Apache Spark。

013：Apache Airflow 概述 🚀

在本节课中，我们将学习 Apache Airflow 这一强大的工作流编排平台。我们将了解它的核心概念、主要组件、工作原理、关键特性以及常见应用场景。

什么是 Apache Airflow？ 🤔

Apache Airflow 是一个由活跃社区支持的开源工作流编排工具。它是一个平台，允许你以编程方式创建、调度和监控工作流，例如批处理数据管道。

在 Apache Airflow 中，一个工作流被表示为一个 DAG，即有向无环图。DAG 包含称为“任务”的独立工作单元，这些任务按照依赖关系排列。

请注意：与 Apache Kafka、Apache Storm、Apache Spark 或 Flink 等大数据工具不同，Apache Airflow 不是 数据流处理解决方案。它主要是一个工作流管理器。

Apache Airflow 核心组件 🧩

上一节我们介绍了 Apache Airflow 的基本概念，本节中我们来看看它的核心架构组件。以下是 Apache Airflow 基本组件的简化概述：

  • 调度器：Airflow 内置了一个调度器，负责触发所有已调度的工作流。它判断任务依赖关系是否满足，并将任务提交给执行器。
  • 执行器：执行器负责运行任务，它将任务分配给工作节点。
  • 工作节点：工作节点是实际运行任务的计算单元。
  • Web 服务器：Web 服务器提供 Airflow 强大的交互式用户界面。通过此 UI，你可以检查、触发和调试你的 DAG 及其任务。
  • DAG 目录：该目录包含你所有的 DAG 文件，供调度器、执行器及其工作节点访问。
  • 元数据数据库：Airflow 使用一个元数据数据库，供调度器、执行器和 Web 服务器存储每个 DAG 及其任务的状态。

DAG 与任务生命周期 🔄

一个 DAG 规定了任务之间的依赖关系和执行顺序，而任务本身则描述了要执行的具体操作。例如，一个 DAG 中的任务可能包括数据摄取、数据分析、保存数据、生成报告以及通过电子邮件触发错误报告等系统。

现在，让我们了解一下任务在其生命周期中可能经历的状态变化。下图展示了 Apache Airflow 如何为任务分配状态：

  • 无状态：任务尚未排队等待执行。
  • 已调度：调度器已确定任务依赖关系满足，并已安排其运行。
  • 已移除：由于某些原因，任务在 DAG 运行开始后消失了。
  • 上游失败：一个上游任务失败了。
  • 已排队：任务已分配给执行器，正在等待可用的工作节点。
  • 运行中：任务正在由工作节点运行。
  • 成功：任务运行完成，没有错误。
  • 失败：任务在执行过程中出错，运行失败。
  • 重试中：任务失败，但仍有重试次数，将被重新调度。

理想情况下，一个任务应该从“无状态”流经“已调度”、“已排队”、“运行中”，最终到达“成功”状态。

Apache Airflow 的五大特性与优势 ✨

了解了任务的生命周期后，我们来看看 Apache Airflow 广受欢迎的五大主要特性和优势：

以下是 Apache Airflow 的五大核心优势：

  1. 纯 Python：使用标准 Python 创建你的工作流。这使你在构建数据管道时能保持完全的灵活性。核心概念可以表示为：workflow = Python_Code()
  2. 实用的 UI：通过一个功能完善的 Web 应用程序监控、调度和管理你的工作流，让你能全面了解任务状态。
  3. 丰富的集成：Apache Airflow 提供了许多即插即用的集成（如 IBM Cloudant），可以随时执行你的任务。
  4. 易于使用：任何具备 Python 知识的人都可以部署工作流。Airflow 不限制你管道的范围。
  5. 开源：当你想要分享你的改进时，可以通过提交拉取请求来实现。Airflow 拥有许多活跃用户，他们在 Apache Airflow 社区中分享经验。

Apache Airflow 的设计原则 🏗️

Apache Airflow 管道建立在四个主要原则之上：

  1. 可扩展：Airflow 采用模块化架构，并使用消息队列来协调任意数量的工作节点，可以轻松扩展到极大规。
  2. 动态：Airflow 管道使用 Python 定义，允许动态生成管道。因此，你的管道可以包含多个同时执行的任务。
  3. 可扩展：你可以轻松定义自己的操作符并扩展库，以适应你的特定环境需求。
  4. 简洁：Airflow 管道简洁而明确。参数化是其核心功能，通过强大的 Jinja 模板引擎实现。

Apache Airflow 常见用例 🏢

Apache Airflow 已帮助许多公司实现了目标，以下是一些常见用例：

  • Shopify：使用 Airflow 定义和组织机器学习管道依赖关系。
  • SeniorLink：提高了其批处理流程的可见性，并实现了解耦。
  • Xperity：将 Airflow 部署为企业级调度工具。
  • One Football：使用 Airflow 协调数据仓库中的 SQL 转换，并发送每日分析邮件。

总结 📝

本节课中我们一起学习了 Apache Airflow 的核心知识。我们了解到 Apache Airflow 是一个用于以编程方式创建、调度和监控工作流的平台。

其五大主要特性包括：使用 Python、直观实用的用户界面、丰富的即插即用集成、易于使用以及开源性质。

我们还学习了 Apache Airflow 的四大设计原则：可扩展性、动态性、可扩展性和简洁性。

最后，我们看到了使用 Apache Airflow 定义和组织机器学习管道依赖关系是其常见用例之一。

014：在Apache Airflow中将数据流水线表示为DAG的优势 🚀

在本节课中，我们将学习如何在Apache Airflow中使用有向无环图（DAG）来表示数据流水线。我们将探讨DAG的基本概念、其组成部分，以及将工作流定义为代码所带来的关键优势。

什么是DAG？ 📊

上一节我们介绍了课程概述，本节中我们来看看DAG的定义。DAG是一种特殊类型的图，称为有向无环图。

一个简单的图由节点和边组成。例如，圆圈代表节点，连接节点的线代表边。有向图在此基础上增加了方向性，每条边都有一个指定的方向，连接一个起始节点和另一个节点。最后，“无环”意味着图中没有循环，即不存在一系列有向边能够返回到链中的某个节点。

公式：DAG = (V, E)，其中V是节点集合，E是有向边集合，且不存在环。

DAG的示例 🌳

以下是几个DAG的示例。

最简单的非平凡DAG包含一条有向边，它有一个单一的根节点连接到一个单一的终端节点。

另一个常见的DAG示例是树形结构，常用于表示家谱或目录结构。所有树都是DAG，但并非所有DAG都是树。例如，一个DAG可能拥有多个根节点，而树则不行。DAG不施加这些限制，因此单个节点可以有多个父节点，也可能存在多个没有父节点的节点。

在Airflow中使用DAG表示工作流 ⚙️

DAG在Apache Airflow中用于表示工作流或流水线。数据流水线中执行的每个任务都表示为DAG中的一个节点，而流水线中两个任务之间的每个依赖关系则表示为DAG中的一条有向边。换句话说，边定义了两个任务应该运行的顺序。因此，Airflow使用DAG来定义应该运行哪些任务以及它们应该以何种顺序运行。

DAG在一个Python脚本中定义，该脚本代表了DAG的结构。因此，任务及其依赖关系被定义为代码。同时，调度指令也在DAG脚本中作为代码指定。

DAG中的任务与操作符 🔧

让我们更仔细地看看DAG中的节点或任务。就像DAG本身一样，在DAG中执行的每个任务也是用Python编写的。每个任务实现一个操作符。

以下是几种操作符的示例：

  • PythonOperator：用于部署一些Python代码。
  • SQLOperator：用于运行SQL查询。
  • BashOperator：用于运行bash命令。

操作符用于定义DAG中每个任务的功能。

传感器是一类特殊的操作符，用于等待某个时间或条件被满足。例如，您可以使用传感器每30秒检查一次文件是否存在，或者检查另一个DAG是否已完成运行。

还有其他许多类型的操作符，包括电子邮件和HTTP请求操作符。

DAG定义文件的结构 📝

一个Apache Airflow DAG是一个Python脚本，由以下逻辑块组成：

以下是DAG定义脚本的主要组成部分：

  1. 库导入：导入所需的Python库。
  2. DAG参数：指定DAG的默认参数。
  3. DAG定义：实例化DAG对象。
  4. 任务定义：定义DAG中的各个任务（节点）。
  5. 任务流水线：指定任务之间的依赖关系（边）。

让我们简要地看一个例子。

代码示例：

# 1. 库导入
from airflow import DAG
from airflow.operators.bash_operator import BashOperator
from datetime import datetime

# 2. DAG参数
default_args = {
    'owner': 'airflow',
    'start_date': datetime(2023, 10, 27),
}

![](https://github.com/OpenDocCN/dsai-notes-pt1-zh/raw/master/docs/ibm-dtengi-8/img/f02780fed08073a7bad0a03e33513511_37.png)

# 3. DAG定义
dag = DAG('example_dag', default_args=default_args, schedule_interval='@daily')

# 4. 任务定义
task1 = BashOperator(
    task_id='print_date',
    bash_command='date',
    dag=dag,
)

task2 = BashOperator(
    task_id='sleep',
    bash_command='sleep 5',
    dag=dag,
)

![](https://github.com/OpenDocCN/dsai-notes-pt1-zh/raw/master/docs/ibm-dtengi-8/img/f02780fed08073a7bad0a03e33513511_39.png)

# 5. 任务流水线
task2.set_upstream(task1)  # task2 依赖于 task1

Airflow调度器 🗓️

您的新DAG已经创建，但尚未部署。为此，Airflow调度器被设计为在Airflow生产环境中作为持久服务运行。

Apache Airflow调度器可用于在多个工作节点上部署您的工作流。它遵循您在DAG中指定的任务和依赖关系。一旦启动Airflow调度器实例，您的DAG将根据您在每个DAG中作为代码指定的开始日期开始运行。之后，调度器根据您指定的调度间隔触发每个后续的DAG运行。

将工作流定义为代码的优势 ✨

Apache Airflow将数据流水线表示为DAG的方法的一个关键优势在于它们被表达为代码。

当工作流被定义为代码时，它们变得：

  • 更易于维护：开发者可以通过阅读代码来明确理解已指定的内容。
  • 可版本控制：代码修订可以轻松地通过如Git这样的版本控制系统进行跟踪。
  • 可协作：开发团队可以轻松地在整个工作流的代码开发和维护上进行协作。
  • 可测试：任何修订都可以通过单元测试来确保代码仍按预期工作。

总结 🎯

本节课中我们一起学习了：

  • 在Apache Airflow中，DAG是定义为Python代码的工作流。
  • 任务是DAG中的节点，通过实现Airflow内置的操作符来创建。
  • 流水线被指定为任务之间的依赖关系，这些是DAG中节点之间的有向边。
  • Airflow调度器负责调度和部署您的DAG。
  • 最后，Apache Airflow将数据流水线表示为DAG的方法的关键优势在于它们被表达为代码，这使得您的数据流水线更易于维护、测试和协作。

015：Apache Airflow UI 详解 🖥️

在本节课中，我们将学习Apache Airflow用户界面的核心功能。你将了解如何识别环境中的DAG，通过多种方式可视化DAG，审查定义DAG的代码，分析任务在多轮运行中的持续时间，以及查看任务实例的上下文元数据。

欢迎来到Apache Airflow用户界面

观看本视频后，你将能够识别环境中的当前DAG，列出可视化特定DAG的不同方法，审查定义DAG的代码，分析DAG中每个任务在多轮运行中的持续时间，并为任何任务实例选择上下文元数据。

DAGs视图概览 📊

Apache Airflow用户界面的默认登录页面是DAGs视图。这是一个表格，包含环境中每个DAG的数据。

以下是DAGs视图中每一行显示的信息：

  • DAG名称：DAG的唯一标识。
  • 运行计划：DAG的运行调度时间，通常以Cron格式显示。
  • 所有者：DAG的创建者或负责人。
  • 任务状态：当前或最近一次DAG运行中各个任务的状态。
  • 历史运行状态：所有先前DAG运行的状态概览。
  • 快速链接：最左侧的列提供了一系列快速链接，可以深入查看与该DAG相关的更多信息。
  • 暂停/启动开关：在下一列，你可以通过开关来暂停或启动一个DAG。目前，这里显示的所有DAG都处于未运行状态。

可视化DAG的多种方式

你可以通过以下几种方式可视化DAG。首先，点击你想要查看的DAG名称。例如，这个名为“simple example”的DAG目前正在生产环境中运行，你可以通过其旁边的“开启”按钮确认这一点。

树状视图

点击DAG名称后，默认会打开该DAG的树状视图。它按时间线显示了你的DAG及其任务在每次运行中的状态。

在树状视图中，你可以选择基准状态和要显示的运行次数。每种状态都根据此处显示的图例进行了颜色编码。你还可以将鼠标指针悬停在时间线上的任何任务上，以查看更多相关信息。

图形视图

接下来，我们看看另一个以图形视图显示的DAG。在屏幕底部，你可以看到DAG的任务及其依赖关系。每个任务根据其操作符类型，按照此处的图例进行颜色编码。你可以通过切换这些状态选项按钮来过滤视图。

任务实例上下文菜单

任务实例上下文菜单可以从任何显示DAG任务实例的视图中访问。例如，在树状视图或图形视图中右键点击任务即可。

这个菜单允许你深入查看选定的任务实例，以查看和编辑其许多详细信息，或者查看该任务的日志文件。

查看DAG定义代码

通过点击“代码”按钮，你还可以查看定义DAG的完整Python源代码。在这里，我们可以看到DAG的构建模块，例如库的导入和各个任务的定义。在这个例子中，任务定义调用了Bash操作符。

分析任务持续时间

通过点击“任务持续时间”，你可以查看DAG任务持续时间的时间线图表，以了解它们的性能表现。在这里，你可以切换选择希望高亮显示的任务。

课程总结

在本节课中，我们一起学习了Apache Airflow拥有一个功能丰富的用户界面，它简化了数据管道的工作流程。你可以通过多种信息丰富的方式可视化你的DAG，包括图形模式和树状模式。你还可以审查最初定义DAG的Python代码，分析DAG中每个任务在多轮运行中的持续时间，最后，你可以为任何任务实例选择上下文元数据。

016：使用Airflow构建DAG 🛠️

在本节课中，我们将学习如何将Airflow管道编写为一个定义Airflow DAG对象的Python脚本。我们将了解DAG定义文件的关键组成部分，学习如何通过实例化操作符来创建任务，并设置任务之间的依赖关系。

概述

一个Apache Airflow DAG本质上是一个Python脚本。它由几个逻辑块构成，包括库导入、DAG参数定义、DAG实例化、任务定义以及任务依赖关系设置。理解这些组成部分是构建有效数据管道的基础。

DAG定义文件的逻辑块

一个典型的Airflow DAG定义脚本包含以下五个逻辑块。我们将逐一进行介绍。

1. Python库导入

首先，我们需要导入构建DAG所需的Python库。以下是导入语句的示例：

from airflow import DAG
from airflow.operators.bash_operator import BashOperator
from datetime import datetime
  • DAG 类用于定义工作流。
  • BashOperator 用于创建执行Bash命令的任务。
  • datetime 模块用于处理时间相关的参数。

2. DAG参数定义

接下来，我们定义一个Python字典来指定DAG的默认参数。这些参数将应用于DAG中的所有任务。

default_args = {
    'owner': 'you',
    'start_date': datetime(2021, 7, 28),
    'retries': 1,
    'retry_delay': timedelta(minutes=5)
}
  • owner：DAG的所有者。
  • start_date：DAG开始运行的日期。
  • retries：任务失败时的重试次数。
  • retry_delay：重试之间的等待时间。

3. DAG实例化

在这一步，我们将工作流实例化为一个DAG对象。我们可以在此设置DAG的名称、描述、默认参数和调度计划。

dag = DAG(
    'simple_example',
    description='一个简单的示例DAG',
    default_args=default_args,
    schedule_interval=timedelta(seconds=5)
)
  • 'simple_example'：DAG的唯一标识符。
  • description：对DAG功能的描述。
  • default_args：应用上面定义的默认参数字典。
  • schedule_interval：DAG运行的调度间隔，例如每5秒运行一次。

4. 任务定义

任务定义是DAG的核心，每个任务都是DAG中的一个节点。我们通过实例化操作符来创建任务。

以下是定义两个Bash任务的示例：

t1 = BashOperator(
    task_id='print_hello',
    bash_command='echo "Greetings, the date and time are:"',
    dag=dag
)

t2 = BashOperator(
    task_id='print_date',
    bash_command='date',
    dag=dag
)

  • task_id：任务的唯一标识符。
  • bash_command：该任务要执行的Bash命令。
  • dag=dag：将此任务分配给上面创建的DAG实例。

5. 任务依赖关系设置

最后，我们需要指定任务之间的执行顺序，即定义任务管道。这决定了工作流的逻辑流程。

t1 >> t2
  • >> 操作符表示“下游”或“之后运行”。这里表示 t2 在 t1 之后运行。也就是说，print_hello 任务成功完成后，print_date 任务才会开始执行。

总结

本节课中，我们一起学习了如何构建一个Airflow DAG。我们了解到：

  1. Airflow管道是一个实例化Airflow DAG对象的Python脚本。
  2. DAG定义文件的关键组成部分包括：库导入、DAG参数、DAG定义、任务定义和任务管道规范。
  3. 可以通过在DAG定义中设置 schedule_interval 参数来让DAG按计划重复运行。
  4. 任务是通过实例化从Apache Airflow操作符模块导入的操作符来创建的。

通过掌握这些基本概念和结构，你已经具备了创建简单但功能完整的Airflow数据管道的能力。

017：Airflow监控与日志记录 📊

在本节课中，我们将学习如何使用Airflow的日志记录功能来监控任务状态、诊断问题，并了解如何访问Airflow发出的各类指标，如计数器、测量器和计时器。掌握这些技能对于管理和维护高效、可靠的数据管道至关重要。

日志记录功能概述

日志记录功能是开发者监控DAG运行中任务状态、诊断和调试问题的必备工具。默认情况下，Airflow的日志会以文件形式保存在本地文件系统中。这种方式便于开发者在开发环境中快速查阅日志。

对于生产环境的Airflow部署，日志文件也可以发送到云存储服务（如IBM Cloud、AWS或Azure）以便远程访问。此外，日志还可以发送到搜索引擎和仪表板进行进一步的检索与分析。Airflow推荐使用Elasticsearch和Splunk这两种流行的文档数据库和搜索引擎来索引、搜索和分析日志文件。

日志文件组织结构

默认情况下，日志文件按照DAG ID和任务ID进行组织。你可以使用以下路径约定来查找特定任务执行的日志文件：

logs/{DAG_ID}/{TASK_ID}/{EXECUTION_DATE}/{TRY_NUMBER}.log

例如，假设你想查找在特定时间执行的dummy_dag中任务task1的第一次执行尝试日志，你可以定位到文件夹 logs/dummy_dag/task1/{execution_date}/1.log。打开这个日志文件，你可以查看大量有用信息，例如运行的命令、命令结果、任务结果等。

通过Web UI查看任务事件

除了直接查看日志文件，你还可以通过Airflow Web服务器提供的用户界面快速回顾任务事件。在UI中，你可以使用DAG ID、任务ID和执行日期等字段搜索事件，快速获取你所关注的特定DAG和任务的概览信息。

Airflow的指标类型

Airflow会生成三种不同类型的指标，用于检查和监控组件的健康状况。它们分别是：

  • 计数器：这类指标的值总是递增的。例如，成功或失败任务的总计数。
  • 测量器：这类指标的值可能会波动。例如，当前正在运行的任务数量或DAG包的大小。
  • 计时器：这类指标与时间长度相关。例如，完成任务所需的时间，或任务达到成功或失败状态所需的时间。

生产环境中的指标处理

与日志类似，在生产环境部署中生成的指标也应该发送到专门的存储库和工具进行分析。Airflow推荐使用StatsD，这是一个网络守护进程，可以从Airflow收集指标并将其发送到专用的指标监控系统。

对于指标监控和分析，Airflow推荐使用Prometheus，这是一个流行的指标监控与分析系统。Prometheus还可以在仪表板中聚合和可视化指标，以进行更具交互性的可视化分析。

课程总结

本节课我们一起学习了Airflow的监控与日志记录。你了解到可以将Airflow日志保存到本地文件系统，也可以发送到云存储、搜索引擎和日志分析器。Airflow建议将生产部署的日志发送给Elasticsearch或Splunk进行分析。通过Airflow的Web UI，你可以轻松查看DAG和任务事件。我们还学习了Airflow的三种指标类型：计数器、测量器和计时器。最后，Airflow建议通过StatsD将生产部署的指标发送给Prometheus进行分析。掌握这些监控手段，能帮助你更好地维护数据管道的稳定运行。

018：分布式事件流平台组件

在本节课中，我们将要学习分布式事件流平台的核心概念与组件。我们将了解什么是事件、常见的事件格式，以及事件流平台的作用和主要构成部分。课程内容旨在为初学者提供一个清晰、直观的理解框架。

🎯 什么是事件？

在事件流处理的上下文中，事件 指的是一种特殊类型的数据，它描述了实体随时间推移发生的、值得关注的状态更新。

例如：

  • 一辆移动汽车的GPS坐标。
  • 一个房间的温度。
  • 一位病人的血压测量值。
  • 一个运行中应用程序的RAM使用情况。

📝 事件的常见格式

事件作为特殊的数据类型，具有不同的格式。以下是三种最常见的格式：

  1. 基本类型：事件可以是一个基本数据类型，例如纯文本、数字或日期。

    • 示例：42， "error"， 2023-10-27

  2. 键值对格式：事件可以是键值对格式。其值可以是基本数据类型，也可以是复杂数据类型（如列表、元组、JSON、XML甚至字节）。

    • 示例：{"car_id": 1, "coordinates": (39.9042, 116.4074)}

  3. 带时间戳的键值对：事件通常还会关联一个时间戳，使其具有时间敏感性。

    • 示例：{"sensor_id": "temp_01", "value": 22.5, "timestamp": "2023-10-27T10:30:00Z"}

🌊 什么是事件流？

假设我们有一个事件源（例如一组传感器、监控设备、数据库或运行中的应用程序）。这个事件源可能会在短时间内隔或近乎实时地持续产生大量事件。

这些实时事件需要被恰当地传输到一个事件目的地（例如文件系统、另一个外部数据库或应用程序）。事件源和事件目的地之间这种持续的事件传输过程，就称为事件流。

🏗️ 为什么需要事件流平台？

根据我们目前所学的ETL知识，你可能会认为在单一事件源和单一目的地之间实现这样的ETL过程是直接的。

然而，如果我们有多个不同的事件源和目的地呢？在现实场景中，事件流可能非常复杂，涉及多个分布式的事件源和目的地。因为数据传输管道可能基于不同的通信协议，例如FTP、HTTP、JDBC、SCP等。

此外，一个事件目的地也可以同时是另一个事件源。例如，一个应用程序可以接收事件流并进行处理，然后将处理结果作为新的事件流传输给另一个目的地。

为了克服处理不同事件源和目的地的挑战，我们需要使用事件流平台。

ESP在各种事件源和目的地之间充当中间层，为基于事件的ETL处理提供统一接口。这样一来，所有事件源只需将事件发送给ESP，而无需分别发送给每个事件目的地。另一方面，事件目的地只需订阅ESP，并消费来自ESP的事件，而无需对接每个单独的事件源。

⚙️ 事件流平台的主要组件

不同的ESP可能有不同的架构和组件。这里我们介绍大多数ESP系统中包含的一些常见组件。

以下是ESP的主要组件：

  1. 事件代理：这是ESP的核心组件，设计用于接收和消费事件。我们将在下一部分详细解释。
  2. 事件存储：用于存储从事件源接收的事件。据此，事件目的地无需与事件源同步，存储的事件可以随时被检索。
  3. 分析与查询引擎：用于查询和分析存储的事件。

🔧 深入理解事件代理

事件代理是ESP的核心组件。它通常包含三个子组件：摄取器、处理器和分发器。

  • 摄取器：设计用于高效地从各种事件源接收事件。
  • 处理器：对数据执行操作，例如序列化与反序列化、压缩与解压缩、加密与解密等。
  • 分发器：从事件存储中检索事件，并高效地分发给已订阅的事件目的地。

🌍 流行的事件流平台

市场上有许多ESP解决方案，每种都有其独特的功能和应用场景。

流行的ESP包括：

  • Apache Kafka（可能是最流行的开源ESP）
  • Amazon Kinesis
  • Apache Flink
  • Apache Spark
  • Apache Storm
  • 其他，如Elastic Stack中的Logstash等。

📖 课程总结

本节课中，我们一起学习了分布式事件流平台的基础知识。

我们了解到：

  • 事件流代表了实体状态随时间的变化。
  • 常见的事件格式包括基本数据类型、键值对以及带时间戳的键值对。
  • 当存在多个事件源和目的地时，尤其需要ESP。
  • ESP的主要组件包括事件代理、事件存储、以及分析与查询引擎。
  • Apache Kafka是最流行的开源ESP之一。
  • 其他流行的ESP还包括Amazon Kinesis、Apache Flink、Apache Spark、Apache Storm等。

通过掌握这些核心概念和组件，你为理解和构建高效、可扩展的实时数据管道奠定了坚实的基础。

019：使用Shell、Airflow和Kafka的ETL和数据管道 🚀

第19课：Apache Kafka 概述 📡

在本节课中，我们将要学习Apache Kafka，一个流行的事件流平台。我们将了解其架构、常见用例、主要特性与优势，以及一些基于Kafka的商业服务提供商。

什么是Apache Kafka？

上一节我们介绍了事件流平台及其核心组件。你可能认为从头实现一个事件流平台极其困难，这确实如此。但幸运的是，我们已经有许多优秀的开源和商业ESP解决方案可用，它们内置了许多功能。其中，Apache Kafka这个开源项目可能是最流行的事件流平台。

Kafka的常见用例

Kafka是一个综合性平台，可用于多种应用场景。以下是其一些常见用例：

  • 用户活动追踪：Kafka最初用于追踪用户活动，例如键盘敲击、鼠标点击、页面浏览、搜索、手势、屏幕使用时间等。
  • 指标流处理：现在它也适用于各种指标流处理，例如传感器读数、GPS数据，以及针对企业应用和基础设施的软硬件监控。
  • 日志集成：对于拥有海量日志的系统，Kafka可用于收集日志并将其整合到集中式存储库中。
  • 金融交易：对于银行、保险或金融科技公司，Kafka也广泛用于支付和交易处理。

这些场景只是冰山一角。基本上，当你需要在各种事件源和目标之间进行高吞吐量、可靠的数据传输服务时，都可以使用Kafka。所有事件都将被摄取到Kafka中，并可供订阅和消费，用途包括：

  • 进一步的数据存储，以及移动到其他在线和离线数据库及备份。
  • 实时处理和分析，包括仪表板、机器学习、AI算法等。
  • 生成通知，例如电子邮件、短信和即时消息。
  • 数据治理和审计，以确保银行交易等敏感数据符合法规要求。

Kafka的架构

Kafka采用分布式客户端-服务器架构。

  • 服务器端：Kafka是一个集群，包含许多称为Broker的关联服务器，它们充当事件代理，负责接收、存储和分发事件。所有这些Broker由另一个称为Zookeeper的分布式系统管理，以确保所有Broker高效协同工作。
  • 通信协议：Kafka使用基于TCP的网络通信协议在客户端和服务器之间交换数据。
  • 客户端：Kafka提供不同类型的客户端，例如：
    • Kafka CLI：一组用于与Kafka服务器通信的Shell脚本。
    • 许多高级编程API，如Java、Scala、REST API。
    • 由Kafka社区制作的一些特定第三方客户端。

你可以根据需求选择不同的客户端。

Kafka的主要特性与优势

现在你对Kafka有了基本了解，让我们看看为什么Apache Kafka能成为如此流行的ESP。Kafka具有以下主要特性：

  • 分布式与高可扩展性：它是一个分布式系统，使其能够高度扩展以处理高数据吞吐量和并发。一个Kafka集群通常有多个事件代理，可以并行处理事件流，因此Kafka非常快速且高度可扩展。
  • 高容错性与可靠性：Kafka还将事件存储划分为多个分区和副本，这使其具有容错能力且高度可靠。
  • 持久化存储：Kafka永久存储事件，因此消费者可以在任何合适的时间进行事件消费，没有截止时间限制。
  • 开源：Kafka是开源的，意味着你可以免费使用它，甚至可以根据特定需求进行定制。

基于Kafka的ESP服务提供商

尽管Kafka是开源且文档完善，但在没有专业协助的情况下配置和部署Kafka仍然具有挑战性。部署Kafka集群需要投入大量精力来调整基础设施并持续调整配置，尤其是对于企业级部署。

幸运的是，有几家商业服务提供商提供ESP即服务来满足你的流处理需求。其中许多都建立在Kafka之上，并为客户提供附加价值。一些知名的ESP提供商包括：

  • Confluent Cloud：为客户提供完全托管的Kafka服务，可以在本地或云端部署。
  • IBM Event Streams：同样基于Kafka，并提供许多附加服务，例如企业级安全性、灾难恢复和7x24小时集群监控。
  • Amazon Managed Streaming for Apache Kafka：也是一个完全托管的服务，旨在简化Kafka的构建和部署。

总结

本节课中我们一起学习了Apache Kafka。我们了解到Apache Kafka是最流行的开源ESP之一。其常见用例包括用户活动追踪、指标和日志集成以及金融交易处理。Apache Kafka是一个高度可扩展且可靠的平台，能够永久存储事件。最后，流行的基于Kafka的ESP服务提供商包括Confluent Cloud、IBM Event Streams和Amazon Managed Streaming。

020：使用Kafka构建事件流处理管道 🚀

在本节课中，我们将学习如何使用Apache Kafka构建事件流处理管道。我们将了解Kafka的核心组件，学习如何发布和订阅事件流，并探讨一个端到端的事件流处理管道示例。

概述 📋

Kafka是一个分布式流处理平台，用于构建实时数据管道和流应用程序。它能够以高吞吐量、低延迟的方式处理数据流。本节课程将介绍Kafka的基本概念和操作。

Kafka核心组件 🏗️

Kafka集群包含一个或多个Broker。你可以将Kafka Broker视为一个专用服务器，用于接收、存储、处理和分发事件。Broker由另一个名为Zookeeper的专用服务器进行同步和管理。

例如，在Broker 0中可能有一个日志主题和一个交易主题；在Broker 1中有一个支付主题和一个GPS主题；在Broker 2中有一个用户点击主题和一个用户搜索主题。每个Broker包含一个或多个主题。你可以将主题视为一个数据库，用于存储特定类型的事件，例如日志、交易和指标。

Broker负责将发布的事件保存到主题中，并将事件分发给订阅的消费者。

分区与复制 🔄

与许多其他分布式系统一样，Kafka实现了分区和复制的概念。它使用主题分区和副本来提高容错能力和吞吐量，从而使事件发布和消费可以并行进行，并利用多个Broker。

此外，即使某些Broker宕机，Kafka客户端仍然能够与其他正常工作的Broker中复制的目标主题进行交互。

例如，一个日志主题被分成两个分区（0和1），一个用户主题也被分成两个分区（0和1）。每个主题分区被复制成两个副本，并存储在不同的Broker中。

Kafka命令行界面（CLI） 💻

Kafka CLI或命令行界面客户端提供了一系列强大的脚本文件，供用户构建事件流处理管道。kafka-topics脚本可能是你经常用来管理Kafka集群中主题的工具，它的使用非常直接。

以下是kafka-topics脚本的一些常见用法：

  • 创建主题：使用--create选项。例如，创建一个名为log_topic、具有两个分区和两个副本的主题。请注意，许多Kafka命令（如kafka-topics）要求用户通过主机和端口（例如localhost:9092）来指定一个正在运行的Kafka集群。
  • 列出主题：创建一些主题后，可以使用--list选项检查集群中所有已创建的主题。
  • 查看主题详情：如果你想查看主题的更多详细信息，例如分区和副本信息，可以使用--describe选项。
  • 删除主题：可以使用--delete选项删除一个主题。

接下来，我们将了解如何使用Kafka生产者发布事件。

Kafka生产者 📤

Kafka生产者是客户端应用程序，它们将事件发布到主题分区中。事件按照发布的顺序存储。

在Kafka生产者中发布事件时，可以选择性地为事件关联一个键。具有相同键的事件将被发布到同一个主题分区。未关联任何键的事件将以轮询方式发布到各个主题分区。

让我们通过一个例子看看如何将事件发布到主题分区。

假设你有一个事件源1，它生成各种日志条目；还有一个事件源2，它生成用户活动跟踪记录。

你可以创建一个Kafka生产者，将日志记录发布到日志主题分区；再创建一个用户生产者，将用户活动事件发布到用户主题分区。在生产者中发布事件时，可以选择为事件关联一个键，例如应用程序名称或用户ID。

与kafka-topics CLI类似，Kafka提供了kafka-console-producer CLI供用户管理生产者。最重要的方面是启动一个生产者，将事件写入或发布到一个主题。

例如，你可以启动一个生产者并将其指向log_topic，然后在控制台中输入一些消息来开始发布事件，例如log1、log2和log3。你可以为事件提供键，以确保具有相同键的事件进入同一个分区。

例如，你可以启动一个生产者到user_topic，并将--parse-key选项设置为true，同时指定键分隔符为逗号。然后，你可以按以下格式写入消息：key,user1 value,login website、key,user1 value,click the top item和key,user1 value,logout website。

这样，所有关于user1的事件都将保存在同一个分区中，以方便消费者读取。

Kafka消费者 📥

一旦事件被发布并正确存储在主题分区中，你就可以创建消费者来读取它们。消费者是客户端应用程序，可以订阅主题并读取存储的事件。然后，事件目的地可以进一步从Kafka消费者读取事件。

消费者按照事件发布的相同顺序从主题分区读取数据。消费者还会存储每个主题分区的偏移量，作为最后读取的位置。通过偏移量，可以保证消费者读取到实时发生的事件。

通过将偏移量重置为零，也可以实现回放。这样，消费者可以从头开始读取主题分区中的所有事件。

在Kafka中，生产者和消费者是完全解耦的。因此，生产者不需要与消费者同步。事件存储在主题中后，消费者可以按照独立的计划来消费它们。

为了从主题分区读取已发布的日志和用户事件，你需要创建日志和用户消费者，并让它们订阅相应的主题。然后，Kafka会将事件推送给那些订阅的消费者，消费者再进一步发送给事件目的地。

使用kafka-console-consumer脚本启动消费者也很简单。例如，从log_topic读取事件，你只需要运行kafka-console-consumer脚本，并指定一个Kafka集群和要订阅的主题。启动的消费者将只读取从上次分区偏移量之后的新事件。这些事件被消费后，消费者的分区偏移量也会被更新并提交回Kafka。

通常，用户希望从头开始读取所有事件，作为所有历史事件的回放。为此，你只需要添加--from-beginning选项。现在，你可以从偏移量零开始读取所有事件。

端到端事件流处理管道示例 🌐

让我们看一个更具体的例子，帮助你理解如何构建一个端到端的事件流处理管道。

假设你想要收集和分析天气和Twitter事件流，以便将人们在Twitter上谈论极端天气的情况关联起来。你可以使用两个事件源：

  1. IBM Weather API：获取实时和预测的天气数据（JSON格式）。
  2. Twitter API：获取实时推文和提及（同样是JSON格式）。

为了在Kafka中接收天气和Twitter的JSON数据，你需要在Kafka集群中创建一个天气主题和一个Twitter主题，并设置一些分区和副本。

为了将天气和Twitter JSON数据发布到这两个主题，你需要创建一个天气生产者和一个Twitter生产者。事件的JSON数据将被序列化为字节并保存在Kafka主题中。

为了从这两个主题读取事件，你需要创建一个天气消费者和一个Twitter消费者。存储在Kafka主题中的字节将被反序列化为事件的JSON数据。

如果你现在想将天气和Twitter事件的JSON数据从消费者传输到关系型数据库，你可以使用一个数据库写入器来解析这些JSON文件并创建数据库记录，然后使用SQL INSERT语句将这些记录写入数据库。

最后，你可以从关系型数据库中查询这些记录，并在仪表板中可视化和分析它们，从而完成端到端的管道。

总结 🎯

在本节课中，我们一起学习了：

  • Kafka的核心组件：
    • Broker：接收、存储、处理和分发事件的专用服务器。
    • Topic：事件的容器或数据库。
    • Partition：将主题划分到不同Broker中。
    • Replication：将分区复制到不同Broker中。
    • Producer：将事件发布到主题中的Kafka客户端应用程序。
    • Consumer：订阅主题并从其中读取事件的Kafka客户端应用程序。
  • 我们还学习了：
    • kafka-topics CLI用于管理主题。
    • kafka-console-producer CLI用于管理生产者。
    • kafka-console-consumer CLI用于管理消费者。

通过掌握这些核心概念和工具，你已经具备了使用Kafka构建基本事件流处理管道的基础知识。

021：Kafka流处理流程

在本节课中，我们将学习Kafka流处理的核心概念。我们将了解什么是Kafka Streams API及其主要优势，并深入探讨Kafka流处理拓扑结构。通过一个天气数据处理的实际例子，我们将对比传统特设处理器与使用Kafka Streams API的差异，从而理解其如何简化流处理应用的开发。

事件流处理概述

在事件流处理中，数据工程师不仅需要传输数据，还需要对数据进行处理。处理方式包括数据过滤、聚合和增强。任何为处理数据流而开发的应用程序都被称为流处理应用程序。

特设流处理应用

对于基于Kafka的流处理应用，一种直接的方法是实现一个特设的数据处理器。这个处理器从一个主题读取事件，进行处理，然后将结果发布到另一个主题。

以下是构建此类应用的一个步骤示例：

  1. 首先，从一个天气API请求原始的JSON数据。
  2. 启动一个天气生产者，将原始数据发布到一个原始天气主题。
  3. 启动一个消费者，从原始天气主题读取数据。
  4. 创建一个特设数据处理器，过滤原始天气数据，仅包含极端天气事件（例如极高温度）。这个处理器可以是一个简单的脚本文件或一个使用Kafka客户端读写数据的应用程序。
  5. 处理器将处理后的数据发送给另一个生产者。
  6. 生产者将数据发布到一个已处理的天气主题。
  7. 最后，处理后的天气数据由一个专门的消费者消费，并发送到仪表板进行可视化。

然而，如果需要处理许多不同的主题，这种特设处理器可能会变得非常复杂。Kafka提供了一个解决方案来应对这些挑战：Streams API。

Kafka Streams API简介

Kafka Streams API是一个简单的客户端库，旨在简化事件流管道中的数据处
理。它处理和分析存储在Kafka主题中的数据，因此其输入和输出都是Kafka主题。

该API的核心特性包括：

  • 确保每条记录只被处理一次。
  • 一次只处理一条记录。

流处理拓扑

Kafka Streams API基于一个称为流处理拓扑的计算图。在这个拓扑中：

  • 每个节点都是一个流处理器。
  • 每个流处理器从其上游处理器接收流，执行数据转换（如映射、过滤、格式化和聚合），并将输出流生成到其下游流处理器。
  • 因此，图的边就是输入/输出流。

在拓扑中有两种特殊类型的处理器：

  1. 源处理器：没有上游处理器。它类似于一个消费者，从Kafka主题消费流，并将处理后的流转发给其下游处理器。
  2. 接收器处理器：没有下游处理器。它类似于一个生产者，将接收到的流发布到Kafka主题。

使用Kafka Streams API重构应用

现在，让我们使用Kafka Streams API重新设计之前的天气流处理应用。假设Kafka中有一个原始天气主题和一个已处理的天气主题。

此时，无需花费大量精力开发特设处理器，只需在此处接入Kafka Streams API即可。

在Kafka流处理拓扑中，我们设计了三个流处理器：

  1. 源处理器：从原始天气主题消费原始天气流，并将天气流转发给流处理器。
  2. 流处理器：根据高温条件过滤流。
  3. 接收器处理器：接收过滤后的流，并将输出发布到已处理的天气主题。

与特设数据处理器相比，这是一个更简洁的设计，尤其是在需要处理多个不同主题时。

课程总结

本节课我们一起学习了以下内容：

  • Kafka Streams API是一个简单的客户端库，可帮助数据工程师在事件流管道中进行数据处理。
  • 流处理器接收、转换和转发数据流。
  • Kafka Streams API基于一个称为流处理拓扑的计算图。
  • 在拓扑中，每个节点是一个流处理器，边是输入/输出流。
  • 拓扑中有两种特殊类型的处理器：源处理器和接收器处理器。
posted @ 2026-03-26 08:50  布客飞龙II  阅读(0)  评论(0)    收藏  举报