简介数据仓库主题的中英文对照PDF适合刚开始接触数据仓库概念、希望积累专业词汇的初学者或数据分析从业者。内容围绕数据仓库的定义展开说明它作为与日常操作数据库相分离的独立数据库如何整合来自客户、供应商、产品、销售等不同业务系统的数据并提供历史性、综合性的视角来支撑管理决策文中重点讲解W.H. Inmon提出的“面向主题、集成、时变、非易失”四个关键特征并简要介绍ETL、数据集市、OLAP等扩展应用。中英文并置的排版让读者既能准确理解中文表述又能掌握对应英文术语便于后续阅读原版教材或技术文档。资源共包含1个PDF文件约20KB轻量易读适合碎片化学习已有122人学习下载对建立数据仓库核心框架认知和积累专业英文词汇很有帮助。1. 数据仓库中英文术语的坑从一份分享 PDF 说起办公室里总有人把「数据仓库(中英文翻译)分享.pdf」转到群里起因是读国外文档时查词太费劲。同一个 dimension 被翻成「维度」或「维表」granularity 有「粒度」「颗粒度」两种叫法。对照表的价值不在翻译而在钉住概念边界。这份 PDF 背后其实只有三块内容数仓分层与建模术语的准确来源、不同规模下常见数仓产品怎么选、术语能不能落成可跑通的 SQL。检索「数据仓库」与「常用数据仓库有哪些」的人多半卡在同一处单词都认识连成句子就看不懂看完概念又不知道先装什么。下文先理清中英文概念边界再按规模过一遍产品最后用一段 SQL 验证词表。适合刚接手数仓项目、需要读英文资料或对外输出中文文档的工程师。2. 数据仓库中英文对照先把概念边界定准2.1 数据仓库、数据湖与湖仓一体英文词根先分清数据仓库的英文是 Data Warehouse指一组面向主题subject-oriented、集成integrated、非易失non-volatile、随时间变化time-variant的数据集合。这四个特征是 Bill Inmon 教材里的原始定义中文翻译五花八门英文原文却十分固定。相邻的三个词容易被拖下水Data Lake 是数据湖强调原始数据集中存放、读取时再定义结构即 schema-on-readLakehouse 是湖仓一体在数据湖存储之上补上事务、索引与元数据管理能力schema-on-write 与 read 的界限开始模糊。常见误区是把数据仓库与数据库混为一谈。Database 解决事务型读写Data Warehouse 解决分析型查询英文文档里用 OLTP联机事务处理与 OLAP联机分析处理区分两类系统。中英文对照表若只写「数据库Database、数据仓库Data Warehouse」不解释 OLTP 与 OLAP 的分工读者遇到英文原句照样理解不了。判断一段英文在讲哪类系统先看它讨论的是事务提交还是聚合扫描比记住术语更管用。2.2 ETL 与 ELT、Staging 与 ODS流水线的术语错位ETL 全称 Extract-Transform-Load抽取、转换、装载ELT 是 Extract-Load-Transform先装载后转换。差别不在字母顺序而在转换发生在哪一端ETL 把转换放在中间处理层ELT 把转换交给目标端计算引擎。云数仓普遍倾向 ELT原因是目标端按需扩展、算力成本更低。翻译时如果两者都笼统写成「数据集成」就丢掉了最关键的架构含义数据在哪里被转换。常见做法是再把中间层拆出 Staging 与 ODS 两个概念。Staging 是原始抽取区数据基本原样落地Operational Data StoreODS是面向操作的整合存储比 Staging 多做一步清洗与去重。中文社区的「数仓分层」ODS、DWD、DWS、ADS 中ODS 与英文原词对应DWD、DWS、ADS 则是国内约定俗成的叫法英文原文通常写作 cleansed/detail layer、summary layer、application layer。做中英文对照时应给这类中文层名补英文解释而不是硬找单词对应。2.3 事实表、维度表、星型模型建模词根要统一维度建模由 Ralph Kimball 提出核心对象是事实表Fact Table与维度表Dimension Table。事实表记录业务事件的度量行数大、字段少外键指向各维度表维度表保存描述性上下文如日期、产品、门店行数少但字段宽。二者相连构成星型模型Star Schema事实表居中维度表直接连接不在维度表之间继续拆分。若按范式规则把维度表继续拆分成多张就得到雪花模型Snowflake Schema。这里最容易翻错的是 granularity。中文有「粒度」「颗粒度」「明细程度」三种译法英文文档里还常与 grain 混用。一个事实表的粒度指一行记录对应一个业务事件的精细程度订单明细级、按天汇总级、按渠道汇总级完全不是一回事。术语表应统一译成「粒度」并注明 grain 是同义词。另一个高频词是缓慢变化维Slowly Changing DimensionSCD指的是维度属性随时间变化的历史处理策略Type 2 保存多条带生效时间的版本记录中文常说的「拉链表」所指就是它。2.4 高频中英文对照表不能望文生义的 15 个词整理术语表时我会把容易望文生义的词单独放一列避免新人按字面理解。下面是读数仓英文文档时最常遇到的 15 个词中文英文关键说明数据仓库Data Warehouse面向分析的主题化数据集合数据集市Data Mart面向部门或主题的子集数据湖Data Lake原始数据集中存储读时建模湖仓一体Lakehouse数据湖上的数仓能力抽取-转换-装载ETL先转换再写入目标抽取-装载-转换ELT先写入目标再转换事实表Fact Table业务事件度量与关联外键维度表Dimension Table描述事实的上下文属性星型模型Star Schema维度表不继续拆分的模型雪花模型Snowflake Schema维度表按范式继续拆分粒度Granularity / Grain一行记录对应的业务事件级别缓慢变化维Slowly Changing Dimension维度属性随时间变化Type 2 保留历史一致性维度Conformed Dimension跨多个事实表共享的标准维度退化维度Degenerate Dimension直接存在事实表中的订单号等标识血缘Lineage数据来源与流转关系表里后两行是翻译重灾区。一致性维度容易被理解成「唯一维度」实际含义是同一张维度表被多个事实表复用口径必须一致退化维度则是指订单号、发票号这类高基数标识单独建维度表成本高直接留在事实表中即可。把这两条放进词表比背「维度dimension」有用得多。3. 常用数据仓库有哪些从云数仓到小型引擎的选型对照「常用数据仓库有哪些」是检索里出现频率很高的问题答案不是唯一的而是按规模与运维条件分档。我的选择顺序是先看数据量与并发规模再看团队有没有能值班的运维最后看查询模式。按这个顺序可以把产品分成云数仓、开源 OLAP、小型嵌入式三档。3.1 云数仓三选一BigQuery、Redshift、Snowflake 的英文关键词BigQuery 是 Google Cloud 的 serverless 数仓存储与计算分离按扫描字节数计费典型运维负担最小。英文文档里有两个独有词slot 表示并发计算的资源单元partitioned table 表示按时间或整数分区。调查询性能时先看 slot 是否打满再看分区裁剪是否生效。没有集群可管、预算依赖查询量这类场景选 BigQuery 最合适。Amazon Redshift 是托管集群架构底层是列式存储按节点实例规格付费。文档关键词是 cluster、node、sortkey、distribution style其中 sortkey 决定列存排序distkey 决定数据分布这两项直接决定 join 性能。已有 AWS 生态、愿意接受集群扩容与 vacuum 维护的团队常见做法是 Redshift没有专职 DBA 时要谨慎评估它的维护成本。Snowflake 的存储与计算完全分离virtual warehouse 是独立的计算仓按实际运行时长计费微分区micro-partition自动完成文件级裁剪。三者的共性词是「虚拟集群」但官方文档里各叫各的BigQuery 叫 slotRedshift 叫 cluster capacitySnowflake 叫 virtual warehouse。中英文对照表里统一翻成「计算资源」更安全比硬套「集群」一词准确。3.2 开源与国产 OLAPClickHouse、Doris、StarRocks 怎么读文档ClickHouse 是列式 OLAP 引擎单表聚合速度极快适合日志分析与宽表查询核心机制在 MergeTree 引擎族。读文档时抓住两个点建表要写 ENGINE MergeTree 并指定 ORDER BY排序键决定合并与查询裁剪分布式场景看 distributed table 与 shard 配置。它的强项不是高并发多表 join而是大宽表的极速扫描。Apache Doris 与 StarRocks 都是 MPP 架构的 OLAP 数据库支持批量导入与实时导入带物化视图和 Rollup 能力中文文档相对齐全StarRocks 是 Doris 社区分化出的分支两者原理相近但由不同社区维护。读这两类文档关注 rollup、tablet、materialized_view 三个词rollup 是多维预聚合tablet 是数据分片单元物化视图用于加速固定查询。中小团队在云数仓成本不可控时常用做法是先试用开源的 Doris 或 StarRocks。3.3 小型场景DuckDB 与 SQLite 的定位差异和最小命令小型项目经常被过度设计。单机分析、几十 GB 以内、不想部署服务的场景DuckDB 是最接近「小型数据仓库」的选项它是嵌入式 OLAP进程内运行支持标准 SQL可以直接查询 CSV 与 Parquet 文件。SQLite 定位是嵌入式关系库擅长事务型读写不适合聚合与多表 join拿 SQLite 当数仓用查询一复杂就慢是常见误用。判据只有一条查询里是否大量出现 GROUP BY、窗口函数与多表 join是就选 DuckDB。用 DuckDB 验证一份销售 CSV 的渠道汇总最小命令是这样import duckdb # 进程内临时库不落盘适合分析与演示 con duckdb.connect(:memory:) rows con.execute( SELECT channel, SUM(amount) FROM read_csv_auto(sales.csv) GROUP BY channel ).fetchall() print(rows)connect(:memory:) 表示内存模式退出即释放read_csv_auto 自动推断文件名里的列名、类型与分隔符省去手工建表GROUP BY 聚合交给列式执行引擎并行完成。同样的操作如果用 SQLite要先手工 CREATE TABLE 再导入类型推断也不可靠这是二者定位差异最直观的体现。注意看「常用数据仓库有哪些」这类文章只能当作候选清单最终决定要拿自己的真实查询跑一遍基准只看产品名没有意义。4. 用 SQL 验证数据仓库建模术语建最小星型模型术语表背得再熟不如建一张事实表和两张维度表把建模术语对应到具体语句。这个最小模型覆盖事实表、维度表、外键、孤儿键、粒度五个概念建完再跑两条验证查询词表里容易混淆的词就全落地了。4.1 维度表与事实表的建表语句主键、外键与字段类型先建两张维度表再建事实表。建表顺序有讲究事实表的外键要引用维度主键所以维度表必须先存在。-- 维度表日期date_key 为业务无关主键 CREATE TABLE dim_date ( date_key INTEGER PRIMARY KEY, full_date DATE NOT NULL, year INTEGER NOT NULL, month INTEGER NOT NULL, is_weekend BOOLEAN DEFAULT FALSE ); -- 维度表商品 CREATE TABLE dim_product ( product_key INTEGER PRIMARY KEY, sku VARCHAR(32) NOT NULL, product_name VARCHAR(128) NOT NULL, category VARCHAR(64), brand VARCHAR(64) ); -- 事实表销售明细外键引用两张维度表 CREATE TABLE fact_sales ( sales_key INTEGER PRIMARY KEY, date_key INTEGER NOT NULL REFERENCES dim_date(date_key), product_key INTEGER NOT NULL REFERENCES dim_product(product_key), quantity INTEGER NOT NULL, amount DECIMAL(12, 2) NOT NULL, channel VARCHAR(16) );date_key 与 product_key 是业务无关的整数主键即英文里的 surrogate key。不用日期字符串或 SKU 当键是因为业务键可能在源系统里被修改或重复使用而人工主键与业务解耦维度表重建时无须改动事实表。事实表只放度量与外键channel 这类低基数属性直接冗余在事实表里对应退化维度的一种常见处理属性简单、不需要单独建维度表留在原处比 join 一张只有两列的表更高效。注意 amount 用 DECIMAL(12, 2) 而不是 FLOAT。浮点类型在累计求和时会引入精度误差DECIMAL 是精确数值。英文文档里的 numeric precision 经常被译成「数字精度」真正含义是「用定点数避免二进制近似」。这个词条值得单独写进中英文对照表。4.2 一条装载 SQL 里对应了哪些术语标准做法是先把源数据落到 staging 表再做维度匹配后写入事实表。下面这条 INSERT 语句把 ETL 的转换与装载两步压缩在一个查询里-- 从 staging 层抽取通过 JOIN 做维度匹配再写入事实表 INSERT INTO fact_sales (date_key, product_key, quantity, amount, channel) SELECT d.date_key, p.product_key, s.quantity, s.amount, s.channel FROM staging_sales s JOIN dim_date d ON s.order_date d.full_date JOIN dim_product p ON s.sku p.sku;staging_sales 是原始抽取层两个 JOIN 把业务键翻译成维度主键这个过程就是 transform写入 fact_sales 是 load。ELT 风格的差异只在于执行位置先让原始数据落进目标端大宽表再在目标端执行相同 JOIN关联条件不变。中英文对照里的 ETL/ELT 之争在这里表现为「JOIN 在哪台机器上运行」而不是翻译的差别。4.3 验证维度一致性孤儿键检查与粒度校验装载完成后第一件事是检查事实表里是否存在维度表没有的键行业里叫孤儿键orphan key对应数据质量的参照完整性referential integrity概念-- 左连接后再筛维度键为空命中的就是孤儿键 SELECT count(*) AS orphan_rows FROM fact_sales f LEFT JOIN dim_date d ON f.date_key d.date_key LEFT JOIN dim_product p ON f.product_key p.product_key WHERE d.date_key IS NULL OR p.product_key IS NULL;结果应为 0。只要出现孤儿键后续所有报表在关联维度属性时都会丢失上下文表现为日期显示为空、商品分类对不上。LEFT JOIN 加 IS NULL 是检查外键约束的通用写法比直接依赖数据库外键更早发现问题尤其适合建表时没有启用外键约束的数仓。第二类检查是验证事实表的粒度是否成立-- 按声明的粒度字段分组看是否存在重复行 SELECT date_key, product_key, count(*) AS dup_rows FROM fact_sales GROUP BY date_key, product_key HAVING count(*) 1;这条查询的意图不是证明数据有错而是验证声明的最小粒度。如果业务口径是「某天某商品的一次渠道销售」date_key 与 product_key 组合出现重复属于正常如果口径声明为「某天某商品的汇总」重复就意味着上游重复入库需要在 ETL 里做去重。同一段 SQL 在不同粒度声明下得出相反结论这正是 grain 这个词值得单独占一行对照表的原因。5. 中英文术语表落地的检查清单反查、争议词与检索化5.1 用官方文档反查原文别拿二手词典当标准拿到任何一份数据仓库中英文翻译分享 PDF先抽查五个正在用的词。打开产品官方文档或 Kimball、Inmon 原著的英文索引找原句对照。比如 Redshift 文档里的 sortkey、distribution styleSnowflake 文档里的 micro-partition查完再回去看 PDF 的翻译是否对得上。二手博客的定义经常互相抄官方文档才是基准。5.2 争议词中文术语在英文里没有一一对应下面这些词中文社区常用但英文里没有严格对应翻译时最容易各写各的中文更接近的英文表达宽表wide table / denormalized table拉链表SCD Type 2 / historized dimension数仓分层layered architecture各层用 staging / summary / application 表达汇总表aggregated table / rollup宽表不是标准术语英文读者能猜出 wide table 的字面意思但设计文档里最好写成 denormalized fact table拉链表是中文形象叫法标准表达是 SCD Type 2。这类词放进词表时英文侧应写成「建议表达」而不是「标准翻译」。5.3 把 PDF 转成可检索的词表并接进评审流程手头是 PDF 格式时先用 poppler-utils 的 pdftotext 转成纯文本再 grep 反查# 保留原排版转成文本再检索关键术语 pdftotext -layout 数据仓库_中英文翻译分享.pdf glossary.txt grep -n -i -E granularity|lineage|conformed glossary.txt-layout 保留原 PDF 的换行结构中文文件名按当前目录直接引用即可转出来的文本可以继续用 sed、wc 处理也可以导入文档工具进一步整理。整理完成后把词表放回团队仓库的 docs 目录在建模评审前跑一遍同样的 grep把「grain 今天叫粒度还是颗粒度」这类一致性问题挡在会前。本文还有配套的精品资源点击获取
一文理清数据仓库中英文术语与常用选型
简介数据仓库主题的中英文对照PDF适合刚开始接触数据仓库概念、希望积累专业词汇的初学者或数据分析从业者。内容围绕数据仓库的定义展开说明它作为与日常操作数据库相分离的独立数据库如何整合来自客户、供应商、产品、销售等不同业务系统的数据并提供历史性、综合性的视角来支撑管理决策文中重点讲解W.H. Inmon提出的“面向主题、集成、时变、非易失”四个关键特征并简要介绍ETL、数据集市、OLAP等扩展应用。中英文并置的排版让读者既能准确理解中文表述又能掌握对应英文术语便于后续阅读原版教材或技术文档。资源共包含1个PDF文件约20KB轻量易读适合碎片化学习已有122人学习下载对建立数据仓库核心框架认知和积累专业英文词汇很有帮助。1. 数据仓库中英文术语的坑从一份分享 PDF 说起办公室里总有人把「数据仓库(中英文翻译)分享.pdf」转到群里起因是读国外文档时查词太费劲。同一个 dimension 被翻成「维度」或「维表」granularity 有「粒度」「颗粒度」两种叫法。对照表的价值不在翻译而在钉住概念边界。这份 PDF 背后其实只有三块内容数仓分层与建模术语的准确来源、不同规模下常见数仓产品怎么选、术语能不能落成可跑通的 SQL。检索「数据仓库」与「常用数据仓库有哪些」的人多半卡在同一处单词都认识连成句子就看不懂看完概念又不知道先装什么。下文先理清中英文概念边界再按规模过一遍产品最后用一段 SQL 验证词表。适合刚接手数仓项目、需要读英文资料或对外输出中文文档的工程师。2. 数据仓库中英文对照先把概念边界定准2.1 数据仓库、数据湖与湖仓一体英文词根先分清数据仓库的英文是 Data Warehouse指一组面向主题subject-oriented、集成integrated、非易失non-volatile、随时间变化time-variant的数据集合。这四个特征是 Bill Inmon 教材里的原始定义中文翻译五花八门英文原文却十分固定。相邻的三个词容易被拖下水Data Lake 是数据湖强调原始数据集中存放、读取时再定义结构即 schema-on-readLakehouse 是湖仓一体在数据湖存储之上补上事务、索引与元数据管理能力schema-on-write 与 read 的界限开始模糊。常见误区是把数据仓库与数据库混为一谈。Database 解决事务型读写Data Warehouse 解决分析型查询英文文档里用 OLTP联机事务处理与 OLAP联机分析处理区分两类系统。中英文对照表若只写「数据库Database、数据仓库Data Warehouse」不解释 OLTP 与 OLAP 的分工读者遇到英文原句照样理解不了。判断一段英文在讲哪类系统先看它讨论的是事务提交还是聚合扫描比记住术语更管用。2.2 ETL 与 ELT、Staging 与 ODS流水线的术语错位ETL 全称 Extract-Transform-Load抽取、转换、装载ELT 是 Extract-Load-Transform先装载后转换。差别不在字母顺序而在转换发生在哪一端ETL 把转换放在中间处理层ELT 把转换交给目标端计算引擎。云数仓普遍倾向 ELT原因是目标端按需扩展、算力成本更低。翻译时如果两者都笼统写成「数据集成」就丢掉了最关键的架构含义数据在哪里被转换。常见做法是再把中间层拆出 Staging 与 ODS 两个概念。Staging 是原始抽取区数据基本原样落地Operational Data StoreODS是面向操作的整合存储比 Staging 多做一步清洗与去重。中文社区的「数仓分层」ODS、DWD、DWS、ADS 中ODS 与英文原词对应DWD、DWS、ADS 则是国内约定俗成的叫法英文原文通常写作 cleansed/detail layer、summary layer、application layer。做中英文对照时应给这类中文层名补英文解释而不是硬找单词对应。2.3 事实表、维度表、星型模型建模词根要统一维度建模由 Ralph Kimball 提出核心对象是事实表Fact Table与维度表Dimension Table。事实表记录业务事件的度量行数大、字段少外键指向各维度表维度表保存描述性上下文如日期、产品、门店行数少但字段宽。二者相连构成星型模型Star Schema事实表居中维度表直接连接不在维度表之间继续拆分。若按范式规则把维度表继续拆分成多张就得到雪花模型Snowflake Schema。这里最容易翻错的是 granularity。中文有「粒度」「颗粒度」「明细程度」三种译法英文文档里还常与 grain 混用。一个事实表的粒度指一行记录对应一个业务事件的精细程度订单明细级、按天汇总级、按渠道汇总级完全不是一回事。术语表应统一译成「粒度」并注明 grain 是同义词。另一个高频词是缓慢变化维Slowly Changing DimensionSCD指的是维度属性随时间变化的历史处理策略Type 2 保存多条带生效时间的版本记录中文常说的「拉链表」所指就是它。2.4 高频中英文对照表不能望文生义的 15 个词整理术语表时我会把容易望文生义的词单独放一列避免新人按字面理解。下面是读数仓英文文档时最常遇到的 15 个词中文英文关键说明数据仓库Data Warehouse面向分析的主题化数据集合数据集市Data Mart面向部门或主题的子集数据湖Data Lake原始数据集中存储读时建模湖仓一体Lakehouse数据湖上的数仓能力抽取-转换-装载ETL先转换再写入目标抽取-装载-转换ELT先写入目标再转换事实表Fact Table业务事件度量与关联外键维度表Dimension Table描述事实的上下文属性星型模型Star Schema维度表不继续拆分的模型雪花模型Snowflake Schema维度表按范式继续拆分粒度Granularity / Grain一行记录对应的业务事件级别缓慢变化维Slowly Changing Dimension维度属性随时间变化Type 2 保留历史一致性维度Conformed Dimension跨多个事实表共享的标准维度退化维度Degenerate Dimension直接存在事实表中的订单号等标识血缘Lineage数据来源与流转关系表里后两行是翻译重灾区。一致性维度容易被理解成「唯一维度」实际含义是同一张维度表被多个事实表复用口径必须一致退化维度则是指订单号、发票号这类高基数标识单独建维度表成本高直接留在事实表中即可。把这两条放进词表比背「维度dimension」有用得多。3. 常用数据仓库有哪些从云数仓到小型引擎的选型对照「常用数据仓库有哪些」是检索里出现频率很高的问题答案不是唯一的而是按规模与运维条件分档。我的选择顺序是先看数据量与并发规模再看团队有没有能值班的运维最后看查询模式。按这个顺序可以把产品分成云数仓、开源 OLAP、小型嵌入式三档。3.1 云数仓三选一BigQuery、Redshift、Snowflake 的英文关键词BigQuery 是 Google Cloud 的 serverless 数仓存储与计算分离按扫描字节数计费典型运维负担最小。英文文档里有两个独有词slot 表示并发计算的资源单元partitioned table 表示按时间或整数分区。调查询性能时先看 slot 是否打满再看分区裁剪是否生效。没有集群可管、预算依赖查询量这类场景选 BigQuery 最合适。Amazon Redshift 是托管集群架构底层是列式存储按节点实例规格付费。文档关键词是 cluster、node、sortkey、distribution style其中 sortkey 决定列存排序distkey 决定数据分布这两项直接决定 join 性能。已有 AWS 生态、愿意接受集群扩容与 vacuum 维护的团队常见做法是 Redshift没有专职 DBA 时要谨慎评估它的维护成本。Snowflake 的存储与计算完全分离virtual warehouse 是独立的计算仓按实际运行时长计费微分区micro-partition自动完成文件级裁剪。三者的共性词是「虚拟集群」但官方文档里各叫各的BigQuery 叫 slotRedshift 叫 cluster capacitySnowflake 叫 virtual warehouse。中英文对照表里统一翻成「计算资源」更安全比硬套「集群」一词准确。3.2 开源与国产 OLAPClickHouse、Doris、StarRocks 怎么读文档ClickHouse 是列式 OLAP 引擎单表聚合速度极快适合日志分析与宽表查询核心机制在 MergeTree 引擎族。读文档时抓住两个点建表要写 ENGINE MergeTree 并指定 ORDER BY排序键决定合并与查询裁剪分布式场景看 distributed table 与 shard 配置。它的强项不是高并发多表 join而是大宽表的极速扫描。Apache Doris 与 StarRocks 都是 MPP 架构的 OLAP 数据库支持批量导入与实时导入带物化视图和 Rollup 能力中文文档相对齐全StarRocks 是 Doris 社区分化出的分支两者原理相近但由不同社区维护。读这两类文档关注 rollup、tablet、materialized_view 三个词rollup 是多维预聚合tablet 是数据分片单元物化视图用于加速固定查询。中小团队在云数仓成本不可控时常用做法是先试用开源的 Doris 或 StarRocks。3.3 小型场景DuckDB 与 SQLite 的定位差异和最小命令小型项目经常被过度设计。单机分析、几十 GB 以内、不想部署服务的场景DuckDB 是最接近「小型数据仓库」的选项它是嵌入式 OLAP进程内运行支持标准 SQL可以直接查询 CSV 与 Parquet 文件。SQLite 定位是嵌入式关系库擅长事务型读写不适合聚合与多表 join拿 SQLite 当数仓用查询一复杂就慢是常见误用。判据只有一条查询里是否大量出现 GROUP BY、窗口函数与多表 join是就选 DuckDB。用 DuckDB 验证一份销售 CSV 的渠道汇总最小命令是这样import duckdb # 进程内临时库不落盘适合分析与演示 con duckdb.connect(:memory:) rows con.execute( SELECT channel, SUM(amount) FROM read_csv_auto(sales.csv) GROUP BY channel ).fetchall() print(rows)connect(:memory:) 表示内存模式退出即释放read_csv_auto 自动推断文件名里的列名、类型与分隔符省去手工建表GROUP BY 聚合交给列式执行引擎并行完成。同样的操作如果用 SQLite要先手工 CREATE TABLE 再导入类型推断也不可靠这是二者定位差异最直观的体现。注意看「常用数据仓库有哪些」这类文章只能当作候选清单最终决定要拿自己的真实查询跑一遍基准只看产品名没有意义。4. 用 SQL 验证数据仓库建模术语建最小星型模型术语表背得再熟不如建一张事实表和两张维度表把建模术语对应到具体语句。这个最小模型覆盖事实表、维度表、外键、孤儿键、粒度五个概念建完再跑两条验证查询词表里容易混淆的词就全落地了。4.1 维度表与事实表的建表语句主键、外键与字段类型先建两张维度表再建事实表。建表顺序有讲究事实表的外键要引用维度主键所以维度表必须先存在。-- 维度表日期date_key 为业务无关主键 CREATE TABLE dim_date ( date_key INTEGER PRIMARY KEY, full_date DATE NOT NULL, year INTEGER NOT NULL, month INTEGER NOT NULL, is_weekend BOOLEAN DEFAULT FALSE ); -- 维度表商品 CREATE TABLE dim_product ( product_key INTEGER PRIMARY KEY, sku VARCHAR(32) NOT NULL, product_name VARCHAR(128) NOT NULL, category VARCHAR(64), brand VARCHAR(64) ); -- 事实表销售明细外键引用两张维度表 CREATE TABLE fact_sales ( sales_key INTEGER PRIMARY KEY, date_key INTEGER NOT NULL REFERENCES dim_date(date_key), product_key INTEGER NOT NULL REFERENCES dim_product(product_key), quantity INTEGER NOT NULL, amount DECIMAL(12, 2) NOT NULL, channel VARCHAR(16) );date_key 与 product_key 是业务无关的整数主键即英文里的 surrogate key。不用日期字符串或 SKU 当键是因为业务键可能在源系统里被修改或重复使用而人工主键与业务解耦维度表重建时无须改动事实表。事实表只放度量与外键channel 这类低基数属性直接冗余在事实表里对应退化维度的一种常见处理属性简单、不需要单独建维度表留在原处比 join 一张只有两列的表更高效。注意 amount 用 DECIMAL(12, 2) 而不是 FLOAT。浮点类型在累计求和时会引入精度误差DECIMAL 是精确数值。英文文档里的 numeric precision 经常被译成「数字精度」真正含义是「用定点数避免二进制近似」。这个词条值得单独写进中英文对照表。4.2 一条装载 SQL 里对应了哪些术语标准做法是先把源数据落到 staging 表再做维度匹配后写入事实表。下面这条 INSERT 语句把 ETL 的转换与装载两步压缩在一个查询里-- 从 staging 层抽取通过 JOIN 做维度匹配再写入事实表 INSERT INTO fact_sales (date_key, product_key, quantity, amount, channel) SELECT d.date_key, p.product_key, s.quantity, s.amount, s.channel FROM staging_sales s JOIN dim_date d ON s.order_date d.full_date JOIN dim_product p ON s.sku p.sku;staging_sales 是原始抽取层两个 JOIN 把业务键翻译成维度主键这个过程就是 transform写入 fact_sales 是 load。ELT 风格的差异只在于执行位置先让原始数据落进目标端大宽表再在目标端执行相同 JOIN关联条件不变。中英文对照里的 ETL/ELT 之争在这里表现为「JOIN 在哪台机器上运行」而不是翻译的差别。4.3 验证维度一致性孤儿键检查与粒度校验装载完成后第一件事是检查事实表里是否存在维度表没有的键行业里叫孤儿键orphan key对应数据质量的参照完整性referential integrity概念-- 左连接后再筛维度键为空命中的就是孤儿键 SELECT count(*) AS orphan_rows FROM fact_sales f LEFT JOIN dim_date d ON f.date_key d.date_key LEFT JOIN dim_product p ON f.product_key p.product_key WHERE d.date_key IS NULL OR p.product_key IS NULL;结果应为 0。只要出现孤儿键后续所有报表在关联维度属性时都会丢失上下文表现为日期显示为空、商品分类对不上。LEFT JOIN 加 IS NULL 是检查外键约束的通用写法比直接依赖数据库外键更早发现问题尤其适合建表时没有启用外键约束的数仓。第二类检查是验证事实表的粒度是否成立-- 按声明的粒度字段分组看是否存在重复行 SELECT date_key, product_key, count(*) AS dup_rows FROM fact_sales GROUP BY date_key, product_key HAVING count(*) 1;这条查询的意图不是证明数据有错而是验证声明的最小粒度。如果业务口径是「某天某商品的一次渠道销售」date_key 与 product_key 组合出现重复属于正常如果口径声明为「某天某商品的汇总」重复就意味着上游重复入库需要在 ETL 里做去重。同一段 SQL 在不同粒度声明下得出相反结论这正是 grain 这个词值得单独占一行对照表的原因。5. 中英文术语表落地的检查清单反查、争议词与检索化5.1 用官方文档反查原文别拿二手词典当标准拿到任何一份数据仓库中英文翻译分享 PDF先抽查五个正在用的词。打开产品官方文档或 Kimball、Inmon 原著的英文索引找原句对照。比如 Redshift 文档里的 sortkey、distribution styleSnowflake 文档里的 micro-partition查完再回去看 PDF 的翻译是否对得上。二手博客的定义经常互相抄官方文档才是基准。5.2 争议词中文术语在英文里没有一一对应下面这些词中文社区常用但英文里没有严格对应翻译时最容易各写各的中文更接近的英文表达宽表wide table / denormalized table拉链表SCD Type 2 / historized dimension数仓分层layered architecture各层用 staging / summary / application 表达汇总表aggregated table / rollup宽表不是标准术语英文读者能猜出 wide table 的字面意思但设计文档里最好写成 denormalized fact table拉链表是中文形象叫法标准表达是 SCD Type 2。这类词放进词表时英文侧应写成「建议表达」而不是「标准翻译」。5.3 把 PDF 转成可检索的词表并接进评审流程手头是 PDF 格式时先用 poppler-utils 的 pdftotext 转成纯文本再 grep 反查# 保留原排版转成文本再检索关键术语 pdftotext -layout 数据仓库_中英文翻译分享.pdf glossary.txt grep -n -i -E granularity|lineage|conformed glossary.txt-layout 保留原 PDF 的换行结构中文文件名按当前目录直接引用即可转出来的文本可以继续用 sed、wc 处理也可以导入文档工具进一步整理。整理完成后把词表放回团队仓库的 docs 目录在建模评审前跑一遍同样的 grep把「grain 今天叫粒度还是颗粒度」这类一致性问题挡在会前。本文还有配套的精品资源点击获取
