~~数据仓库概述~~数据仓库英文名称为Data Warehouse可简写为DW或DWH。数据仓库是为企业所有级别的决策制定过程提供所有类型数据支持的战略集合。它是单个数据存储出于分析性报告和决策支持目的而创建。 为需要业务智能的企业提供指导业务流程改进、监视时间、成本、质量以及控制数据仓库的特点1.面向主题主题域每一个主题对应一个宏观的分析领域主题域是围绕企业某一类核心业务过程或业务对象组织起来的逻辑数据集合业务指的是企业为了达成其目标而进行的一系列有组织的活动、流程和操作。例如电商公司的“交易业务”就包含了从 用户浏览商品、下单、支付到售后 等一系列连贯的过程。业务 (Business) 与主题域的关系数据仓库的“面向主题”特性正是为了服务于这些业务的分析需求。一个“主题域”就是围绕一个核心业务领域如交易、客户、营销组织起来的数据集合。因此业务是源头和目的企业的各项业务活动产生了原始数据而数据仓库建设的最终目的是为了分析和优化这些业务。主题域是组织和呈现方式数据仓库将分散在不同业务系统中的数据按照业务主题如交易域、客户域进行整合、清洗和建模形成易于分析的数据结构。业务过程是构成单元一个主题域由多个具体的“业务过程”组成。例如“交易域”这个主题就包含了“下单”、“支付”、“退款”等多个业务过程。每个业务过程通常对应一张或多张事实表或维度表。通过这种映射数据仓库能够将原始的、面向事务的业务数据转化为面向分析的、集成的信息直接支撑如“分析本月各渠道的销售趋势”、“评估营销活动 ROI”等业务决策。注一个主题域包含多个业务过程,一个业务需要多张表来表示比如 交易域 包含 订单、支付、退款、优惠券使用、售后 这些业务过程2.集成的在某一个主题下需要将数据进行提取、清洗、转换和装载等集成操作。数据类型统一 , 数据标准化 ,数据去重相对稳定的数据仓库中的数据是相对稳定的不会因为日常业务操作而频繁更新。数据一旦加载到数据仓库中通常只会被查询和分析而不是频繁修改。这种特性使得数据仓库能够支持历史数据分析和趋势预测。特点数据仓库中的数据是历史性的、不可变的适合进行长期的数据分析。例如销售数据在数据仓库中会保留多年用于分析销售趋势、季节性变化等。反映历史变化数据仓库中的数据是随时间变化的能够反映历史数据的变化趋势。数据仓库通常会保留多个时间点的数据以便分析数据随时间的变化情况。这种特性使得数据仓库能够支持趋势分析、时间序列分析等。特点数据仓库中的数据是带有时间戳的能够反映数据在不同时间点的状态。例如企业可以分析过去几年的销售数据了解哪些产品在哪些时间段表现最好从而制定未来的销售策略。数据仓库 VS 数据库事物的特点数据仓库 VS 数据库事务 (Transaction) 的特点事务是数据库管理系统DBMS中一个核心概念它代表一个不可分割的工作逻辑单元。一个事务内的所有操作要么全部成功执行要么全部不执行以确保数据从一种一致性状态转换到另一种一致性状态。事务通常具有以下四个特性合称为 ACID 特性原子性 (Atomicity)事务被视为一个不可分割的“原子”操作。事务中的所有操作要么全部完成要么全部不完成不会停留在中间某个状态。如果事务在执行过程中发生错误会被回滚Rollback到事务开始前的状态就像这个事务从未执行过一样。一致性 (Consistency)*事务执行的结果必须使数据库从一个一致性状态转变到另一个一致性状态。这意味着事务必须遵守数据库的所有预定义规则如约束、触发器、级联等不会破坏数据的业务逻辑完整性。一致性是事务的最终目标原子性、隔离性和持久性都是为了保障一致性而存在的。隔离性 (Isolation)数据库系统允许多个事务并发执行。隔离性确保并发执行的事务相互隔离一个事务的执行不能被其他事务干扰。事务内部的操作及使用的数据对其他并发事务是隔离的防止出现脏读、不可重复读、幻读等问题。数据库通过不同的隔离级别如读未提交、读已提交、可重复读、串行化来实现不同程度的隔离。持久性 (Durability)一旦事务被提交Commit它对数据库中数据的改变就是永久性的。即使后续系统发生故障如断电、崩溃已提交事务的结果也不会丢失。数据库通常通过将事务日志写入非易失性存储如硬盘来保证持久性。数据库的三范式(数据库建模规范)- 1NF : 列不可再分 - 2NF : 非主键字段完全依赖主键(必须依赖主键的全部字段) - 3NF : 不能存在传递依赖数据库(OLTP)在线事物处理数据库主要是处理事物的,属于 OLTP类型数据仓库(OLAP)数据仓库主要是存储分析数据,属于 OLAP 类型核心功能是 分析数据数据仓库的设计规范优秀可靠的数仓体系往往需要清晰的数据分层结构即要保证数据层的稳定又要屏蔽对下游的影响并且要避免链路过长。那么问题来了一直在讲数仓要分层那数仓分几层最好目前市场上主流的分层方式眼花缭乱不过看事情不能只看表面还要看到内在的规律不能为了分层而分层没有最好的只有适合的数据仓库分层优点1.清晰数据结构(明确责任)3.数据血缘追踪4.减少重复开发5.统一加工口径屏蔽原始数据的影响数据仓库的分层架构基于业务的建模设计数据仓库的建模设计必须紧密围绕业务需求展开其核心目标是构建一个能够准确反映业务、高效支持分析的数据模型。步骤业务调研与需求分析建模的第一步是深入理解业务。①识别关键业务过程与业务部门沟通明确核心业务流程如用户下单、“商品支付”、“客户服务等。②定义业务指标确定需要度量的关键绩效指标KPIs如销售额”、“用户留存率”、“订单转化率”。③明确分析维度确定分析的角度如按时间年、月、日、地区、产品类别、客户等级等。概念模型设计基于业务调研划分主题域这是连接业务与数据的桥梁。①划分原则将紧密相关的业务过程和数据划分到同一主题域。例如电商场景可划分为②交易域涵盖下单、支付、退款、售后等过程。③用户域涵盖注册、登录、画像、行为等过程。④商品域涵盖商品上架、库存、类目等过程。⑤营销域涵盖活动、优惠券、广告投放等过程。⑥输出物主题域矩阵图明确各主题域包含的业务过程和主要数据实体。逻辑模型设计维度建模核心步骤采用维度建模方法构建事实表和维度表。选择业务过程从主题域中确定要建模的具体业务过程如下单。声明粒度明确事实表中每一行数据所代表的业务含义如一个订单项、“一次支付事件”。粒度是设计的基础。确定维度描述业务过程的上下文即谁、什么、何时、何地、如何。例如订单事实表的维度可能包括时间、商品、用户、渠道等。确定事实定义可度量的业务数值通常是可加性指标如订单金额、“商品数量”、“支付金额”。模型类型选择星型模型一个事实表关联多个维度表结构简单查询性能高是最常用的模型。雪花模型维度表本身又关联其他维度表规范化程度高但查询复杂度增加。示例交易域下单业务逻辑模型事实表fact_order订单事实表粒度一个订单项order_item维度dim_time时间、dim_product商品、dim_user用户、dim_store店铺事实order_amount金额、quantity数量、discount_amount折扣金额维度表dim_user用户维度表包含用户ID、姓名、等级、注册时间等属性。物理模型设计与实施① 操作系统linux 、Windows Server、Unix、IBM AIX、HP-UX②存储技术 关系型数据库 ORACLE IBM DB2 SQLServer MySql国产数据库 阿里云dataworks 华为高斯 、达梦、人大金仓 …GP…分布式大数据技术Hadoop —HDFS—HIVESQL③ETL技术kettlePDI ODI informatica IBM datastage 国产ETL工具 datax 。。。。。④数据开发工具PLSQL …⑤BI工具Cognos 、Tableau 、Power BI 、 、FineReport FineBI 、永洪BI …⑥web中间件Tomcat \ WebLogic \ JBoss处理多系统数据订单要区分不同系统吗在实际企业中同一个业务实体如“订单”的数据可能来自多个独立的业务系统。例如电商系统处理线上零售订单。门店POS系统处理线下门店订单。批发ERP系统处理B2B大客户订单。移动端小程序处理社交电商订单。答案是在数据仓库中通常需要区分不同系统的订单但最终目标是实现数据的整合与统一分析。具体处理方式如下ODS层保留来源标识在数据接入层ODS原样接入各系统数据但必须为每张表或每条记录增加明确的数据来源系统标识如source_system字段值可为ec_online、pos_store、erp_wholesale等。这是数据血缘追溯的基础。DWD层清洗、整合与标准化这是处理多系统数据的关键层。目标是为“订单”建立一个统一的、干净的、粒度一致的明细事实表例如dwd_order_detail数据清洗与转换针对每个来源系统根据其数据格式和业务规则进行清洗如状态码映射、金额单位统一、时间格式标准化。业务逻辑统一*将不同系统中业务含义相同但字段名或值不同的数据对齐。例如将各系统的“订单状态”映射到一套统一的枚举值如待支付、已支付、已发货、已完成、已取消。保留来源信息在整合后的宽表中保留source_system字段甚至可能保留原始订单ID如original_order_id和原始系统的一些关键上下文字段如original_channel。这便于问题排查和特定场景下的细分分析。生成代理键为整合后的订单生成数据仓库内部的唯一主键如order_sk用于关联其他维度。维度建模中的体现方案一推荐将“来源系统”作为一个维度。创建dim_source_system维度表包含系统代码、系统名称、业务类型等属性。在订单事实表中source_system_sk作为外键关联到此维度表。这样分析时可以轻松地按系统、按业务类型进行筛选、分组和对比。方案二作为事实表的退化维度。如果来源系统属性很少且稳定也可以直接将source_system_code和source_system_name作为字段冗余在事实表中避免关联查询。总结通过上述处理数据仓库既保留了各系统数据的来源特征满足溯源和细分分析需求又将它们整合到统一的模型和口径下。最终业务用户可以在一个报表中同时查看来自线上、线下、批发等所有渠道的订单总额、趋势和对比实现真正的全域业务洞察。即在接入和清洗阶段要区分记录来源在整合和建模阶段要统一建立一致的事实和维度在分析阶段可以灵活选择既可以看整体也可以下钻看特定系统。将逻辑模型转化为在特定数据仓库中实现的物理结构。表命名规范制定统一的命名规则如dwd_{业务过程}_{数据粒度}、dim_{维度主题}。字段类型与长度根据数据特性选择合适的数据类型。分区与分桶对大数据量表如事实表按时间dt进行分区提升查询效率。索引策略在维度表的关联键、常用过滤条件字段上建立索引。核心原则业务为核心始终从业务问题和分析需求出发避免为技术而技术始终保持一致性相同的业务术语和指标在整个仓库中定义必须唯一在模型复杂度与查询性能之间取得平衡完善的数据字典和血缘文档是模型可持续维护的保障。通过以上步骤可以将模糊的业务需求转化为清晰、稳定、高效的数据仓库模型真正发挥数据驱动决策的价值。注①ODSODS 层是最接近数据源中数据的一层为了考虑后续可能需要追溯数据问题因此对于这一层就不建议做过多的数据清洗工作原封不动地接入原始数据即可至于数据的去噪、去重、异常值处理等过程可以放在后面的 DWD 层来做。②DWDDWD 是数据仓库的主要存储层用于存放经过清洗、整合、加工后的详细数据。DWD 层主要完成了数据的清洗、去重、数据格式转换等工作确保数据质量和一致性并且保留了数据的详细信息。支持数据的历史追溯提供了基础数据的单一版本适合进行数据挖掘、分析和报表等操作该层一般保持和 ODS 层一样的数据粒度并且提供一定的数据质量保证。DWD层要做的就是将数据清理、整合、规范化把脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的数据处理掉。同时为了提高数据明细层的易用性该层会采用一些维度退化手法将维度退化至事实表中减少事实表和维表的关联。另外在该层也会做一部分的数据聚合将相同主题的数据汇集到一张表中提高数据的可用性③DWS则基于DWD层数据按主题进行轻度或中度汇总。比如生成产品销售汇总、用户每日行为统计等。这些数据通常以宽表形式存储目的是提高后续分析的效率。④ADS这一层是面向业务需求定制的。它从DWS或DWD中取数进一步汇总成适合特定部门或场景使用的数据集。比如市场团队可能需要广告效果分析表财务团队则需要收支报表。DM层就是为他们准备的结构简洁、查询高效更贴近业务用语。