大数据工程师必知：技术文档高频英文词汇解析

最近带了个新来的同事他基础不错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、FollowerMaster主节点负责管理和分配任务通常也是整个集群的“大脑”。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 与 LakehouseData Warehouse数据仓库面向分析场景的集中式数据存储数据经过清洗、建模通常存储在关系型结构里。Data Lake数据湖存储任意格式的原始数据保留数据的原始样貌。Lakehouse湖仓一体把数据湖的低成本存储和数据仓库的治理、性能优势合在一起。不少人在简历上写“搭建数据仓库”一问细节数仓分层、维度建模根本没概念。Data Warehouse 词本身不难难的是背后的建模方法论。建议入行的人先搞懂什么是 ODS、DWD、DWS、ADS这些虽然是缩写但本质就是数仓里的层级划分。4.2 Fact Table 与 Dimension TableFact Table事实表记录业务事件的数据比如订单表、支付流水表量很大键通常包含多个外键。Dimension Table维度表描述业务对象属性的数据比如用户维表、商品维表。Star Schema星型模型事实表在中间维度表围绕在旁查询像星星一样展开是最常见的建模方式。Slowly Changing Dimension缓慢变化维维度属性会随时间变化常见有 SCD1 直接覆盖、SCD2 保留历史版本、SCD3 只保留上一版。5. 数据开发流程里的英文黑话5.1 ETL 与 ELTETL抽取、转换、加载先从源系统抽数据再到中间层做清洗转换最后加载到目标库。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 LineageMetadata元数据描述数据的数据比如表的字段、类型、分区信息、负责人。Data Catalog数据目录把元数据集中起来提供检索和查看能力。Data Lineage数据血缘数据从哪来、经过哪些加工、最终到哪去全链路的流向关系。在强调数据治理的公司里Data Lineage 几乎是必查项。业务方问你这个指标怎么算出来的你打开血缘图一眼看到从源表到汇总表的每一步加工逻辑这比翻半天文档强太多。6.2 Data Quality 与 SLAData 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 做数据追踪能列出一个链条说明你对整个数据流向是清晰的。列不出来说明该补课了。这份词汇表会持续更新。大数据这行工具更新快词库也跟着变。这次整理的主要是存储、计算、数据仓库、调度、治理这些常青部分之后遇到新的高频词我还会补齐进来。根据个人经验你只要把这些词从“眼熟”混到“能用”翻技术文档的速度至少快一倍排查问题的思路也会清楚很多。