企业官网建设流程全解析

简介：这是一份数据仓库中英文对照翻译资料，面向数据仓库初学者、备考学生以及需要快速理解核心概念的技术人员。内容从数据仓库的产生背景讲起，说明其与操作数据库的区别，重点解析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的旧式数仓。ELT（Extract-Load-Transform）则先把原始数据全部加载到数据湖或数仓中，再利用数仓的算力做转换。现在云数仓和MPP数据库普及后，ELT逐渐成为主流。

选哪个，不取决于潮流，取决于团队分工。如果团队里SQL能力强，ELT能让分析师直接操作原始数据；如果团队里Java/Python工程师多，ETL可以让他们在数据入库前用代码完成复杂清洗。我个人的倾向是：入库前只做必要的数据类型校正和去重，复杂的业务逻辑转换推迟到数仓内用SQL实现。这样原始数据被保留，出问题时可以重新转换，而不是重新抽取。

2.3 常用数据仓库有哪些，小型场景怎么选

标题里的“常用数据仓库”指向选型问题。按部署方式分，目前常见的是四类：

小型团队（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_PASSWORD=dw_test_2024 \ -e POSTGRES_DB=warehouse \ -p 5432:5432 \ postgres:14

启动后，用psql连接并创建分层schema：

psql -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，就能知道中文表达对应的英文字段，以及它在数仓中的准确位置。数据的可维护性，本质上就是从这些微小的翻译一致性中长出来的。

本文还有配套的精品资源，点击获取