说实话，我第一次参加数据部门的周会时，整个人是懵的。PPT 上密密麻麻写着 Lake、Warehouse、Pipeline、SLA、Retention、QPS，同事嘴里蹦出来的英文基本没有断句，我只能靠猜。后来在数据这个行当摸爬滚打久了才明白，这些词汇不是门槛，而是同行之间交流的“快捷键”。这篇就把我日常工作里频繁出现的大数据常见英文词汇按场景整理出来，给刚入行的朋友当参考手册，也给自己留一份待更新的速查表。

1. 数据地盘与流程词：先分清楚 Warehouse、Lake、Pipeline、ETL

大数据圈子里最常见的一类英文，是“数据放哪、数据怎么流动”。很多新人一上来就钻到 SQL 和框架里，反而把最基础的地图词搞混了，后面看文档、听方案都费劲。

1.1 Data Warehouse、Data Lake、Data Mart 的边界

这三兄弟几乎每个数据团队都会提到。Data Warehouse 是数据仓库，面向分析场景的集中式存储，数据在进入之前就经过了清洗、转换、建模，结构固定，查询稳定。Data Lake 是数据湖，把原始数据以原样收进来，不管是结构化表、日志、图片还是 JSON，先存了再说，等真要用的时候再按需解析。Data Mart 是数据集市，通常面向某个部门或主题，比如销售数据集市、用户行为数据集市，可以理解为“从数仓或数据湖里提炼出来专门服务特定业务的小型仓库”。

我会这样类比：数据仓库是超市，货架分类清晰、商品贴好标签，进去就能拿；数据湖是水库，天然水直接蓄进来，喝之前得自己净化；数据集市是便利店，规模小，但专门满足附近居民的最常用需求。现实中经常有人问“到底该用 Lake 还是 Warehouse”，我的看法是：如果你还在探索阶段、业务口径天天变，湖更合适；如果报表和分析模型已经固定、要求稳定高效，仓更合适。两套并存也很常见，核心原因是它们的定位根本不冲突。

1.2 ETL 与 ELT：字母顺序反了，架构思路完全不同

ETL 是 Extract、Transform、Load 的缩写，先抽取、再转换、最后加载到目标系统。ELT 则是 Extract、Load、Transform，先把数据全部加载进去，再做转换。这俩的差别不只是字母顺序，而是代表了两种技术路线的取舍。

传统数仓时代计算资源贵，加载前的转换必须做精做细，不然垃圾数据进库会污染报表，所以 ETL 主导。到了云时代和湖仓一体的语境，存储和计算被拆开，数据湖先把原始数据装进低成本存储，然后用弹性计算资源按需转换，ELT 就成了主流。尤其是上游数据源五花八门、口径经常调整的场景，ELT 的灵活性明显更高——你永远不需要为上一步变换是否合理而提前拍板。听到这两个词时，先区分“先清洗后入库”还是“先入库后清洗”，方案讨论就不会跑偏。

Data Pipeline 指的是数据管道，是 ETL/ELT 过程中一系列自动化步骤的统称。它强调“流动”的概念：从一个源头持续或定时地把数据搬运、加工到下一个目的地。日常说“这条 pipeline 挂了”“pipeline 跑了几小时”，指的不是某一个工具，而是从抽取到装载的整条链路。理解这一点很重要，因为它决定了排查问题时你必须具备端到端的视角。

1.3 Batch、Real-time 与两种架构方案

批处理和实时处理是另一组必懂的反义词。Batch 是批处理，适合对延迟不敏感、数据量大的场景，比如凌晨结算前一天的全量日志。Real-time 是实时处理，强调数据产生后毫秒级或秒级响应，比如风控拦截、实时大屏。中间还有一个词叫 Near Real-time，近实时，一般指分钟级延迟，比如每五分钟同步一次增量数据。

聊到实时和批量，总是绕不开 Lambda 架构和 Kappa 架构。Lambda 是早期为了同时满足批量和实时需求而设计的双轨方案：批处理层保证结果的准确性，实时层保证低延迟，但代价是同一套业务逻辑要维护两套代码，成本和一致性都很头疼。Kappa 则把一切都放在流处理里，用重放历史数据的方式补齐批处理的能力，把双轨并成单轨。实际生产中，超大规模团队依然会采用 Lambda 的变体，而中小团队选择纯 Kappa 的也不少。这组词的价值在于：听到“架构选型”时，你知道对方在权衡的其实是准确性和延迟成本，而不是在纠结某个具体工具。

2. 存储与文件格式词：为什么同一份数据，换个格式性能差十倍

存储层的英文词直接影响查询速度，但很多人只把注意力放在 SQL 本身，忽略了底层文件格式和存储结构。这一块非常“百闻不如一见”——同样一张表，选对分区和文件格式后，查询时间能从上小时变成几十秒。

2.1 Partition 和 Bucket：两个看似像、实际不同的概念

Partition 是分区，按某个列的取值把表的数据拆成多个目录，比如按日期分区，每天一个分区。查询时如果带上分区字段，引擎可以直接跳过无关目录，这叫分区裁剪，效果等同给人按区分类放书，找一本时不用翻遍整个书房。Bucket 是分桶，在分区内部再按哈希函数把数据散列成固定数量的文件，让数据分布更均匀。分桶通常用于采样和 join 优化，但要注意不能滥用。

我踩过的坑是“过分分区”。有一张表按天分区，业务同学觉得不够，又按小时分区，结果每个分区只有几百条记录，小文件成堆，NameNode 元数据压力变大，查询启动耗时反而翻倍。如果数据量级不大，日分区完全足够。分区字段的选择还要兼顾常见查询条件，很多团队直接用日期做默认分区，但从不用日期查的业务，等于分区白建，还会拖慢写路径。

2.2 列式存储三剑客：Parquet、ORC、Avro

看到这三个词别慌，它们都是文件格式，决定数据“在地上是横着摆还是竖着放”。

行式存储按行组织，一行数据的所有字段挨在一起，适合点查和写入频繁的业务系统；列式存储则把同一列的所有值连续存放，分析查询只读取涉及的列，天然省 IO，Parquet 和 ORC 都属于列式格式。Avro 是行式存储，但它的核心优势是 schema 演进灵活、压缩率高，写密集场景更合适。下面这张对比表是我在选型时常用到的参考：

在实际项目里，分析报表表的底层我基本只用 Parquet 或 ORC；数据从业务系统实时接入、需要频繁更新单条记录时，才考虑 Avro。很多人纠结不在这几个格式之间选，而是根本忘了设置格式，直接用了默认文本格式，这一步就能让后续查询慢好几倍。

2.3 Replica、Sharding、Snapshot、Compression 与存储可靠性

Replica 是副本，同一份数据在不同机器上保留多份，用来防机器故障。常见配置是 3 副本，一旦某台机器挂了，系统仍能从另外两台读取。Sharding 是分片，把一个大表横向切分到多台机器，每台只负责一部分数据，解决的是单机存不下、算不动的问题。Sharding 和 Partition 容易混淆，这里我自己的理解是：Partition 偏向逻辑层面的目录划分，Sharding 偏向物理层面的跨机分布，实际使用中它们可能结合出现。

Snapshot 是快照，给某一时刻的数据做一份整体“拍照”，方便回滚和容灾。数仓里最常见的应用是：上游变更数据前先打快照，跑挂了可以回退到安全版本。Compression 就是压缩，用 CPU 开销换存储空间和 IO 开销。常用的有 Snappy、Gzip、LZ4，Snappy 压缩和解压都快但压缩率低，Gzip 压缩率高但速度慢。调解查询的时候，我发现很多慢查询不是计算瓶颈，而是存储层没压缩、IO 把时间吃掉了。换格式和选对压缩算法，往往是性价比最高的优化手段。

3. 计算引擎与调度词：Spark、Job、Stage、Task 到底谁包含谁

大数据计算引擎的英文词很多，但核心就一条主线：一个任务提交后，如何被切碎、分发、并行执行。你不需要记住每个框架的 API，但至少要知道 Job、Stage、Task 的层级关系，不然日志里抛出的异常都看不懂。

3.1 从 MapReduce 到 Spark：为什么说计算范式变了一次代

MapReduce 是早期的分布式计算模型，把任务拆成 Map 和 Reduce 两个阶段：Map 负责并行读数据、做初步整理，Reduce 负责汇总结果。这种模型开创性地解决了“怎么让一堆机器协同算一份大任务”，但它的致命缺点是每个阶段的结果都要落盘，遇到迭代计算时磁盘读写开销大到离谱。

Spark 的核心改进是引入内存计算。它把中间结果尽量留在内存里，避免反复写磁盘，对迭代类算法、多阶段 SQL 的提升是数量级的。这里给个直观感受：同规模数据，用类 MapReduce 模型跑一个需要五轮迭代的算法，可能要一小时；换成 Spark 这类内存计算，通常几分钟就能完成。这也是为什么现在提到大数据计算，默认首选都是 Spark，而“MapReduce”更多作为编程模型概念存在于教材和遗留系统里。

3.2 Job、Stage、Task 和 DAG：一次查询是怎么被拆开的

假设你用 Spark SQL 跑一句简单的聚合查询。调度器会把它解析成一个 DAG（有向无环图），图中的每个节点是一个算子，比如读取、过滤、聚合、排序。这个 DAG 整体叫一个 Job，一个 Job 会被切分成多个 Stage，每个 Stage 对应图中可以连起来连续执行的那一段，Stage 之间通常有需要 shuffle 的边界。每个 Stage 内部再根据数据分片，生成多个 Task，这些 Task 才是真正在各节点上跑的小任务。

举一个实际例子：查询“select region, count(*) from orders group by region”，读取阶段可能只对应一个 Stage，但 group by 需要按 region 把数据重新分发，就会触发一次 shuffle，产生一个新的 Stage。Stage 里的 Task 数量，基本等于需要处理的数据分片数。出了问题看日志时，先定位是哪个 Stage 失败，再看它前面的 shuffle 是不是导致了数据倾斜，比漫无目的地翻日志有效得多。Executors 指的是计算节点上真正干活的工作进程，Driver 是负责任务调度和状态协调的“指挥官”，这两个词也是看执行日志时最常见的词。

3.3 资源管理词：YARN、Cluster、Auto-scaling

资源管理层还有一组高频词。Cluster 是集群，很好理解，一组机器组成计算资源池。YARN 是经典的大数据资源调度框架，负责给提交上来的任务分配 CPU、内存。现在的趋势是 Kubernetes 这类容器编排系统，逐渐取代或部分取代传统资源管理，因为它在多框架混布、弹性伸缩上更通用。

Auto-scaling 是自动伸缩，指集群可根据负载变化动态增减计算资源。做实时任务时尤其要注意：流量高峰来了，资源配置跟不上，任务会积压；但资源也不是越多越好，节点多了，调度开销和成本都会增加。我曾经把一个凌晨批处理任务从固定 20 个 executor 改成按积压量自动伸缩，高峰期资源能到 60 个节点，闲时回落到 5 个，整体费用反而降了三成。理解这些资源词，排查性能瓶颈时才能准确判断“是代码问题还是资源问题”。

4. 消息队列与流处理词：从 Kafka 的 Offset 到 Flink 的 Watermark

现代大数据架构里，实时部分的词汇自成体系，而且最绕。因为流处理要同时处理“无数个事件”“不保证顺序”“机器可能故障”这三个麻烦。这条链路里的核心概念，值得单独梳理。

4.1 消息链路基础词：Producer、Consumer、Broker、Topic、Partition、Offset、Consumer Group

Kafka 类消息系统里，Producer 是生产者，把消息发出去；Consumer 是消费者，从队列里取消息处理；Broker 是消息中间件的服务器节点，负责接收和存储消息。Topic 是主题，可以理解为一个信箱类别；Partition 是主题的分区，同一个 Topic 的数据被拆到多个分区里，保证并行能力和水平扩展；Offset 是分区内的偏移量，相当于你读书时的书签，记录了“消费者读到哪里了”。

Consumer Group 是消费者组，组内消费者共同消费一个 Topic，分到的分区互不重复。它的意义在于：既保证每条消息只被组内一个成员处理，又保证整个组能完整消费所有消息。比如有 10 个分区、3 个消费者在组里，那么 3 个消费者会各自分担几个分区，而不是每个人都读全量。理解 Offset 尤其重要，生产环境里最常见的故障就是消费者提交偏移量的时机不对：处理完再提交，叫手动提交，安全但可能重复；先提交再处理，效率高但容易丢。我刚工作那会儿遇到过“每天固定丢几万条消息”的问题，最后发现就是代码里把自动提交开着、业务逻辑又在消费后异步处理，消息还没处理完，Offset 已经提交了，进程一重启，那段数据就再也读不回来了。

4.2 消息投递语义：At-least-once、At-most-once、Exactly-once

流处理系统的可靠性，主要通过这组词来定义。At-most-once 是至多一次，消息最多处理一次，可能会丢但绝不会重复；At-least-once 是至少一次，消息不丢但可能出现重复；Exactly-once 是精确一次，每条消息恰好被处理一次，不丢也不重。

工程上，真正的 Exactly-once 成本极高，很多实现号称精确一次，底层其实还是“至少一次 + 去重/幂等”。所以你在设计实时作业时，不要一上来就追求三个词里最漂亮的那个，要先判断业务是否允许少量重复。比如记录用户点击行为，多一条少一条影响不大；但涉及扣减金额、发放奖励，就必须幂等。标准做法是：底层用 At-least-once 保障不丢数据，在写入目标端时通过唯一键做幂等，从业务角度达到“精确一次”的效果。这套组合拳我至今仍认为是流处理项目里性价比最高的方案。

4.3 Window 与 Watermark：迟到的数据怎么处理才算对

Windows 在流处理里是指窗口，用于把无限流切成有限的一段段做计算。Tumbling Window 是滚动窗口，窗口之间不重叠，比如每五分钟算一次；Sliding Window 是滑动窗口，窗口之间有重叠，适合做平滑统计；Session Window 是会话窗口，按不活跃间隔切分，适合分析用户连续操作。选哪种窗口，取决于业务希望统计的是“固定时间段”还是“连续活跃段”。

Watermark 是水位线，含义是“数据时间推进到某一点，此前的数据允许参与计算”。它是流处理处理乱序数据的核心工具。举个例子：事件时间 10:00:01 的数据，可能因为网络延迟，10:00:03 才到达。如果系统严格执行事件时间做窗口，你敢不敢等？等太久延迟就高，等太短会漏数据。水位线就是说好一个策略，比如“允许 10 秒乱序”，那么等到事件时间推进到 10:00:10 时，就认为 10:00:00 这个窗口已经关闭。Watermark 之外还有两个相关词：Late Data 是窗口关闭后才到的数据，Out-of-order 是数据到达顺序和事件顺序不一致。真实线上环境里，这两者是常态而不是异常，设计时要明确对迟到数据“丢弃、侧输出、还是触发重新计算”。很多刚上手的人把窗口结束当作万事大吉，完全没考虑迟到数据，最后对不上数才回头补救，这个成本非常高。

4.4 Backpressure、Checkpoint、State：流任务的“刹车、存档和记忆”

Backpressure 是背压，指下游处理速度跟不上上游生产速度时，压力会像堵住的水管一样向上游传递，系统需要自动降速或缓存来保护自身。不了解背压机制的人，看到流任务延迟上涨，第一反应是加并行度，结果并行度上去了，下游数据库写入变成了瓶颈，背压更严重。正确的排查顺序应该是：先定位背压出现在哪个算子，再去补对应环节的资源或优化算法。

Checkpoint 是检查点，流处理框架定期把算子状态存到远程存储，以便故障后从最近一次完整存档处恢复。State 是状态，流任务里保存的累计值、中间结果。二者的关系是：State 是数据，Checkpoint 是对 State 定期拍快照的行为。Flink 之类引擎开 Checkpoint 时，如果间隔设得太短，会影响吞吐；设得太长，故障恢复的重复计算区间就大。我的经验是默认 1 到 2 分钟起步，根据实际业务对延迟的容忍度再调度。

5. 数据治理与质量词：口径含糊的前一天，往往是因为这些词没对齐

做数仓时间长了会发现，慢查询和框架难题都不是最让人着急的，最磨人的是“同一个指标两套报表数字差 0.1”，以及“数据凌晨三点还没产出导致业务没法看”。这背后的英文词，都属于数据治理和质量领域。

5.1 Metadata、Data Lineage、Data Catalog：拿什么来对齐口径

Metadata 是元数据，描述数据的数据，比如表的注释、字段含义、更新时间、负责人。Data Lineage 是数据血缘，追踪一份数据从上游原始表到下游报表的完整流转链路。Data Catalog 是数据目录，把表、字段、标签、权限、负责人集中成一个可检索的清单。

这三个词里，我感受最深的是 Data Lineage。以前公司里经常出现“销售金额”这个指标有五个口径，报表组在Excel里各自维护，谁也说不清某个数是从哪张明细汇总来的。后来我们把核心指标的血缘关系建立起来：从埋点日志 → 明细表 → DWD 层 → ADS 层 → 报表，每一步都记录加工逻辑和代码位置。从此再有人问“这个数准不准”，不用吵架，沿着血缘图查一遍就知道中间哪个环节漏了过滤条件。搭建血缘不是买一套昂贵工具就能立即见效，而是需要逐渐把“字段级来源”补全，哪怕一开始只能到表级，也比完全没有强得多。

5.2 Data Quality、SLA、SLO：数据团队怎么向业务承诺

Data Quality 是数据质量，包括完整性、准确性、一致性、及时性。Data Quality 差最常见的表现是：字段大量为空、重复数据、时间戳错乱、前后两天数字对不上。数据质量不是“测出来”的，而是“设计出来”的：从埋点规范到入库校验、从调度依赖到产出监控，每层都要埋检查规则。

SLA 是服务等级协议，业务侧和数据平台侧签的正式承诺，比如“每日核心报表最迟 7:00 产出”。SLO 是服务等级目标，是 SLA 里的具体量化指标，比如“7:00 产出的成功率不低于 99.5%”。我们团队在执行中一般对 SLO 拆成两块：任务延迟类（何时跑完）和结果准确类（内容是否匹配）。一旦某个任务的 SLO 连续三天不达标，就拉进专项治理清单。说句掏心窝的话，数据团队在业务面前有没有话语权，很大程度上就看你 SLO 是否定得清、守得住，而这些词就是表达契约的基本单位。

5.3 ACID、BASE、CAP：分布式系统没法纯“讲道理”

数据库和分布式系统语境下的 ACID 是原子性、一致性、隔离性、持久性，它是传统单机数据库保障事务可靠的四条铁律。BASE 则是基本可用、软状态、最终一致性，是分布式系统为了可用性和性能做出的妥协方案。CAP 定理说的是在一致性、可用性、分区容错性之间，分区容错不可放弃时，一致性和可用性往往只能二选一。

很多初学的人把 ACID 和 BASE 当成对立两派，其实它们面对的问题域不同：ACID 保证单次事务的绝对可靠，BASE 接受一段时间的中间状态，只保证最后一致。实际业务里，账户余额扣减必须 ACID 风格，而推荐系统的用户画像更新用 BASE 足够。懂这些词能帮你在设计数据链路时快速判断瓶颈来源：比如某张表写入总超时，不是代码写得烂，而是需求本身对一致性要求太高，如果把强一致降成最终一致，吞吐能提升好几倍。

5.4 Idempotency：数仓重跑不算重复记账的底气

Idempotency 是幂等性，指同一个操作执行多少次，结果都一样。这个词在数仓任务里含金量极高，因为“任务重跑”是日常操作：凌晨跑挂了，修完代码重跑；口径想改了，回溯历史数据重算。如果每一步的写操作不幂等，重跑一遍数据就翻倍。

实现幂等的常见办法有三种：一是用唯一键和去重逻辑，表中不允许出现重复主键；二是用全量表覆盖写，每跑一次都是整体替换分区，天然幂等；三是用事务性写入保证要么全部成功要么全部失败。我习惯在核心表上强制保留主键或唯一键，并在写入任务里带上“先删后插”的分区覆盖逻辑。一个历史任务如果不幂等，它给我的教训是：重跑一时爽，对账火葬场。

6. 分析建模与指标词：Metric 满天飞，但别只会对着数字读

数据分析侧的英文词汇，是业务方和数据团队日常沟通频率最高的部分。会议里所有人都在说 DAU、LTV、Funnel、Retention，如果你对这些词没有准确理解，很容易被带着走。

6.1 指标词族：KPI、Metric、DAU、MAU、LTV、ARPU

KPI 是关键绩效指标，业务目标量化的值；Metric 是度量、口径，是宽泛意义上的业务数字。二者的关系是：KPI 是重要 Metric 的集合，一个 Metric 不一定能当 KPI，但 KPI 一定建立在 Metric 之上。DAU 是日活跃用户数，MAU 是月活跃用户数，LTV 是用户生命周期价值，ARPU 是每用户平均收入。这些都是产品分析的基础盘。

值得注意的是，这些词在不同公司可能定义不完全一样：“活跃”可以是打开 App，也可以是产生有效行为；“收入”可以是流水，也可以是剔退后的净收入。所以看到指标名字时，永远先问“它的分子分母是什么”。我曾经被一个需求坑过：对方说“把 DAU 拉出来看趋势”，我直接按打开 App 口径出了图，结果对方想的是“完成注册且产生点击”的活跃——差了两倍多。数据的歧义从来不是数字的问题，而是词表没有先在团队内部固化成统一的定义。

6.2 Funnel、Cohort、Retention、A/B Test：分析方法的英文高频词

Funnel 是漏斗，描述用户从进入一个流程到完成目标的每一步转化，比如“曝光 → 点击 → 加购 → 支付”。做漏斗分析时最要紧的是每一步的流失率和相对上一步的转化率，但很多报表只展示每一步的绝对人数，不看转化，等于只给了过程没给结果。真正有价值的漏斗，还得配合时间窗口，否则两周前进入和昨天才进入的用户被混在同一锅数据里，转化率必然失真。

Cohort 是同期群，按用户首次行为时间分组，用来排除时间效应对分析的干扰。Retention 是留存率，衡量用户在一段时间后是否还留在产品里。A/B Test 是实验，通过随机分流对比两个版本的效果差异。这几个词合在一起使用是常见做法：用同期群看不同月份新增用户的留存曲线，用实验验证某个优化是否真的提升了留存。会议里别人说“这期实验 retention 有提升但不够显著”，你就明白他在讲的是实验组的留存相对对照组的变化，而不是整体大盘的留存，更不是在泛泛地说用户变多了。

6.3 建模词：Dim、Fact、Star Schema、Slowly Changing Dimension

Datamodeling 词汇组里，Dim 是维度表，存放描述性信息，比如用户维度表、商品维度表；Fact 是事实表，存放可度量的业务事件，比如订单事实表、点击事实表。Star Schema 是星型模型，事实表居中，维度表环绕在四周，查询时通过主键关联。这种模型是数仓建模最常见也最安全的起手式。

SCD 是缓慢变化维度，指维度属性随时间缓慢变更时的处理方式。Type 1 直接覆盖旧值，实现简单但不留历史；Type 2 新增一行并带起止时间，能保留历史但会让维度表膨胀；Type 3 只保留当前值和上一次值，属于折中方案。选哪种不是拍脑袋，而是看业务是否需要追溯历史。比如用户所属城市变了，如果分析“老用户留存按城市细分”，就必须用 Type 2 保留历史版本；如果只是看当前画像，Type 1 就够。这个选择做错了，最典型的症状就是“历史报表数据随维度更新悄悄变了”，导致复盘口径不可信。

6.4 Ad-hoc、Dashboard、Drill-down：报表需求的专业表达

Ad-hoc 是临时查询，指没经过固化、按即时需求写的分析，通常没有文档、没有生产调度，跑完就扔。Dashboard 是仪表盘，把核心指标图形化集中展示。Drill-down 是下钻，从汇总层级点到明细层级，比如从全国销售额点到一个城市、再点到一个门店。

我特别想提醒一件事：Ad-hoc 查询看似简单，其实最危险。因为在生产环境里跑全表扫描、日期范围又不受限制，很容易把集群资源打满，影响正式调度任务。我们团队之前就有过一次惨痛教训：业务同学直接连着生产库跑了一个大 join，跑了一个多小时，把凌晨结算任务全部拖挂了。后来所有 Ad-hoc 必须走队列隔离和资源限制，重要报表只从汇总表取数，不让摸明细大表。Dashboard 是给人看的结论，Ad-hoc 是探索过程，千万别把探索过程直接架在生产数据上。

7. 协作与会议高频词：数据团队里的“中英夹杂”不是装，是效率

在数据团队内部开需求评审会，你会发现大家的英文词密度不比技术文档低。这其实是行业协作的惯性表达，把这些词搞明白，能直接减少沟通损耗。

7.1 角色词：Analyst、Scientist、Engineer、BI、Infra

Data Analyst 是数据分析师，主要负责取数、报表、归因分析，偏业务理解；Data Scientist 是数据科学家，做模型、实验设计、统计推断，偏算法和不确定性；Data Engineer 是数据工程师，负责管道、数仓、调度、质量，偏工程落地；BI Engineer 偏商业智能工具和报表平台建设；Infra 指基础设施团队，管集群、存储、网络、调度平台。实际团队里边界可能模糊，比如分析师也会写 SQL 建宽表，工程师也会做指标口径核对，但角色词指出了核心分工和话语权重。

理解角色词还有个实际用处：在跨团队协作时，你知道遇到“数据对不上”找分析师梳理口径，遇到“管道慢、任务挂”找工程师修链路，遇到“策略效果如何”找科学家设计实验，能省掉大量无效沟通。

7.2 项目协作词：Stakeholder、Alignment、Deliverable、Iteration、Blocker

Stakeholder 是利益相关方，指这个项目成败关系到谁；Alignment 是对齐，指各方在目标、范围、口径上达成一致；Deliverable 是可交付物，指这个项目最终要交出的具体成果，可能是报表、模型或治理文档；Iteration 是迭代周期，敏捷开发里的节奏单位；Blocker 是阻塞项，指当前无法推进的障碍。

开项目例会时，你会听到这样的对话：“这个迭代的两个 deliverable 已经完成，但有一个 blocker，数据源方迟迟没给字段文档，alignment 还要再拉一次会。”以前我觉得这是话术，后来发现这些词确实比绕来绕去的中文表达更精准。做数据项目时，最怕的就是 Stakeholder 没有事先对齐指标口径，交付时才发现做的是另一套。处理这类问题的有效手段是：在项目启动时就输出一份口径文档，让所有 Stakeholder 签字确认，同时明确每个迭代的 deliverable 和验收标准。这些词不只是词汇，更是项目管理的表达工具。

7.3 高频词的记忆方式与扩展建议

最后说一个学习方法。很多人背数据词汇是拿来一本词典干啃，今天背“denormalization”，明天背“shuffle”，后天就忘。我的习惯是把词汇挂到具体场景里记：比如在你处理“重跑任务导致数据翻倍”的那一天，记住 Idempotency；在你排查“上游数据迟到导致窗口结果不对”的那一天，记住 Watermark 和 Late Data；在业务质疑“口径不一致”的那一天，记住 Data Lineage。一个词配一个真实的踩坑片段，记忆牢固得多。

我给自己定的方法是建一张“场景-词汇-案例”表，每遇到一个新场景就随手记下来，积累多了就是自己的数据词典。这也是开头说这篇“待更新”的原因——大数据领域的词汇还在随着新的架构、新的工具持续出现，词表本身就不该是静态的。如果你在自己的工作环境里也遇到了一些高频但让人挠头的英文词，欢迎记下来一起交流，我会持续把这些新的表达整理进这份速查表里，让后来的人少翻一点文档、多省一点时间。