说实话我第一次参加数据部门的周会时整个人是懵的。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看到这三个词别慌它们都是文件格式决定数据“在地上是横着摆还是竖着放”。行式存储按行组织一行数据的所有字段挨在一起适合点查和写入频繁的业务系统列式存储则把同一列的所有值连续存放分析查询只读取涉及的列天然省 IOParquet 和 ORC 都属于列式格式。Avro 是行式存储但它的核心优势是 schema 演进灵活、压缩率高写密集场景更合适。下面这张对比表是我在选型时常用到的参考维度ParquetORCAvro存储布局列式列式行式压缩效率高更高中高谓词下推支持且较好支持且强不支持Schema 演进支持有限支持有限原生支持强典型场景分析查询、湖表存储分析查询、Hive 场景写入链路、消息队列落地在实际项目里分析报表表的底层我基本只用 Parquet 或 ORC数据从业务系统实时接入、需要频繁更新单条记录时才考虑 Avro。很多人纠结不在这几个格式之间选而是根本忘了设置格式直接用了默认文本格式这一步就能让后续查询慢好几倍。2.3 Replica、Sharding、Snapshot、Compression 与存储可靠性Replica 是副本同一份数据在不同机器上保留多份用来防机器故障。常见配置是 3 副本一旦某台机器挂了系统仍能从另外两台读取。Sharding 是分片把一个大表横向切分到多台机器每台只负责一部分数据解决的是单机存不下、算不动的问题。Sharding 和 Partition 容易混淆这里我自己的理解是Partition 偏向逻辑层面的目录划分Sharding 偏向物理层面的跨机分布实际使用中它们可能结合出现。Snapshot 是快照给某一时刻的数据做一份整体“拍照”方便回滚和容灾。数仓里最常见的应用是上游变更数据前先打快照跑挂了可以回退到安全版本。Compression 就是压缩用 CPU 开销换存储空间和 IO 开销。常用的有 Snappy、Gzip、LZ4Snappy 压缩和解压都快但压缩率低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 GroupKafka 类消息系统里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、ARPUKPI 是关键绩效指标业务目标量化的值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 DimensionDatamodeling 词汇组里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、InfraData Analyst 是数据分析师主要负责取数、报表、归因分析偏业务理解Data Scientist 是数据科学家做模型、实验设计、统计推断偏算法和不确定性Data Engineer 是数据工程师负责管道、数仓、调度、质量偏工程落地BI Engineer 偏商业智能工具和报表平台建设Infra 指基础设施团队管集群、存储、网络、调度平台。实际团队里边界可能模糊比如分析师也会写 SQL 建宽表工程师也会做指标口径核对但角色词指出了核心分工和话语权重。理解角色词还有个实际用处在跨团队协作时你知道遇到“数据对不上”找分析师梳理口径遇到“管道慢、任务挂”找工程师修链路遇到“策略效果如何”找科学家设计实验能省掉大量无效沟通。7.2 项目协作词Stakeholder、Alignment、Deliverable、Iteration、BlockerStakeholder 是利益相关方指这个项目成败关系到谁Alignment 是对齐指各方在目标、范围、口径上达成一致Deliverable 是可交付物指这个项目最终要交出的具体成果可能是报表、模型或治理文档Iteration 是迭代周期敏捷开发里的节奏单位Blocker 是阻塞项指当前无法推进的障碍。开项目例会时你会听到这样的对话“这个迭代的两个 deliverable 已经完成但有一个 blocker数据源方迟迟没给字段文档alignment 还要再拉一次会。”以前我觉得这是话术后来发现这些词确实比绕来绕去的中文表达更精准。做数据项目时最怕的就是 Stakeholder 没有事先对齐指标口径交付时才发现做的是另一套。处理这类问题的有效手段是在项目启动时就输出一份口径文档让所有 Stakeholder 签字确认同时明确每个迭代的 deliverable 和验收标准。这些词不只是词汇更是项目管理的表达工具。7.3 高频词的记忆方式与扩展建议最后说一个学习方法。很多人背数据词汇是拿来一本词典干啃今天背“denormalization”明天背“shuffle”后天就忘。我的习惯是把词汇挂到具体场景里记比如在你处理“重跑任务导致数据翻倍”的那一天记住 Idempotency在你排查“上游数据迟到导致窗口结果不对”的那一天记住 Watermark 和 Late Data在业务质疑“口径不一致”的那一天记住 Data Lineage。一个词配一个真实的踩坑片段记忆牢固得多。我给自己定的方法是建一张“场景-词汇-案例”表每遇到一个新场景就随手记下来积累多了就是自己的数据词典。这也是开头说这篇“待更新”的原因——大数据领域的词汇还在随着新的架构、新的工具持续出现词表本身就不该是静态的。如果你在自己的工作环境里也遇到了一些高频但让人挠头的英文词欢迎记下来一起交流我会持续把这些新的表达整理进这份速查表里让后来的人少翻一点文档、多省一点时间。 
长河君 · 2026/10/14 23:38:41 · 阅读 1.2k 大数据高频英文词汇速查：从数据仓库到流处理的必备术语
说实话我第一次参加数据部门的周会时整个人是懵的。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看到这三个词别慌它们都是文件格式决定数据“在地上是横着摆还是竖着放”。行式存储按行组织一行数据的所有字段挨在一起适合点查和写入频繁的业务系统列式存储则把同一列的所有值连续存放分析查询只读取涉及的列天然省 IOParquet 和 ORC 都属于列式格式。Avro 是行式存储但它的核心优势是 schema 演进灵活、压缩率高写密集场景更合适。下面这张对比表是我在选型时常用到的参考维度ParquetORCAvro存储布局列式列式行式压缩效率高更高中高谓词下推支持且较好支持且强不支持Schema 演进支持有限支持有限原生支持强典型场景分析查询、湖表存储分析查询、Hive 场景写入链路、消息队列落地在实际项目里分析报表表的底层我基本只用 Parquet 或 ORC数据从业务系统实时接入、需要频繁更新单条记录时才考虑 Avro。很多人纠结不在这几个格式之间选而是根本忘了设置格式直接用了默认文本格式这一步就能让后续查询慢好几倍。2.3 Replica、Sharding、Snapshot、Compression 与存储可靠性Replica 是副本同一份数据在不同机器上保留多份用来防机器故障。常见配置是 3 副本一旦某台机器挂了系统仍能从另外两台读取。Sharding 是分片把一个大表横向切分到多台机器每台只负责一部分数据解决的是单机存不下、算不动的问题。Sharding 和 Partition 容易混淆这里我自己的理解是Partition 偏向逻辑层面的目录划分Sharding 偏向物理层面的跨机分布实际使用中它们可能结合出现。Snapshot 是快照给某一时刻的数据做一份整体“拍照”方便回滚和容灾。数仓里最常见的应用是上游变更数据前先打快照跑挂了可以回退到安全版本。Compression 就是压缩用 CPU 开销换存储空间和 IO 开销。常用的有 Snappy、Gzip、LZ4Snappy 压缩和解压都快但压缩率低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 GroupKafka 类消息系统里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、ARPUKPI 是关键绩效指标业务目标量化的值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 DimensionDatamodeling 词汇组里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、InfraData Analyst 是数据分析师主要负责取数、报表、归因分析偏业务理解Data Scientist 是数据科学家做模型、实验设计、统计推断偏算法和不确定性Data Engineer 是数据工程师负责管道、数仓、调度、质量偏工程落地BI Engineer 偏商业智能工具和报表平台建设Infra 指基础设施团队管集群、存储、网络、调度平台。实际团队里边界可能模糊比如分析师也会写 SQL 建宽表工程师也会做指标口径核对但角色词指出了核心分工和话语权重。理解角色词还有个实际用处在跨团队协作时你知道遇到“数据对不上”找分析师梳理口径遇到“管道慢、任务挂”找工程师修链路遇到“策略效果如何”找科学家设计实验能省掉大量无效沟通。7.2 项目协作词Stakeholder、Alignment、Deliverable、Iteration、BlockerStakeholder 是利益相关方指这个项目成败关系到谁Alignment 是对齐指各方在目标、范围、口径上达成一致Deliverable 是可交付物指这个项目最终要交出的具体成果可能是报表、模型或治理文档Iteration 是迭代周期敏捷开发里的节奏单位Blocker 是阻塞项指当前无法推进的障碍。开项目例会时你会听到这样的对话“这个迭代的两个 deliverable 已经完成但有一个 blocker数据源方迟迟没给字段文档alignment 还要再拉一次会。”以前我觉得这是话术后来发现这些词确实比绕来绕去的中文表达更精准。做数据项目时最怕的就是 Stakeholder 没有事先对齐指标口径交付时才发现做的是另一套。处理这类问题的有效手段是在项目启动时就输出一份口径文档让所有 Stakeholder 签字确认同时明确每个迭代的 deliverable 和验收标准。这些词不只是词汇更是项目管理的表达工具。7.3 高频词的记忆方式与扩展建议最后说一个学习方法。很多人背数据词汇是拿来一本词典干啃今天背“denormalization”明天背“shuffle”后天就忘。我的习惯是把词汇挂到具体场景里记比如在你处理“重跑任务导致数据翻倍”的那一天记住 Idempotency在你排查“上游数据迟到导致窗口结果不对”的那一天记住 Watermark 和 Late Data在业务质疑“口径不一致”的那一天记住 Data Lineage。一个词配一个真实的踩坑片段记忆牢固得多。我给自己定的方法是建一张“场景-词汇-案例”表每遇到一个新场景就随手记下来积累多了就是自己的数据词典。这也是开头说这篇“待更新”的原因——大数据领域的词汇还在随着新的架构、新的工具持续出现词表本身就不该是静态的。如果你在自己的工作环境里也遇到了一些高频但让人挠头的英文词欢迎记下来一起交流我会持续把这些新的表达整理进这份速查表里让后来的人少翻一点文档、多省一点时间。