1. 课程导入与全景认知
在真实的数据平台里，数据很少只走一条路。日志、业务库变更、埋点事件、文件批量导入往往同时存在：有的要求秒级可见，有的允许按小时汇总；有的需要先清洗再入库，有的需要跨系统搬运后再做聚合。Elastic 生态提供的批流一体能力，正是为这种"多源、多速率、多目标"的场景准备的。本课程要解决的核心问题是：如何把分散的数据源，通过可编排的管道稳定地送入 Elasticsearch，并让批处理与流处理在同一套技术栈里协同工作。
学习目标
完成本课程后，你应当能够独立完成以下几类任务：
- 根据数据特征（时效性、数据量、是否需转换）选择合适的采集与写入组件，而不是默认只用一种工具；
- 使用 Logstash、Beats、Elastic Agent、Ingest Pipeline 等构建从采集、解析、富化到索引的完整链路；
- 理解批处理与流处理在 Elastic 体系中的分工，并能用 Elasticsearch 的索引生命周期、数据流（Data Stream）等机制承载两类数据；
- 对管道进行任务编排、失败重试、监控与排障，判断数据是否真正"落库且可用"。
核心概念：批、流与管道
批处理（Batch）指按固定周期、以有界数据集为单位处理数据，典型如每天凌晨把前一天的订单表导出并写入 Elasticsearch。它的特点是吞吐高、延迟以分钟到小时计、可重跑。流处理（Streaming）指数据产生即处理，以无界数据流为单位，典型如应用日志实时写入并在 Kibana 中秒级查询。它的特点是延迟低、需要处理乱序与背压。
数据管道（Pipeline）是把"源 → 采集 → 转换 → 缓冲 → 写入 → 存储/检索"串起来的处理链。在 Elastic 语境下，管道既可以是 Logstash 的 input/filter/output 三段式配置，也可以是 Elasticsearch 内部的 Ingest Pipeline（由一系列 processor 组成），还可以是 Elastic Agent 的集成策略。理解"管道"的关键在于：每一段都有明确的输入契约和输出契约，段与段之间可以解耦、可以独立扩缩容。
技术栈组成
本课程涉及的技术栈可以按职责分为四层：
| 层次 | 代表组件 | 主要职责 |
|---|---|---|
| 采集层 | Filebeat、Metricbeat、Elastic Agent、Logstash input | 从文件、系统指标、消息队列、数据库等源读取数据 |
| 转换层 | Logstash filter、Ingest Pipeline processor、Painless 脚本 | 解析、字段映射、富化、脱敏、类型转换 |
| 缓冲/传输层 | Kafka、Redis、Logstash persistent queue | 削峰填谷、解耦生产与消费、支持重放 |
| 存储/检索层 | Elasticsearch 索引、Data Stream、ILM | 持久化、分片与副本、生命周期管理、查询聚合 |
编排则贯穿各层：Logstash 的 pipeline 配置、Elasticsearch 的 ingest pipeline 引用、Kibana 的 Fleet 策略下发，都是"编排"的具体形态。编排的目标不是把组件堆在一起，而是让数据流向可预期、失败可恢复、状态可观测。
典型应用场景
举一个贯穿本课程的教学示例：某电商平台需要把三类数据送入 Elasticsearch。第一类是 Nginx 访问日志，要求 5 秒内可查，用于实时错误率看板；第二类是 MySQL 订单表，每天 02:00 全量同步一次，用于经营分析；第三类是用户行为埋点，经 Kafka 缓冲后写入，用于漏斗分析。这三类数据分别对应流式、批式和"流式+缓冲"三种模式，但最终都落在同一套 Elasticsearch 集群上，通过不同的索引和 Data Stream 隔离。
假设日志单条约 1.2 KB，峰值 8000 条/秒，则峰值写入约 9.6 MB/s；订单表每天约 200 万行，单行约 0.8 KB，全量约 1.6 GB。这些量级决定了：日志链路要关注 refresh interval 和批量 bulk 大小，订单链路要关注批量提交的分片与并行度。示例参数仅用于说明选型思路，实际应以压测结果为准。
整体架构
下图给出本课程后续章节会反复引用的全景架构：左侧是多源数据，中间是采集与转换管道，右侧是 Elasticsearch 存储与 Kibana 消费，底部是贯穿全链路的编排与监控。
这张架构图有三个值得注意的地方。第一，采集与缓冲是分开的：Beats/Agent 负责轻量采集，Kafka 或持久化队列负责削峰，这样上游突发流量不会直接压垮 Elasticsearch。第二，转换可以发生在两个位置：Logstash filter 在写入前处理，Ingest Pipeline 在 Elasticsearch 内部处理，选择哪一个取决于是否需要复用、是否要减轻客户端负担。第三，编排与监控是横向能力，它不属于某一层，而是贯穿全链路，这也是本课程后半部分重点展开的内容。
学习路径建议
建议按"先跑通一条最小链路，再逐步加复杂度"的方式学习。最小链路可以是：Filebeat 采集一个日志文件 → Logstash 解析 → 写入单个索引 → Kibana 查看。跑通后再依次加入 Kafka 缓冲、Ingest Pipeline 富化、Data Stream 与 ILM、批量回补任务、失败重试与监控。每加一个组件，都要问三个问题：输入是什么、输出是什么、失败时数据会怎样。能回答这三个问题，管道才算真正可控。
接下来的章节会沿着这张全景图逐层展开：先讲采集与缓冲的具体配置，再讲转换与编排的实现方式，然后讲存储侧的索引与生命周期设计，最后讲监控、排障与性能调优。你在学习过程中可以随时回到这张图，确认自己正在处理的是哪一层、哪一段契约。