数仓术语

最新推荐文章于 2025-07-02 09:38:32 发布

weixin_30781107

最新推荐文章于 2025-07-02 09:38:32 发布

阅读量1.1k

点赞数

CC 4.0 BY-SA版权

原文链接：http://www.cnblogs.com/drjava/p/10638856.html

电商数据仓库术语

这篇随笔，我想写写在电商数仓建设中遇到的术语。

可能不是规范，各个公司定义有所不同，但是是比较通用的说法。

口径

就是统一的定义。比如成交的口径就是成交的定义。虽然看似多余，但是涉及运营指标的统计时，口径至关重要。

所以一家公司内，对于某个业务，一定要有统一的口径。

流水

流水一般用在涉及财务的交易清单。流水会详细的记录每一笔进出的钱款。比如银行流水，交易流水。

流水表：狭义的流水表就是财务的对账单。广义上也可以包含每次变化都会记录的有钱款的表。

JMV,JMS

JMV:Gross Merchandise Volume,主要指拍下订单的总金额，包含付款和未付款两部分。不减去退款金额。

这个指标主要用在体现520，双11等活动，用户的购买意向。

JMS: 实际成交额

卡点

原子性数据加载时间。

卡点的目的是保证尽量进入数据库的数据是完整的一天数据，并且包含尽量少的第二天的数据。

pv,uv

pv：pv page view：某天访问量，不去重。

uv：user view，某天访问用户数。要根据用户id去重。

留存

留存用户：包含1日留存，3日留存，7日留存等。自注册n日起，有登陆的用户数。比如7日留存，自注册7起，有登陆的用户数。

留存率：比如7日留存率，就是7日留存用户数，占7日内新注册的用户的比例。

粒度

某一个事物统计的单位。比如时间可以用天作为粒度。商品可以用商品类目作为粒度。

转载于:https://www.cnblogs.com/drjava/p/10638856.html

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

weixin_30781107

关注关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

数仓建模—建模方法论之实体-关系(Entity-Relationship)建模

03-31

8万+

实体是现实世界中可区分的、有实际存在意义的事物或对象，如人、物、地点、事件等。在ER模型中，实体通常用矩形框表示，矩形框内写明实体名。每个实体都有属性，属性描述了实体的特征或属性。ER模型是一种用于描述现实世界中实体、属性和关系之间关系的数据模型。通过ER模型，可以直观地表示数据结构，帮助分析和设计数据库和系统。ER模型提供了一种有效的方式来理解和描述现实世界中的复杂问题，并在设计数据库时提供了指导。

数仓建模—物理数据模型

最新发布

派可数据的博客

07-02

816

1.数据仓库 (Data Warehouse - DW / EDW):2.数据集市 (Data Mart):派可数据-数据仓库。

什么是退化维度？

a6822342的博客

08-30

2万+

退化维度的维度表可以被剔除，从而简化维度数据仓库的模式。因为简单的模式比复杂的更容易理解，也有更好的查询性能。当一个维度没有数据仓库需要的任何数据时就可以退化此维度。需要把退化维度的相关数据迁移到事实表中，然后删除退化的维度。维度属性也可以存储到事实表中，这种存储到事实表中的维度列被称为“退化维度”。与其他存储在维表中的维度一样，退化维度也可以用来进行事实表的过滤查询、实现聚合操作等。那...

数据仓库术语

08-23

1188

大数据之数仓术语（面试篇）

默主归沙的博客

03-19

2323

特别说明：本文续更。 1、RDBMS ：关系型数据库 2、Prometheus、Grafana ：都是组件监控 3、工作流,其实也调度工具（常用）：azkaban、oozie、airflow 4、日志区分：行为日志、内容日志、业务数据行为日志：用户与平台交互产生的数据业务日志：是由公司服务端业务系统`产生的数据日内日志：公司在不同的业务需求产生的 5、关于二次开发编写Flume Interceptor的原因 hive是可以自动识别json格式的message，但是无法识别base64

数仓建模—ChatETL

05-31

6万+

虽然ChatGPT在BI领域有着潜在的积极影响，但也需要注意其局限性，包括对于复杂技术领域的理解限制以及对于领域特定术语的处理不足。在实际应用中，结合ChatGPT与专业数据分析工具和技术是更为理想的做法，以充分发挥各自的优势。

数仓建模—需求管理

05-31

6万+

数仓建模—Data Warebase AI 时代数据平台应当的样子

07-29

3万+

引言：在这个 AI 技术飞速发展的时代，我们有能力更深入地发掘数据潜在的价值，而数据处理不应当成为阻碍。云原生分布式 Data Warebase 将开启处理数据的新范式，它让数据的使用返璞归真，不论是存储还是查询，一个系统满足业务全方位数据需求。打破复杂数据架构的束缚，大大降低数据的使用门槛，释放数据潜能，让数据涌现智能。2002 年我加入 Microsoft SQL Server 引擎团队。那时的数据库市场相对简单，主要有三个厂商：Oracle、IBM（DB2）和 Microsoft（SQL Server

商业智能与数据仓库术语大全

12-09

商业智能与数据仓库术语大全,商业智能与数据仓库术语大全。

数据仓库术语整理

戰士博客

10-29

2216

一、度量、指标、指标器度量和维度构成OLAP的主要概念，对于在事实表或者一个多维立方体里面存放的数值型的、连续的字段，就是度量。这符合上面的意思，有标准，一个度量字段肯定是统一单位，例如元、户数。如果一个度量字段，其中的度量值可能是欧元又有可能是美元，那这个度量没法汇总。在OLAP中还有计算度量的说法，用一个总费用除以用户数，得到每户平均费用。但这究竟还算不算度量了呢？这已经不是原本意义上的度...

数据仓库的术语

路漫漫其修远兮吾将上下而求索

03-30

1125

数据仓库(Data Warehouse) 数据集市(Data Mart) 操作型数据存储(ODS, Operational Data Store) 企业数据仓库(EDW, Enterprise Data Warehouse) 集结区(Staging Area) 展现区(Presentation area)

数据仓库相关术语

if.else.Z

04-09

561

ETL（Extraction-Transformation-Loading）即数据提取、转换和加载。 BI（BusinessIntelligence）即商务智能。它是一套完整的解决方案，用来将企业中现有的数据进行有效的整合，快速准确的提供报表并提出决策依据，帮助企业做出明智的业务经营决策。 boss系统（Business &Operation Support System）即业

数据仓库常用名词汇总

dkjhl的博客

06-28

2334

数仓为了支撑企业或组织的决策和业务分析，而从各个业务系统中抽取数据集成到一个数据存储中心，这样的数据存储中心称为数据仓库（Data Warehouse），而在搭建数据仓库时，通常会采用一些命名规范，常见的有：ods、dim和dws。 1. ODS：ODS全称是Operational Data Store，即运营数据存储层，是数据仓库中的一层，主要用于存储来自源系统的数据，该层保留着与业务相关的行为数据，通常不对数据进行聚合处理，也不进行数据清洗和格式转换。ODS主要是为数据仓库提供数据源。

数仓专有名词

qq_45972323的博客

04-11

655

比如说订单id，这种量级很大的维度，没必要用一张维度表来进行存储，而我们进行数据查询或者数据过滤的时候又非常需要，所以这种就冗余在事实表里面，这种就叫退化维度，citycode这种我们也会冗余在事实表里面，但是它有对应的维度表，所以它不是退化维度。数据集市（Data Mart），也叫数据市场，数据集市就是满足特定的部门或者用户的需求，按照多维的方式进行存储，包括定义维度、需要计算的指标、维度的层次等，生成面向决策分析需求的数据立方体。从年的维度可以下钻到月的维度、日的维度等。如将超过200斤的称为大胖子。

数据仓库和数据集市专业术语解释

JHON07的博客

01-16

546

数据仓库：数据标准化的数据集（标准化数据库设计会使数据拆分成最低的粒度）实数仓库：常使用关系模型（关系模型和关系数据库设计的权威著作参考：Ted Codd 和ChristDate的书籍）数据集市：是一种数据结构，是数据仓库的子集合，是依据一个部门（比如财务，运营部门）需求建议的多维模型；数据集市：常用多维模型：星型模型，雪花模型星型模型：由事实表和维度表组成（事实表利用外键关联维度表）事实表：...

数仓建设

06-10

<think>嗯，用户这次明确想了解数据仓库建设的最佳实践，之前引用的三篇Hadoop/Hive相关材料其实已经覆盖了核心要点。用户应该是企业的数据工程师或架构师角色，需要实操性强的方案，而不是理论框架。注意到用户提供的引用里藏着几个关键维度：架构设计、数据建模、ETL规范、性能优化、数据治理。特别是引用[2]提到的目录规范、代码公约这些细节，说明用户可能正面临团队协作效率问题。有趣的是第三篇引用暴露了业务诉求——销售分析场景，这提示我在回答时要绑定价值产出。上次讨论快速排序时我采用了“核心方法+应用场景”的结构，这次可以延续但需调整：数据仓库的生命周期比算法复杂得多，应该按建设流程分层展开。用户引用的材料里反复出现的“分区分桶”、“维度建模”等术语，必须用业务场景解释才能避免枯燥，比如把“时间分区优化”对应到促销分析的案例。需要警惕的是引用[3]末尾的广告信息，这可能是用户随手粘贴的无效内容。重点还是紧扣[1][2]中经过验证的规范——元数据管理、湖仓一体这些趋势性技术要提，但货币单位标准化这种细节更能解决用户的实际痛点。最后补充的问题列表特意加入了团队落地挑战，因为看到用户两次引用都强调“规范约束行为”，说明执行阻力才是真正痛点。</think> 好的，关于数据仓库建设的最佳实践，结合行业经验和您提供的参考资料[^1][^2][^3]，可以归纳为以下几个核心方面，并具体说明： 1. **明确业务目标与范围 (业务驱动)：** * **始于业务：** 数据仓库的建设**必须**围绕具体的业务需求和目标展开（例如：分析销售趋势、客户行为、商品盈利能力、库存优化、客户流失预警等）[^3]。建设初期需要与业务部门紧密沟通，清晰定义关键业务指标(KPI)和分析场景。 * **迭代演进：** 不要试图一次性构建满足所有需求的“完美”数据仓库。应识别出最核心、最有价值的业务主题域（如销售、客户、商品），优先建设这些核心领域的模型和数据管道，后续再逐步扩展范围[^1]。这降低了初始风险并能更快见到价值。 2. **合理的架构设计与层次规划：** * **分层结构：** 采用经典的分层架构（如ODS、DWD/DIM、DWS、ADS）是普遍认可的最佳实践[^1][^2]。每层具有明确职责： * **ODS (操作数据层)：** 源数据的近实时或周期镜像层，结构基本不变，用于集成和缓冲。 * **DWD (数据明细层) / DIM (维度表层)：** 对ODS数据进行清洗、转换、关联、维度退化等，形成业务过程清晰的、原子粒度的明细事实表和一致性维度表。**DWD层是数据仓库的核心基础。** * **DWS (数据汇总层)：** 基于DWD/DIM层，按特定分析主题（如用户、商品、渠道）进行轻度或重度聚合汇总，以提高查询效率。 * **ADS (应用数据层 / 数据集市层)：** 面向具体应用或报表的直接访问层，通常是维度建模或宽表模式，为最终用户提供高度聚合的数据或衍生指标。 * **目录规范：** **极其重要**。必须对每层的数据库/文件夹**目录结构进行严格规划**，明确约定ODS、DWD/DIM、DWS、ADS层的存放位置，公共代码、项目代码、个人代码的存放规则等，确保所有团队成员都能轻松找到所需内容[^2]。 3. **科学的数据建模（核心方法论）：** * **维度建模主导：** 在DWD、DWS层（尤其是ADS）广泛应用维度建模（星型模型、雪花模型）。它使用事实表（描述业务事件）和维度表（描述事件的上下文），结构清晰、易于理解和查询优化[^1][^2]。这是Kimball方法论的基石。 * **一致性维度：** **非常关键**。确保公共维度（如日期、客户、商品、地区）在**所有事实表和数据集市中具有统一的定义和编码（代理键）**，这是跨主题域集成分析的基础[^2]。 * **数据命名规范：** 为表、字段、视图、索引等制定严格的命名规范，确保语义清晰、风格统一，避免混乱。 4. **高效的ETL/ELT开发与管理：** * **标准化与模块化：** 编写代码必须遵循**统一的编程规范**，包括注释格式（如必须包含作者、创建/修改日期、变更记录、用途说明）、代码对齐、日志记录等[^2]。采用模块化设计提高复用性（如公共清洗函数、通用维表加载逻辑）。 * **增量处理：** 尽可能使用增量加载（Merge, Change Data Capture）代替全量更新，尤其是对于源系统变化不频繁或数据量巨大的表，**可以显著提升处理效率和资源利用率**[^1]。 * **依赖调度：** 使用成熟的调度工具（如Apache Airflow, DolphinScheduler）管理和监控任务的执行顺序、依赖关系、错误处理及重试机制。 5. **关键的性能优化策略：** * **分区（Partitioning）：** **基础且重要**。按时间（如天、小时）或业务键（如地区、品类）对事实表进行分区是**必须**的优化手段，它能极大减少查询时扫描的数据量[^1][^2]。**灵活运用时间分区**是引用中明确强调的最佳实践[^2]。 * **分桶（Bucketing）：** 在分区基础上，Hive中可以通过分桶进一步优化连接（Join）和采样（Sampling）效率（如基于Join Key分桶）[^1]。 * **适当的索引：** 在OLAP引擎允许且有需求时（如Impala、Presto或部分关系型数据库作为存储后端），为高频查询的关键字段创建合适的索引。 * **数据压缩与列式存储：** 使用高效压缩算法（如Snappy, Zstd, Gzip）和列式存储格式（如Parquet, ORC）可以显著减少存储空间占用、提高I/O效率（只需读查询需要的列）[^1]。 * **计算引擎选择：** 根据场景选择合适的计算引擎（Hive on MR/Tez/Spark, Spark SQL, Impala, Presto等），在并发性、实时性、吞吐量之间做权衡。 6. **数据治理与元数据管理：** * **元数据管理：** **不可或缺**。建立和维护技术元数据（表结构、ETL映射、血缘）、业务元数据（指标定义、业务术语、数据负责人）是确保数据质量、保障可信度、方便用户查找和理解数据的关键[^1]。血缘分析对理解数据变更影响至关重要。 * **数据质量监控：** 在ETL流程中嵌入数据质量检查规则（如完整性检查：记录数/列非空比例验证；有效性检查：格式、范围验证；一致性检查：跨表校验；准确性检查：核对关键指标）。建立异常报告和告警机制。 * **数据安全与权限：** 定义清晰的角色权限模型（如RBAC），实施行级/列级安全控制，并对敏感信息进行脱敏或加密。审计关键数据访问行为。 7. **规范落地与最佳实践制度化：** * **开发规范强制推行：** 所有提到的规范和最佳实践（如一致性维度定义、分区策略、数据类型规范、货币金额统一用“分”表示[^2]、代码格式）**必须通过成文的开发规范和约束性流程来强制所有开发者遵循**，否则难以真正落地和长期保持[^2]。 * **文档化：** 持续维护和更新架构设计文档、数据模型文档（ER图/维度建模图）、ETL设计说明、使用手册等。 * **团队协作与文化：** 建立明确的责任人制度（如数据Owner），促进数据团队内部的良好协作以及与业务部门的沟通文化。 8. **拥抱技术演进：** * **湖仓一体化：** 考虑数据湖的灵活性与数据仓库的治理优势的结合，探索采用开放表格式（如Apache Iceberg, Hudi, Delta Lake）构建更灵活、高性能的湖仓一体平台架构[^1]。 * **云原生：** 利用云平台提供的托管服务（如S3, DynamoDB, BigQuery, Redshift, Snowflake, Databricks SQL, EMR等）提升运维自动化程度、增强弹性和成本效益[^1]。 **总结：** 数据仓库建设最佳实践的核心在于**以业务价值为驱动，采用经过验证的分层架构与维度建模方法，建立严格的开发规范和数据治理体系，并持续应用分区分桶、压缩列存等关键优化技术，同时通过制度化和工具化确保这些实践的落地生根。** 整个过程需要架构师的高瞻远瞩、开发者的专业执行力、业务方的密切配合以及管理层的坚定支持[^1][^2]。