网站一个多少钱,什么是网络营销包含哪些内容,口碑好的郑州网站建设,wordpress有赞云数据仓库、商业智能及维度建模初步
记录一下读《数据仓库工具箱》时的思考#xff0c;摘录一些书中关于维度建模比较重要的思想与大家分享#x1f923;#x1f923;#x1f923; 博主在这里先把这本书变薄~有时间的小伙伴可以亲自再读一读#xff0c;感受一下…数据仓库、商业智能及维度建模初步
记录一下读《数据仓库工具箱》时的思考摘录一些书中关于维度建模比较重要的思想与大家分享 博主在这里先把这本书变薄~有时间的小伙伴可以亲自再读一读感受一下变厚再变薄的过程。欢迎交流讨论哈 数据仓库、商业智能及维度建模初步 数据仓库、商业智能及维度建模初步1.1 数据获取与数据分析的区别1.2 数据仓库与商业智能的目标1.3 维度建模简介1.3.1 星型模式与OLAP多维数据库1.3.2 用于度量的事实表1.3.2 用于描述环境的维度表1.3.4 星型模式中维度与事实的连接 1.4 Kimball的DW/BI架构1.4.1 操作型源系统1.4.2 获取-转换-加载ETL系统1.4.3 用于支持商业智能决策的展现区1.4.4 商业智能应用1.4.5 以餐厅为例描述Kimball架构 1.5 其他DW/BI架构1.6 维度建模神话1.6.1 神话1维度模型仅包含汇总数据1.6.2 神话2维度模型是部门级而不是企业级的1.6.3 神话3维度模型是不可扩展的1.6.4 神话4维度模型仅用于预测1.6.5 神话5维度模型不能被集成 水平有限欢迎在评论区讨论交流~ 数据仓库和商业智能Data Warehousing and Bussiness IntelligenceDW/BI系统首先应该考虑的问题是业务需求。
tips技术服务于业务不能一味的追求技术上的精进对于业务的精准把握与理解同等重要。 1.1 数据获取与数据分析的区别
信息几乎总是用作两个目的书上这两点总结的可以说非常到位了
操作型记录的保存—操作型系统保存数据。分析型决策的制定—DW/BI系统使用数据。 1操作型系统的用户确保组织正常运转。 对操作型系统进行优化的目的—更快地处理事务。 操作型系统一般一次处理一个事务记录通常不必维护历史数据只需修改数据以反映最新的状态。
2DW/BI系统的用户研究分析企业的运转并对其性能进行评估。
分析并判断操作型过程是否处于正确的工作状态。DW/BI系统一般不会一次只处理一个事务回答用户的查询通常需要搜索成千上万的事务并将查询结果放入一个查询集合中。DW/BI系统的用户通常要求保存历史环境用于精确地评估组织在一段时间内的性能。对DW/BI系统进行优化的目的是高性能的完成用户的查询。 1.2 数据仓库与商业智能的目标
书中引入了几个挺有意思的话题
我们收集了海量的数据但无法对其访问我们需要以各种方式方便地对数据进行切片以及切块业务人员需要方便地获取数据将最重要的事情展示给我会议自始至终争论的是谁的数字正确而不是制定决策我们希望人们能过够使用信息来支持更多的基于事实的决策制定 大家看了上面的topic想必已经对DW/BI系统需要解决的问题以及目标有所感悟。
摘录一下书中关于DW/BI系统目标最重要的两点 1DW/BI系统必须成为提高决策能力的权威和可信的基础。 2DW/BI系统成功的标志是业务群体接受DW/BI系统。 书中关于DW/BI系统管理者的责任总结的非常到位列位可以向这些目标所靠拢思考一下怎么去做好自己的工作。不要感觉枯燥个人认为文中讲的每一点都值得仔细推敲能做到这些都是业界翘楚啦 1理解业务用户 理解他们的工作责任、目标和任务 tips个人见解理解业务用户的日常职责、面临的挑战以及他们需要达成的目标是什么。了解这些才能确保系统提供的功能是符合他们需求的。 确定商业用户在制定哪些决策时需要DW/BI系统的帮助 tips个人见解不同的业务用户需要DW/BI系统帮助的决策点不同。明确哪些决策点是关键并为这些决策提供必要的支持。 识别出那些制定高效、高影响决策的“最佳用户” tips个人见解并不是所有用户的决策对公司影响一样大。有些人负责的是战略层面的决策他们的决策可能对公司发展有着更大影响。需要识别出这些关键人物确保他们能够得到系统支持。 发现潜在的新用户并让他们意识到DW/BI系统能够给他们带来什么能力 tips个人见解在公司中可能有一些部门或角色还没有充分意识到DW/BI系统的价值。应该主动发现这些潜在的新用户向他们展示如何通过数据分析提升工作效率或决策质量。 2对业务用户发布高质量、相关的、可访问的信息和分析 选择最健壮、可操作的数据放入DW/BI系统中 tips个人见解数据是DW/BI系统的核心但并不是所有数据都值得投入。需要确保选择的是最有用、最可靠的数据这些数据应该能够支持业务决策并且是容易被使用和理解的。 简化用户接口和应用采用模版驱动方式与用户的认知过程轮廓匹配 tips个人见解为了让业务用户能够顺利使用DW/BI系统应该简化用户界面并通过模板等方式帮助用户轻松获取所需的信息。就好像把复杂的报表变成一个简单的图表用户看得懂、用得方便。 确保数据精确、可信使其标识在整个企业具有一致性 tips个人见解如果系统中的数据不准确业务决策将会受到严重影响。确保数据的质量和一致性是底线。比如财务部门的数据与销售部门的数据必须一致不能因为数据的差异导致错误的决策。 不间断地监控数据和分析的准确性 tips个人见解DW/BI系统不是一次性建设完成的而是一个持续更新的过程。需要定期监控数据的质量确保信息和分析的准确性。如果发现问题及时修正避免误导业务决策。 适应用户不断变化的思维方式、需求和业务优先级及新数据源的可用性 tips个人见解业务环境在不断变化用户的需求和思维方式也在变化。需要快速响应这些变化不断调整系统满足用户新的需求和新的数据源。 3维护DW/BI环境 采用DW/BI系统制定的成功的业务决策验证人员配置及要投入的开支 定期对DW/BI系统进行更新 tips个人见解技术和业务需求都在不断发展DW/BI系统需要不断进行更新和优化。这不仅仅是技术上的更新还包括数据、模型和功能上的更新确保系统始终满足业务需求。 保持业务用户的信任 tips个人见解用户对系统的信任是系统能否成功应用的关键。如果业务用户认为系统的数据不准确或者界面难用他们就不会愿意使用。需要保证系统的稳定性、可靠性并且定期与用户沟通解决他们的疑虑保持他们的信任。 保持业务用户、执行赞助商和IT管理层满意度 tips个人见解DW/BI系统的成功不仅仅是技术团队的责任还需要业务部门的支持、管理层的赞助和持续投入。确保各方面的利益相关者都对系统感到满意确保系统能够持续发展和优化。 1.3 维度建模简介
维度建模并不是一种新技术早期主要用于简化数据库。简单性至关重要确保快速有效发现、公布结果。
维度建模是展现分析数据的首选技术
以商业用户可理解的方式发布数据。提供高效的查询性能。
从简单的数据模型开始是保持设计简单性的基础。如果从复杂的数据模型起步最终会导致模型过度复杂查询性能低下最终使商业用户反感。 尽管维度模型通常应用在关系数据库管理系统上但是并不要求维度模型必须满足3NF第三范式。
3NF主要是为了消除冗余规范化的3NF将数据划分为多个不同的实体每个实体构成一个关系表。满足3NF可能会出现“北京地铁线路图”超级复杂 业界有时将3NF模型称为实体-关系模型ER模型—实体关系图表示了表间的交互关系。但是3NF和维度模型都可以用ER模型表示因为都包含可连接的关系表。主要差别在于规范化程度书中强调不要将ER模型当成3NF模型。 规范化的3NF模型主要应用于操作过程中因为对事务的更新与插入仅仅触及数据库的单一地方。然而对于BI查询来说规范化模型太复杂用户难以理解、检索。维度建模则解决了模式过分复杂的问题。 Tips: 维度模型包含的信息与规范化模型包含的信息相同但将数据以一种用户可理解的、满足查询性能要求的、灵活多变的方式进行了包装。 1.3.1 星型模式与OLAP多维数据库
在RDBMS中实现的维度模型称为星型模式结构类似星星。 在多维数据库环境中实现的维度模型通常称为联机分析处理OnLine Analytical Processing,OLAP多维数据库。 如果采用的DW/BI环境包括星型模式或者OLAP多维数据库则可以说是利用了维度概念。 1.3.2 用于度量的事实表 维度模型中的事实表存储组织机构业务过程事件的性能度量结果。“事实”这一术语表示某个业务度量。 应该尽量将来源于同一个业务过程的底层度量结果存储于一个维度模型中。因为度量的数据量巨大所以不应该为满足多个组织功能的需要而将这些数据存放在多个地方。 应该允许多个组织的业务用户访问同一个单一的集中式数据仓库确保他们能在整个企业中使用一致的数据。保持一致性 事实表中的每行对应一个度量事件。每行中的数据是一个特定级别的细节数据称为粒度。维度建模的核心原则之一——同一事实表中所有度量行必须具有相同的粒度确保不会出现重复计算度量的问题。 Tips
物理世界的每一个度量事件与对应的事实表行具有一对一的关系这一思想是维度建模的基本原则。其他工作都是以此为基础建立的。最实用的事实是数值类型和可加类型事实可加性至关重要因为BI应用不太可能仅仅检索事实表的单一行。 一般都是一次检索成百上千行甚至百万级别的事实表行(最有用的操作就是把他们加在一起)。一般事实表具有两个或者更多的外键与维度表中的主键关联可以通过维度表使用连接操作来实现对事实表的访问。 通常几个维度一起唯一标识每一个事实表行。
Sales_IDCustomer_IDProduct_IDDate_IDStore_IDSales_AmountQuantity_Sold1C001P00120240101S0015022C002P00320240102S0023013C003P00220240103S001753
如果没有相关维度不要试图以0表示没有活动发生来填充事实表因为这些0将会占据大量的事实表。从行的数量来看事实表趋向于变长。从列的数量来看事实表趋向于变短。鉴于事实表占据大量空间的实际情况应该仔细考虑对事实表空间的利用问题。 1.3.2 用于描述环境的维度表 维度表包含与业务过程度量事件有关的文本环境“谁、什么、哪里、何时、如何、为什么”。 维度属性可以作为查询约束、分组、报表标识的主要来源。维度属性对构建DW/BI系统的可用性和可理解性也起着非常重要的作用属性应该是真实使用的词汇而不是令人迷惑的缩写。 与事实表比较维度表趋向于包含较少的行但由于可能存在大量文本列而导致存在多列的情况。 维度表通常以层次关系表示。例如产品抽象为品牌然后抽象为类别。层次描述信息虽然存在冗余但可以方便使用和提高查询性能。
产品链产品描述品牌名称类别名称P001Phone AAppleElectronicsP002Phone BSamsungElectronicsP003Sports Shoes CNikeSportswearP004Laptop DDellElectronicsP005Running Shoes EAdidasSportswearP006Sofa FIKEAFurniture
维度表通常不一定要满足3NF常常是非规范化的一个维度表往往存在多对一的关系。 Tips
一个数字量到底是事实还是维度属性对设计者来说是一个两难的问题。一般认为连续值数字基本上可以认为属于事实来自于一个不太大的列表的离散数字基本可认为是维度属性。多数情况下数据仓库的好坏直接取决于维度属性的设置DW/BI环境的分析能力直接取决于维度属性的质量和深度。——强大的维度熟悉带来的回报是健壮的分片-分块能力。 1.3.4 星型模式中维度与事实的连接
维度模型表示每个业务过程包含事实表事实表存储事件的数值化度量围绕事实表的是多个维度表维度表包含事件发生时实际存在的文本环境。 维度模型首先需要注意的是其简单性对业务用户有利属于易于理解和查询和对称性。维度模型的简单性也会带来性能方面的好处。数据库优化器在处理这些很少使用连接操作的简单模式会更加高效。维度模型非常适于变化。每个维度的地位都相同所有维度在事实表中都存在对应的入口点。如果业务用户建议采用新的模式分析业务不需要调整模式例如需要添加一个新的维度比如“渠道”维度只需要在维度表中添加一个新的维度数据表并且通过外键与事实表连接即可。 1.4 Kimball的DW/BI架构
Kimball的DW/BI架构分为四个不同的组成部分
操作型源系统、ETL系统、数据展现、商业智能应用。 1.4.1 操作型源系统
操作型源系统是指产生原始数据的业务系统也就是日常运营中使用的系统主要关注处理性能和可用性。操作型源系统中的数据通常是事务性的、实时的用于支持日常的业务操作。源系统中的数据是进入数据仓库的基础。数据的结构通常是 规范化的即数据尽量避免冗余以优化数据的存储和处理效率。源系统一般不维护历史信息好的数据仓库可以更好地承担源系统表示过去情况的责任。 1.4.2 获取-转换-加载ETL系统
ETLExtract, Transform, Load系统是整个数据仓库架构中的关键部分。它的主要任务是从操作型源系统中获取数据进行必要的转换并将数据加载到数据仓库中。 获取Extract 从操作型源系统中提取数据。这些数据可以来自不同的数据库、文件系统、API等。获取过程需要从不同的数据源抽取数据并确保数据的完整性。 转换Transform 数据在ETL过程中需要进行转换使其符合数据仓库的设计要求和业务需求。转换的过程可能包括 清洗例如处理缺失数据、去除重复数据、规范化字段格式如日期格式统一。计算进行各种业务计算如汇总、加总、平均值计算等。映射和整合将来自不同系统的数据映射到统一的标准合并不同数据源中的信息。数据质量验证确保数据的正确性和一致性。 加载Load 将清洗和转换后的数据加载到数据仓库中。根据数据仓库的设计数据可以按 批量加载如每晚一次或者 实时加载如使用流式处理。
ETL系统的目标是确保数据仓库中的数据是高质量、统一的并且能够快速响应业务决策的需求。 1.4.3 用于支持商业智能决策的展现区
展现区Presentation Layer是数据仓库的核心部分也是支持商业智能BI决策的基础。这个区域存储着经过ETL处理、符合查询需求的数据。 展现区的设计通常遵循以下模式 星型模式Star Schema在这种模式下数据仓库的核心是 事实表它包含了业务数据如销售数量、金额等。围绕事实表存在多个 维度表它们提供了业务数据的上下文如时间、产品、客户等。星型模式简单、易理解适合高效查询。 雪花模式Snowflake Schema与星型模式相似但维度表进一步规范化形成类似雪花形状的结构。虽然雪花模式减少了数据冗余但查询性能相对较差通常适用于需要较复杂分析的情况。 数据集市Data Mart对于大型企业来说可能会将整个数据仓库分成多个小的 数据集市每个数据集市针对特定部门或业务领域如销售数据集市、财务数据集市等。数据集市通常是数据仓库的一个子集能够提供特定部门所需的数据。 Tips
《数据仓库工具箱》第三版中关于展现区设计的重要原则 数据应该以维度模型来展现星型模型或OLAP多维数据库 维度模型是数据仓库中的一种常见结构主要用于支持高效的查询和分析。在展现区数据应该通过星型模型或OLAP多维数据库来组织和展现。星型模型由一个中心的事实表和多个与其相连的维度表组成。这种结构非常直观易于理解适合快速查询和多维分析。OLAP多维数据库则是另一种将数据按照多个维度组织的方式通常通过数据立方体来实现支持更加灵活和复杂的查询方式如切片、切块、钻取等。维度模型的设计有助于高效地支持报表和数据分析它可以将复杂的数据结构简化为便于理解和查询的格式。 必须包含详细的原子数据 展现区不仅要提供汇总和聚合数据还应当包含详细的原子数据。这些原子数据是数据仓库中的基础单元是任何高级分析或报表的构建基础。原子数据通常来自于数据仓库的事实表它包含每个事件或交易的基本信息如销售记录、交易金额等。通过提供原子数据业务用户可以更深入地分析数据进行详细的钻取、追踪和分析。例如销售数据不仅应该提供销售额的汇总还应该包括每一笔交易的详细记录支持用户进行更精细的分析和探索。 围绕业务过程度量事件来构建 展现区的数据应该围绕业务过程度量事件来构建。业务过程是指企业运作中的关键活动或操作如销售、生产、库存等。每一个业务过程通常会产生度量数据如销售额、生产数量等。在设计展现区时应该确保这些业务过程的度量数据在事实表中得到体现并且能够被按不同的维度进行分析。例如销售过程的度量数据可以按时间、区域、产品等维度进行分析帮助决策者更好地理解业务情况。这种以度量事件为核心的设计方式有助于确保数据仓库中的数据反映了实际的业务活动符合业务需求。 必须使用公共且一致的维度建立维度结构遵守总线结构 展现区应该使用公共且一致的维度来构建维度结构。维度表是数据仓库中用来描述和分析数据的结构它们与事实表中的度量数据一起使用来生成报表和分析视图。总线结构是一种标准化的数据仓库设计方法要求在整个数据仓库中使用一致的维度。这些维度表应当在所有数据集市中共享以确保不同部门或功能区域使用的是一致的数据。使用一致的维度结构有助于确保跨业务部门或功能区域的数据能够进行一致性分析并提高数据的可维护性和可扩展性。例如客户维度、时间维度、产品维度等应该在整个数据仓库中保持一致避免不同区域或部门使用不同版本的维度数据。 1.4.4 商业智能应用
商业智能应用是最终用户用来访问数据仓库和展现区的工具。它们包括各种用于数据分析、报告和决策支持的应用程序和工具。 报表工具用于生成定期的业务报告。例如财务报告、销售报告等。 仪表盘Dashboards可视化工具帮助用户实时查看业务关键指标KPI例如销售额、利润、库存等。仪表盘通常用于监控和跟踪实时业务数据。 OLAP在线分析处理工具支持多维分析让用户能够从不同的角度分析数据。例如用户可以按时间、地点、产品等多个维度查看销售数据。 数据挖掘工具用于深入分析数据发现潜在的趋势、模式和关系。例如预测模型、客户行为分析等。 自助式BI工具例如Tableau、Power BI等它们使业务用户能够不依赖IT部门自主探索数据、生成报告和创建可视化图表。 1.4.5 以餐厅为例描述Kimball架构
在《数据仓库工具箱》第三版的1.4.5节中书中通过餐厅的例子来描述了Kimball架构
餐厅的运营流程
顾客点餐顾客是餐厅的用户他们通过点餐开始了整个过程。在这个比喻中顾客就代表了业务用户他们需要通过数据仓库来获取所需的信息。厨房准备食物餐厅的厨房代表着数据仓库的ETL过程数据提取、转换和加载。数据从不同的来源系统提取出来经过清洗和转换最终被准备好类似食物的准备过程然后进入展现区供顾客业务用户享用。菜单设计餐厅的菜单类似于数据仓库中的数据模型它列出了顾客可以选择的各种菜品。在数据仓库中菜单是指数据模型的设计例如使用维度模型如星型模型来组织和展示数据确保业务用户能够通过简单的查询快速获得所需信息。顾客享用餐食顾客最终通过餐厅的服务例如点餐系统、服务员等享用食物这个环节对应了数据仓库的用户访问层。业务用户通过BI工具或其他应用程序访问和分析数据以支持决策。 Kimball架构的关键特点
业务需求驱动餐厅的设计和菜单是根据顾客需求来决定的类似地Kimball架构强调数据仓库的设计必须从业务需求出发确保数据仓库能够满足最终用户的需求。数据集市Data Mart餐厅的菜单可以看作是不同的数据集市。在Kimball架构中数据仓库通常被分为多个数据集市针对不同的业务领域如销售、财务、客户等进行优化。这些数据集市通过共享的维度模型如星型模型来整合成一个整体的企业数据仓库。ETL流程数据仓库的ETL流程就像餐厅的厨房一样负责从多个数据源提取数据、进行清洗和转化然后将数据加载到数据仓库中的事实表和维度表。这个过程确保了数据的质量和一致性。共享维度餐厅的菜单上的菜品和价格等信息是统一的Kimball架构要求所有的数据集市都应使用公共且一致的维度例如客户、时间、产品等维度从而确保跨部门和跨业务领域的数据能够一致地进行分析和报表生成。以分析为驱动餐厅不仅要提供美食还要根据顾客需求不断调整菜单。同样数据仓库的设计不仅仅是为了存储数据更是为了支持分析和决策。因此Kimball架构强调围绕业务过程如销售、生产、库存等来设计数据仓库确保数据能够高效支持各种业务分析需求。 1.5 其他DW/BI架构
这一小节不太重要略过啦~
1.6 维度建模神话
维度建模尤其是星型模型是数据仓库设计的核心但它也有一些误解存在这些误解可能导致数据仓库设计的误区。
《数据仓库工具箱》第三版1.6节中关于维度建模的一些常见误解做出的解释
1.6.1 神话1维度模型仅包含汇总数据 神话内容许多人认为维度模型只处理汇总数据即将大量的详细数据聚合到一个简化的视图中进行统计分析。 现实实际上维度模型不仅包含汇总数据还包含原始的、详细的事务数据。维度模型的目的是让用户能够灵活地对数据进行多维度查询和分析。这些维度表中的数据可以支持从汇总到细节的各种查询。比如用户不仅可以查询“销售总额”还可以钻取到每一笔具体的销售记录。 结论维度模型可以同时存储详细数据和汇总数据提供更深层次的分析能力。 1.6.2 神话2维度模型是部门级而不是企业级的 神话内容有人认为维度模型仅适用于某一部门如销售、财务等级别的业务分析而不能跨部门或跨企业进行整合。 现实维度模型的设计可以是企业级的通过使用共享的维度例如时间、客户、产品等来保证跨部门的数据一致性。这种设计方式能够促进跨部门的数据整合使得整个企业的数据仓库形成统一的数据视图。例如一个企业可以有多个部门的数据集市但这些集市都会共享一个统一的客户维度、时间维度等确保数据的一致性和互操作性。 结论维度模型设计可以服务于整个企业而不仅仅是某个部门。通过共享维度维度模型能够实现企业级的数据整合和分析。 1.6.3 神话3维度模型是不可扩展的 神话内容有些人认为维度模型一旦设计好就无法扩展或修改。例如增加新的维度或度量项会很困难。 现实维度模型具有很高的可扩展性。随着业务需求的变化新的维度、事实表或度量项可以轻松地被添加到现有的模型中。例如可以根据新的业务需求增加客户地域、产品类别等维度或者增加新的指标如新的销售渠道或服务类型。通过适当的设计维度模型能够适应业务的发展支持业务的不断扩展。 结论维度模型具有很好的可扩展性能够根据业务需求的变化灵活调整。 1.6.4 神话4维度模型仅用于预测 神话内容有人误以为维度模型仅用于预测分析如趋势预测、需求预测等而不适用于其他类型的数据分析。 现实维度模型广泛应用于各种类型的数据分析不仅仅局限于预测。它能够支持包括历史数据分析、运营数据监控、性能分析等多种分析需求。维度模型通过多维度视角支持报表生成、趋势分析、KPI关键绩效指标分析等各类业务决策帮助企业在多个维度上进行深入分析。 结论维度模型不仅适用于预测分析还可以广泛用于历史数据分析、报表生成、趋势分析等多种类型的商业智能分析。 1.6.5 神话5维度模型不能被集成 神话内容有些人认为维度模型无法与其他数据源如大数据平台、数据湖等进行集成因此它只能在传统数据仓库环境中使用。 现实维度模型是非常灵活的可以与多种不同的数据源集成包括传统的关系型数据库、大数据平台、云数据仓库以及数据湖等。通过适当的数据集成方法和工具维度模型可以从多种数据源抽取数据并统一存储和管理。无论是从结构化数据源还是从非结构化数据源如日志数据、文本数据等获取的数据都可以集成到维度模型中进行统一分析。 结论维度模型不仅能与传统数据仓库集成还可以与大数据平台、云计算和数据湖等现代数据架构集成。 水平有限欢迎在评论区讨论交流~
