★ FEATURED ARTICLE 干这一行的人都知道大数据领域有个很尴尬的新手墙技术文档能看懂代码能跑通但一开会就露馅儿——大家嘴里蹦出来的全是英文缩写和术语HDFS、YARN、Shuffle、血缘、水位线听着都耳熟真让你解释明白或者让你用这个词说清楚一个业务场景就卡壳了。这份词汇整理不是我拍脑袋写的是我这些年带新人、做项目评审、写技术方案时被问到最多、也最容易被混淆的一批词。我按基础设施、计算引擎、存储查询、流处理、数据治理这几个实际工作场景分了类每个词不光说它是什么意思还讲它解决什么问题、在什么场景下你会碰到它最后附了排查经验。适合刚入行的大数据开发、数据分析师也适合那些要和数仓团队打交道的产品经理和业务同学。总之这份东西能从根上帮你把听天书的问题解决掉。1. 为什么要把常英文词汇单独拎出来整理先说个我自己的经历。早些年带一个新人做数仓需求我让他去查一下这个任务在YARN上的资源使用情况他在终端敲了半天命令也没找到入口回头问我YARN是什么。我当时挺意外因为这个词在那批人里基本属于默认你会的知识。后来我做了一次小范围摸底发现很多做了半年多报表开发的人对YARN、Shuffle、血源这类的概念还是停留在听说过的层面能说出三句话以上的人不超过三分之一。这不是个例。大数据这个行当有个特点核心概念大多来自英文论文和开源项目文档中文资料又喜欢直接夹英文导致你学到的每个词都是碎片式记忆——知道这个词的存在但不知道它在整个技术栈里处于什么位置和上下游什么关系。这种状态很危险因为排查问题的时候你连该往哪个组件去看都不知道更别提定位根因了。所以我整理词汇有一个原则按工作流来分组不按字母表来排列。你日常做数据开发接触的词汇顺序其实是有逻辑的——先是数据存到哪HDFS然后谁去调度资源YARN再是计算引擎怎么跑Spark/Flink跑完的数据放哪数仓/OLAP最后是数据怎么保证质量治理和血缘。按照这个顺序去理解每个词你会发现它们不再是孤立的术语而是一套完整的技术叙事。另一个原因是很多词的翻译一塌糊涂。比如Shuffle直译是洗牌但它真正描述的是数据在分布式环境下跨节点重新分配的过程再比如Watermark直译水印在流处理里它反而是数据延迟的最大容忍度。这些词如果只看字面意思理解一定会跑偏。我用这张表把字面意思和实际含义的差距直接点破能省掉大量自己瞎琢磨的时间。2. 基础设施层的核心词汇分布式文件系统与资源调度2.1 从HDFS到对象存储数据到底是怎么放下的HDFSHadoop Distributed File System分布式文件系统是大数据最底层的存储基石。它的大思路是把一个大文件拆成很多小块分散放到集群的不同机器上。默认情况下一个文件块Block是128MB早期是64MB每个块在集群里默认存三份副本。这里要理解一个关键点它不是RAID那种硬盘级别的冗余而是机器级别的冗余——同一份数据的不同副本放在不同节点上某个节点宕机了数据从另外的节点照样能读出来。注意HDFS适合一次写入、多次读取的大文件场景特别不适合大量小文件和频繁随机写。如果你的业务每天产生几百万个小文件直接往里怼NameNode的内存迟早被元数据撑爆。这是新手踩得最多的坑没有之一。NameNode 和 DataNode是HDFS的两个角色。NameNode管元数据文件目录、块位置、副本信息相当于图书管理员只记哪本书在哪个书架不搬书DataNode真正存数据块相当于书架本身。实际运维中NameNode是单点虽然现在有联邦和HA方案但它的内存大小基本决定了集群能存多少文件。Object Storage对象存储是另一个常见存储方案比如S3或者开源的对象存储系统。它的思路不是文件目录树而是桶Bucket加键Key的扁平模型。好处是扩展性极强、对小文件也友好、成本低缺点是延迟比HDFS稍高、对追加写支持弱。现在很多湖仓一体架构把数据底座放在对象存储上而把HDFS保留给对IO要求高的计算场景。二者不是替代关系而是按场景选型。2.2 YARN和资源调度你的SQL是怎么跑起来的YARNYet Another Resource Negotiator直译又一个资源协调器但它的真实身份是集群的操作系统内核。你在Hive或者Spark提交一个任务任务本身不关心集群有多少CPU和内存它只向YARN申请资源YARN再把这些资源以**Container容器**的形式分配给你任务跑完资源自动回收。这种计算和存储分离调度的设计让同一个HDFS集群上可以同时跑SQL、跑机器学习、跑实时流任务互不干扰。资源调度的核心概念有三个队列Queue、优先级Priority、弹性Elasticity。生产集群一般会按业务线划分多个队列每个队列设置容量上限防止某条业务线把资源占满拖死别人。优先级则是控制同一队列里先跑谁的开关。我曾经遇到过凌晨大任务把资源全部抢走导致白天的报表任务排队几小时的故障——根源就是队列配置没做隔离一个占满全集群其余全部陪跑。Cluster Mode vs. Client Mode也是面试和实战里的高频词。简单说客户端模式里你的提交节点作为Driver参与计算如果提交节点挂了任务就没了集群模式下Driver被放到集群内部提交节点和任务运行完全解耦。生产环境一律用集群模式提交这条我用血泪教训验证过。3. 计算引擎层的常用术语从MapReduce到Spark3.1 聊透Shuffle这个性能杀手到底干了什么Shuffle写代码的时候未必直接碰到它但你的每个任务几乎都会发生。它的本质是把数据打散重排上游每个节点处理完自己的数据后按照下游需要的规则比如按某个Key重新分区把数据通过网络传到对应节点上。举个例子你有100个Map任务要做一个全局的Group By每个Map的输出里有各个Key的碎片数据只有把相同Key的数据全部汇聚到同一个Reduce任务才能计算出正确结果——这个跨节点搬运并归类的过程就是Shuffle。为什么说它是性能杀手因为Shuffle涉及磁盘读写和网络传输是整个分布式计算里最慢、最容易出问题的环节。生产调优中控制Shuffle数据量是核心目标能过滤的字段提前过滤能合并的小文件提前合并。Spark里有一个参数叫做Shuffle Partitions默认200很多性能问题都出在分区数设置不合理上——设太小单个任务数据量过大设太大小任务太多调度开销反而更高。没有万能值要按数据量去试。还有一个相关概念叫数据倾斜Data Skew。它说的是某几个Key的数据量远大于其他Key导致大部分任务跑完了那两三个任务还在那儿磨蹭。最常见的一句报错就是某个Stage 99%都没问题就是最后那几个任务卡住。解决思路通常是加盐Salting把大Key拆成多个带随机前缀的小Key做完局部聚合后再去掉前缀做全局聚合。这个技巧看似简单实际用起来很考验对业务的理解——不是所有聚合都能安全加盐得看你是不是做去重这类操作。3.2 Spark、Flink的运行时词汇Driver、Executor、Job、DAGDriver是Spark应用的大脑负责任务调度、分发和结果汇总Executor是工人真正在你申请的Container里跑任务。这里有个容易混淆的坑你的Spark代码里定义的变量和方法只有Driver能看到全局状态Executor各自在不同的JVM里闭包引用的变量如果不做特殊处理比如累加器根本不会按你预期共享。DAGDirected Acyclic Graph有向无环图是Spark把一个复杂计算拆解成执行计划的核心结构。你的SQL或者DataFrame代码会被翻译成一系列StageStage之间有依赖关系但整体不允许有闭环所以叫无环。理解DAG最大的用处是搞懂为什么我的任务被拆成了这么多Stage以及为什么Stage N走不动——在Spark UI上DAG图就是排查性能瓶颈的第一现场哪个Stage时间长哪个Stage里数据量大一眼就能定位。提示Spark UI是每个Spark开发者的必备工具。任务慢第一反应不是改代码而是先打开UI看Stage耗时分布和Shuffle数据量。很多时候问题不在代码逻辑而在资源参数和分区策略。宽依赖和窄依赖这两个词是理解DAG和故障恢复的钥匙。窄依赖一个父RDD分区只被子RDD的一个分区使用不需要跨节点传输宽依赖一个父分区被多个子分区消费必然产生Shuffle。窄依赖的容错恢复快只要重算丢掉的父分区就行宽依赖一旦某个分区丢失可能要把上游全部重算一遍。写代码时多设计窄依赖的操作链能显著降低任务失败后的恢复成本这个细节很多人忽略。4. 存储与查询层的词汇数仓模型和OLAP的世界4.1 Hive、数仓分层、事实表和维度表Hive这个词在老一代人嘴里几乎就等于离线数仓。它的本质是把SQL翻译成MapReduce/Spark程序跑在HDFS上所以它解决的痛点是让不会写Java的分析师也能用SQL处理大数据。Hive还有一个关键词是Metastore元数据存储——你建立的每个库、每张表、每列的结构信息都存在这里。日常碰到建了表查不到或者表结构变了但查询没感知八成是元数据缓存没刷新而不是数据本身丢了。数仓领域的一套标准词汇是分层ODS原始数据层、DWD明细数据层、DWS汇总数据层、ADS应用数据层。这套分层的价值不是代码洁癖而是责任边界——每一层解决一类问题上游变了不影响下游指标口径在DWS统一收口。我见过不少团队一开始图省事直接ODS算完就出报表结果三周后需求一变所有报表脚本重写这就是没分层的代价。分层可以简化但绝对不能省。事实表Fact Table记录业务过程产生的度量值比如订单金额、点击次数特点是行会一直追加维度表Dimension Table描述业务对象的属性比如用户城市、商品类目特点是特征相对稳定、会缓慢变化。这两类词是做任何数据分析建模的基础。判断一个需求应该查哪张表先问自己是看发生了多少还是看它长什么样——前者找事实表后者找维度表。宽表Wide Table是把事实和维度提前拼好的一张超宽大表。宽表用起来很爽一条SQL查完不用再JOIN。但代价是存储膨胀和计算量上涨因为冗余了太多维度字段。我的经验是三层以内能查清楚的不要刻意做宽表指标特别多、查询频率又高的场景才值得不然你维护字段一致性的痛苦会反超它的便利。4.2 从慢查询看OLTP和OLAP的路线之争OLTP联机事务处理和OLAP联机分析处理是所有存储系统开篇就会讲的两个词。OLTP系统比如你业务后台的MySQL的核心特点是高并发、短事务、以行操作为主OLAP系统比如数仓里的列式存储引擎的核心特点是大规模批量扫描、聚合分析为主、不在乎单条数据的写入延迟。如果一个需求是查一个用户最近十笔订单那是OLTP的活如果是统计全站用户近三十天复购率那就是OLAP的活。生产环境最常见的翻车现场就是把OLAP的大查询跑到OLTP库上。早些年我遇到过业务方把数仓的分析任务直接挂在业务数据库上还把几十张表JOIN在一起做汇总结果业务高峰期数据库CPU直接打满前台接口超时。后来把所有分析查询全部迁移到数仓引擎问题才彻底消失。所以这两个词不光定义架构更规定使用边界。列式存储Columnar Storage是OLAP引擎高效的关键。传统行存把一行的所有字段放在一起而列存把同一列的数据放在连续区域。好处是查询只需要扫描用到的列不用的列根本不读取大大减少了IO同一列的数据类型相同压缩比也更高。你在看Parquet、ORC这类文件格式时核心一定要理解它为什么按列存储——答案就在分析型查询的访问模式里。5. 流处理与实时计算Kafka到Flink的常用词5.1 Kafka是消息队列还是存储系统Kafka是实时数据管道的事实标准它同时扮演两个角色消息队列和分布式日志存储。数据在Kafka里以Topic为单位组织生产端写入消费端读取。它的设计核心是把数据按Partition分片每个Partition内部的数据是有序追加的消费者按**Offset偏移量**记录自己读到哪了。这个Offset机制是整个Kafka消费语义的基石。很多刚接触实时计算的人会混淆消息消费完就没了吗这个问题。Kafka不是那种一条消息只能被一个消费者读一次的传统队列它是一个持久的日志消息按保留策略存储默认七天不同消费者组可以互不影响地各自消费同一批数据。这也是它既能支撑实时流计算又能支撑离线批量回放的原因。Consumer Group消费组是一个很重要的概念。同一个组里的消费者分工消费同一个Topic的分区组内一个分区只能被一个消费者处理这是为了防止重复处理同一批数据。但跨组消费互不干扰——比如数据链路里有一个实时画像任务和一个实时监控任务它们各自一个Group同时消费同一份埋点日志谁也不会影响谁。如果遇到了消息没人消费或消费速度上不去的问题第一步永远是检查分区的并行度和消费组里的消费者数量是否匹配。5.2 从 Watermark 到 Backpressure实时计算的灵魂词汇Watermark水位线是Flink中事件时间语义的核心机制。实时数据从产生、经过网络传输到进入计算引擎必然会有一个延迟叫乱序。比如一个传感器10:00:01产生的数据可能10:00:03才到。那你做窗口聚合的时候窗口要到什么时候才算数据齐了可以输出水位线就是为此设计的——它是一个提前预设的乱序容忍度。假设你设置延迟5秒那么只有当时钟推进到窗口结束时间5秒时系统才认为该窗口的数据收集完毕并触发计算。注意水位线设置太小会频繁触发迟到的数据被丢弃设置太大窗口计算结果的延迟就会变长。生产环境里这是实时任务调优的一个核心权衡点没有标准答案要结合业务对延迟和数据准确性的容忍度来定。数据去重场景通常宁可等久一点实时大屏则可以牺牲一点准确性换延迟。Backpressure背压是流处理里下游处理不过来、上游还在一直灌数据时产生的一种反作用力。Flink天生有一套机制来应对背压下游处理不动时会逐步把压力反馈到上游让上游放慢速度如果压力实在太大数据会在某个环节积压。排查实时任务卡顿看的是数据积压量和反压状态。出现背压不要慌先看是临时波峰还是常态性性能瓶颈——临时波峰扛一扛就过了常态性的就要考虑加并行度、优化算子或者拆业务流程了。流处理里还有几个高频词值得一起记掉At-least-once至少一次和Exactly-once精确一次描述了处理语义前者允许重复但不丢后者理论上每条数据只生效一次。很多人一听精确一次就觉得绝对不重复实际生产中它是靠状态存储事务提交配合实现的而下游输出系统如果本身不支持事务最终仍然可能重复。所以你在设计实时链路时一定要问清楚数据重复了业务容忍吗如果不容忍那Kafka的幂等生产者、事务API和下游的幂等消费都要一起考虑上缺一环都不行。6. 数据治理与质量词汇从元数据到数据血缘6.1 元数据体系和数据血缘到底记录了什么元数据Metadata是关于数据的数据。表名、字段类型、创建时间、负责人、健康度、调度信息都属于元数据。元数据治理的价值用一个场景就能说清新来的同事要做一个报表他不知道该用哪张表不知道这个字段是下单口径还是支付口径只好挨个问人。如果你有一套完整的元数据平台表含义、字段口径、更新频率一目了然——这就是元数据治理在降低协作成本上的直接体现。数据血缘Data Lineage则记录数据从哪儿来、经过了哪些加工、最终流向哪里。比如你看到某张报表上的字段血缘能回溯出它来自哪张ODS表、经过了几层SQL加工、哪段逻辑做了过滤和拼接。血缘图在排查为什么两张表对不上数、评估这张表改动会影响下游哪些应用以及合规审计时用处巨大。我实际追踪过一类疑难故障每天凌晨报表跑批偶尔会出现数据延迟一开始怀疑是计算资源问题后来顺着血缘图回溯发现是一条底层数据同步任务在特定日期触发了重跑逻辑数据晚到了一小时导致整条链路上的所有任务顺延。没有血缘关系图这种跨任务影响的定位会非常困难。6.2 数据质量、主数据治理、以及 Schema 的那些事数据质量Data Quality是一套衡量数据可信度的指标体系最常见的几个维度是完整性有没有缺失值、准确性数值是否和真实世界相符、一致性同一个指标在数仓各层的口径是否统一、及时性数据是否按时产出。每家公司都会有一些看板专门监控数仓表的质量规则比如订单表今日新增数据量不少于昨日80%否则告警。这种用规则自动卡质量的方式比出了问题再找人大骂有效得多。主数据Master Data是企业里跨系统共享的核心基础数据比如用户ID、物料编码、部门组织机构。主数据治理的意义在于一套标准、多处共用。如果订单系统的用户ID和CRM系统的用户ID定义不一样那做跨系统分析就成了灾难。遇到过最多的问题是同一个用户在两套库里ID对不上解决办法通常是在数据湖或者数仓里建一张主数据映射表用一个全局唯一标识串起各系统的局部标识。Schema这个词在不同地方含义有些微差别但本质都是数据的结构定义。离线数仓里它指表的字段集合和约束在Kafka里它是消息的格式定义在数据湖框架里它可能是文件内的字段结构。Schema Evolution结构演化指的是表结构在不停微调比如加一列、改一个字段类型。这在生产环境里是个大坑下游任务解析上游消息结构上游一加字段如果用严格模式下游直接反序列化失败如果用宽松模式新旧数据格式混在一起又容易出脏数据。应对方案是上游变更前一定要做兼容性评估以及给下游留出缓冲期不要上午改格式下午就生效。7. 词汇速查表与记忆技巧最后把上面讲的词汇做一张速查表适合贴在工位上随时翻。这张表我是按你听到这个词时应该想到什么来设计的不追求面面俱到只求快速唤起记忆。词汇一句话含义你何时会碰到它HDFS把大文件切块多副本存在多台机器上的文件系统数据落盘、存储选型、小文件治理NameNode / DataNode管理元数据的管理员 / 真存数据的书架集群容量规划、文件数量告警YARN给集群任务分配CPU和内存的调度器任务排队、资源不足、队列配置Shuffle数据跨节点重新分配的过程性能调优、Stage卡住数据倾斜某些Key数据量远大于均值导致任务不均任务长尾、聚合SQL变慢DAG计算任务拆成的有向无环执行图Spark UI、Stage耗时排查窄依赖 / 宽依赖父分区只被一个子分区用 / 被多个子分区用故障恢复慢、任务重算事实表 / 维度表存度量事件 / 存描述属性建模设计、需求分析OLTP / OLAP高并发短事务 / 大查询复杂分析存储选型、慢查询治理列式存储按列连续存放数据的文件格式高压缩比、分析查询优化Kafka Offset消费者读取消息的位置标记消息积压、消费重复Watermark乱序数据的最大容忍时间窗口计算延迟、丢数排查Backpressure下游跟不上导致上游被拖慢的现象实时任务卡顿、反压监控元数据描述数据的数据数据地图、口径管理数据血缘数据加工链路的上下游关系影响分析、故障溯源Schema Evolution表结构随时间变化的处理策略上游字段变更、下游解析失败关于怎么记这些词我的经验是别死记定义用场景索引去记。比如你改天遇到任务一直Pending的问题就去查YARN遇到窗口数据迟迟不输出就去查Watermark和事件时间遇到对不上数顺着血缘和元数据一步步追。把词挂到问题上每个词背后都粘着一个真实的故障场景这比任何单词软件都记得牢。还有个小技巧给自己建一个行业术语收集本每次开会、读文档、看PRD遇到不确定的词就记下来一个月后回看会发现高频词就那几个翻来覆去都是它。这份待更新的词汇表我是打算一直往里面补的——流批一体、湖仓一体、数据编排、DataOps、数据产品化这些词正在慢慢变成新的人口中的高频词。后面每接触一批新项目我就会回来更新一次类似这样的词汇积累用不了半年你再去参加会议那种听不懂的焦虑感基本就能消掉一大半。
阅读完成 · 觉得有帮助？
