守株阁

Logstash 常被当成"把日志灌进 Elasticsearch 的那个工具"，学习方式往往是抄一段 logstash.conf、改几个 Grok 正则、跑通就算会了。这条路能用起来，但解释不了几个问题：为什么同样一份配置，pipeline.workers 调大有时提升吞吐、有时毫无变化？为什么下游 Elasticsearch 变慢，会反过来让 input 端读取变慢？持久队列到底在崩溃时保住了什么、又保不住什么？ 这些问题的答案都不在插件参数表里，而在两个更底层的抽象上：Logstash 处理的核心对象是 event，处理的骨架是 input-filter-output 三段管道。event 是一个带 @timestamp 的结构化文档，是管道里流动的最小单位；三段管道规定了字节怎么变成 event、event 怎么被加工、加工完的 event 怎么发往下游。codec、Grok、队列、批处理、背压这些机制，全都是围绕"event 在三段管道里怎么流"展开的。 本系列只抓一个问题：Logstash 这套以 event 为核心对象、以三段...

Kibana 常被介绍为"Elasticsearch 的图形界面"或"ES 的可视化前端"。这个说法把 Kibana 的位置放低了一层，也解释不了几个基本现象：为什么 Kibana 要自带一个 Node.js 服务，而不是像 Kibana 3 那样纯浏览器直连 ES？为什么在浏览器里保存一张 Dashboard，会往 Elasticsearch 里写一条数据，而这条数据又不出现在业务索引里？为什么升级 Kibana 大版本时，它会在启动阶段做一轮"迁移"，动的却是 ES 里的某些系统索引？ 更准确的说法是：Kibana 是一个后端在 Elasticsearch、前端在浏览器、而自身状态也存在 Elasticsearch 里的三层应用平台。用户在界面上建的每一个 Data View、拖的每一张可视化、组的每一个 Dashboard、配的每一条告警规则，都不是存在浏览器本地、也不是存在某个独立数据库，而是以 Saved Object 的形式写进以 .kibana 为前缀的系统索引。Kibana 把 Elasticsearch...

大模型的知识库能力在过去两年里经历了快速迭代。OpenAI 和 Anthropic 作为这个领域最有代表性的两家公司，走出了截然不同的技术路线。一家押注"窗口越大越好"，另一家选择"检索越准越好"。这种分歧不是表面的产品差异，而是反映了对"如何让 AI 有效利用外部知识"这一基本问题的不同回答。 从时间跨度上看，2023 年底到 2026 年中这段时间是知识库能力爆发式增长的阶段。两家公司几乎每个季度都有新的能力发布，而且技术路线的分化越来越明显。 这里说的"知识库"不仅仅指 RAG 或向量数据库，而是涵盖了从文档存储、检索、记忆管理到工具连接的整个链路——所有让 AI 系统能够有效利用外部知识的技术。 OpenAI：用规模碾压复杂度 OpenAI 在知识库方向上的核心策略可以概括为一句话：把上下文窗口做大，把基础设施做全，让用户把文档直接塞进去。 这个策略的底层逻辑并不复杂：如果模型能一次性「看到」所有相关信息，那检索这个步骤就变得多余。 而 OpenAI 恰好拥有最强的算力基础设施来支撑这个方向。...

上一篇讲了现代大数据栈的演进。本篇是系列最后一篇——总结 Hadoop 留下的设计遗产。 Hadoop 项目本身在某些场景被云原生 stack 取代，但 Hadoop 沉淀的设计思想已经成为后续所有大数据、云原生系统的默认起点。本篇把全系列 22 篇文章压成一组"可迁移的设计模式"，看 Hadoop 的哪些核心思想被后续系统继承。 Hadoop 的设计遗产不是"代码"，而是"前提假设 + 工程对策"——节点失败是常态、大对象切块、副本放在一起、心跳监控、自动重做、双层调度、分而治之、Append-Only Journal、Snapshot + Checkpoint。这些模式已经成为现代分布式系统的标准设计语言，被 Kafka、Cassandra、Kubernetes、Spark、Flink、Ray 等系统以不同方式继承。 本篇只抓一个问题：Hadoop 的哪些设计模式被后续系统继承、各自如何变体、为什么这些模式有跨时代的生命力。 三条核心前提的传承 本系列 00 篇把 Hadoop 的主线压成一句话——以"节点...

上一篇讲了 Hadoop 生态。本篇讲现代大数据栈的演进——对象存储和 Kubernetes 如何逐步替代 HDFS 和 YARN。 云原生大数据栈常被简化成"把 Hadoop 搬到云上"。这个简化漏了核心架构变化。准确的说法是：现代大数据栈把 Hadoop 的"存储 + 计算 + 编排"三层各自独立演化——存储层从 HDFS 切到 S3 / OSS 等对象存储（彻底解耦存储与计算）、计算层从 MapReduce 演进到 Spark / Flink（内存优先 + 流批一体）、编排层从 YARN 切到 Kubernetes（弹性扩缩容 + 多租户隔离）。三层解耦后每个组件独立演化、独立计费、独立运维，让大数据栈从"集成式 Hadoop 集群"变成"组合式数据平台"。 本篇只抓一个问题：对象存储为什么能取代 HDFS、Spark on K8s 现在能取代 YARN 多少、现代大数据栈与 Hadoop 的具体架构差异、什么场景应该选哪种。 存储层：HDFS vs 对象存储 HDFS 在 Hadoop 1.x...

前四阶段把 Hadoop 核心（HDFS / YARN / MapReduce + Common）讲完了。第五阶段展开 Hadoop 周边的生态系统和现代演进。本篇先讲生态——Hive、HBase、Pig 在 Hadoop 之上各自的角色。 Hadoop 生态常被介绍成"HDFS + YARN + MapReduce + 一堆工具"。这个描述对应了组件清单但完全没解释这些工具为什么存在。准确的说法是：Hive 是 SQL 编译器（把 SQL 翻译成 MapReduce/Tez/Spark 执行计划），不是计算引擎；HBase 是把随机读写放上 HDFS 的 LSM-Tree KV 存储，依赖 HDFS 做持久化但通过 RegionServer 提供低延迟访问；Pig 是脚本化的数据流编程语言，曾被 Yahoo 大规模使用但已被 Spark 取代。这三个工具各自填补 Hadoop 的一个能力空白——SQL 接口、随机读写、复杂数据流——但底层都跑在 HDFS + YARN 之上，不替代它们。 本篇只抓一个问题：Hive 的 SQL 编译流程是什么、HBase 怎...

上一篇讲了安全。本篇讲 Hadoop 的可观测性——Metrics、JMX、日志聚合。这是 HA、安全与 Common 篇的最后一篇。 Hadoop 可观测性常被介绍成"看 Web UI 和日志"。这个描述对应了基本操作但漏了系统化设计。准确的说法是：Hadoop 提供三层可观测性——Metrics V2 是结构化指标系统（Source-Sink 架构，周期性采样暴露给外部采集）、JMX 是运行时 Java 指标暴露接口（Prometheus JMX Exporter 让 Hadoop 接入现代时序数据库）、YARN Log Aggregation 是 Task 日志的集中存储和查询。这三层共同构成 Hadoop 集群的运维可观测性基座。 本篇只抓一个问题：Metrics V2 的 Source-Sink 架构怎么工作、JMX 怎么接入 Prometheus 等现代监控栈、YARN Log Aggregation 的写入和查询流程、生产环境的可观测性最佳实践。 Metrics V2：Source-Sink 架构 Hadoop 2.x 引入了 Metrics V...

上一篇讲了序列化与压缩。本篇讲 Hadoop 的安全机制——Kerberos 认证、Delegation Token、Proxy User。 Hadoop 安全常被介绍成"Kerberos 配置"。这个描述对应了最显眼的部分但漏了完整设计。准确的说法是：Hadoop 安全是一个分层模型——底层用 Kerberos 做初始强认证，中间层用 Delegation Token 减轻 KDC 压力，资源访问层用 Block Token / Container Token 做时间受限授权，最上层用 ACL 做细粒度权限控制。Proxy User 让超级用户代表真实用户访问 Hadoop，是 HiveServer2 / Oozie / Hue 这类网关服务的核心机制。 本篇只抓一个问题：Kerberos 在 Hadoop 里到底起什么作用、Delegation Token 怎么减少 KDC 压力、Proxy User 与 doAs 模型怎么让网关服务代用户访问。 为什么 Hadoop 需要 Kerberos Hadoop 默认是 SIMPLE 认证——客户端声称自己是哪个...

上一篇讲了 RPC。本篇讲 RPC 和数据存储都依赖的两个底层机制——序列化和压缩。 序列化与压缩常被合并介绍。这两个机制其实是不同维度——序列化解决"对象怎么变字节流"（结构化），压缩解决"字节流怎么变更小的字节流"（空间优化）。两者经常组合使用——序列化后的字节流再压缩存储或传输。准确的说法是：Hadoop 提供多种序列化格式（Writable / Protobuf / Avro），与多种压缩格式（Gzip / BZip2 / Snappy / LZ4 / Zstd）正交组合，按场景选择最优组合。 本篇只抓一个问题：Writable 与 Java Serializable 的差别、Protobuf 与 Avro 各自的取舍、Snappy vs Zstd vs Gzip 的压缩比/速度权衡、压缩在 Hadoop 各个环节的具体应用位置。 序列化的本质 序列化（serialization）解决"对象 → 字节流"和"字节流 → 对象"的双向转换。分布式系统的所有跨进程数据交换都依赖序列化——RPC 参...

前三阶段把 HDFS / YARN / MapReduce 三个子系统讲完了。第四阶段展开三个子系统共用的那套基础设施——RPC、序列化、安全、监控。本篇先讲 RPC。 Hadoop RPC 常被介绍成"Hadoop 进程间通信的协议"。这个描述对应了功能但完全没解释机制。准确的说法是：Hadoop RPC 是一个独立的、自研的 RPC 框架，不是 gRPC / Thrift / Dubbo 之类通用框架。它用 Protobuf 做序列化（Hadoop 2.x 起默认），用 SASL 做认证（Kerberos / Delegation Token / Simple），用 NIO + 长连接做传输。整个 Hadoop 项目（HDFS / YARN / MapReduce）的所有进程间通信都走这套 RPC——NameNode 与 DataNode、ResourceManager 与 NodeManager、ApplicationMaster 与 RM、Task 与 MRAppMaster。 本篇只抓一个问题：Hadoop RPC 的六层栈是怎么组织的、Protob...