简介这是一份数据仓库中英文对照翻译资料面向数据仓库初学者、备考学生以及需要快速理解核心概念的技术人员。内容从数据仓库的产生背景讲起说明其与操作数据库的区别重点解析W.H.Inmon关于“面向主题、集成、时变、非易失”的经典定义并对四大特征逐一展开中英文对照阐述同时覆盖ETL过程、数据清洗、数据集市、OLAP等配套知识点帮助读者建立完整的数据仓库理论框架。资源为单个PDF文件大小约20KB轻量易读适合作为课堂笔记补充、面试或项目汇报前的速查手册。英文原文与中文译文相互对照便于同步提升技术英语阅读能力。目前已有122人学习下载适合希望系统掌握数据仓库基础并强化专业文献理解能力的读者。1. 数据仓库不等于数据库弄混术语是第一个坎很多人在看数据仓库资料时第一反应是去搜“数据仓库和数据库的区别”结果被一堆中英文混杂的解释绕晕。其实反直觉的真相是数据仓库不是一种数据库产品而是一套面向分析的数据处理体系。MySQL、PostgreSQL、Snowflake、ClickHouse都可以承载数据仓库但装上数据库不等于建好了数据仓库。这份以中英文翻译形式分享的PDF核心价值在于把散落在英文文档里的术语——fact table、dimension table、ETL、OLAP——还原成能直接用于工作交流的中文表达。对于刚接触数仓的工程师、从业务转数据岗位的分析师以及需要跟跨国团队对齐口径的技术管理者先把术语体系理清楚比急着写SQL更重要。本章不需要列任何定义只需记住一个判断标准凡是面向历史数据、多表关联、聚合查询的场景才需要数据仓库凡是面向单行增删改的业务系统那是OLTP的事。2. 数据仓库的核心建模概念与中英文术语对照2.1 维度建模不是玄学是围绕“事实”和“维度”的翻译题打开任何一本数仓英文教材前两章一定绕不开两个词fact和dimension。中文翻译通常叫“事实表”和“维度表”。但单纯记单词没有意义关键在于理解两者的关系。事实表记录业务事件比如订单、支付、日志维度表记录业务实体的属性比如用户、商品、时间。一个订单事实表通过外键关联到用户维度和商品维度就形成了星型模型。我在实际项目中见到最多的问题是新人把维度属性全部塞进事实表理由是“查询时少一次JOIN”。短期来看查询是快了但维度属性一旦变化比如用户手机号换了事实表的历史数据也跟着被污染。用代码说明这个问题。常见的错误建模方式是这样CREATE TABLE order_fact_wrong ( order_id BIGINT PRIMARY KEY, user_id BIGINT, user_name VARCHAR(64), user_phone VARCHAR(20), goods_id BIGINT, goods_name VARCHAR(128), category_name VARCHAR(64), order_amount DECIMAL(10,2), order_ts TIMESTAMP );这段建表语句的副作用是当用户改名或商品调整分类时必须用UPDATE语句回刷历史订单。数据量大时UPDATE成本极高而且容易错过部分行造成数据不一致。正确的星型建模应该拆成两张表CREATE TABLE dim_user ( user_id BIGINT PRIMARY KEY, user_name VARCHAR(64), user_phone VARCHAR(20), start_ts TIMESTAMP, end_ts TIMESTAMP ); CREATE TABLE fact_order ( order_id BIGINT PRIMARY KEY, user_id BIGINT, goods_id BIGINT, order_amount DECIMAL(10,2), order_ts TIMESTAMP );事实表只保留业务过程和可度量值维度属性全部下沉到维度表。提示start_ts和end_ts是缓慢变化维SCD的常用做法用来区分同一用户在不同时间段的属性状态。2.2 ETL与ELT的顺序之争“ETL”这个缩写在中文资料里几乎不翻译大家直接说“跑ETL”。但英文原文Extract-Transform-Load的顺序背后藏着对数据走向的取舍。传统ETL先做清洗转换再入库适合数据量有限、目标库是Oracle或SQL Server的旧式数仓。ELTExtract-Load-Transform则先把原始数据全部加载到数据湖或数仓中再利用数仓的算力做转换。现在云数仓和MPP数据库普及后ELT逐渐成为主流。选哪个不取决于潮流取决于团队分工。如果团队里SQL能力强ELT能让分析师直接操作原始数据如果团队里Java/Python工程师多ETL可以让他们在数据入库前用代码完成复杂清洗。我个人的倾向是入库前只做必要的数据类型校正和去重复杂的业务逻辑转换推迟到数仓内用SQL实现。这样原始数据被保留出问题时可以重新转换而不是重新抽取。2.3 常用数据仓库有哪些小型场景怎么选标题里的“常用数据仓库”指向选型问题。按部署方式分目前常见的是四类类型代表产品适合场景传统MPP数仓Teradata、Greenplum企业级大规模分析云原生数仓Snowflake、BigQuery、Redshift弹性伸缩、按量付费开源OLAPClickHouse、Doris、StarRocks实时分析、高并发查询数据湖查询引擎Presto/Trino、Spark SQL直接查询对象存储上的文件小型团队10人以内、数据量在TB以下的常见误区是一上来就上全套Hadoop体系。我见过的更务实的做法是业务数据量不大时用PostgreSQL或TiDB做数仓底座配合调度工具完成日级ETL需要实时分析时引入ClickHouse用物化视图处理聚合场景。提示选型时优先看团队的现有技术栈不要为了“高频词数据仓库”去引入一套没人维护的开源组件。3. 小型团队的数据仓库落地从建库到数据同步3.1 最小可用的数仓分层架构不管用什么引擎数仓分层是通用方法论。中文资料里常出现“ODS层”“DWD层”“DWS层”“ADS层”对应英文分别是Operational Data Store、Data Warehouse Detail、Data Warehouse Summary、Application Data Store。这四层不是上级要求而是工程上为了避免“烟囱式开发”被迫形成的隔离。ODS层保存原始数据不做任何业务修改DWD层做清洗和维度退化形成明细事实表DWS层按主题做汇总比如用户维度的当日累计值ADS层直接面向报表和应用。我见过最精简的团队会把DWS层省略让报表直接查DWD层。这种做法在小数据量下可行但一旦报表数量增多每次跑报表都要扫描全表明细资源开销成倍增长。建议至少保留一个轻量的汇总层。3.2 用Docker本地跑通数仓环境不依赖云服务在本地验证数仓流程最快的方式是用Docker启动一个PostgreSQL实例作为数仓。以下命令可以在本地快速拉起测试环境docker run -d \ --name dw_pg_test \ -e POSTGRES_PASSWORDdw_test_2024 \ -e POSTGRES_DBwarehouse \ -p 5432:5432 \ postgres:14启动后用psql连接并创建分层schemapsql -h localhost -p 5432 -U postgres -d warehouse在psql中执行CREATE SCHEMA IF NOT EXISTS ods; CREATE SCHEMA IF NOT EXISTS dwd; CREATE SCHEMA IF NOT EXISTS dws;参数说明POSTGRES_PASSWORD是初始化密码-p 5432:5432把容器内的5432端口映射到宿主机。创建三个schema的目的是让数据流转路径清晰可见。3.3 用SQL模拟一条ETL过程数仓的ETL未必需要Flink或Airflow小数据量阶段用SQL就可以完成。下面用INSERT INTO ... SELECT模拟从ODS层清洗到DWD层的过程INSERT INTO dwd.dim_user (user_id, user_name, user_phone, start_ts, end_ts) SELECT user_id, TRIM(user_name) AS user_name, REGEXP_REPLACE(user_phone, [^0-9], ) AS user_phone, start_ts, 9999-12-31 AS end_ts FROM ods.raw_user WHERE user_id IS NOT NULL AND user_name ;这段SQL做的事有三件去除用户姓名首尾空格、过滤电话中的非数字字符、过滤无效字段。逻辑说明清洗规则越简单越好不要在入库时做复杂的业务判断否则后续口径调整时改代码成本很高。REGEXP_REPLACE的具体语法在不同数据库中略有差异MySQL 8.0和PostgreSQL都支持SQL Server需要改用REPLACE嵌套。3.4 中英文翻译在建模时的实际作用这里要回应标题里的“中英文翻译”。做数仓建模时经常出现同一张表在不同文档里叫法不一致的问题。比如dim_user有人翻译成“用户维表”有人叫“用户维度扩展表”也有人直接保留英文表名注释里有写着“会员表”。我的建议是表名用英文与物理表一致注释和口径描述用中文并附上英文原文。例如COMMENT ON TABLE dwd.dim_user IS 用户维度表 (dim_user) - 对应用户注册信息;这种做法的好处是中方团队看注释秒懂外方团队看表名无歧义。中英文对照的意义不在于翻译本身而在于建立统一的沟通锚点。4. 数据仓库性能与数据质量分区、物化视图与校验4.1 分区策略是查询性能的分水岭数仓查询慢大概率是分区设计出了问题。没有分区的表即使数据量只有几百万行全表扫描也会拖垮资源。分区字段的选择遵循一个原则查询条件里最常用的过滤字段。对于订单明细表按日期分区是最常见的做法CREATE TABLE dwd.fact_order_detail ( order_id BIGINT, user_id BIGINT, goods_id BIGINT, order_amount DECIMAL(10,2), order_ts TIMESTAMP ) PARTITION BY RANGE (order_ts);在ClickHouse中则使用分区键定义CREATE TABLE dwd.fact_order_detail ( order_id UInt64, user_id UInt64, goods_id UInt64, order_amount Decimal(10,2), order_ts DateTime ) ENGINE MergeTree PARTITION BY toYYYYMMDD(order_ts) ORDER BY (user_id, order_ts);前者是PostgreSQL的声明式分区后者是ClickHouse的MergeTree引擎。通用建议分区粒度不要太小日分区是常态小时分区只保留最近一段时间查询时必须强制带分区过滤条件否则全表扫描。4.2 物化视图用空间换时间的典型参数DWS层的汇总数据可以用物化视图自动维护而不必手动写定时任务。以PostgreSQL为例基础用法如下CREATE MATERIALIZED VIEW dws.user_daily_summary AS SELECT user_id, order_date, COUNT(*) AS order_cnt, SUM(order_amount) AS total_amount FROM dwd.fact_order_detail GROUP BY user_id, order_date; REFRESH MATERIALIZED VIEW dws.user_daily_summary;参数细节物化视图本身是静态数据调用REFRESH才会更新。PG的物化视图更新是阻塞式的查询大表时会出现短暂的不可用。如果对可用性要求高需要改成并发刷新REFRESH MATERIALIZED VIEW CONCURRENTLY dws.user_daily_summary;使用CONCURRENTLY的前提是物化视图上必须存在唯一索引。提示ClickHouse的物化视图是增量写触发的适合实时聚合但要注意它不能修改已有的历史分区。4.3 数据质量校验的3个必做检查点数仓产出数据没人敢用多数是因为没有建立校验环节。不需要复杂工具三个检查点就能拦住大部分问题。第一行数校验。任务跑完后对比源表与目标表的行数偏差超过阈值就报警。第二主键唯一性校验。事实表的主键重复是常见故障源。第三空值率监控。维度表中的关键字段空值率突然升高往往意味着上游业务改动。用一个SQL片段说明空值率检查的实现方式SELECT COUNT(*) AS total_cnt, COUNT(user_name) AS valid_cnt, ROUND((COUNT(*) - COUNT(user_name)) * 100.0 / COUNT(*), 2) AS null_rate FROM dwd.dim_user WHERE dt CURRENT_DATE;查询逻辑说明COUNT(user_name)会自动忽略NULL值与COUNT(*)相减得到空值数量。当null_rate大于阈值比如5%时说明上游数据有异常。这种翻译成业务的表达是用户维度表中用户名为空的比例异常增高。5. 把中英文翻译变成数仓资产的管理技巧最后一个部分回到标题里的“中英文翻译分享”。与其把术语对照表存在PDF里吃灰不如把它变成数仓管理中的活文档。具体做法是维护一张元数据术语表。在数据仓库中建立physical表专门存放术语、英文全称、缩写、中文翻译、业务口径、负责人等字段。这张表本身不是业务数据而是元数据管理的底座。CREATE TABLE metadata.dw_glossary ( term_en VARCHAR(128) PRIMARY KEY, term_cn VARCHAR(128) NOT NULL, abbreviation VARCHAR(32), definition TEXT, owner VARCHAR(32), update_ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP );之后每次建模时先在术语表中检索是否有标准定义。如果发现“DWD”在不同业务线分别被叫作“明细层”和“数据仓库明细层”统一在表里落一个标准说法并把别名记录到definition字段中。这种维护动作不能靠个人自觉落实方式是在ETL任务的注释里强制引用术语ID让代码与术语表形成直接关联。例如COMMENT ON COLUMN dwd.fact_order.user_id IS 用户ID (glossary_ref: dim_user.user_id, 名词来源: 统一术语表 v1.3);养成这个习惯后新同事接入项目时不用翻PDF直接查metadata.dw_glossary就能知道中文表达对应的英文字段以及它在数仓中的准确位置。数据的可维护性本质上就是从这些微小的翻译一致性中长出来的。本文还有配套的精品资源点击获取 数据仓库中英文术语对照与建模实践：从事实表到ETL落地
简介这是一份数据仓库中英文对照翻译资料面向数据仓库初学者、备考学生以及需要快速理解核心概念的技术人员。内容从数据仓库的产生背景讲起说明其与操作数据库的区别重点解析W.H.Inmon关于“面向主题、集成、时变、非易失”的经典定义并对四大特征逐一展开中英文对照阐述同时覆盖ETL过程、数据清洗、数据集市、OLAP等配套知识点帮助读者建立完整的数据仓库理论框架。资源为单个PDF文件大小约20KB轻量易读适合作为课堂笔记补充、面试或项目汇报前的速查手册。英文原文与中文译文相互对照便于同步提升技术英语阅读能力。目前已有122人学习下载适合希望系统掌握数据仓库基础并强化专业文献理解能力的读者。1. 数据仓库不等于数据库弄混术语是第一个坎很多人在看数据仓库资料时第一反应是去搜“数据仓库和数据库的区别”结果被一堆中英文混杂的解释绕晕。其实反直觉的真相是数据仓库不是一种数据库产品而是一套面向分析的数据处理体系。MySQL、PostgreSQL、Snowflake、ClickHouse都可以承载数据仓库但装上数据库不等于建好了数据仓库。这份以中英文翻译形式分享的PDF核心价值在于把散落在英文文档里的术语——fact table、dimension table、ETL、OLAP——还原成能直接用于工作交流的中文表达。对于刚接触数仓的工程师、从业务转数据岗位的分析师以及需要跟跨国团队对齐口径的技术管理者先把术语体系理清楚比急着写SQL更重要。本章不需要列任何定义只需记住一个判断标准凡是面向历史数据、多表关联、聚合查询的场景才需要数据仓库凡是面向单行增删改的业务系统那是OLTP的事。2. 数据仓库的核心建模概念与中英文术语对照2.1 维度建模不是玄学是围绕“事实”和“维度”的翻译题打开任何一本数仓英文教材前两章一定绕不开两个词fact和dimension。中文翻译通常叫“事实表”和“维度表”。但单纯记单词没有意义关键在于理解两者的关系。事实表记录业务事件比如订单、支付、日志维度表记录业务实体的属性比如用户、商品、时间。一个订单事实表通过外键关联到用户维度和商品维度就形成了星型模型。我在实际项目中见到最多的问题是新人把维度属性全部塞进事实表理由是“查询时少一次JOIN”。短期来看查询是快了但维度属性一旦变化比如用户手机号换了事实表的历史数据也跟着被污染。用代码说明这个问题。常见的错误建模方式是这样CREATE TABLE order_fact_wrong ( order_id BIGINT PRIMARY KEY, user_id BIGINT, user_name VARCHAR(64), user_phone VARCHAR(20), goods_id BIGINT, goods_name VARCHAR(128), category_name VARCHAR(64), order_amount DECIMAL(10,2), order_ts TIMESTAMP );这段建表语句的副作用是当用户改名或商品调整分类时必须用UPDATE语句回刷历史订单。数据量大时UPDATE成本极高而且容易错过部分行造成数据不一致。正确的星型建模应该拆成两张表CREATE TABLE dim_user ( user_id BIGINT PRIMARY KEY, user_name VARCHAR(64), user_phone VARCHAR(20), start_ts TIMESTAMP, end_ts TIMESTAMP ); CREATE TABLE fact_order ( order_id BIGINT PRIMARY KEY, user_id BIGINT, goods_id BIGINT, order_amount DECIMAL(10,2), order_ts TIMESTAMP );事实表只保留业务过程和可度量值维度属性全部下沉到维度表。提示start_ts和end_ts是缓慢变化维SCD的常用做法用来区分同一用户在不同时间段的属性状态。2.2 ETL与ELT的顺序之争“ETL”这个缩写在中文资料里几乎不翻译大家直接说“跑ETL”。但英文原文Extract-Transform-Load的顺序背后藏着对数据走向的取舍。传统ETL先做清洗转换再入库适合数据量有限、目标库是Oracle或SQL Server的旧式数仓。ELTExtract-Load-Transform则先把原始数据全部加载到数据湖或数仓中再利用数仓的算力做转换。现在云数仓和MPP数据库普及后ELT逐渐成为主流。选哪个不取决于潮流取决于团队分工。如果团队里SQL能力强ELT能让分析师直接操作原始数据如果团队里Java/Python工程师多ETL可以让他们在数据入库前用代码完成复杂清洗。我个人的倾向是入库前只做必要的数据类型校正和去重复杂的业务逻辑转换推迟到数仓内用SQL实现。这样原始数据被保留出问题时可以重新转换而不是重新抽取。2.3 常用数据仓库有哪些小型场景怎么选标题里的“常用数据仓库”指向选型问题。按部署方式分目前常见的是四类类型代表产品适合场景传统MPP数仓Teradata、Greenplum企业级大规模分析云原生数仓Snowflake、BigQuery、Redshift弹性伸缩、按量付费开源OLAPClickHouse、Doris、StarRocks实时分析、高并发查询数据湖查询引擎Presto/Trino、Spark SQL直接查询对象存储上的文件小型团队10人以内、数据量在TB以下的常见误区是一上来就上全套Hadoop体系。我见过的更务实的做法是业务数据量不大时用PostgreSQL或TiDB做数仓底座配合调度工具完成日级ETL需要实时分析时引入ClickHouse用物化视图处理聚合场景。提示选型时优先看团队的现有技术栈不要为了“高频词数据仓库”去引入一套没人维护的开源组件。3. 小型团队的数据仓库落地从建库到数据同步3.1 最小可用的数仓分层架构不管用什么引擎数仓分层是通用方法论。中文资料里常出现“ODS层”“DWD层”“DWS层”“ADS层”对应英文分别是Operational Data Store、Data Warehouse Detail、Data Warehouse Summary、Application Data Store。这四层不是上级要求而是工程上为了避免“烟囱式开发”被迫形成的隔离。ODS层保存原始数据不做任何业务修改DWD层做清洗和维度退化形成明细事实表DWS层按主题做汇总比如用户维度的当日累计值ADS层直接面向报表和应用。我见过最精简的团队会把DWS层省略让报表直接查DWD层。这种做法在小数据量下可行但一旦报表数量增多每次跑报表都要扫描全表明细资源开销成倍增长。建议至少保留一个轻量的汇总层。3.2 用Docker本地跑通数仓环境不依赖云服务在本地验证数仓流程最快的方式是用Docker启动一个PostgreSQL实例作为数仓。以下命令可以在本地快速拉起测试环境docker run -d \ --name dw_pg_test \ -e POSTGRES_PASSWORDdw_test_2024 \ -e POSTGRES_DBwarehouse \ -p 5432:5432 \ postgres:14启动后用psql连接并创建分层schemapsql -h localhost -p 5432 -U postgres -d warehouse在psql中执行CREATE SCHEMA IF NOT EXISTS ods; CREATE SCHEMA IF NOT EXISTS dwd; CREATE SCHEMA IF NOT EXISTS dws;参数说明POSTGRES_PASSWORD是初始化密码-p 5432:5432把容器内的5432端口映射到宿主机。创建三个schema的目的是让数据流转路径清晰可见。3.3 用SQL模拟一条ETL过程数仓的ETL未必需要Flink或Airflow小数据量阶段用SQL就可以完成。下面用INSERT INTO ... SELECT模拟从ODS层清洗到DWD层的过程INSERT INTO dwd.dim_user (user_id, user_name, user_phone, start_ts, end_ts) SELECT user_id, TRIM(user_name) AS user_name, REGEXP_REPLACE(user_phone, [^0-9], ) AS user_phone, start_ts, 9999-12-31 AS end_ts FROM ods.raw_user WHERE user_id IS NOT NULL AND user_name ;这段SQL做的事有三件去除用户姓名首尾空格、过滤电话中的非数字字符、过滤无效字段。逻辑说明清洗规则越简单越好不要在入库时做复杂的业务判断否则后续口径调整时改代码成本很高。REGEXP_REPLACE的具体语法在不同数据库中略有差异MySQL 8.0和PostgreSQL都支持SQL Server需要改用REPLACE嵌套。3.4 中英文翻译在建模时的实际作用这里要回应标题里的“中英文翻译”。做数仓建模时经常出现同一张表在不同文档里叫法不一致的问题。比如dim_user有人翻译成“用户维表”有人叫“用户维度扩展表”也有人直接保留英文表名注释里有写着“会员表”。我的建议是表名用英文与物理表一致注释和口径描述用中文并附上英文原文。例如COMMENT ON TABLE dwd.dim_user IS 用户维度表 (dim_user) - 对应用户注册信息;这种做法的好处是中方团队看注释秒懂外方团队看表名无歧义。中英文对照的意义不在于翻译本身而在于建立统一的沟通锚点。4. 数据仓库性能与数据质量分区、物化视图与校验4.1 分区策略是查询性能的分水岭数仓查询慢大概率是分区设计出了问题。没有分区的表即使数据量只有几百万行全表扫描也会拖垮资源。分区字段的选择遵循一个原则查询条件里最常用的过滤字段。对于订单明细表按日期分区是最常见的做法CREATE TABLE dwd.fact_order_detail ( order_id BIGINT, user_id BIGINT, goods_id BIGINT, order_amount DECIMAL(10,2), order_ts TIMESTAMP ) PARTITION BY RANGE (order_ts);在ClickHouse中则使用分区键定义CREATE TABLE dwd.fact_order_detail ( order_id UInt64, user_id UInt64, goods_id UInt64, order_amount Decimal(10,2), order_ts DateTime ) ENGINE MergeTree PARTITION BY toYYYYMMDD(order_ts) ORDER BY (user_id, order_ts);前者是PostgreSQL的声明式分区后者是ClickHouse的MergeTree引擎。通用建议分区粒度不要太小日分区是常态小时分区只保留最近一段时间查询时必须强制带分区过滤条件否则全表扫描。4.2 物化视图用空间换时间的典型参数DWS层的汇总数据可以用物化视图自动维护而不必手动写定时任务。以PostgreSQL为例基础用法如下CREATE MATERIALIZED VIEW dws.user_daily_summary AS SELECT user_id, order_date, COUNT(*) AS order_cnt, SUM(order_amount) AS total_amount FROM dwd.fact_order_detail GROUP BY user_id, order_date; REFRESH MATERIALIZED VIEW dws.user_daily_summary;参数细节物化视图本身是静态数据调用REFRESH才会更新。PG的物化视图更新是阻塞式的查询大表时会出现短暂的不可用。如果对可用性要求高需要改成并发刷新REFRESH MATERIALIZED VIEW CONCURRENTLY dws.user_daily_summary;使用CONCURRENTLY的前提是物化视图上必须存在唯一索引。提示ClickHouse的物化视图是增量写触发的适合实时聚合但要注意它不能修改已有的历史分区。4.3 数据质量校验的3个必做检查点数仓产出数据没人敢用多数是因为没有建立校验环节。不需要复杂工具三个检查点就能拦住大部分问题。第一行数校验。任务跑完后对比源表与目标表的行数偏差超过阈值就报警。第二主键唯一性校验。事实表的主键重复是常见故障源。第三空值率监控。维度表中的关键字段空值率突然升高往往意味着上游业务改动。用一个SQL片段说明空值率检查的实现方式SELECT COUNT(*) AS total_cnt, COUNT(user_name) AS valid_cnt, ROUND((COUNT(*) - COUNT(user_name)) * 100.0 / COUNT(*), 2) AS null_rate FROM dwd.dim_user WHERE dt CURRENT_DATE;查询逻辑说明COUNT(user_name)会自动忽略NULL值与COUNT(*)相减得到空值数量。当null_rate大于阈值比如5%时说明上游数据有异常。这种翻译成业务的表达是用户维度表中用户名为空的比例异常增高。5. 把中英文翻译变成数仓资产的管理技巧最后一个部分回到标题里的“中英文翻译分享”。与其把术语对照表存在PDF里吃灰不如把它变成数仓管理中的活文档。具体做法是维护一张元数据术语表。在数据仓库中建立physical表专门存放术语、英文全称、缩写、中文翻译、业务口径、负责人等字段。这张表本身不是业务数据而是元数据管理的底座。CREATE TABLE metadata.dw_glossary ( term_en VARCHAR(128) PRIMARY KEY, term_cn VARCHAR(128) NOT NULL, abbreviation VARCHAR(32), definition TEXT, owner VARCHAR(32), update_ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP );之后每次建模时先在术语表中检索是否有标准定义。如果发现“DWD”在不同业务线分别被叫作“明细层”和“数据仓库明细层”统一在表里落一个标准说法并把别名记录到definition字段中。这种维护动作不能靠个人自觉落实方式是在ETL任务的注释里强制引用术语ID让代码与术语表形成直接关联。例如COMMENT ON COLUMN dwd.fact_order.user_id IS 用户ID (glossary_ref: dim_user.user_id, 名词来源: 统一术语表 v1.3);养成这个习惯后新同事接入项目时不用翻PDF直接查metadata.dw_glossary就能知道中文表达对应的英文字段以及它在数仓中的准确位置。数据的可维护性本质上就是从这些微小的翻译一致性中长出来的。本文还有配套的精品资源点击获取