守株阁

上一篇确立了 Spark 的核心是一张 DAG，而 DAG 的节点就是 RDD。这一篇进入 RDD 本身。 RDD 容易被理解成"分布式的数组"或者"分布在多台机器上的数据集合"。更准确的说法是：RDD 是一份计算配方，记录了数据从哪来、经过什么变换、丢失一个分区后怎么重算。 本文只抓一个问题：RDD 的五大属性分别控制了什么，以及这五个属性如何支撑 Spark 的调度和容错。 五大属性总览 Spark 源码中 RDD 的抽象类定义了五个方法，每个方法对应一个核心属性： 123456RDD[T]├── getPartitions: Array[Partition] ← 数据怎么切分├── getDependencies: Seq[Dependency[_]] ← 上游是谁├── compute(split, context): Iterator[T] ← 一个分区怎么算├── partitioner: Option[Partitioner] ← 按什么规则分区└── getPreferredLocations(s...

Spark 常被介绍为"比 MapReduce 快 100 倍的计算引擎"。这个说法把重点放错了地方。速度差异只是结果，不是原因。真正的区别在于执行模型：MapReduce 是一条固定的 Map-Shuffle-Reduce 三段流水线，而 Spark 是一个可以表达任意有向无环图（DAG）的执行引擎。 本篇只抓一个问题：Spark 的 DAG 执行模型到底和 MapReduce 的线性管道有什么本质区别，以及这个区别如何贯穿整个系列。 MapReduce 的线性管道 MapReduce 的执行模型可以用一句话概括：读数据 → Map → 写磁盘 → Shuffle → 写磁盘 → Reduce → 写数据。 1HDFS → Map Task → Local Disk → Shuffle → Local Disk → Reduce Task → HDFS 这条管道有两个结构性约束： 第一，每个 MapReduce 作业只有一轮 Map 和一轮 Reduce。如果业务逻辑需要多轮聚合（比如先按用户分组，再按地区汇总），就必须把逻辑拆成多个 MapReduce 作...

人工智能的历史，本质上是一部关于"什么是智能"的争论史。 从 1950 年代至今，这个领域经历了至少两次大规模繁荣和两次寒冬，催生了符号主义、连接主义、统计学习、深度学习、强化学习等多个范式。这些范式的兴衰，表面上看是技术路线的竞争，底层驱动力却是对一个哲学问题的不同回答：智能究竟是"规则的执行"还是"数据的涌现"？ 一、两种智能观的源头 1.1 符号主义：智能就是符号操作 1943 年，Warren McCulloch 和 Walter Pitts 发表了一篇论文，用数理逻辑描述神经元的行为。这篇论文同时启发了两个方向——一个方向关注"逻辑"本身，另一个方向关注"神经元网络"本身。前者演化为符号主义（Symbolism），后者演化为连接主义（Connectionism）。 符号主义的哲学根基可以追溯到莱布尼茨。莱布尼茨试图创建一种"通用逻辑演算"来表达所有人类思想，17 世纪的霍布斯则主张推理"不过是计算"。这条线索在 20 世纪中叶被 ...

九一八之后，尤其是七七事变之后，中文世界一直流传一种说法：美国一边在道义上谴责日本侵略，一边继续跟日本做生意，卖给日本的石油、废钢比卖给中国的还多，所以日本用来打中国的子弹，“七成以上其实是美国人间接造的”。这个判断在情绪上很有冲击力，在朋友圈和短视频里反复出现，但它有两个一直没被认真处理的问题：第一，那个"七成"到底是怎么算出来的，是不是一个能站住的统计；第二，"美国偏袒日本"这个定性，能不能被美方自己的贸易数据和政策档案支持。 把这两个问题拆开看，结论并不是简单的"是"或"否"。事实内核大体成立——直到 1940 年，美国确实是给日本战争机器输血最多的国家，而且这种输血在南京大屠杀之后又持续了整整三年。但"偏袒"这个定性，以及"七成子弹"这个具体数字，都需要修正。美国不是在"援助"日本，而是在一套孤立主义的自由贸易法律框架下"卖货"给日本；与此同时，它是最早拒绝承认日本征服成果的大国，一直在给中国放贷款，并且从 193...

引子：10 倍代码不等于 10 倍工程 Google 首席软件工程师 Adam Bender 在 Google I/O 2026 的一场演讲里抛出大多数人还没来得及思考的问题：当 AI 把代码产出速度推到现有工程流程无法承载的地步，开发者生态系统里什么会最先垮掉？ 他的回答直白：今天构建软件的方式，在 10 倍速度下根本行不通。AI 时代的真正赢家不是产出最高的团队，而是基本功最扎实的那些人。AI 只负责放大，不负责方向。 这场演讲串起一个大多数人没听过的概念：软件生态学，对生产软件的社会技术生态系统进行整体性研究的学科。它要求不只看技术，还要看人、看文化、看组织里那些不成文的规则。 软件生态学：被忽视的整体视角 系统、生态系统与社会技术系统 要理解软件生态学，得先回到三个基础概念。 系统是一组相互关联的元素，按照一套规则运作，形成统一的整体。空调就是系统：恒温器知道目标温度，暖通空调负责升温或降温，房间温度合适了信号就停。 生态系统是特殊的系统，由相互依赖的行动者组成的动态网络，这些行动者与其环境共同演化，具有涌现行为和去中心化的自主性。关键点是，环境是系统的一部分，不能把两...

软件工程有一条反直觉的规律：集成的频率越高，每次集成的痛苦越小。这条规律从 1990 年代末被 Kent Beck 写进极限编程的实践清单，到今天演化出一整套涵盖构建、测试、部署、发布的自动化体系。CI/CD 不是某一个工具或某一种流程，而是三十年工程实践反复迭代的产物。 持续集成的诞生（1996-2006） 极限编程与 CI 的起源 1996 年，Kent Beck 加入克莱斯勒公司的 C3（Chrysler Comprehensive Compensation System）项目。这个项目此前陷入僵局，Beck 将它作为极限编程（XP）的试验田，引入了十二条核心实践，持续集成是其中之一。CI 的核心主张很简单：开发者每天多次将代码集成到主干，每次集成都触发自动构建和测试。1999 年出版的《Extreme Programming Explained: Embrace Change》正式将 CI 确立为一个命名实践。 CI 要解决的问题在当时有一个形象的说法叫"集成地狱"（integration hell）——团队各自开发数周甚至数月，最后合并代码时发现冲突...

MySQL 在绝大多数业务系统中扮演事实源的角色。Redis 和 ES 都是派生存储——数据可以从 MySQL 重建，反过来不行。围绕 MySQL 的架构模式，核心问题始终是三个：怎么扛住读写压力、怎么保证数据不丢、怎么随业务增长水平扩展。 下面整理十个生产环境中反复出现的 MySQL 架构模式。和 ES 架构模式 与 Redis 用例全解 形成三件套：Redis 管热路径和派生状态，ES 管可搜索的派生索引，MySQL 管事实。 模式速查 模式 解决的问题 核心机制 典型场景 主从复制 + 读写分离 读压力分摊 binlog 复制 + 代理层路由 读多写少的业务 半同步复制 + 增强半同步 主从切换时数据不丢 after-sync / after-commit 金融、订单 双主（互为主从） 机房级故障切换 双向复制 + 自增步长错开 同城双活 级联复制 大规模从库扩展 从库的从库 读流量极大的分析场景 分库分表 单库容量和写入瓶颈 水平分片 + 路由中间件 亿级数据量 影子表与 Online DDL 大表结构变更不锁表 pt-osc / gh...

Elasticsearch 不只是一个搜索引擎。围绕它的分片、副本、别名、ILM 等原语，生产环境中沉淀出了一批反复出现的架构模式。这些模式解决的问题各不相同——有的管数据生命周期，有的管多租户隔离，有的管读写分离——但核心思路一致：用 ES 的原语组合出业务需要的数据分布和访问路径。 下面整理十个常见的 ES 架构模式。“时间分区索引 + 别名滚动”——每月一个物理索引、基于别名查询、定期淘汰老索引——是日志和时序场景的基石，配置也最精细，放在第一个。 模式速查 模式 解决的问题 核心原语 典型场景 时间分区索引 + 别名滚动 数据无限增长的生命周期管理 Index Template + Alias + ILM/Rollover 日志、订单流水、审计 冷热分层存储 不同时效数据的成本优化 Node Attribute + Allocation Filter + ILM 日志、监控指标 读写分离 写入不影响搜索延迟 写别名 + 读别名 + Replica 调度 高写入吞吐 + 低延迟搜索 多租户索引隔离 租户间数据和性能隔离 Index-per-ten...

上一篇解决了生产运维——分层监控、扩缩容和故障排查。这篇作为系列收尾，回答一个经常被问到的问题：为什么选 Elasticsearch 而不是 Solr（或反过来）。 Elasticsearch 和 Solr 都基于 Apache Lucene。核心搜索能力——倒排索引、BM25 打分、文本分析——本质上相同，因为它们共享同一个底层引擎。差异在于分布式架构、配置哲学、生态绑定和许可协议这些"Lucene 之上"的设计选择。 本文不下"谁更好"的结论，而是给出一个选择框架。 共同基础：Apache Lucene 两者都基于 Lucene 构建。以下能力在两者中本质相同： 倒排索引（FST + Posting List） BM25 打分 Analyzer（Character Filter → Tokenizer → Token Filter） Doc Values（列式存储，用于排序/聚合） BKD-tree（数值和地理范围查询） Segment 不可变 + 后台 merge 理解了 Lucene（本系列第 02 篇），两个搜索引擎的搜索能...

上一篇解决了安全体系——认证、授权、加密的洋葱模型。这一篇进入生产环境中 ES 集群怎样运维。 生产运维的核心工作是监控和排障。ES 提供了丰富的内置 API 来观察集群各层的状态。关键是建立分层监控的思路：从集群健康到节点资源到索引性能到查询诊断，逐层下钻。 本文抓两个问题：生产集群应该监控哪些指标，以及常见故障怎样排查。 分层监控 监控从宏观到微观分四层，每层对应不同粒度的 API 和指标。排查问题时从 L1 开始逐层下钻，定位到具体层再展开： L1：集群健康 1GET _cluster/health Status 含义 响应 green 所有 primary 和 replica 已分配 正常 yellow 所有 primary 已分配，部分 replica 未分配 关注但不紧急 red 部分 primary 未分配 紧急——数据不可用 12GET _cat/health?v# 快速查看 status, node.total, shards, unassign Yellow 状态在单节点集群中是正常的（replica 无法分配到另一个节点）。在...