当前位置：首页 > news >正文

网站以下内容未做缓存如何制作微网站

news 2025/12/19 4:05:30

网站以下内容未做缓存,如何制作微网站,电商平台开发方案,铜梁城乡建设网站目录数仓建模为什么要对数据仓库进行分层主题主题的概念维度建模#xff1a; 模型的选择#xff1a; 星形模式雪花模型星座模式拉链表维度表和事实表#xff1a; 维度表事实表事实表设计规则退化维度事务事实表、周期快照事实表、累积快照事实…目录数仓建模为什么要对数据仓库进行分层主题主题的概念维度建模模型的选择星形模式雪花模型星座模式拉链表维度表和事实表维度表事实表事实表设计规则退化维度事务事实表、周期快照事实表、累积快照事实表四步维度建模建模步骤落地实施的具体步骤同步策略基本原则数仓建模不以规矩不能成方圆。火车之所以能奔驰千里是因为它始终离不开两条铁轨风筝之所以能飞翔万尺是因为它总是情系着手中的线大江东流日月交替大自然生生不息用规则演绎着生命的轨迹。先确认主题然后是维度建模的四个步骤为什么要对数据仓库进行分层实现好分层架构有以下好处清晰数据结构每一个数据分层都有对应的作用域在使用数据的时候能更方便的定位和理解。数据血缘追踪提供给业务人员或下游系统的数据服务时都是目标数据目标数据的数据来源一般都来自于多张表数据。若出现目标数据异常时清晰的血缘关系可以快速定位问题所在。而且血缘管理也是元数据管理重要的一部分。减少重复开发数据的逐层加工原则下层包含了上层数据加工所需要的全量数据这样的加工方式避免了每个数据开发人员都重新从源系统抽取数据进行加工。数据关系条理化源系统间存在复杂的数据关系比如客户信息同时存在于核心系统、信贷系统、理财系统、资金系统取数时该如何决策呢数据仓库会对相同主题的数据进行统一建模把复杂的数据关系梳理成条理清晰的数据模型使用时就可避免上述问题了。屏蔽原始数据的影响数据的逐层加工原则上层的数据都由下一层的数据加工获取不允许跳级取数。而原始数据位于数仓的最底层离应用层数据还有多层的数据加工所以加工应用层数据的过程中就会把原始数据的变更消除掉保持应用层的稳定性。主题主题的概念主题Subject是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念每一个主题基本对应一个宏观的分析领域。在逻辑意义上它是对应企业中某一宏观分析领域所涉及的分析对象。例如“销售分析”就是一个分析领域因此这个数据仓库应用的主题就是“销售分析”。主题域是对某个主题进行分析后确定的主题的边界。分析主题域确定要装载到数据仓库的主题是信息打包技术的第一步。而在进行数据仓库设计时一般是一次先建立一个主题或企业全部主题中的一部分因此在大多数数据仓库的设计过程中都有一个主题域的选择过程。主题域的确定必须由最终用户和数据仓库的设计人员共同完成。主题域的确定必须由最终用户和数据仓库的设计人员共同完成的而在划分主题域时大家的切入点不同可能会造成一些争论、重构等的现象考虑的点可能会是下方的某些方面按照业务或业务过程划分比如一个靠销售广告位置的门户网站主题域可能会有广告域客户域等而广告域可能就会有广告的库存销售分析、内部投放分析等主题根据需求方划分比如需求方为财务部就可以设定对应的财务主题域而财务主题域里面可能就会有员工工资分析投资回报比分析等主题按照功能或应用划分比如微信中的朋友圈数据域、群聊数据域等而朋友圈数据域可能就会有用户动态信息主题、广告主题等按照部门划分比如可能会有运营域、技术域等运营域中可能会有工资支出分析、活动宣传效果分析等主题维度建模在维度建模的基础上又分为三种模型星型模型、雪花模型、星座模型。模型的选择首先就是星座不星座这个只跟数据和需求有关系,跟设计没关系,不用选择。星型还是雪花,取决于性能优先,还是灵活更优先。目前实际企业开发中,不会绝对选择一种,根据情况灵活组合,甚至并存(一层维度和多层维度都保存)。但是整体来看,更倾向于维度更少的星型模型。尤其是Hadoop体系,减少Join就是减少Shuffe,性能差距很大。(关系型数据可以依靠强大的主键索引) 星形模式星型模型是数据集市维度建模中推荐的建模方法。星型模型是以事实表为中心所有的维度表直接连接在事实表上像星星一样。星型模型的特点是数据组织直观执行效率高。因为在数据集市的建设过程中数据经过了预处理比如按照维度进行了汇总排序等等数据量减少执行的效率就比较高星形模式的维度建模由一个事实表和一组维表成且具有以下特点维表只和事实表关联维表之间没有关联每个维表的主码为单列且该主码放置在事实表中作为两边连接的外码以事实表为核心维表围绕核心呈星形分布雪花模型雪花模型也是维度建模中的一种选择。雪花模型的维度表可以拥有其他维度表的虽然这种模型相比星型模型更规范一些但是由于这种模型不太容易理解维护成本比较高而且性能方面需要关联多层维表性能也比星型模型要低。所以一般不是很常用。星形模式中的维表相对雪花模式来说要大而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表满足了规范化设计。然而这种模式在实际应用中很少见因为这样做会导致开发难度增大而数据冗余问题在数据仓库里并不严重。星座模式星座模型是星型模型延伸而来星型模型是基于一张事实表的而星座模型是基于多张事实表的而且共享维度信息。通过构建一致性维度来建设星座模型也是很好的选择。比如同一主题的细节表和汇总表共享维度不同主题的事实表可以通过在维度上互相补充来生成可以共享的维度。拉链表什么是拉链表拉链表是针对数据仓库设计中表存储数据的方式而定义的顾名思义所谓拉链就是记录历史。记录一个事物从开始一直到当前状态的所有变化的信息。拉链表和流水表流水表存放的是一个用户的变更记录比如在一张流水表中一天的数据中会存放一个用户的每条修改记录但是在拉链表中只有一条记录。维度表和事实表维度表维度表一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。例如用户、商品、日期、地区等。与事实表比较维度表一般包含较少的行但是可能列数较多缓慢变化维事实表事实表中的每行数据代表一个业务事件下单、支付、退款、评价等。“事实”这个术语表示的是业务事件的度量值可统计次数、个数、金额等每一个事实表的行包括具有可加性的数值型的度量值、与维表相连接的外键、通常具有两个和两个以上的外键、外键之间表示维表之间多对多的关系。事实表中的每行对应一个度量事件每行中的数据是一个特定级别的细节数据称为粒度粒度可划分为三类事务、周期性快照、累积快照事实表的事实数值可分为三种可加性、半可加、不可加事实表设计规则尽可能包含所有与业务过程相关的事实只选择与业务过程相关的事实分解不可加性事实为可加的组件比如订单的优惠率应该分解为订单原价金额与订单优惠金额在选择维度和事实之前必须先声明粒度在同一个事实表中不能有多种不同粒度的事实粒度的声明是事实表设计中不可忽视的重要一步粒度用于确定事实表中一行所表示业务的细节层次决定了维度模型的扩展性在选择维度和事实之前必须先声明粒度且每个维度和事实必须与所定义的粒度保持一致在同一个事实表中不能有多种不同粒度的事实事实的单位要保持一致对事实的 null 值要处理在数据库中null值对常用的大于或小于等SQL不生效建议使用零值填充使用退化维度提高事实表的易用性目的主要是为了减少下游用户使用时关联多个表的操作。直接通过退化维度实现对事实表的过滤查询、控制聚合层次、排序数据以及定义主从关系等退化维度有时维度除了主键外没有其他内容。例如当某一发票包含多个数据项时数据项事实行继承了发票的所有描述性维度外键发票除了外键外无其他项。但发票数量仍然是在此数据项级别的合法维度键。这种退化维度被放入事实表中清楚地表明没有关联的维度表。退化维度常见于交易和累计快照事实表中。事务事实表、周期快照事实表、累积快照事实表 ·事务事实表事务事实表描述业务过程事务层面的事实每条记录代表一个事务事件保留事务事件活动的原始内容。事务事实表中的数据在事务事件发生后记录一般记录后数据就不再进行更改其更新方式为增量更新。事务事实表相对其他事实表保存的数据粒度更细可以通过事务事实表对事务行为进行详细分析。 ·周期快照事实表周期快照事实表以具有规律性、可预见的时间间隔产生快照来记录事实每行代表某个时间周期的一条记录记录的事实是时间周期内的聚集事实值或状态度量。周期快照事实表的内容一般在所表达的时间周期结束后才会产生一般记录后数据就不再更改其更新方式为增量更新。周期快照事实表一般是建立在事务事实表之上的聚集维度比事务事实表少粒度比事务事实表粗但是由于对事实进行了多种形式的加工从而产生了新的事实故一般事实会比事务事实表多。 ·累计快照事实表累积快照事实表覆盖一个事务从开始到结束之间所有的关键事件覆盖事务的整个生命周期通常具有多个日期字段来记录关键事件时间点。周期快速事实表涉及的多个事件中任意一个的产生都要做记录由于周期快照事实表涉及的多个事件的首次加载和后续更新时间是不确定的因此在首次加载后允许对记录进行更新一般采用全量刷新的方式更新。累计快照事实表一般用于追踪某个业务的全生命周期及状态转换比如交易业务涉及下单、支付、发货、确认收货这些相关事件在不同的事务事实表中通过事务事实表很难看到不同事件之间的转化及状态变化通过累计快照事实表可把相关事件串起来放在一条记录中这样就很容易解决了。四步维度建模不管哪种类型的事实表设计方法都类似事实表设计可以遵循以下步骤选择业务过程→声明粒度→确认维度→确认事实第一步选择业务过程确定业务过程。企业业务是由一个个业务过程组成的事实表就是为了记录这些业务过程产生的事实以便还原任意时刻的业务运转状态。所以设计事实表第一步就是确定实施所要表达的是哪一个或者几个业务过程。笔者理解业务过程是企业活动事件比如注册、登录、下单、投诉等都是业务过程最基本的是每一个业务过程对应一张事实表这样最容易理解。但是实际开发过程中业务过程和事实表会存在多对多的关系。第二步定义粒度。不管事实表对应一个还是多个业务过程粒度必须是确定的每个事实表都有且只能有唯一的粒度粒度是事实表的每一行所表示的业务含义是事实的细节级别。在实际设计过程中粒度与主键等价粒度更偏向业务而主键是站在技术角度说的。虽然粒度在最终的事实表中很难被体现但是定义粒度是必不可少的步骤这样可避免整个事实表的业务含义模糊。第三步确定维度。定义粒度之后事实表每一行的业务含义就确定了。那么业务人员会站在哪些角度来描述事实度量这就要确定维度了常见的维度有时间、区域、客户、产品、员工等。维度依附于粒度是粒度的环境描述。第四步确定事实。事实就是事实表度量的内容也就是业务过程产生的事实度量的计算结果比如注册量、登录次数、交易金额、退款量等。事实表的所有事实度量都与事实表所表达的业务过程相关所有事实必须满足第二步所定义的粒度。第五步冗余维度属性。事实表的设计要综合考虑数据来源和使用需求在满足业务事实记录的同时也要满足使用的便利性和性能要求。大数据时代事实表记录数动辄亿级甚至数十亿、数百亿维表也有可能达到亿级甚至更多。利用标准维度模型会经常出现维表与事实表关联的情况这种对亿级表的关联计算在性能上是灾难性的。为了满足业务需求降低资源消耗建议适当冗余维度属性数据到事实表直接利用事实表就可以完成绝大部分业务的使用需求这样下游使用时可减少大表关联提升效率。所以大数据时代适当进行维度冗余是可取的。建模步骤主要过程自己归纳可能部分有误 1了解业务流程确定范围、收集业务和技术资料、模型设计研讨 2分析源数据分析整理数据结构分析源系统样本数据 3建立实体模型框架设计、数据源主题划分、概念模型设计 4模型详细设计归纳映射、属性扩展、数据类型定义、实体间依赖关系、填写并完善实体属性 5逻辑数据模型客户化按主题规划宽表设计 6模型验证命名、布局、划分是否规范数据验证准确性以及是否有遗漏应用验证是否满足下游应用系统和数据分析的要求合理性验证准入原则、数据关系落地实施的具体步骤 1按照命名规范创建表包括维表和事实表 2开发生成维表和事实表的数据的逻辑代码 3进行代码逻辑测试验证数据加工逻辑的正确性 4代码发布加入生产调度并配置相应的质量监控和报警机制 5持续任务运维监控。同步策略数据同步策略的类型包括全量表、增量表、新增及变化表、拉链表全量表存储完整的数据。增量表存储新增加的数据。新增及变化表存储新增加的数据和变化的数据。拉链表对新增及变化表做定期合并。 1、实体表同步策略　实体表比如用户商品商家销售员等　实体表数据量比较小通常可以做每日全量就是每天存一份完整数据。即每日全量。 2、维度表同步策略　　维度表比如订单状态审批状态商品分类　维度表数据量比较小通常可以做每日全量就是每天存一份完整数据。即每日全量。　说明　　　 1针对可能会有变化的状态数据可以存储每日全量。　　　 2没变化的客观世界的维度比如性别地区民族政治成分鞋子尺码可以只存一份固定值。 3、事务型事实表同步策略事务型事实表比如交易流水操作日志出库入库记录等。因为数据不会变化而且数据量巨大所以每天只同步新增数据即可所以可以做成每日增量表即每日创建一个分区存储。　　 4、周期型事实表同步策略　周期型事实表比如订单、请假、贷款申请等　这类表从数据量的角度存每日全量的话数据量太大冗余也太大。如果用每日增量的话无法反应数据变化。　　每日新增及变化量包括了当日的新增和修改。一般来说这个表足够计算大部分当日数据的。但是这种依然无法解决能够得到某一个历史时间点时间切片的切片数据。　　所以要用利用每日新增和变化表制作一张拉链表以方便的取到某个时间切片的快照数据。所以我们需要得到每日新增及变化量。基本原则 1.高内聚和低耦合一个逻辑或者物理模型由哪些记录和字段组成应该遵循最基本的软件设计方法论的高内聚和低耦合原则。主要从数据业务特性和访问特性两个角度来考虑将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型将高概率同时访问的数据放一起将低概率同时访问的数据分开存储。核心模型与扩展模型分离建立核心模型与扩展模型体系核心模型包括的字段支持常用的核心业务扩展模型包括的字段支持个性化或少量应用的需要不能让扩展模型的字段过度侵入核心模型以免破坏核心模型的架构简洁性与可维护性。公共处理逻辑下沉及单一越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现不要让公用的处理逻辑暴露给应用层实现不要让公共逻辑多处同时存在。成本与性能平衡适当的数据冗余可换取查询和刷新性能不宜过度冗余与数据复制。数据可回滚处理逻辑不变在不同时间多次运行数据结果确定不变。一致性具有相同含义的字段在不同表中的命名必须相同必须使用规范定义中的名称。命名清晰、可理解表命名需清晰、一致表名需易于消费者理解和使用。

查看全文

http://www.dnsts.com.cn/news/190548.html