企业官网建设流程全解析

最近带了个新来的同事，他基础不错，SQL写得也溜，结果一拿到英文技术文档就卡壳。不是看不懂单词，是搞不懂一堆词放在一起到底在说什么。比如看到“backfill”他不知道是要补数据，看到“shuffle”也完全想象不出这个动作发生在哪一步。这种场景我见得太多了，干大数据这行，你要是不把这些常见英文词汇当成基本功，光靠中文博客和二手资料，走不远。

这篇文章就是一份我自己整理的大数据常见英文词汇，标题带“待更新”，意思是说这玩意儿本来就是个动态清单，技术栈一变、业务场景一变，词汇表自然要跟着长。我尽量按实际使用频率来排序，把平常开会、写代码、看文档、面试里出现率最高的词先讲清楚。

1. 为什么劝你把这些词当成基本功

1.1 从一次被英文文档卡住说起

有一次我要给实时计算任务调优，查官方文档，通篇都是“exactly-once”“state backend”“checkpoint”这些词。中文资料里有人翻译成“精确一次”“状态后端”“检查点”，翻译得没错，但你拿这个去搜英文社区、跟人对问题，根本对不上号。反过来，你要是脑子里直接存英文，看完就会知道这说的是哪几个模块，出了问题也知道去哪个参数附近找。

所以我把这些词当成基本功，不是说英语有多高级，而是因为大数据这个领域的源头就是英文文档、英文社区、英文代码注释。你可以不精通英文，但常用词一定要做到“看到就能反应出场景”。

1.2 术语背后是一整条技术脉络

一个词往往不是独立存在的。比如“partition”这个词，在 HDFS 里指文件的数据块分片，在 Kafka 里指主题的分区，在 Spark 里又指 RDD 的分区。同一个词，在不同框架里都有自己的一套机制，但核心思路都是“把一个东西切碎、分散处理”。所以先懂词根的意思，再看它在具体框架里的玩法，会顺很多。

1.3 这份清单该怎么用

我建议你把它当成自测表，而不是阅读材料。你可以盖住英文列，看中文能说出对应英文算过；盖住中文列，看英文能说出大概含义和使用场景算过。两关都过了，才能叫掌握。不然只是“看着眼熟”，一写就手生，白搭。

2. 大数据最核心的十来个词，先背烂它

2.1 5V 家族

• Volume（数据量）：指数据的规模，动不动就是 TB、PB 级别。你在简历上写“处理过 10 亿条数据”，别人问你数据量大在哪，本质就是在考 Volume。
• Velocity（速度）：指数据产生和处理的速度。电商大促每秒产生多少订单、日志系统每秒产生多少条日志，都是 Velocity 的范畴。
• Variety（多样性）：指数据来源和格式的多样，有结构化、半结构化、非结构化。
• Veracity（准确性）：指数据的可信度。数据脏、重复、缺失，都是准确性问题。
• Value（价值）：指数据分析后能带来的商业价值。这五个 V 是做大数据最基础的概念，面试开场白特别喜欢问。

2.2 Cluster、Node 与水平扩展

• Cluster（集群）：一堆机器（节点）连在一起干同一件事，对外看起来像一台超级电脑。
• Node（节点）：集群里的单台机器。
• Horizontal Scaling（横向扩展）：通过加机器提升处理能力。与之相对的是 Vertical Scaling（纵向扩展），就是给单台机器加内存加 CPU。

我常见很多人把分布式和集群搞混。其实集群强调的是“一堆机器协同”，分布式强调的是“任务分散到多台机器上处理”。集群是实现分布式的一种常见形态，但不是唯一形态。

2.3 Master、Slave、Leader、Follower

• Master（主节点）：负责管理和分配任务，通常也是整个集群的“大脑”。
• Slave（从节点）：负责干活，听主节点指挥。
• Leader（领导者）：在分布式协调场景里，多个节点通过选举产生一个领导，负责写请求或关键决策。
• Follower（追随者）：同步 Leader 的状态，在部分框架里能读不能写。

现在很多开源框架把 Slave 改叫 Worker 或 Follower，因为“slave”这个词有不好的暗示，但老文档里还经常能看到。看到别懵。

2.4 Job、Task、Stage 的关系

在大数据计算引擎里：

• Job（作业）：一次完整的计算请求。
• Stage（阶段）：一个 Job 被拆成若干个阶段，阶段之间是有依赖关系的。
• Task（任务）：每个 Stage 里真正被并行执行的最小工作单元。

举个例子，一个 Spark 任务跑起来之后，你在 UI 上先看到 Job，点进去有多个 Stage，每个 Stage 又包含几百个 Task。排错的时候先看失败的是哪个 Stage，再定位到具体 Task 占用的数据和处理逻辑，这个思路就是从这里来的。

3. 存储与计算引擎的词，翻文档必备

3.1 HDFS 相关词汇

• NameNode（命名节点）：HDFS 的元数据管理节点，记录文件目录、文件块映射。
• DataNode（数据节点）：真正存数据的节点。
• Block（数据块）：HDFS 文件被切成固定大小的块存储，默认通常 128MB。
• Replication（副本）：同一个块存几分，默认三副本，目的是容错。
• Rack Awareness（机架感知）：副本放置策略会考虑物理机架，让副本分散在不同机架，防止一个机架断电全丢。

之前有个踩坑案例，某公司为了省存储把副本数改成 2，结果一个大版本上线前磁盘坏了，数据直接找不回来，最后只好从备份恢复，耽误了半天。做生产环境，副本数别乱调，调之前一定想清楚容灾需求。

3.2 Spark 里高频出现的词

• RDD（弹性分布式数据集）：Spark 最核心的数据抽象，可以理解成分布式的集合。
• DataFrame / Dataset：带 Schema 的分布式数据集，比 RDD 有更高的执行效率。
• Transformation（转换）：懒执行的算子，比如 map、filter、join，它不立刻计算。
• Action（行动）：触发真正计算的算子，比如 count、collect、save。
• DAG（有向无环图）：Spark 把执行计划构造成 DAG，方便优化。
• Shuffle（洗牌）：数据重新分区分发的过程，也是很多性能问题的主要来源。
• 宽依赖与窄依赖：窄依赖是每个父分区只被一个子分区使用；宽依赖是多个子分区依赖同一个父分区，宽依赖会引发 shuffle。
• Checkpoint（检查点）：把中间结果写到可靠存储，避免计算链过长导致数据丢失。

这里重点说 Shuffle。很多新手调优不知道从哪下手，其实大部分慢任务都卡在 shuffle 阶段。因为数据要跨节点传输，还要排序、聚合，网络和磁盘的开销很高。遇到 task 倾斜、数据倾斜，先查是不是某些 key 的数据量太大，再考虑加盐打散或调整并行度，这些都是在处理 shuffle 的问题。

3.3 Flink 与流处理的词

• Streaming（流处理）：数据源源不断输入，边到边处理。
• Event Time（事件时间）：数据真实发生的时间。
• Watermark（水位线）：用来处理乱序事件的机制，表示“在这个时间点之前的数据基本都到了”。
• State（状态）：流式计算中需要保存的中间信息，比如计数、聚合值。
• State Backend（状态后端）：状态存储的位置和方式，常见有内存、文件系统、RocksDB。
• Checkpoint（检查点）：Flink 定期做状态快照，用于故障恢复。
• Exactly-Once（精确一次）：每条数据恰好被处理一次，不丢也不重。

流处理和批处理最大的区别在于：批处理是“今天的数据明天算”，流处理是“数据到了就得尽快算”。你要是从事实时数仓相关工作，这些词比 Spark 的还要常出现。面试的时候能说出 Watermark 和 Checkpoint 的配合原理，就已经超过很多人了。

3.4 Kafka 那一串词

• Topic（主题）：消息的分类，类似数据库里的表。
• Producer（生产者）：发送消息的一方。
• Consumer（消费者）：消费消息的一方。
• Consumer Group（消费组）：一组消费者共同消费一个或多个主题，同一个分区只能被组内一个消费者消费。
• Partition（分区）：Topic 被拆成多个分区，并行处理的基础。
• Offset（偏移量）：消费者在分区内的消费位置。
• Replica（副本）：分区数据的拷贝，保证高可用。
• Consumer Lag（消费滞后）：消费者落后于生产者的消息条数。

我之前排查过一个实时链路问题，数据延迟越来越大，最后发现是消费组里某个消费者实例挂了，分区没人消费，导致 lag 一直涨。你说这些词不熟的话，连问题描述都写不清楚，更别谈定位了。

4. 数据仓库与建模的词，做数开绕不开

4.1 Data Warehouse、Data Lake 与 Lakehouse

• Data Warehouse（数据仓库）：面向分析场景的集中式数据存储，数据经过清洗、建模，通常存储在关系型结构里。
• Data Lake（数据湖）：存储任意格式的原始数据，保留数据的原始样貌。
• Lakehouse（湖仓一体）：把数据湖的低成本存储和数据仓库的治理、性能优势合在一起。

不少人在简历上写“搭建数据仓库”，一问细节，数仓分层、维度建模根本没概念。Data Warehouse 词本身不难，难的是背后的建模方法论。建议入行的人先搞懂什么是 ODS、DWD、DWS、ADS，这些虽然是缩写，但本质就是数仓里的层级划分。

4.2 Fact Table 与 Dimension Table

• Fact Table（事实表）：记录业务事件的数据，比如订单表、支付流水表，量很大，键通常包含多个外键。
• Dimension Table（维度表）：描述业务对象属性的数据，比如用户维表、商品维表。
• Star Schema（星型模型）：事实表在中间，维度表围绕在旁，查询像星星一样展开，是最常见的建模方式。
• Slowly Changing Dimension（缓慢变化维）：维度属性会随时间变化，常见有 SCD1 直接覆盖、SCD2 保留历史版本、SCD3 只保留上一版。

5. 数据开发流程里的英文黑话

5.1 ETL 与 ELT

• ETL（抽取、转换、加载）：先从源系统抽数据，再到中间层做清洗转换，最后加载到目标库。
• ELT（抽取、加载、转换）：先抽数、加载到数据仓库，再在仓库里做转换，适合基于大数据引擎进行处理。

这几年 ELT 越来越常见，因为数仓引擎本身计算能力强，转换放后面，能减少中间环节的数据搬运。我早期做项目都是 ETL，后来切到 ELT，发现代码干净很多，调试也方便。核心原因就是“转换”这一层的位置变了，放源头做是 ETL，放目标侧做是 ELT。

5.2 增量与全量

• Full Load（全量加载）：把整张表的数据全部同步一次。
• Incremental Load（增量加载）：只同步变化的部分。
• Backfill（回填）：因为数据晚到或逻辑修正，重新计算历史某段时间的数据。

我见过很多新人听到“回填”两个字一脸蒙。其实说白了就是历史算错了或没算，得重跑一遍。Backfill 在实时任务里尤其常见，上游数据迟到几个小时，下游作业重新把这几小时的数据补上。

5.3 调度与依赖

• Schedule（调度）：按时间或事件触发任务执行。
• Dependency（依赖）：上游任务跑完，下游才能跑。
• Workflow（工作流）：多个任务编排起来形成一个整体流程。
• Cron（定时表达式）：用表达式描述执行周期，比如每天凌晨跑一次。

调度系统的词看起来简单，但实际项目里依赖关系经常乱成一锅粥。特别是临时任务和例行任务混在一起，谁先谁后全靠猜。我建议在设计工作流时，明确把每个任务的数据输入输出标注出来，谁的输出是别人的输入，谁就得排在前面，这个思路比记一堆调度表达式更重要。

6. 数据治理与质量，进阶必备的词

6.1 Metadata 与 Data Lineage

• Metadata（元数据）：描述数据的数据，比如表的字段、类型、分区信息、负责人。
• Data Catalog（数据目录）：把元数据集中起来，提供检索和查看能力。
• Data Lineage（数据血缘）：数据从哪来、经过哪些加工、最终到哪去，全链路的流向关系。

在强调数据治理的公司里，Data Lineage 几乎是必查项。业务方问你这个指标怎么算出来的，你打开血缘图，一眼看到从源表到汇总表的每一步加工逻辑，这比翻半天文档强太多。

6.2 Data Quality 与 SLA

• Data Quality（数据质量）：准确性、完整性、一致性、及时性等。
• SLA（服务等级协议）：你和业务方约定好的保障标准，比如“每天六点前产出昨日报表”。
• Data Profiling（数据探查）：对数据内容进行分析，看分布、空值、异常。

数据质量的问题，通常不是技术问题，而是管理问题。数据质量规则没定，格式变了没人管，字段删了没人通知，下游跑挂了才开始紧急排查。所以做数据开发的，手里要有 SLA 意识，先把“产出时间、正确性标准”谈清楚，后面少背锅。

6.3 脱敏、分级与保留

• Data Masking（数据脱敏）：对敏感字段做变形处理，比如手机号中间四位打星。
• Data Classification（数据分级分类）：对数据按敏感程度分类，比如公开、内部、机密。
• Data Retention（数据保留策略）：数据该存多久，超过期限要清除或归档。
• Backup（备份）：对数据做定期拷贝。
• Disaster Recovery（容灾）：在故障场景下能快速恢复系统服务。

合规这块现在越来越重要，我在的项目里，只要涉及用户手机号、身份证号，一律脱敏之后才能给下游用。这个意识最好入行就有，别等安全团队来通知才补。

7. 经验谈：这些词在面试和实战中的用法

7.1 面试里的“词汇理解”考法

面试官问“你了解数据倾斜吗”，重点不是让你翻译“data skew”，而是让你说清楚现象、原因、解决方案。我一般这么回答：

• 现象：某个任务运行特别慢，或者某些 Task 处理的数据量远大于其他 Task。
• 原因：数据分布不均，比如某个热点 key 占了大部分数据。
• 处理思路：拆分热点 key、加随机前缀、调整并行度、使用广播 join 等。

所以词汇表看着是单词，其实是帮你组织答案的结构。你不光要知道它叫什么，还要知道它对应哪个问题，有什么常见解法。

7.2 容易误解的几个词

• Scale Out（横向扩展）与 Scale Up（纵向扩展）：前者加机器，后者加配置。
• Idempotent（幂等）：同一个操作执行多次，结果和一次一样。写入场景特别重要，防止重复消费造成数据重复。
• Schema（模式/结构）：描述数据字段和类型的定义。
• Serialization（序列化）：把对象转成字节流，方便传输或存储。
• Deserialization（反序列化）：字节流转回对象。

举个例子，你写 Spark 任务往大数据存储里写数据，任务重跑了一遍，结果表里多了重复数据。如果写入逻辑是幂等的，重跑就没事；不幂等，就得先清理再重跑。这个场景里，Idempotent 不只是一个单词，而是一个设计原则。

7.3 词汇积累的方法

我自己的办法是“文档优先英文、笔记中英对照”。看官方文档时不直接看中文翻译，先猜词义，查了再对比。因为很多中文翻译都有偏差，比如“Job”在不同框架里有的指作业，有的指阶段任务，直接看英文原文反而不容易乱。

另外，把自己做过的项目用英文关键词列一遍，比如：

• 项目里用了 Kafka 做数据接入
• Spark 做离线清洗
• Flink 做实时汇总
• Hive 做数仓建模
• 用 DataLineage 做数据追踪

能列出一个链条，说明你对整个数据流向是清晰的。列不出来，说明该补课了。

这份词汇表会持续更新。大数据这行工具更新快，词库也跟着变。这次整理的主要是存储、计算、数据仓库、调度、治理这些常青部分，之后遇到新的高频词，我还会补齐进来。根据个人经验，你只要把这些词从“眼熟”混到“能用”，翻技术文档的速度至少快一倍，排查问题的思路也会清楚很多。