Kubernetes 上的大数据——现代数据栈

在本章中，我们将探讨用于构建可扩展和灵活的数据平台的现代数据架构。具体来说，我们将讨论Lambda架构模式及其如何实现实时数据处理和批量数据分析。您将了解Lambda架构的关键组件，包括用于历史数据的批处理层、用于实时数据的速度处理层以及用于统一查询的服务层。我们将讨论如何使用Apache Spark、Apache Kafka和Apache Airflow等技术在大规模上实现这些层。

到本章结束时，您将理解构建现代数据湖的核心设计原则和技术选择。您将能够解释Lambda架构相对于传统数据仓库设计的优势。最重要的是，您将具备开始构建自己的现代数据平台的概念基础。

所涵盖的概念将使您能够在低延迟下处理流数据，同时也能对历史数据执行复杂的分析工作负载。您将获得利用开源大数据技术构建可扩展和灵活的数据管道的实用知识。无论您需要实时分析、机器学习模型训练还是临时分析，现代数据堆栈模式都能使您满足多样化的数据需求。

本章提供了从传统数据仓库过渡到下一代数据湖的蓝图。课程将装备您掌握构建现代数据平台所需的关键架构原则、组件和技术，这些平台基于Kubernetes。

在本章中，我们将讨论以下主要主题：

• 数据架构
• 面向大数据的数据湖设计
• 实施湖仓架构

数据架构

现代数据架构在过去十年中显著发展，使组织能够利用大数据的力量推动高级分析。出现了两种关键的架构模式：Lambda架构和Kappa架构。在本节中，我们将看看这两种架构，并了解它们如何为构建大数据环境提供有用的框架。

Lambda架构

Lambda架构是一种大数据处理架构模式，平衡了批处理和实时处理方法。其名称来源于Lambda演算模型。Lambda架构在2010年代初期变得流行，作为一种以经济有效和灵活的方式处理大量数据的方法。

Lambda架构的核心组件包括以下几个部分：

• 批处理层：负责管理主数据集。该层以固定的时间间隔（通常是每24小时）批量摄取和处理数据。处理完成后，批处理视图被视为不可变并存储起来。
• 实时处理层：负责处理尚未被批处理层处理的最新数据。该层在数据到达时实时处理数据，以提供低延迟的视图。
• 服务层：通过合并来自批处理层和实时处理层的视图来响应查询。

这些组件在架构图中如图4.1所示：

Lambda架构的主要优势在于它提供了一种混合方法，结合了大数据量的历史视图（批处理层）和最新数据的实时视图（实时处理层）。这使得分析人员能够统一地查询最新和历史数据，从而快速获得洞察。

批处理层优化了吞吐量和效率，而实时处理层则优化了低延迟。通过分离这些职责，该架构避免了每次查询都必须运行大规模、长时间的批处理作业。相反，查询可以利用预计算的批处理视图，并通过来自实时处理层的最新数据进行补充。

在基于云基础设施的现代数据湖中，Lambda架构提供了一个灵活的蓝图。云存储层作为数据湖的基础层，数据在此落地。批处理层利用分布式数据处理引擎（如Apache Spark）来生成批处理视图。实时处理层流式传输和处理最新数据，服务层运行高性能的查询引擎（如Trino）来分析数据。

Kappa架构

Kappa架构是由Lambda架构的主要创造者提出的一种替代方法。Kappa架构的主要区别在于它旨在通过消除独立的批处理层和实时处理层来简化Lambda模型。

相反，Kappa架构通过单一的流处理路径处理所有数据。其关键组件包括以下几个部分：

• 流处理层：负责以流的形式摄取和处理所有数据。该层处理历史数据（通过日志/文件的重放）以及新进数据。
• 服务层：通过访问流处理层生成的视图来响应查询。

图4.2中展示了这一架构的视觉表示：

Kappa架构的核心是使用Kafka和事件源模式等工具创建的不可变、仅追加的日志。流数据直接摄入日志，而不是通过独立的管道。该日志确保了数据的有序性、防篡改性和自动重放能力，这些都是流处理和批处理的关键支持因素。

Kappa架构的优点在于其设计的简洁性。通过单一的处理路径，无需管理独立的批处理和实时系统。所有数据都通过流处理来处理，这也使得灵活的历史数据重处理和分析成为可能。

其权衡点在于流处理引擎可能无法提供与最先进的批处理引擎相同的规模和吞吐量（尽管现代流处理器不断进化以处理非常大的工作负载）。此外，尽管Kappa设计可能更简单，但其架构本身比Lambda更难实现和维护。

对于数据湖，Kappa架构与大量数据落地的性质非常契合。云存储层作为原始数据的骨干。然后，流处理器如Apache Kafka和Apache Flink摄取、处理并生成分析就绪的视图。服务层利用Elasticsearch和MongoDB等技术来支持分析和仪表盘。

Lambda与Kappa的比较

Lambda和Kappa架构采用不同的方法，但解决了类似的需求，即准备、处理和分析大型数据集。关键区别列在表4.1中：

特性	Lambda	Kappa
复杂性	管理独立的批处理和实时系统	通过流处理整合
重处理	重处理历史批次	依赖流重放和算法
延迟	在实时处理层对最近数据具有较低延迟	所有数据具有相同延迟
吞吐量	利用为吞吐量优化的批处理引擎	将所有数据作为流处理

表4.1 - Lambda和Kappa架构的主要区别

在实践中，现代数据架构通常混合使用这些方法。例如，Lambda的批处理层可能只运行每周或每月一次，而实时流则填补了这一空缺。Kappa可能在其流中利用小批量来优化吞吐量。围绕平衡延迟、吞吐量和重处理的核心思想是共享的。

对于数据湖，Lambda提供了一个经过验证的蓝图，而Kappa则提供了一个强大的替代方案。虽然有人认为Kappa提供了更简单的操作，但其实现难度大且成本可能随着规模的增加而迅速增长。Lambda的另一个优势在于其完全适应性。如果不需要（或在经济上不可行）数据流处理，我们可以只实现批处理层。

数据湖构建者应了解每种架构的关键原则，以设计与其业务、分析和运营需求相匹配的最佳架构。通过利用云基础设施的规模和灵活性，现代数据湖可以实施这些模式来处理当今的数据量并推动高级分析。

在下一节中，我们将深入探讨Lambda架构方法及其如何应用于创建高性能、可扩展的数据湖。

大数据的数据湖设计

在本节中，我们将对比数据湖与传统数据仓库，并讨论核心设计模式。这将为最后“如何操作”部分中的实操工具和实现内容打下基础。让我们从现代数据架构的基础——数据仓库开始。

数据仓库

几十年来，数据仓库一直是商业智能和分析的支柱。数据仓库是一个集成多个来源的数据仓库，专门用于报告和分析。

传统数据仓库架构的关键方面如下：

• 结构化数据：数据仓库通常只存储结构化数据，如来自数据库和CRM系统的交易数据。不包括文档、图像、社交媒体等非结构化数据。
• 写时模式：在数据仓库设计期间预先定义数据结构和模式。这意味着添加新的数据源和改变业务需求可能会很困难。
• 批处理：数据按照计划从源系统中提取、转换和加载（ETL），通常是每天或每周一次。这会在访问最新数据时引入延迟。
• 独立于源系统：数据仓库作为独立的数据存储进行优化分析，与源事务系统无关。

在大数据时代，数据量、种类和速度的增长暴露了传统数据仓库架构的一些局限性。

它无法以成本效益的方式存储和处理来自新来源（如网站、移动应用、物联网设备和社交媒体）的巨大非结构化和半结构化数据量。此外，它缺乏灵活性——添加新的数据源需要更改模式和ETL，这使得适应变得缓慢且昂贵。最后，批处理无法为实时个性化和欺诈检测等新兴需求提供足够快的洞察力。

这催生了数据湖架构，我们将在下一节详细介绍。

大数据和数据湖的兴起

为了应对上述挑战，新的数据湖方法使得能够以规模处理任何类型的大数据存储，使用经济实惠的分布式存储如Hadoop HDFS或云对象存储。数据湖采用读时模式，而不是预先模式。数据以原生格式存储，只有在读取时解释模式。它包括通过Apache Kafka等工具捕获、存储和访问实时流数据。还有一个用于可扩展处理的大型开源生态系统，包括MapReduce、Spark等工具。

数据湖是一个集中的数据存储库，旨在按原样存储数据。这提供了按需分析不同类型数据的灵活性（表格、图像、文本、视频等），而不需要预先确定如何使用它。因为它是基于对象存储实现的，可以存储来自任何地方的大量数据，并以不同的时间间隔到达（有些数据可以每天到达，有些每小时到达，有些接近实时）。数据湖还将存储和处理技术分开（不同于数据仓库，存储和处理发生在一个唯一的结构中）。通常，数据处理涉及一个分布式计算引擎（如Spark）来处理TB级数据。

数据湖提供了一种成本效益地存储组织处理的巨大和多样化数据量并执行分析的方法。然而，它们也面临一些挑战：

• 没有治理，数据湖有变成无法访问的数据沼泽的风险。数据需要加上上下文进行目录化，以便于发现。
• 准备原始数据进行分析仍然涉及跨不同孤立工具的复杂数据整理。
• 大多数分析仍然需要先对数据进行建模、清理和转换——如同数据仓库。这会重复工作。
• 数据湖中使用的基于对象的存储系统不允许执行行级修改。当需要修改表中的一行时，整个文件将被重写，对处理性能产生巨大影响。
• 数据湖中没有高效的模式控制。虽然读时模式使得新的数据源更容易，但不能保证表不会因失败的摄取而改变结构。

近年来，已经进行了重大努力以克服这些新挑战，通过结合两者的最佳特性，这被称为数据湖仓（data lakehouse）。让我们深入探讨这个概念。

数据湖仓的兴起

在2010年代，由于Delta Lake、Apache Hudi和Apache Iceberg等新开源技术的出现，术语“湖仓”引起了人们的关注。湖仓架构旨在结合数据仓库和数据湖的最佳方面：

• 像数据湖一样支持任何规模的多种结构化和非结构化数据
• 提供对原始和精炼数据的高性能SQL分析，类似于数据仓库
• 在大数据集上进行ACID（原子性、一致性、隔离性和持久性）事务

数据湖仓允许同时在开放格式中存储、更新和查询数据，同时确保大规模的正确性和可靠性。这使得以下功能成为可能：

• 模式 enforcement、演进和管理
• 行级 upserts（更新+插入）和删除，实现高性能可变性
• 跨历史数据的时间点一致性视图

使用湖仓架构，整个分析生命周期，从原始数据到清理和建模数据再到精心策划的数据产品，对于批处理和实时用例来说都可以在一个地方直接访问。这驱动了更大的敏捷性，减少了重复工作，并通过生命周期内的数据重用和重新利用实现了更容易的操作。

接下来，我们将了解在这种架构概念中数据的结构。

湖仓存储层

像数据湖架构一样，湖仓也是建立在云对象存储上的，通常分为三个主要层次：铜层、银层和金层。这种方法被称为“奖章”设计。

• 铜层是原始摄取数据层。它包含来自各种来源的原始数据，完全按照接收到的方式存储。数据格式可以是结构化、半结构化或非结构化的。例如，日志文件、CSV文件、JSON文档、图像、音频文件等。该层的目的是以最完整和原始的格式存储数据，作为分析目的的真实版本。在此层不会进行任何转换或汇总。它作为构建更高层次的精心策划和汇总数据集的来源。
• 银层包含精心策划的、精炼的和标准化的数据集，这些数据集经过丰富、清理、集成和符合业务标准。数据具有一致的模式，可以用于分析。该层的目的是准备高质量的、可供分析的数据集，以便下游的分析和机器学习模型使用。这包括数据整理、标准化、去重、连接不同数据源等。结构可以是表格、视图或优化查询的文件。例如，Parquet、Delta Lake表、物化视图等。添加元数据以启用数据发现。
• 金层包含汇总数据模型、指标、KPI和其他派生数据集，这些数据集支持商业智能和分析仪表板。该层的目的是为业务用户提供即用的精心策划的数据模型，用于报告和可视化。这涉及预先计算指标、汇总、业务逻辑等，以优化分析工作负载。结构通过列式存储、索引、分区等来优化分析。例如，聚合、立方体、仪表板和机器学习模型。元数据将其与上游数据联系起来。

有时，常见的做法是在铜层之前有一个额外的层——着陆区。在这种情况下，着陆区接收原始数据，所有的清理和结构化工作在铜层中进行。

在下一节中，我们将看到如何使用现代数据工程工具将数据湖仓设计付诸实践。

实现湖仓架构

图4.3展示了在Lambda设计中实现数据湖仓架构的可能方案。图中展示了常见的湖仓层及在Kubernetes上实现这些层所使用的技术。左侧的第一组代表了可能与此架构配合的数据源之一。这种方法的一个关键优势是其能够从各种来源和多种格式摄取和存储数据。正如图中所示，数据湖可以连接并集成来自数据库的结构化数据以及API响应、图像、视频、XML和文本文件等非结构化数据。这种读时模式使原始数据能够快速加载而无需预先建模，使架构高度可扩展。当需要分析时，湖仓层能够通过查询模式在一个地方查询所有这些数据集。这使得从不同来源集成数据以获得新见解变得更加简单。加载与分析的分离还使得随着对数据的新理解的出现能够进行迭代分析。总体而言，现代数据湖仓优化了快速落地多结构和多来源的数据，同时也赋予用户灵活分析数据的能力。

首先，我们将深入了解图4.3顶部所示的批处理层。

批量摄取

设计的第一层是指批量摄取过程。对于所有非结构化数据，自定义Python过程是首选方法。可以开发自定义代码从API端点查询数据、读取XML结构以及处理文本和图像。对于数据库中的结构化数据，我们有两种摄取数据的选择。首先，Kafka和Kafka Connect提供了一种简单配置数据迁移作业并连接大量数据库的方法。Apache Kafka是一个分布式流平台，允许发布和订阅记录流。Kafka的核心是一个基于发布-订阅模型的持久消息代理。Kafka Connect是Kafka自带的一个工具，提供了一种将数据移入和移出Kafka的通用方法。它提供了可重复使用的连接器，可以帮助将Kafka主题连接到外部系统，如数据库、键值存储、搜索索引和文件系统。Kafka Connect具有许多常见数据源和接收器的连接器插件，如JDBC、MongoDB、Elasticsearch等。这些连接器将数据从外部系统移动到Kafka主题，反之亦然。

这些连接器是可重复使用和可配置的。例如，JDBC连接器可以配置为从PostgreSQL数据库捕获更改并将其写入Kafka主题。Kafka Connect处理数据格式转换、分布式协调、容错等，并通过跟踪源连接器（例如，数据库变更数据捕获（CDC）连接器）中的数据变化并将变化流传输到Kafka主题，支持流处理。这简化了将数据移入和移出Kafka的过程。尽管Kafka是流数据的知名工具，但其与Kafka Connect一起使用在从数据库进行批量数据迁移方面也证明了极高的效率。

有时，当管理Kafka集群进行数据迁移不可行时（我们稍后会讨论一些这种情况），可以使用Apache Spark从结构化来源摄取数据。Apache Spark为将各种结构化数据源的数据摄取到基于云对象存储（如Amazon S3或Azure Data Lake Storage）的数据湖提供了一个多功能工具。Spark DataFrame API允许从关系数据库、NoSQL数据存储和其他结构化数据源查询数据。尽管方便，但在Spark中从JDBC数据源读取数据可能效率不高。Spark会将表读取为单个分区，因此所有处理将在单个任务中进行。对于大表，这可能会减慢摄取和后续查询（更多细节见第5章）。为了优化，我们需要手动分区读取源数据库的数据。Spark数据摄取的主要缺点是需要自己处理这些分区和优化问题。其他工具可以通过管理并行摄取作业来帮助，但Spark提供了开箱即用地连接和处理许多数据源的灵活性。

现在，让我们来看看存储层。

存储

接下来，在图的中间部分是存储层。这是唯一一个我不建议迁移到Kubernetes的层。基于云的对象存储服务现在具有许多优化可扩展性和可靠性的功能，使操作变得简单且具有良好的检索性能。尽管有一些很好的工具可以在Kubernetes中构建数据湖存储层（例如，min.io/），但不值得付出努力，因为你需要自己负责可扩展性和可靠性。为了本书的目的，我们将在Kubernetes中处理所有湖仓层，除了存储层。

批处理

现在，我们将讨论批处理层。Apache Spark已成为大数据生态系统中大规模批处理数据处理的事实标准。与传统的MapReduce作业将中间数据写入磁盘不同，Spark在内存中处理数据，使其在迭代算法和交互数据分析方面速度更快。Spark利用集群管理器来协调一组工作节点上的作业执行。这使得它可以通过将数据分布到集群中并并行化处理来处理非常大的数据集。Spark可以高效地处理存储在分布式文件系统（如HDFS）和云对象存储中的TB级数据。

Spark的一个关键优势是它为SQL和复杂分析提供的统一API。数据工程师和科学家可以使用Python DataFrame API处理和分析批处理数据集。然后，可以通过Spark SQL查询相同的DataFrame，提供熟悉性和交互性。这使得Spark对于广泛的用户非常简单操作。通过利用内存处理和提供易于使用的API，Apache Spark已成为可扩展批处理数据分析的首选解决方案。拥有大量日志文件、传感器数据或其他记录的公司可以依赖Spark高效地并行处理这些庞大的数据集。这巩固了它在现代数据架构中的基础性地位。

接下来，我们将讨论编排层。

编排

在图4.3中，存储层和批处理层上方，我们可以看到一个编排层。随着我们构建出将多个处理步骤串联在一起的更复杂的数据管道，我们需要一种可靠地管理这些管道执行的方法。这就是编排框架的作用所在。在这里，我们选择使用Airflow。Airflow是一个开源的工作流编排平台，最初由Airbnb开发，用于编写、调度和监控数据管道。自那时起，它成为了数据管道中最流行的编排工具之一。

使用Airflow进行批处理数据管道的主要原因如下：

• 调度：Airflow允许你定期调度批处理作业（每小时、每天、每周等）。这消除了手动启动作业的需要，并确保它们可靠地运行。
• 依赖管理：作业通常需要按顺序运行或等待其他作业完成。Airflow提供了一种简单的方法在有向无环图（DAG）中设置这些依赖关系。
• 监控：Airflow有一个内置的仪表板来监控作业状态。你可以看到什么作业成功、失败、正在运行等。它还保留了日志和历史记录以供以后调试。
• 灵活性：可以通过修改DAG添加新的数据源、转换和输出，而不会影响其他不相关的作业。Airflow DAG提供了高可配置性。
• 抽象：Airflow DAG允许管道开发人员专注于业务逻辑，而不是应用程序编排。底层的Airflow平台处理工作流调度、状态监控等。

现在，让我们移到服务层。

批量服务

对于Kubernetes中的批量服务层，我们选择了Trino。Trino（前身为PrestoSQL）是一个开源的分布式SQL查询引擎，构建用于对各种数据源执行交互式分析查询。Trino可以用于运行高达PB规模的查询。使用Trino，你可以并行查询多个数据源。当向Trino提交SQL查询时，它会解析并计划创建分布式执行计划。然后，这个执行计划提交给工作节点，工作节点并行处理查询并将结果返回给协调节点。它支持ANSI SQL（最常见的SQL模式之一），并且可以连接到各种数据源，包括所有主要的基于云的对象存储服务。通过利用Trino，数据团队可以直接在他们的云数据湖上启用自助式SQL分析。这消除了仅为分析而进行的昂贵且缓慢的数据移动，同时仍然提供交互式响应时间。

接下来，我们将看看为数据可视化选择的工具。

数据可视化

对于数据可视化和分析，我们选择了Apache Superset。尽管市场上有许多出色的工具，但我们发现Superset易于部署、运行、使用和集成。Superset是一个开源数据探索和可视化应用程序，允许用户轻松构建交互式仪表板、图表和图形。Superset于2015年在Airbnb内部作为分析师和数据科学家的工具而诞生。随着Airbnb的使用和贡献增加，它决定在2016年将Superset开源并捐赠给Apache软件基金会。从那时起，Superset被许多其他公司采用，并拥有一个活跃的开源社区贡献其发展。它具有直观的图形界面，通过丰富的仪表板、图表和图形可视化和探索数据，支持许多复杂的可视化类型。它有一个SQL Lab编辑器，允许你对不同数据库编写SQL查询并可视化结果。它提供了安全访问和角色管理，允许对数据访问和修改进行细粒度控制。它可以连接到多种数据源，包括关系数据库、数据仓库和SQL引擎如Trino。Superset可以使用提供的Helm图表方便地在Kubernetes上部署。Helm图表提供了所有必需的Kubernetes对象——部署、服务、入口等，以运行Superset。

凭借丰富的可视化能力、与各种数据源的工作灵活性以及Kubernetes的部署支持，Apache Superset是现代数据堆栈中有价值的补充。

现在，让我们移到图4.3底部的实时层。

实时摄取

在批量数据摄取中，数据定期以较大块或批量加载。例如，批处理作业可能每小时、每天或每周运行一次，从源系统加载新数据。另一方面，在实时数据摄取中，数据随着生成被连续流式传输到系统中。这实现了数据湖中真正的近实时数据流。实时数据摄取是事件驱动的——事件发生时生成数据并流入系统。这可能包括用户点击、物联网传感器读数、金融交易等。系统在事件到达时对其进行反应和处理。Apache Kafka是处理实时数据流的最流行的开源工具之一，它提供了一个可扩展的、容错的平台。可以使用Kafka Connect从数据库和其他结构化数据源流式传输数据，或使用用Python开发的自定义数据生产者。

在Kafka中实时摄取的数据通常也会“同步”到存储层以便进行历史分析和备份。我们不建议使用Kafka作为唯一的实时数据存储。相反，我们采用最佳实践，在定义的时间段后擦除数据以节省存储空间。默认的时间段是七天，但我们可以对其进行配置。尽管如此，实时数据处理不是在存储层之上完成的，而是直接从Kafka读取数据。接下来我们将看到的是实时处理。

实时处理

有多种用于实时数据处理的优秀工具：Apache Flink、Apache Storm和KSQLDB（Kafka家族的一部分）。尽管如此，我们选择使用Spark，因为其性能优越且易于使用。

Spark Structured Streaming是一个可以用于处理流数据的Spark模块。其关键理念是Structured Streaming从概念上将实时数据流转变为不断追加数据的表。其内部通过将实时流拆分为小批数据，这些数据然后由Spark SQL处理，就像处理表一样。

在实时流的数据被拆分为几毫秒的小批数据后，每个小批被视为追加到逻辑表的表。Spark SQL查询在批次到达时执行，以生成最终的结果流。这种微批架构提供了可扩展性，因为它可以利用Spark的分布式计算模型对数据批次进行并行化。可以添加更多机器以扩展到更大的数据量。微批方法还提供了容错保证。Structured Streaming使用检查点机制，定期快照计算状态。如果发生故障，流处理可以从最后一个检查点重新开始，而不是重新计算所有数据。

通常，Spark Structured Streaming查询直接从Kafka主题读取数据（使用必要的外部库），在内部处理并进行必要的计算，然后将其写入实时数据服务引擎。接下来是我们的实时服务层。

实时服务

为了在实时中服务数据，我们需要能够快速查询数据并以低延迟返回数据的技术。最常用的两种技术是MongoDB和Elasticsearch。

MongoDB是一种流行的开源、面向文档的NoSQL数据库。与传统关系数据库使用表和行不同，MongoDB以灵活的、类似JSON的文档存储数据，这些文档可以在结构上有所不同。MongoDB设计用于可扩展性、高可用性和性能。它使用高效的存储格式、索引优化和其他技术，提供低延迟的读写。文档模型和分布式能力使MongoDB能够非常高效地处理实时数据的读写。可以在数据积累时进行查询、数据聚合和分析。

Elasticsearch是一个基于Apache Lucene的开源搜索和分析引擎。它提供了一个分布式的、多租户的全文搜索引擎，具有HTTP web接口和无模式的JSON文档。Elasticsearch的一些关键功能和用例包括：

• 实时分析和洞察：Elasticsearch允许你实时分析和探索非结构化数据。当数据被摄取时，Elasticsearch会对数据进行索引，使其立即可搜索。这使得实时监控和分析数据流成为可能。
• 日志分析：Elasticsearch通常用于实时摄取、分析、可视化和监控各种来源的日志数据，如应用日志、网络日志、web服务器日志等。这使得实时监控和故障排除成为可能。
• 应用监控和性能分析：通过摄取和索引应用指标，Elasticsearch可以用于实时监控和分析应用性能。可以分析请求速率、响应时间、错误率等指标。
• 实时web分析：Elasticsearch可以实时摄取和处理网站流量的分析数据，启用自动建议、实时跟踪用户行为等功能。
• 物联网（IoT）和传感器数据：对于时间序列的物联网和传感器数据，Elasticsearch提供了聚合数据、异常检测等功能，可以实现物联网平台的实时监控和分析。

由于其低延迟和数据查询速度，Elasticsearch是实时数据消费的一个优秀工具。此外，Elastic家族还有Kibana，允许实时数据可视化，我们将接下来探讨。

实时数据可视化

Kibana是一个专门为Elasticsearch设计的开源数据可视化和探索工具。Kibana提供易于使用的仪表板和可视化，允许你探索和分析索引在Elasticsearch集群中的数据。Kibana直接连接到Elasticsearch集群，并索引集群的元数据，用于呈现关于数据的可视化和仪表板。它提供预构建和可定制的仪表板，允许通过直方图、折线图、饼图、热图等可视化探索数据。这些可视化使得理解趋势和模式变得容易。通过Kibana，用户可以创建和共享自己的仪表板和可视化，以满足特定的数据分析需求。它有专门的工具用于处理时间序列日志数据，使其非常适合监控IT基础设施、应用、物联网设备等，并允许强大的临时数据过滤，快速深入具体细节。

Kibana适用于实时数据的一个主要原因是Elasticsearch设计用于日志分析和全文搜索——这两者都需要快速和近实时的数据摄取和分析。随着数据流入Elasticsearch，Kibana可视化会实时更新以反映数据的当前状态。这使得基于实时数据流进行系统监控、检测异常、设置警报等成为可能。Elasticsearch的可扩展性与Kibana的交互式仪表板结合，为大规模系统中的实时数据可视化和探索提供了一个极其强大的解决方案。

总结

在本章中，我们讨论了现代数据架构的演变及其关键设计模式，如Lambda架构，使构建可扩展和灵活的数据平台成为可能。我们学习了Lambda方法如何结合批处理和实时数据处理来提供历史分析，同时支持低延迟应用程序。

我们讨论了从传统数据仓库到下一代数据湖和数据湖仓的过渡。你现在了解这些基于云对象存储的现代数据平台如何提供模式灵活性、规模上的成本效益以及批处理和流数据的统一。

我们还深入探讨了组成现代数据堆栈的组件和技术。这包括数据摄取工具如Kafka和Spark、分布式处理引擎如用于流数据的Spark Structured Streaming和用于批数据的Spark SQL、编排工具如Apache Airflow、云对象存储上的存储层，以及使用Trino、Elasticsearch和可视化工具如Superset和Kibana的服务层。

无论你的用例是ETL和历史数据分析还是实时数据应用，这个现代数据堆栈提供了一个蓝图。这里的经验教训构成了摄取、处理、存储、分析和服务数据所需的基础，推动高级分析并支持数据驱动的决策。

在下一章中，我们将深入探讨Apache Spark，其工作原理、内部架构及运行数据处理的基本命令。