数仓术语

电商数据仓库术语

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

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

 

口径

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

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

 

流水

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

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

 

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

<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]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值