📚 课程目录第1章课程导入与全景认知

1. 课程导入与全景认知

在开始学习具体工具与操作之前，我们需要先建立一张“全景地图”。很多团队在 Elasticsearch 上遇到的困扰——搜索结果不准、聚合口径不一致、字段含义混乱、索引越建越多却没人敢删——表面看是技术问题，根子上往往是数据质量与元数据治理两件事没有做好。本章先厘清这两个概念的定义与边界，再说明它们在实际工程中的核心挑战，最后给出学习路径与实战环境准备方案。

一、两个核心概念：数据质量与元数据治理

Elastic 数据质量，指的是 Elasticsearch 中存储与检索的数据在多大程度上满足使用要求。它通常可以从几个可度量的维度来刻画：

完整性：应有值的字段是否缺失，例如订单文档中 order_id、amount 是否为空。
准确性：字段值是否符合业务事实，例如 amount 是否为负数、时间戳是否落在合理区间。
一致性：同一实体在不同索引、不同字段中的取值是否统一，例如用户性别在 A 索引是 male、在 B 索引是 M。
唯一性：是否存在重复文档，例如同一 order_id 被写入两次。
时效性：数据是否在预期时间内到达，例如日志延迟是否超过 SLA。
规范性：格式、类型、枚举值是否符合约定，例如 status 只允许 paid/refunded/closed。

元数据治理，则是对“描述数据的数据”进行管理。在 Elastic 语境下，元数据包括：索引名与别名、字段映射（mapping）、字段类型与分词器、字段业务含义、数据血缘（来自哪个上游系统）、生命周期策略（ILM）、访问权限、负责人等。治理的目标是让这些信息可发现、可理解、可信任、可追溯。

两者的关系可以这样理解：元数据治理提供“标准与定义”，数据质量检查提供“验证与反馈”。没有元数据标准，质量规则就无从定义；没有质量检查，元数据标准就只是纸面约定。

二、边界：它们不是什么

明确边界能避免把课程学成“万能工具箱”。数据质量治理不等于数据清洗的全部，它更关注“发现与度量问题”，清洗与修复往往由上游 ETL 或下游应用承担；元数据治理不等于数据目录工具本身，工具只是载体，核心是标准、流程与责任。此外，本课程聚焦 Elasticsearch/Elastic Stack，不展开 Hadoop、数仓建模等其它领域的完整治理体系，但会借鉴其成熟方法论。

三、核心挑战

在真实项目中，挑战通常集中在以下几处：

Schema 弱约束：Elasticsearch 默认动态映射，字段类型可能被“意外”推断，例如 "100" 被识别为 text 而非数值，导致聚合失败。
多源写入不一致：日志、业务库、消息队列多路写入，同一字段命名与格式不统一。
索引膨胀与命名混乱：按天建索引却无统一命名规范，别名缺失，查询与治理成本高。
质量规则难以持续执行：一次性脚本检查后无人维护，问题反复出现。
元数据分散：mapping、业务含义、负责人散落在文档、聊天记录和代码里，无法统一查询。

治理的起点不是工具，而是“先定义标准，再让标准可被自动检查”。建议先选 1～2 个核心索引做试点，跑通“标准—检查—反馈—修复”闭环，再逐步推广。

四、学习路径与实战环境准备

本课程按“认知 → 度量 → 治理 → 落地”推进：先建立全景认知（本章），再学习数据质量维度与检查方法，随后进入元数据采集、字段标准化、索引与别名治理、ILM 与权限，最后通过综合实战把规则固化为可重复执行的流程。

实战环境建议使用 Docker 快速搭建一套本地 Elasticsearch + Kibana，便于随时验证。示例命令如下（仅为教学示例，实际版本可按需调整）：

docker network create elastic-net

docker run -d --name es01 --net elastic-net \
  -p 9200:9200 -p 9300:9300 \
  -e "discovery.type=single-node" \
  -e "xpack.security.enabled=false" \
  docker.elastic.co/elasticsearch/elasticsearch:8.13.0

docker run -d --name kib01 --net elastic-net \
  -p 5601:5601 \
  -e "ELASTICSEARCH_HOSTS=http://es01:9200" \
  docker.elastic.co/kibana/kibana:8.13.0

启动后访问 http://localhost:5601 进入 Kibana，在 Dev Tools 中执行 GET _cluster/health，若返回 "status": "green" 或 "yellow"，说明环境可用。随后可创建一个测试索引并写入几条样例文档，用于后续章节的质量检查练习：

PUT /orders_v1
{
  "mappings": {
    "properties": {
      "order_id":   { "type": "keyword" },
      "amount":     { "type": "double" },
      "status":     { "type": "keyword" },
      "created_at": { "type": "date" }
    }
  }
}

POST /orders_v1/_doc/1
{ "order_id": "A1001", "amount": 199.0, "status": "paid", "created_at": "2024-05-01T10:00:00Z" }

判断环境是否满足练习要求，可以观察三点：集群健康状态、索引 mapping 是否按预期生效、以及能否通过 _search 与 _cat/indices 查看数据与索引概况。这三项也是后续质量检查与元数据采集的基础操作。