网站页脚怎么做美观,江宁区住房和城乡建设厅网站,深圳网站搜索,检察内网门户网站建设1. 简述数据仓库架构 #xff1f;
数据仓库的核心功能从源系统抽取数据#xff0c;通过清洗、转换、标准化#xff0c;将数据加载到BI平台#xff0c;进而满足业 务用户的数据分析和决策支持。 数据仓库架构包含三个部分#xff1a;数据架构、应用程序架构、底层设施
1
数据仓库的核心功能从源系统抽取数据通过清洗、转换、标准化将数据加载到BI平台进而满足业 务用户的数据分析和决策支持。 数据仓库架构包含三个部分数据架构、应用程序架构、底层设施
1底层设施 底层设施为架构提供了基础底层设施包括硬件、数据库平台、网络和桌面系统。 1硬件 硬件主要指服务器硬件主要有数据库服务器、ETL服务器、调度服务器、报表服务器、BI门户服务 器、接口服务器。 2数据库平台 数据库平台分为二大类联机事务处理OLTPon-line transaction processing、联机分析处理OLAPOn-Line Analytical Processing主要有OracelMySQL。OLAP是为数据分析而设计的数据库管理系统。主要有Teradata, GreenplumHiveKudu。 3桌面系统 数据仓库不同的应用对桌面系统也有不同的要求开发工具主要有Window、Mac面系统部署服务器主 要有Unix桌面系统系统BI应用程序主要有Window、Mac、移动设备桌面系统。 4网络 网络是底层设施的基础特别是大数据时代对网络的要求越来越高。
2BI应用程序架构 数据仓库是数据处理的后台业务用户并不关心后台怎么处理。BI应用是数据呈现的前台是业务用户 进行查询的入口。BI应用程序的体验也是衡量数据仓库是否成功的主要因素。 1 BI分析周期 业务分析从监视活动开始识别某个问题或时机进而采取行动最终回到监视该活动产生的结果上来 达到数据驱动业务增长的目的。分析周期把这个过程分为五个不同的阶段。 2 BI应用分类接口查询 数据以接口的形式提供给上下游系统供上下业务系统进行查询。主要有推和拉二种模式。 即席查询 业务用户根据自己的需求自定义查询请求后台自动组织SQL语句访问维度模型。 标准报表 根据业务用户的需求进行定制报表。仪表盘 它是向企业展示度量信息和关键业务指标现状的数据可视化工具。数据挖掘 为数据挖掘工具提供标准基础数据。运营查询 为了减少业务系统的大数据量查询压力数据仓库为业务系统提供实时的查询。 3数据存储 为了提高查询性能BI工具需要把数据存储在本地服务器上 OLAP多维模型需要把数据存储成Cube格式把数据存储成文件格式放在其他服务器上 3数据结构 数据架构主要描述数据从源系统抽取数据然后经过清洗、规范化、提交形成标准模型最终提交给业 务用户以及对数据的管理。 1源系统 数据仓库一般会面临多个、异构数据源的问题主要分为结构化半结构化以及非结构化数据。为了便 于管理需要对源系统建立元数据信息。 2抽取 因为源系统的多样性源抽取阶段一般选择使用工具。在抽取之前还要做以下工作
数据剖析是对数据的技术性分析对数据的内容、一致性和结构进行描述。对源系统的数据质量进行评 估。 数据剖析 变化数据捕获策略 为了减少对源系统的影响一般只抽取变化的数据也需要识别物理删除的数据。CDC策略主要有 添加审计列 在源系统追加日期字段当数据发生变化的时候系统会自动更新该值。如果由后台人员手工修改 数据可能就发生遗漏。 数据比较 比较源系统和数据仓库的数据只抽取变化的数据。这种方法需要全量的数据比较耗费资源。可 以视数据量的大小而定。 读取日志 读取数据库操作日志信息同步到数据仓库中。一般日志的有效期比较短一旦发生要重跑的情 况可能以前的日志已经被清空了。 消息队列 把事务信息放到消息队列里以流的形式同步到数据仓库。这种方式即可以减轻源系统的压力又 能做到实时同步。
3数据转换 数据从源系统抽取过来之后就要进入数据转换阶段。 这一阶段是数据仓库开发核心阶段。主要有以下步骤 清洗 数据清洗是制定转换规则筛选数据并纠正数据的过程。清洗的目的是改进源系统的数据质量但是不 要在数据仓库做过多的清洗源系统的数据质量应该在源头处理。清洗的主要内容包括 制定数据转换规则提交错误事实表 规范化 规范化就是整合各个源系统的数据把数据统一命名统一取值建立企业标准版本数据。主要内容包 括 数据标准化删除重复数据数据共存策略 4提交 提交就要根据维度模型生成维度表和事实表。 提交主要内容包括 选择合适的缓慢变化维类型 为维表生成代理键 管理不同粒度的层次维管理专项维 生成维度桥接表生成代理键管道 选择合适的事实表类型处理延迟到达的事实
生成维度表生成事实表 5聚集 聚集是指根据事务事实表进行更高粒度的聚合以及生成相对应的维度表。主要内容包括 数据聚合 缩小维度表 生成OLAP多维数据集 6数据存储 数据存储是指在在数据的生命周期内对数据的管理主要内容包括 数据备份 历史数据归档 ETL过程中数据分层存储
2. 简述数仓架构设计的方法和原则
1数据设计方法 数据仓库建立之前就必须考虑其实现方法通常有自顶向下、自底向上和两者结合进行的这样三种实 现方案。 1自顶向下实现 自顶向下的实现需要在项目开始时完成更多计划和设计工作这就需要涉及参与数据仓库实现的每个工 作组、部门或业务线中的人员。要使用的数据源、安全性、数据结构、数据质量、数据标准和整个数据 模型的有关决策一般需要在真正的实现开始之前就完成。 2自底向上实现 自底向上的实现包含数据仓库的规划和设计无需等待安置好更大业务范围的数据仓库设计。这并不意 味着不会开发更大业务范围的数据仓库设计随着初始数据仓库实现的扩展将逐渐增加对它的构建。 现在该方法得到了比自顶向下方法更广泛的接受因为数据仓库的直接结果可以实现并可以用作扩 展更大业务范围实现的证明。 3两者结合的折中实现 每种实现方法都有利弊。在许多情况下最好的方法可能是某两种的组合。该方法的关键之一就是确定 业务范围的架构需要用于支持集成的计划和设计的程度因为数据仓库是用自底向上的方法进行构建。 在使用自底向上或阶段性数据仓库项目模型来构建业务范围架构中的一系列数据集市时您可以一个接 一个地集成不同业务主题领域中的数据集市从而形成设计良好的业务数据仓库。这样的方法可以极好 地适用于业务。在这种方法中可以把数据集市理解为整个数据仓库系统的逻辑子集换句话说数据仓 库就是一致化了的数据集市的集合。 2数仓架构争论 关于Inmon 和 Kimball的大辩论Ralph Kimball 和 Bill Inmon 一直是商业智能领域中的革新者开发并测试了新的技术和体系结构。在BI/DW领域中围绕“哪一种数据仓库架构Data Warehouse Architecture最佳”的争论一直没有休止这个问题同时也是企业在建立DW时需要决策的关键问题 Bill Inmon的集线器架构/企业信息工厂架构Hub and Spoke / CIF – Corporate Information Factory与Ralph Kimball的数据集市/数据仓库总线架构Data Mart Bus Architecture/Data Warehouse Bus Architecture则是DW架构的争论焦点。
Bill Inmon 将数据仓库定义为“一个面向主题的、集成的、非易变的、随时间变化的用于支持管理的决策过程的数据集合”他通过“面向主题”表示应该围绕主题来组织数据仓库中的数据例如客户、销售、产 品等等。每个主题区域仅仅包含该主题相关的信息。数据仓库应该一次增加一个主题并且当需要容易 地访问多个主题时应该创建以数据仓库为来源的数据集市。换言之某个特定数据集市中的所有数据 都应该来自于面向主题的数据存储。 Inmon 的方法包含了更多上述工作而减少了对于信息的初始访问。但他认为这个集中式的体系结构持续下去将提供更强的一致性和灵活性并且从长远来看将真正节省资 源和工作
3数仓架构选型 数据仓库架构的选取与其所处的企业环境和业务的发展有着密切的关系Inmon提倡的数据仓库建设 方法需要数据仓库建设人员自顶向下进行建设数据仓库开发人员需要在数据仓库建设之前对企业各 业务线进行深入的调研有着非常全面的了解然后根据企业各业务特点进行主题域划分。这种建设方 式建设周期比较长规划设计比较复杂但是一旦建成这个集中式的体系结构将提供更强的一致性和 灵活性并且从长远来看将真正节省资源和工作Kimball提倡的数据仓库仅仅是构成它的数据集市的联 合各部门或业务可以根据自身的发展建设符合自身主题的数据集市并持续丰富完善这些数据集 市。在应对企业级数据需求时将这些数据集市的维度信息进行统一整理规范然后通过一致的维度信 息将这些数据集市连接起来使数据集市形成一个覆盖企业所有部门或业务的数据仓库对外提供服务。 根据企业发展阶段和业务发展的速度建议传统的、业务成熟的企业可以考虑采用Inmon方法建设数据 仓库业务复杂而且差异较大、发展速度又非常快的企业可以考虑Kimball方法建设数据仓库。
4企业发展中的数据仓库建设变迁 企业或新部门在初期发展过程中业务量少、组织形式相对简单。使得数仓建设人员可以站在全局的高 度俯视整个公司的业务流程对其进行梳理归类并抽取数据模型。以自上而下的方式建设数据仓 库。所以在初期数据仓库建设的过程中基本采用了Inmon提倡的数据仓库建设方法采用了DataSource– ODS→EDW→DM–APP的结构。即由ODS层完成各部门数据源的集成在ODS的基础上建设了覆盖公司 所有业务的包含众多主题的统一的数据仓库然后由这个统一的数据仓库作为唯一的数据源为各部门 的数据集市提供数据支持 但是一旦企业或部门发展速度非常快业务量急剧增大而且业务的组织形式趋于复杂不同的业务之 间可能存在巨大的差距。数据仓库的建设如果再继续沿用自伤而下的方式就会带来很多困难例如在 Inmon模式下EDW规划复杂、建设周期长不能非常快速的响应各部门的需求所以该方案逐步不能适 应公司的发展。为了适应企业的发展经过数仓开发人员的不断探索尝试基本上倾向于采用混合模式 建设数据仓库即采用InmonKimball的变种模式
3. 简述数据仓库分层层级划分每层做什么分层的好处
首先我要知道数据仓库分层架构的目标是什么是为了实现维度建模进而支撑决策分析目标。 数据分层从关系型在线交易系统到面向主题的数据仓库系统从范式建模到维度建模的必经之路。 数据分层是一套让我们的数据体系更有序的行之有效的数据组织和管理方法。数据分层不是银弹也没 有绝对标准当然也不能包治百病不能解决所有的数据问题但是数据分层却可以给我们带来如下 的好处
隔离原始数据不论是数据的异常还是数据敏感度使真实数据与统计数据解耦开。 数据结构化更清晰每一个数据分层都有它的作用域和职责在使用表的时候能更方便地定位和理解。 数据血缘追踪提供给外界使用的是一张业务表但是这张业务表可能来源很多张表。如果有一张来源 表出问题了我们可以快速准确的定位到问题并清楚每张表的作用范围。 增强数据复用能力减少重复开发通过数据分层规范化开发一些通用的中间层数据能够减少重复 计算提高单张业务表的使用率提升系统的执行效率。 简化复杂的问题把一个复杂的业务分成多个步骤实现每一层只处理单一的步骤比较简单和容易理 解。而且便于维护数据的准确性当数据出现问题之后可以不用修复所有的数据只需要从有问题的 步骤开始修复。 减少业务的影响业务可能会经常变化这样做就不必改一次业务就需要重新接入数据。 减少重复开发规范数据分层开发一些通用的中间层数据能够减少极大的重复计算。 统一数据口径通过数据分层提供统一的数据出口统一对外输出的数据口径。 分层的核心思想就是解耦再解耦把复杂的问题简单化。
一个公司可能有多个业务系统而数据仓库就是将所有的业务系统按照某种组织架构整合 起来形成一个仓储平台也就是数仓。
1、四层分层 第一层 ODS——原始数据层存放原始数据 ODS层即操作数据存储是最接近数据源中数据的一层数据源中的数据经过抽取、洗净、传输也 就说传说中的ETL之后装入本层一般来说ODS层的数据和源系统的数据是同构的主要目的是简化 后续数据加工处理的工作。从数据粒度上来说ODS层的数据粒度是最细的。ODS层的表通常包括两类 一个用于存储当前需要加载的数据一个用于存储处理完后的历史数据。历史数据一般保存3-6个月后需 要清除以节省空间。但不同的项目要区别对待如果源系统的数据量不大可以保留更长的时间甚 至全量保存数据在装入本层前需要做以下工作去噪、去重、提脏、业务提取、单位统一、砍字段、 业务判别。 第二层 DWD——数据明细层对ODS层数据进行清洗、维度退化、脱敏等。覆盖所有系统的、完整的、干净的、具有一致性的数据层。 该层一般保持和ODS层一样的数据粒度并且提供一定的数据质量保证在ODS的基础上对数据进行加 工处理提供更干净的数据。同时为了提高数据明细层的易用性该层会采用一些维度退化手法当 一个维度没有数据仓库需要的任何数据时就可以退化维度将维度退化至事实表中减少事实表和维 表的关联。例如订单id,这种量级很大的维度没必要用一张维度表来进行存储而我们一般在进行数 据分析时订单id又非常重要所以我们将订单id冗余在事实表中这种维度就是退化维度。 第三层 DWS——数据服务层 对DWD层数据进行一个轻度的汇总。 DWS层为公共汇总层会进行轻度汇总粒度比明细数据稍粗会针对度量值进行汇总目的是避免重 复计算。该层数据表会相对比较少大多都是宽表(一张表会涵盖比较多的业务内容表中的字段较 多)。按照主题划分如订单、用户等生成字段比较多的宽表用于提供后续的业务查询OLAP分 析数据分发等。 第四层 DM——数据集市层为各种统计报表提供数据。 存放的是轻度聚合的数据也可以称为数据应用层基于DWD、DWS上的基础数据整合汇总成分析某 一个主题域的报表数据。主要是提供给数据产品和数据分析使用的数据通常根据业务需求划分成流 量、订单、用户等生成字段比较多的宽表用于提供后续的业务查询OLAP分析数据分发等。从数 据粒度来说这层的数据是汇总级的数据也包括部分明细数据。从数据的时间跨度来说通常是DW 层的一部分主要的目的是为了满足用户分析的需求而从分析的角度来说用户通常只需要分析近几 年的即可。从数据的广度来说仍然覆盖了所有业务数据。
2、三层分层 上述四层数仓如果是问的三层数仓就相当于是把DWD、DWS合并成DW层往细的方面分DW还包括DWM层数据中间层三层分层如下 第一层 ODS——原始数据层存放原始数据第二层 DW——数据仓库层数据清洗初步汇总 本层将从 ODS 层中获得的数据按照主题建立各种数据模型每一个主题对应一个宏观的分析领域数据仓库层排除对决策无用的数据提供特定主题的简明视图。在DW层会保存BI系统中所有的历史数据 例如保存10年的数据。 第三层 DM——数据集市层
3、五层分层 五层分层如下 第一层 ODS——原始数据层存放原始数据第二层 DWD——数据明细层对ODS层数据进行清洗、维度退化、脱敏等。第三层 DWS——数据汇总层 对DWD层数据进行一个轻度的汇总。第四层 ADS——数据应用层为各种统计报表提供数据 该层是基于DW层的数据整合汇总成主题域的服务数据用于提供后续的业务查询等。第五层 DIM——维表层基于维度建模理念思想建立整个企业的一致性维度。维表层主要包含两部分数据 高基数维度数据一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。 低基数维度数据一般是配置表比如枚举值对应的中文含义或者日期维表。数据量可能是个位数或 者几千几万。
4. 简述数据分层是根据什么
数据分层没有标准数据分层要结合当下的技术当前的数据量业务的复杂度通盘考量。操作型数据 存储ODS、数据仓库DW、数据集市DM其实就是数据分层的原始的指导建议其中操作型 数据存储是满足多个业务系统获取数据并制作操作型报表的需求保留半年以内的明细准实时数据数 据仓库是为了管理决策、战略分析和计划提供单一整合点保留长期的明细和汇总数据数据集市是用 于特定部门或公共分析需求并定制的采用维度建模方式保留中期的明细和汇总数据
5. 简述数仓分层的原则与思路
数据仓库分层没有绝对的规范适合的就是最好的至于分几层建议按照目前的业务和建设现状进 行合理解构和分层设计一般刚开始做建议3、4层。规划1-1.5年的架构然后不断的建设、优化、再 优化。不断逼近满足所有需求。 下面针对一些场景说下分层的想法 场景一时间紧任务重急于看结果
这种场景直接连各个业务数据库抽取数据到大数据平台根据需求组合join或者汇总count、sum就 行就不要分层了有的公司项目就是将各个业务系统数据抽取到oracle你看都没有大数据平台就做 了。 场景二公司业务简单且相对比较固定数据来源不多结构也很清晰需求也不多 直接使用通用的数仓架构就行ODS起到解耦业务数据库异构数据源的问题DWD解决数据脏乱差的 问题DWS服用的指标计算ADS直接面向前台业务需求。 场景三公司业务复杂业务变化较快 可以考虑多一层DWT层做汇总多一层解耦业务变化的时候我们只改DWS层就好了最多穿透到 DWT层。业务变化的时候调整一下工作量也不会太大最重要的是能保证底层结构的稳定和数据分析 的可持续性。 场景四公司业务较为复杂集团性公司下辖多个部门业务部门事业线业务部门间业务内容交叉不 大 可以在数仓通用分层架构上增加一层DM层也就是数据集市层各个数据集市层单独供数甚至 有单独的计算资源这样可以避免因为计算任务代码混在一起、数据权限拆分等问题带来的数据变更成 本。 一个好的数仓模型分层应该具备的要素 一个好的数仓模型分层应该具备的要素是数据模型可复用完善且规范的。 完善度 DWD 跨 层 引 用 率 DWS/ADS/DM汇总数据查询比例 复用度 DWD/DWS模型引用系数 规范度 有多少表没有主题域、业务过程归属模型命名不规范 字段命名不规范 好的数仓设计标准数据比较丰富完善、数据复用性强、规范性强。 从完善度上来讲主要衡量DWD层和汇总层两块的完善度DWD层完善度主要是希望DWD等尽可能被汇总层引用ODS层被除了DWD层外的尽可能少的引用最好是没有。 从复用度上来讲我们希望80%需求由20%的表来支持。直接点讲就是大部分80%以上的需求 都用DWS的表来支持。 从规范度上来讲主要从表名、字段名来看一个规范的表名应该包括层级、主题域、分区规则抽取 类型等信息。字段规范应该是和词根一致同字段同名等。 数据仓库分层没有绝对的规范适合的就是最好的数据仓库分层的核心逻辑是解耦在有限时间、资 源等条件下满足业务需求同时又要兼顾业务的快速变化。所以我们作为数据架构师需要兼顾业务的 复杂变化以及开发的复杂度和可维护性在两者之间做一个平衡和取舍选择合适的分层架构。 另外分层架构是需要不断的优化调整的不能超前太多也不能脱离业务。按照Inmon和Kimball吵了十 几年的经验上看建议架构设计时按超越当前实际情况1~1.5年的设计是比较合适的。
6. 数仓建模常用模型吗区别、优缺点
数据仓库建模的目标是通过建模的方法更好的组织、存储数据以便在性能、成本、效率和数据质量之 间找到最佳平衡点。 现在数据处理大致可以分为两大类 操作型处理叫联机事务处理 OLTPOn-Line Transaction Processing也可以称面向交易的处理系统它是针对具体业务在数据库联机的日常操作通常对少数记录进行查询、修改。用户较为关心操作 的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主 要手段主要用于操作型处理。 分析型处理叫联机分析处理 OLAPOn-Line Analytical Processing一般针对某些主题的历史数据进行分析支持管理决策。 OLTP与OLAP的主要异同如下表
操作型处理 分析型处理 细节的 综合的或提炼的 实体-关系ER模型 星型或雪花模型 存取瞬间数据 存储历史数据不包含最近的数据 可更新的 只读只追加 一次操作一个单元 一次操作一个集合 性能要求高响应时间短 性能要求宽松 面向事务 面向分析 一次操作数据量小 一次操作数据量大 支持日常操作 支持决策需求 数据量小 数据量大 客户订单、库存水平和银行账户等 客户收益分析、市场细分等
1、关系ER实体建模 严格遵循第三范式从图中可以看出较为松散、零碎物理表数量多而数据冗 余程度低。由于数据分布于众多的表中这些数据可以更为灵活地被应用功能性较强。关系模型主要 应用与OLTP系统中为了保证数据的一致性以及避免冗余所以大部分业务系统的表都是遵循第三范式 的。 这是数据仓库之父Bill Inmon提出的建模方法即实体关系Entity RelationshipER模型。这是从全企业的高度设计一个3NF模型用实体关系模型来描述企业业务在范式理论上符合3NF。 关系模型主要应用于OLTP系统中为了保证数据的一致性以及避免冗余所以大部分业务系统的表都是 遵循第三范式的。 特点设计思路自上而下适合上游基础数据存储同一份数据只存储一份没有数据冗余方便解 耦易维护缺点是开发周期一般比较长维护成本高。 范式理论 范式可以理解为设计一张数据表的表结构符合的标准级别也就是规范和要求。 优点关系型数据库设计时遵照一定的规范要求目的在于降低数据的冗余性。缺点范式的缺点是获取数据时需要通过Join拼接出最后的数据。 分类目前业界范式有第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四 范式(4NF)、第五范式(5NF)。 2、维度建模
维度模型主要应用于OLAP系统中通常以某一个事实表为中心进行表的组织主要面向业 务特征是可能存在数据的冗余但是能方便的得到数据。 关系模型虽然冗余少但是在大规模数据跨表分析统计查询过程中会造成多表关联这会大大降低 执行效率。所以一般都会采用维度模型建模把相关各种表整理成两种事实表和维度表两种。 在维度建模的基础上又可分为三种模型星型模型、雪花模型、星座模型。 维度建模是从分析决策的需求出发构建模型为分析需求服务因此它重点关注用户如何更快速的完成 需求分析同事具有较好的大规模复杂查询的相应能力。其典型的代表是星型模型以及在一些特殊场 景下使用的雪花模型。 维度建模设计分为以下步骤 选择需要进行分析决策的业务过程定义粒度 识别维度确认事实
1星型模型 星型模式是维度模型中最简单的形式也是数据仓库以及数据集市开发中使用最广泛的形式。星型模式 由事实表和维度表组成一个星型模式中可以有一个或多个事实表每个事实表引用任意数量的维度 表。 星型模型与雪花模型的区别主要在于维度的层级标准的星型模型维度只有一层而雪花模型可能会涉 及多层。
2雪花模型 雪花模式是一种多维模型中表的逻辑布局与星型模式相同雪花模式也是由事实表和维度表所组成。 所谓的“雪花化”就是将星型模型中的维度表进行规范化处理。当所有的维度表完成规范化后就形成了 以事实表为中心的雪花型结构即雪花模式。
3星座模型 数据仓库由多个主题构成包含多个事实表而维表是公共的可以共享例如两张事实表共用一些维 度表时就叫做星型模型这种模式可以看做星型模式的汇集因而称作星系模式或者事实星座模 式。 4模型选择 在数据仓库建模时会涉及到模式的选择我们要根据不同模式的特点选择适合具体业务的模式。 星型还是雪花取决于性能优先还是灵活更优先。 在实际开发中不会绝对选择一种根据情况灵活组合甚至并存一层维度和多层维度都保存。但 是整体看来更倾向于维度更少的星型模型。 3、建模方法总结 ER模型以及维度模型是当前主流的建模方法。 ER模型常用于OLTP数据库建模应用到构建数仓时更偏重数据整合站在企业整体考虑将各个系统 的数据按相似性、一致性合并处理为数据分析、决策服务但并不便于直接用来支持分析。 ER模型的特点如下 需要全面梳理企业所有的业务和数据流 实施周期长 对建模人员要求高。 维度建模是面向分析场景而生针对分析场景构建数仓模型重点关注快速、灵活的解决分析需求同 时能够提供大规模数据的快速响应性能。针对性强主要应用于数据仓库构建和OLAP引擎低层数据模 型。 不需要完整的梳理企业业务流程和数据 实施周期根据主题边界而定容易快速实现 demo。
7. 简述星型模型和雪花模型的区别应用场景
随着大数据时代的到来数据仓库的技术和模型也越来越受到关注。在数据仓库中星型模型和雪花模型是两种常用的数据建模方式。这两种模型在结构上存在一定的差异同时也具有各自的优缺点。下面我们来详细了解一下这两种模型的区别以及优缺点。
一、星型模型
星型模型是一种基于事实表的模型它的特点是将事实表与其他维度表相连形成一个放射形结构。在星型模型中所有的维度表都与事实表相连因此它的查询效率比较高易于理解和维护。
星型模型的优点主要有以下几个方面 查询效率高。由于星型模型的结构比较简单因此在查询时可以快速定位到需要的数据。 易于理解和维护。星型模型的结构比较清晰易于理解和维护能够大大降低维护成本。 可扩展性好。星型模型的结构比较松散因此在扩展时比较灵活。 维度分析能力强。星型模型适合进行维度分析能够快速地进行数据分析和数据挖掘。
二、雪花模型
雪花模型是一种基于事实表的模型它的特点是将维度表之间的关系变得更加复杂。在雪花模型中维度表之间存在多对多的关系因此它的结构比较复杂查询效率比较低。
雪花模型的优点主要有以下几个方面 容纳更多维度。由于雪花模型的结构比较复杂因此可以容纳更多的维度使得数据分析更加全面。 避免冗余数据。雪花模型中的维度表之间存在多对多的关系因此可以避免数据的冗余。 减少计算量。由于雪花模型的结构比较复杂因此在查询时需要进行更多的计算但是这样可以减少数据的冗余从而减少计算量。
三、数据仓库的星型模型和雪花模型的区别以及优缺点对比
下面我们来对比一下数据仓库的星型模型和雪花模型的区别以及优缺点
结构方面星型模型的结构比较简单呈放射形雪花模型的结构比较复杂呈雪花状。 查询效率方面星型模型的查询效率比较高而雪花模型的查询效率比较低。 数据冗余方面星型模型的数据冗余比较少而雪花模型的数据冗余比较多。 可扩展性方面星型模型的可扩展性比较好而雪花模型的可扩展性比较差。 综上所述数据仓库的星型模型和雪花模型各有优缺点。在实际应用中应根据具体的应用场景和需求来选择合适的建模方式以达到最优的效果。
8. 简述数仓建模有哪些方式
1、维度建模 维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型。 1星型模型 星型模型主要是维表和事实表以事实表为中心所有维度直接关联在事实表上呈星型分布。 2雪花模型 雪花模型在星型模型的基础上维度表上又关联了其他维度表。这种模型维护成本高性能方面也较 差所以一般不建议使用。尤其是基于hadoop体系构建数仓减少join就是减少shuule性能差距会很 大。 星型模型可以理解为一个事实表关联多个维度表雪花模型可以理解为一个事实表关联多个维度表 维度表再关联维度表。 3星座模型 数据仓库由多个主题构成包含多个事实表而维表是公共的可以共享例如两张事实表共用一些维 度表时就叫做星型模型这种模式可以看做星型模式的汇集因而称作星系模式或者事实星座模式。
2、范式建模ER建模 从全企业的高度设计一个3NF模型用实体加关系描述的数据模型描述企业业务架构在范式理论上符 合3NF。此建模方法对建模人员的能力要求非常高。 特点设计思路自上而下适合上游基础数据存储同一份数据只存储一份没有数据冗余方便解 耦易维护缺点是开发周期一般比较长维护成本高。
3、Data Vault模型 DataVault由Hub关键核心业务实体、Link关系、Satellite实体属性 三部分组成 是Dan Linstedt发起创建的一种模型方法论它是在ER关系模型上的衍生同时设计的出发点也是为了实现数 据的整合并非为数据决策分析直接使用。
4、Anchor模型 Anchor模型是对Data Vault模型做了进一步规范化处理它是一个高度可扩展的模型所有的扩展只是添加而不是修改因此它将模型规范到6NF基本变成了K-V结构模型。企业很少使用
9. 简述数仓建模的流程
数据仓库的发展大致经历了这样的三个过程 简单报表阶段这个阶段系统的主要目标是解决一些日常的工作中业务人员需要的报表以及生成一 些简单的能够帮助领导进行决策所需要的汇总数据。大部分表现形式为数据库和前端报表工具。 数据集市阶段这个阶段主要是根据某个业务部门的需要进行一定的数据的采集整理按照业务 人员的需要进行多维报表的展现能够提供对特定业务指导的数据并且能够提供特定的领导决策数 据。 数据仓库阶段这个阶段主要是按照一定的数据模型对整个企业的数据进行采集整理并且能够 按照各个业务部门的需要提供跨部门的完全一致的业务报表数据能够通过数据仓库生成对对业务 具有指导性的数据同时为领导决策提供全面的数据支持。 通过数据仓库建设的发展阶段可以看出数据仓库的建设和数据集市的建设的重要区别就在于数据模 型的支持。因此数据模型的建设对于我们数据仓库的建设有着决定性的意义。 一般来说数据模型的建设主要能够帮助我们解决以下的一些问题 1进行全面的业务梳理改进业务流程 在业务模型建设的阶段能够帮助我们的企业或者是管理机关对本单位的业务进行全面的梳理。 通过业务模型的建设我们应该能够全面了解该单位的业务架构图和整个业务的运行情况能够将 业务按照特定的规律进行分门别类和程序化。 同时帮助我们进一步的改进业务的流程提高业务效率指导我们的业务部门的生产。 2建立全方位的数据视角消灭信息孤岛和数据差异 通过数据仓库的模型建设能够为企业提供一个整体的数据视角不再是各个部门只是关注自己的 数据。 而且通过模型的建设勾勒出了部门之间内在的联系帮助消灭各个部门之间的信息孤岛的问题。 更为重要的是通过数据模型的建设能够保证整个企业的数据的一致性各个部门之间数据的差 异将会得到有效解决。 3解决业务的变动和数据仓库的灵活性 通过数据模型的建设能够很好的分离出底层技术的实现和上层业务的展现。 当上层业务发生变化时通过数据模型底层的技术实现可以非常轻松的完成业务的变动从而达 到整个数据仓库系统的灵活性。 4帮助数据仓库系统本身的建设
通过数据仓库的模型建设开发人员和业务人员能够很容易的达成系统建设范围的界定以及长期 目标的规划从而能够使整个项目组明确当前的任务加快整个系统建设的速度。 1、建模流程 就是业务模型-概念模型-逻辑模型-物理模型的这样一个流程下面我们详细解释一下各个模型阶段 都要做什么。 1业务建模需求沟通 划分整个单位的业务一般按照业务部门的划分进行各个部分之间业务工作的界定理清各业务 部门之间的关系。 深入了解各个业务部门的内具体业务流程并将其程序化。提出修改和改进业务部门工作流程的方法并程序化。 数据建模的范围界定整个数据仓库项目的目标和阶段划分。 业务建模阶段其实是一次和业务人员梳理业务的过程在这个过程中不仅能帮助我们技术人员更好的 理解业务另一方面也能够发现业务流程中的一些不合理的环节加以改善和改进。 2领域概念建模画图想好怎么做 抽取关键业务概念并将之抽象化。 将业务概念分组按照业务主线聚合类似的分组概念。细化分组概念理清分组概念内的业务流程并抽象化。理清分组概念之间的关联形成完整的领域概念模型。
领域概念建模就是运用了实体建模法从纷繁的业务表象背后通过实体建模法抽象出实体事件说 明等抽象的实体从而找出业务表象后抽象实体间的相互的关联性保证了我们数据仓库数据按照数据 模型所能达到的一致性和关联性。 3逻辑建模表设计 业务概念实体化并考虑其具体的属性。 事件实体化也就是所谓的事实并考虑其属性内容。说明实体化也就是所谓的维度并考虑其属性内容。逻辑模型具体要求如下
总体来说就是建表前面已经画出了关系图这里只要将表里头有哪些字段考虑出来就可以如果是事 实表就考虑事实字段和业务主键如果是维度表就考虑维度属性SCD策略等等。在这里需要确定数据 粒度如果多个指标都用到一个字段则取粒度最小的指标。如果不确定指标的量度则取毫秒级作为 粒度。 4物理建模建表 针对特定物理化平台做出相应的技术调整。 针对模型的性能考虑对特定平台作出相应的调整。针对管理的需要结合特定的平台做出相应的调整。生成最后的执行脚本并完善。 物理模型具体要求如下
综合现实的大数据平台、采集工具、etl工具、数仓组件、性能要求、管理要求等多方面因素设计出具 体的项目代码完成数仓的搭建。 总结来说上面的模型设计流程大部分应用于DWD层也就是事实维度层。通过建模捋清逻辑把业 务落实到一张张表并梳理表于表之间的关系。
2、建模过程 假设现在在构建一张订单表 从多个维度进行统计组合形成多维度数据集来从多个角度观察业务过程的好坏 1选择业务过程 确认哪些业务处理流程是数据仓库应该覆盖的是维度方法的基础。因此建模的第一个步骤是描 述需要建模的业务流程。例如需要了解和分析一个零售店的销售情况那么与该零售店销售相关 的所有业务流程都是需要关注的。为了描述业务流程可以简单地使用纯文本将相关内容记录下 来或者使用“业务流程建模标注”BPMN方法也可以使用统一建模语言UML或其他类似 的方法。 业务过程就是需要那种业务场景下产生的订单表(划分到那个业务线和数据域) 业务过程就是用户下单的订单记录表
2选择数据域 1申明粒度 粒度就是确认一条记录代表的含义或者是细化到何种程度(一条记录代表一个订单还是多个订单 如拼团的时候团长的单) 在选择维度和事实前必须声明粒度因为每个候选维度或事实必须与定义的粒度保持一致。在一个 事实所对应的所有维度设计中强制实行粒度一致性是保证数据仓库应用性能和易用性的关键。 从给定的业务流程获取数据时原始粒度是最低级别的粒度。建议从原始粒度数据开始设计因为 原始记录能够满足无法预期的用户查询。汇总后的数据粒度对优化查询性能很重要但这样的粒度 往往不能满足对细节数据的查询需求。 不同的事实可以有不同的粒度但同一事实中不要混用多种不同的粒度。维度模型建立完成之后 还有可能因为获取了新的信息而回到这步修改粒度级别。 2确认维度 维度的粒度必须和第二步所声明的粒度一致。 维度表是事实表的基础也说明了事实表的数据是从哪里采集来的。 典型的维度都是名词如日期、商店、库存等。维度表存储了某一维度的所有相关数据例如日 期维度应该包括年、季度、月、周、日等数据。 3确认事实 这一步识别数字化的度量构成事实表的记录。它是和系统的业务用户密切相关的因为用户正是 通过对事实表的访问获取数据仓库存储的数据。大部分事实表的度量都是数字类型的可累加可 计算如成本、数量、金额等。 3、模型设计的思路 业务需求驱动数据驱动构造数据仓库有两种方式一是自上而下一是自下而上。 1自上而下 Bill Inmon先生推崇“自上而下”的方式即一个企业建立唯一的数据中心就像一个数据的仓库其中数据是经过整合、经过清洗、去掉脏数据的、标准的能够提供统一的视图。要建立这样的数据仓库并 不从它需要支持哪些应用入手而是要从整个企业的环境入手分析其中的概念应该有什么样的数 据达成整体概念。 2自下而上 Ralph Kimball先生推崇“自下而上”的方式他认为建设数据仓库应该按照实际的应用需求加载需要的数据不需要的数据不要加载到数据仓库中。这种方式建设周期较短客户能够很快看到结果。针对 客户的需求需求要什么就做什么
4、模型落地实现 按照命名规范创建表 开发生成维表和事实表的代码 进行代码逻辑测试验证数据加工逻辑的正确性 代码发布加入调度并配置相应的质量监控和报警机制
10. 简述维度建模的步骤如何确定这些维度的
维度建模主要有4个步骤选取业务过程、定义粒度、确定维度和确定事实。这4个步骤贯穿了维度建模 的整个过程和环节。 1、选取业务 过程业务过程即企业和组织的业务活动它们一般都有相应的源头业务系统支持。对于一个超市来说 其最基本的业务活动就是用户收银台付款对于一个保险公司来说最基本的业务活动是理赔和保单 等。当然在实际操作中业务活动有可能并不是那么简单直接此时听取用户的意见通常是这一环节最 为高效的方式。 需要注意的是这里谈到的业务过程并不是指业务部门或者职能。模型设计中应将注意力集中放在业 务过程而不是业务部门如果建立的维度模型是同部门捆绑在一起的就无法避免出现数据不一致的情 况如业务编码、含义等。因此确保数据一致性的最佳办法是从企业和公司全局与整体角度对于 某一个业务过程建立单一的、一致的维度模型。 2、定义粒度 定义粒度意味着对事实表行实际代表的内容和含义给出明确的说明。粒度传递了事实表度量值相联系的 细节所达到的程度的信息。其实质就是如何描述事实表的单个行。 典型的粒度定义包括 超市顾客小票的每一个子项 医院收费单的明细子项 个人银行账户的每一次存款或者取款行为 个人银行账户每个月的余额快照。 对于维度设计来说在事实表粒度上达成一致非常重要如果没有明确的粒度定义则不能进入后面的 环节。如果在后面的环节中发现粒度的定义不够或者是错误的那么也必须返回这一环节重新定义粒 度。 在定义粒度过程中应该最大限度地选择业务过程中最为原子性的粒度这样可以带来后续的最大灵活 度也可以满足业务用户的任何粒度的分析需求。 3、确认维度 定义了粒度之后相关业务过程的细节也就确定了对应的维度就很容易确定。正如前文所述维度是 对度量的上下文和环境的描述。通过维度业务过程度量与事实就会变得丰富和丰满起来。对于订单来 说常见的维度会包含商品、日期、买家、卖家、门店等而每一个维度还可以包含大量的描述信息比 如商品维度表会包含商品名称、标签价、商品品牌、商品类目、商品上线时间等。 4、确认事实 确定事实通过业务过程分析可能要分析什么来确定。定义粒度之后事实和度量一般也很容易确定比 如超市的订单活动相关的度量显然是销售数量和销售金额。
在实际维度事实设计中可能还会碰到度量拆分的问题比如超市开展单个小票满10减10元的活动如 果小票金额超过10元这10元的优惠额如何分配到每一个小票子项实际设计中可以和业务方具体讨论 并制订具体的拆分分配算法。
11. 简述维度建模和范式建模区别
1、范式建模 Inmon提出的集线器的自上而下EDW-DM的数据仓库架构。操作型或事务型系统的数据源通过ETL 抽取转换和加载到数据仓库的ODS层然后通过ODS的数据建设原子数据的数据仓库EDWEDW不是多 维格式的不方便上层应用做数据分析所以需要通过汇总建设成多维格式的数据集市层。 优势易于维护高度集成 劣势结构死板部署周期较长。范式建模应用在EDW层 一个符合第三范式的关系必须具有以下三个条件 每个属性的值唯一不具有多义性 每个非主属性必须完全依赖于整个主键而非主键的一部分 每个非主属性不能依赖于其他关系中的属性因为这样的话这种属性应该归到其他关系中去。 但是由于EDW的数据是原子粒度的数据量比较大完全规范的3范式在数据的交互的时候效率比较低 下所以通常会根据实际情况在事实表上做一些冗余减少过多的数据交互。
2、维度建模 Kimball提出的总线式的自下而上DM-DW的数据仓库架构。同样的操作型或事务型系统的数据 源通过ETL抽取转换和加载到数据仓库的ODS层然后通过ODS的数据利用维度建模方法建设一致 维度的数据集市。通过一致性维度可以将数据集市联系在一起由所有的数据集市组成数据仓库。 优势构建迅速最快的看到投资回报率敏捷灵活 劣势作为企业资源不太好维护结构复杂数据集市集成困难。 在维度建模的基础上又分为三种模型星型模型、雪花模型、星座模型。 具体选择哪种建模模型目前实际企业实际开发中不会选择绝对一种根据情况灵活组合甚至并存 一层维度和多层维度都保存。但是整体来看更倾向于维度更少的星型模型。尤其是Hadoop体 系减少Join就是减少Shuule性能差距很大。
12. 简述维度表和事实表的区别
简单的说维度表就是我们观察该事物的角度维度)事实表就是我们要关注的内容。 事实表表格里存储了能体现实际数据或详细数值一般由维度编码和事实数据组成。
表示对分析主题所属类型的描述。比如”昨天早上张三在京东花费200元购买了一个皮包”。那么以购买 为主题进行分析可从这段信息中提取三个维度时间维度(昨天早上)地点维度(京东), 商品维度(皮包)。通常来说维度表信息比较固定且数据量小。 维度表表格里存放了具有独立属性和层次结构的数据一般由维度编码和对应的维度说明(标签)组 成。 表示对分析主题的度量。比如上面那个例子中200元就是事实信息。事实表包含了与各维度表相关联 的外码并通过JOIN方式与维度表关联。事实表的度量通常是数值类型且记录数会不断增加表规模 迅速增长。 比如你要分析产品销售情况, 你可以选择按类别来进行分析,或按区域来分析. 这样的按…分析就构成一个维度。前面的示例就可以有两个维度类型和区域。下面是两个常见的维度表结构 产品维度表Prod_id, Product_Name, Category, Color, Size, Price 时间维度表TimeKey, Season, Year, Month, Date 而事实表是数据聚合后依据某个维度生成的结果表。它的结构示例如下 销售事实表Prod_id(引用产品维度表), TimeKey(引用时间维度表), SalesAmount(销售总量以货币计), Unit(销售量) 事实数据和维度数据的识别必须依据具体的主题问题而定。事实表用来存储事实的度量measure及 指向各个维的外键值。维表用来保存该维的元数据即维的描述信息包括维的层次及成员类别等
13. 简述什么是ER模型
在信息系统中将事务抽象为“实体”Entity、“属性”Property、“关系”Relationship来表示数据关联和事物描述这种对数据的抽象建模通常被称为ER实体关系模型。 实体通常为参与到过程中的主体客观存在的比如商品、仓库、货位、汽车此实体非数据库表的 实体表。 属性对主体的描述、修饰即为属性比如商品的属性有商品名称、颜色、尺寸、重量、产地等。 关系现实的物理事件是依附于实体的比如商品入库事件依附实体商品、货位就会有“库存”的属 性产生用户购买商品依附实体用户、商品就会有“购买数量”、“金额”的属性产品。 实体之间建立关系时存在对照关系 1:1即1对1的关系 1:n即1对多的关系n:m即多对多的关系 在日常建模中“实体”用矩形表示“关系”用菱形“属性”用椭圆形。ER实体关系模型也称为E-R关系 图。
14. 简述OLAP、OLTP解释
操作型处理叫联机事务处理 OLTPOn-Line Transaction Processing 也可以称面向交易的处理系统它是针对具体业务在数据库联机的日常操作通常对少数记录进行查 询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的 数据库系统作为数据管理的主要手段主要用于操作型处理。 分析型处理叫联机分析处理 OLAPOn-Line Analytical Processing 一般针对某些主题的历史数据进行分析支持管理决策。 OLTP与OLAP的异同如下表所示
操作型处理 分析型处理 细节的 综合的或提炼的 实体-关系ER模型 星型或雪花模型 存取瞬间数据 存储历史数据不包含最近的数据 可更新的 只读只追加 一次操作一个单元 一次操作一个集合 性能要求高响应时间短 性能要求宽松 面向事务 面向分析 一次操作数据量小 一次操作数据量大 支持日常操作 支持决策需求 数据量小 数据量大 客户订单、库存水平和银行账户等 客户收益分析、市场细分等
15. 简述维度设计中有整合和拆分有哪些方法并详细说明
1、垂直整合 在不同来源表中可能会包含这相同的数据集。只是存储的信息不同。如电商的会员相关的表包含了会员 基础信息表、会员扩展表、会员等级信息表等依照维度设计方法尽量整合到会员维度模型中丰富 其维度属性。
2、水平整合 不同来源表包含不同的数据集不同子集之间无交叉也可以存在部分交叉。如上会员体系中还可能存 在各种类型会员表如淘宝生态中 淘宝会员、国际站会员、支付宝会员等水平类型的表。这种情况的整合过程中首先需要考虑各个会员体系是否有交叉如果存在交叉则需要去重如果不存在交叉则 需要考虑不同子集的自然键是否存在冲突如果不冲突则可以考虑将各子集的自然键作为整合后的表
的自然键另一种方式是设置超自然键将来源表各子集的自然键加工成个字段作为超自然键。
3、水平拆分 维度通常可以按照类别和类型细分。如某宝系商品表根据业务线或行业等可以对商品进行细分如淘 宝的商品、天猫的商品、 飞猪旅行的商品、淘宝海外的商品、天猫国际的商品等。不同分类的商品其维度属性可能相同也可能不同。航旅商品想比较于普通商品都有都有商品价格、标题、类型、上架时 间、类目等维度属性。但是航旅的商品除了有这些公共属性外还有酒店、点、门票、旅行等自己独特 的维度属性。 针对此问题一般有两种解决方案 将维度的不同分类实例化为不同的维度同时在主维度表中保存公共属性 维护单一维度包含所有的可能的属性。 具体选择哪种方案在数据模型设计过程中需要考虑的因素有很多基本不可能满足各个特性指标的最 优化。在设计过程中需要重点考虑以下几个原则。 扩展性当源系统、业务逻辑变化时能通过较少的成本快速扩展模型保持核心模型的相对稳定 性。软件工程中的高内聚、低稠合的思想是重要的指导方针。 效能在性能和成本方面取得平衡。通过牺牲一定的存储成本达到性能和逻辑的优化。 易用性模型可理解性高、访问复杂度低。用户能够方便地从模型中找到对应的数据表并能够方 便地查询和分析。 根据数据模型的设计思想我们可以如下考虑和选择 第一个是维度不同分类的属性差异情况。当维度属性随类型变化较大时将所有可能的属性建立在 一个表中时不切合实际的也没有必要这样做。此时建议采用方案一定义一个主维度用于存放公 共属性同时定义多个子维度其中除了包含公共属性外还包含各自的特殊属性。比如在阿里巴 巴数据仓库维度体系中依据此方法构建了商品维度、航旅商品维度等。公共属性 般比较稳 定通过核心的商品维度保证了核心维度的稳定性通过扩展子维度的方式保证了模型的扩展 性。 第二个是业务的关联程度。两个相关性较低的业务稠合在起弊大于利对模型的稳定性和易用性 影响较大。比如在数据仓库维度体系中对某宝商品和 *** 商品构建两个维度。业务各自发展在数据仓库层面属于不同数据集市一 般不会相互调用业务分析人员 般只针对本数据集市进行统计分析。如果设计成一个维度由于不同业务各自发展 此维度需要变更淘宝业务变更亦然 稳定性很差在易用性方面会给数据使用方造成困扰。
4、垂直拆分 维度是维度建模的基础和灵魂维度属性的丰富程度直接决定了数据仓库的能力。在进行维度设计时 依据维度设计的原则尽可能丰富维度属性同时进行反规范化处理。对于具体实现时可能存在的问题 如下 一是在“水平拆分”中提到的由于维度分类的不同而存在特殊的维度属性可以通过水平拆分的方 式解决此问题。 二是某些维度属性的来源表产生时间较早而某些维度属性的来表产出时间较晚或者某些维度属 性的热度高、使用频繁而某些维度属性的热度低、较少使用 或或者某些维度属性经常变化而某些维度属性比较稳定。在“水平拆分”中提到的模型设计的三个原则同样适合解决此问题。 出于扩展性、产出时间、易用性等方面的考虑设计主从维度。主维度表存放稳定、产出时间早、认读 高的属性从表存放变化较快、产出时间较晚、热度低的属性。例如在商品维表的设计中可以设计商 品主维度和商品的扩展维度。主商品表时间可以每天1点产生而扩展维度每天3点才能产生。由于商品 扩展维度有冗余的库存等变化较快的数据对于主维度进行缓慢变化的处理较为重要。通过存储的冗余 和计算成本的增加实现了商品主模型的稳定和产出时间的提前对于整个数据仓库的稳定和下游应用 的产出都有较大意义。
16. 简述事实表设计分几种每一种都是如何在业务中使用
事实表作为数据仓库维度建模的核心紧紧围绕着业务过程来设计通过获取描述业务过程的度量来表 达业务过程包含了引用的维度 和与业务过程有关的度量。 1、事实表概述 事实表有三种类型 : 事务事实表、周期快照事实表和累积快照事实表。 1事务事实表 也称原子事实表描述业务过程跟踪控件或时间上某点的度量事件保存的是最原子的数据。 类似于mysql binlog日志每一次相关的 change 都记录下来生成一行新的数据。 2周期快照事实表 以一个周期为时间间隔来记录事实一般周期可以是每天、每周、每月、每年等。 只看某个业务过程比如订单收货数据按订单收货时间来切分周期可以为每天、每月等。 3累积快照事实表 用来描述过程开始和结束之间的关键步骤事件覆盖过程的整个生命周期通常具有多个日期字段来记 录关键时间点当过程随着生命周期不断变化时记录也会随着过程的变化而被修改。 要看整个生命周期的多个业务过程比如创建订单 → 买家付款 → 卖家发货 → 买家确认收货。粒度是一个订单一行数据创建订单时间付款时间发货时间收货时间分别作为一个字段便于计算 不同业务过程的时间间隔。
2、事实表设计原则 原则 1尽可能包含所有与业务过程相关的事实
分析哪些事实与业务过程相关是设计过程中非常重要的关注点 在事实表中尽量包含所有与业务过程相关的事实即使存在冗余由于事实通常是数字型存储 开销不会太大 原则 2只选择与业务过程相关的事实 如订单的下单这个业务过程事实表中不应该存在支付金额这个表示支付业务过程的事实 原则 3分解不可加性事实为可加的组件 如订单的优惠率应分解为订单原价金额与订单优惠金额两个事实存储在事实表中 原则 4在选择维度和事实之前必须先声明粒度 粒度用于确定事实表中一行所表示业务的细节层次决定了维度模型的扩展性 每个维度和事实必须与所定义的粒度保持一致 设计事实表时粒度定义越细越好一般从最低级别的原子粒度开始 因为原子粒度提供了最大限度的灵活性可以支持无法预期的各种细节层次的用户需求 原则 5在同一个事实表中不能有多种不同粒度的事实 疑问怎么判断不同事实的粒度是否相同 粒度为票一级实际业务中一个订单可以同时支付多张票 票支付金额和票折扣金额两个事实的粒度为 “票级”与定义的粒度一致 订单支付金额和订单票数两个事实的粒度为 “订单级”属于上一层订单级数据与 “票级” 事实表的粒度不一致且不能进行汇总 如果以订单金额和订单票数这两个维度汇总总金额和总票数会造成大量的重复计算 原则 6事实的单位要保持一致 如订单金额、订单优惠金额、订单运费这 3 个事实应该采用统一的计量单位统一为元或者分 以方便使用 原则 7对事实的 null 值要处理 原因在数据库中null 值对常用数字型字段的 SQL 过滤条件都不生效如大于、小于、等于、大于或等于、小于或等于 处理用 0 代替 null 原则 8使用退化维度提高事实表的易用性 事实表中存储各种类型的常用维度信息较少下游用户使用时关联多个表的操作 通过退化维度可以实现对事实表的过滤查询、控制聚合层次、排序数据、定义主从关系等 易用性对事实表更较少关联操作、过滤查询、控制聚合层次、排序数据、定义主从关系等 在 Kimball 的维度建模中通常按照星形模型的方式设计通过事实表的外键关联专门的维表这种方式来获取维度谨慎使用退化维表这与大数据领域的事实表设计不一样。 思路通过增加冗余存储减少计算开销提高使用效率
3、事实表设计方法 上上一题也有说过这里大同小异也可以看上上一题的 Kimball 的维度模型设计 4 步法选择业务过程、声明粒度、确定维度、确定事实。 当前的互联网大数据环境维度模型的设计是基于 Kimball 的四步维度建模方法进行了更进一步的改进。 第一步选择业务过程及确定事实表类型 思路详细分析需求对业务的整个生命周期进行分析明确关键的业务步骤从而选择与需求有关的 业务过程。 以实例说明如何选择业务过程如何确定事实表类型 例淘宝的一个交易订单 1分析业务的生命周期如上图业务过程通常使用行为动词表示业务执行的活动 2明确关键的业务步骤该订单流转的业务过程有 4 个创建订单 → 买家付款 → 卖家发货 → 买家确认收货 3根据业务需求选择与维度建模有关的业务过程 如是选择 “买家付款” 这个业务过程还是选择 “创建订单” 和 “买家付款” 这两个业务过程具体根据业务情况来定。 4根据所选的业务过程确定事实表类型 如选择 “买家付款” 这个业务过程则事实表类型应为只包含买家付款这一个业务过程的 “单事务事实表” 如选择了所有 4 个业务过程并且需要分享各业务过程的时间间隔则事实表类型应为包含了所有 4 个业务过程的 “累积快照事实表”。 第二步声明粒度 粒度的作用 粒度的声明意味着精确定义事实表的每一行所表示的业务含义 明确的粒度能够确保对实表中行的意思的理解不会产生混淆保证所有的事实按照同样的细节层次 记录。 粒度的选择尽量选择最细级别的原子粒度以确保事实表的应用具有最大的灵活性。 灵活性支持无法预期的各种细节层次的用户需求 对于订单级别粒度可以定义为最细的订单级别。如父子订单事实表的粒度可以定 “子订单级别” 第三步确定维度 完成了粒度声明就意味着确定了主键对应的维度组合以及相关的维度字段也可以确定了。 选择维度的原则应该选择能够描述清楚业务过程所处的环境的维度信息 如淘宝订单 “付款事务事实表” 中粒度为 “子订单”相关的维度有买家、卖家、商品、收货人信息、业务类型、订单时间等。 第四步确定事实 确定原则选择与业务过程有关的所有事实且事实的粒度要与所声明的事实表的粒度一致 思路可以通过回答 “过程的度量是什么” 来确定 注意将不可加性事实分解为可加的组件分解的原则可以通过分解后的可加的属性值计算得到 不可加性事实
17. 简述单事务事实表、多事务事实表区别与作用
事务事实表用于跟踪定义业务过程的个体行为设计案例场景如下为交易事务设计事实表 1业务分析交易事务包括下单、支付、发货、完结四个业务过程。 2确定粒度同一个订单中可以包含多个在商品每个商品对应一个子订单。在上述四个业务过程中 下单、支付、完结选择子订单作为粒度而发货业务过程包含物流信息以父订单为粒度。 3确定维度卖家、买家、商品、商品类目、发货地区、收货地区、父订单一级杂项维度。 4确定事实每个业务过程有自己的事实如下单过程的下单金额、下单数量支付过程的支付金 额、积分金额等。 5冗余维度为了提升效率把常用的维度荣誉到事实表
1、单事务事实表 一个业务过程一张事实表方便对每个业务做独立分析 2、多事务事实表 将不同业务过程放在同一个事实表中又可以分为不同业务过程使用不同事实字段和不同业务过程使用 相同事实字段两种。 1不同业务过程使用不同事实字段一般用于业务相似粒度相同但是业务过程的度量差异大的场 景。有两个典型的问题 在数据中遇到不是当前业务过程的度量采用零值处理 表中存在多个业务如何标记给每一个数据加一个属性标识是否当日业务 2不同业务过程使用相同事实字段用一个标签字段标识是那种业务如商品的收藏/删除。一般用 于业务相似粒度相同同时业务过程的度量差异不大的场景。但是有一个问题要注意因为用同一个字 段标识不同业务的度量所以数据一个周期内会有多条记录。 3、单事务事实表与多事务事实表对比
单事务事实表 多事务事实表 粒度 相互不相关 相同粒度 维度 相互不相关 一致 事实 只取当前业务事实 同时保留多个过程事实非当前业务的事实用零值处理 冗余维度 多个业务过程需要冗余多次 多个业务过程只冗余一次 计算成本 较多每个业务单独计算一次 多个业务融合在一张表只需计算一次
另外如果一个业务过程的事实量巨大不宜使用多事务事实表会造成大量零值
18. 简述说下一致性维度、一致性事实、总线矩阵
在Kimball的维度建模的数据仓库中关于多维体系结构MD有三个关键性概念总线架构Bus Architecture一致性维度Conformed Dimension和一致性事实Conformed Fact。
1、总线架构 在多维体系结构MD也就是总线架构的数据仓库架构中主导思想是分步建立数据仓库由数 据集市组合成企业的数据仓库。但是在建立第一个数据集市前架构师首先要做的就是设计出在整个 企业内具有统一解释的标准化的维度和事实即一致性维度和一致性事实。而开发团队必须严格的按照 这个体系结构来进行数据集市的迭代开发。 一致性维度就好比企业范围内的一组总线不同数据集市的事实的就好比插在这组总线上的元件。这也 是称之为总线架构的原因。 实际设计过程中我们通常把总线架构列表成矩阵的形式其中列为一致性维度行为不同的业务处理 过程即事实在交叉点上打上标记表示该业务处理过程与该维度相关。这个矩阵也称为总线矩阵 Bus Matrix。 总线架构和一致性维度、一致性事实共同组成了Kimball的多维体系结构的基础也建立了一套可以逐步 建立数据仓库的方法论。由于总线架构是多维体系结构的核心所以我们有时就把多维体系结构直接称 为总线架构。
2、价值链的意义 每家机构都有一个关键业务过程组成的潜在价值链这个价值链确定机构主体活动的自然逻辑流程。数 据仓库建设就是围绕着价值链建立一致化的维度和事实。
3、数据总矩阵 矩阵的每一行对应都对应机构中的一个业务过程每一列都和一个业务维度相对应用叉号填充显示的 是和每一行相关的列。业务过程应该先从单个数据源系统开始然后再进行多数据源的合并。 企业数据仓库总线矩阵是DW/BI系统的一个总体数据架构提供了一种可用于分解企业数据仓库规划任 务的合理方法开发团队可以独立的异步的完成矩阵的各个业务过程迭代地去建立一个集成的企业 数据仓库。
4、一致性维度 在多维体系结构中没有物理上的数据仓库由物理上的数据集市组合成逻辑上的数据仓库。而且数据 集市的建立是可以逐步完成的最终组合在一起成为一个数据仓库。如果分步建立数据集市的过程出 现了问题数据集市就会变成孤立的集市不能组合成数据仓库而一致性维度的提出正式为了解决这 个问题。 一致性维度的范围是总线架构中的维度即可能会在多个数据集市中都存在的维度这个范围的选取需 要架构师来决定。一致性维度的内容和普通维度并没有本质上区别都是经过数据清洗和整合后的结 果。一致性维度建立的地点是多维体系结构的后台Back Room即数据准备区。 在多维体系结构的数据仓库项目组内需要有专门的维度设计师他的职责就是建立维度和维护维度的一 致性。在后台建立好的维度同步复制到各个数据集市。这样所有数据集市的这部分维度都是完全相同 的。建立新的数据集市时需要在后台进行一致性维度处理根据情况来决定是否新增和修改一致性维 度然后同步复制到各个数据集市。这是不同数据集市维度保持一致的要点。 在同一个集市内一致性维度的意思是两个维度如果有关系要么就是完全一样的要么就是一个维度 在数学意义上是另一个维度的子集。 例如如果建立月维度话月维度的各种描述必须与日期维度中的完全一致最常用的做法就是在日期 维度上建立视图生成月维度。这样月维度就可以是日期维度的子集在后续钻取等操作时可以保持一 致。如果维度表中的数据量较大出于效率的考虑应该建立物化视图或者实际的物理表。这样维度 保持一致后事实就可以保存在各个数据集市中。虽然在物理上是独立的但在逻辑上由一致性维度使 所有的数据集市是联系在一起随时可以进行交叉探察等操作也就组成了数据仓库。
5、一致性事实 在建立多个数据集市时完成一致性维度的工作就已经完成了一致性的80%90%的工作量。余下的工 作就是建立一致性事实。一致性事实和一致性维度有些不同一致性维度是由专人维护在后台Back Room发生修改时同步复制到每个数据集市而事实表一般不会在多个数据集市间复制。需要查询 多个数据集市中的事实时一般通过交叉探查drill across来实现。
为了能在多个数据集市间进行交叉探查一致性事实主要需要保证两点第一个是KPI的定义及计算方 法要一致第二个是事实的单位要一致性。如果业务要求或事实上就不能保持一致的话建议不同单位 的事实分开建立字段保存。 这样一致性维度将多个数据集市结合在一起一致性事实保证不同数据集市间的事实数据可以交叉探 查一个分布式的数据仓库就建成了。
6、小结 总线矩阵业务过程和维度的交点。 一致性维度同一集市的维度表内容相同或包含。一致性维度要么是统一的要么是维度表的一个子 集。 一致性事实不同集市的同一事实需保证口径一致单位统一。指每个度量在整个数据仓库中都是唯 一的统计口径为了避免歧义一个度量只有唯一的业务术语
19. 简述从ODS层到DW层的ETL做了哪些工作
这里我们将数据模型分为三层数据运营层(原始数据层) ODS 、数据仓库层DW和数据应用层APP。 ODS层存放的是接入的原始数据DW层是存放我们要重点设计的数据仓库中间层数据APP是面向业务 定制的应用数据。 1、数据运营层ODSOperational Data Store “面向主题的”数据运营层也叫ODS层是最接近数据源中数据的一层数据源中的数据经过抽取、 洗净、传输也就说传说中的 ETL 之后装入本层。本层的数据总体上大多是按照源头业务系统的分类方式而分类的。 一般来讲为了考虑后续可能需要追溯数据问题因此对于这一层就不建议做过多的数据清洗工作原 封不动地接入原始数据即可至于数据的去噪、去重、异常值处理等过程可以放在后面的DWD层来做。 2、数据仓库层DWData Warehouse 数据仓库层是我们在做数据仓库时要核心设计的一层在这里从 ODS 层中获得的数据按照主题建立各种数据模型。DW层又细分为 DWDData Warehouse Detail层、DWMData WareHouse Middle层和DWSData WareHouse Servce层。 1数据明细层DWDData Warehouse Detail 该层一般保持和ODS层一样的数据粒度并且提供一定的数据质量保证。同时为了提高数据明细层的 易用性该层会采用一些维度退化手法将维度退化至事实表中减少事实表和维表的关联。 另外在该层也会做一部分的数据聚合将相同主题的数据汇集到一张表中提高数据的可用性。 2数据中间层DWMData WareHouse Middle 该层会在DWD层的数据基础上对数据做轻度的聚合操作生成一系列的中间表提升公共指标的复用 性减少重复加工。 直观来讲就是对通用的核心维度进行聚合操作算出相应的统计指标。 3数据服务层DWSData WareHouse Servce
又称数据集市或宽表。按照业务划分如流量、订单、用户等生成字段比较多的宽表用于提供后续 的业务查询OLAP分析数据分发等。 一般来讲该层的数据表会相对比较少一张表会涵盖比较多的业务内容由于其字段较多因此一般 也会称该层的表为宽表。 在实际计算中如果直接从DWD或者ODS计算出宽表的统计指标会存在计算量太大并且维度太少的问 题因此一般的做法是在DWM层先计算出多个小的中间表然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定也可以去掉DWM这一层只留DWS层将所有的数据在放在DWS亦可。 3、数据应用层APPApplication 在这里主要是提供给数据产品和数据分析使用的数据一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据一般就放在这里。
20. 简述数据仓库与传统数据库的区别
数据库传统的关系型数据库的主要应用主要是基本的、日常的事务处理例如银行交易。 数据仓库数据仓库系统的主要应用主要是OLAPOn-Line Analytical Processing支持复杂的分析操作侧重决策支持并且提供直观易懂的查询结果。 业务数据库中的数据结构是为了完成交易而设计的不是为了而查询和分析的便利设计的。 业务数据库大多是读写优化的即又要读查看商品信息也要写产生订单完成支付。因 此对于大量数据的读查询指标一般是复杂的只读类型查询是支持不足的。 而怎么解决这个问题此时我们就需要建立一个数据仓库了公司也算开始进入信息化阶段了。数据仓 库的作用在于 数据结构为了分析和查询的便利 只读优化的数据库即不需要它写入速度多么快只要做大量数据的复杂查询的速度足够快就行 了。 那么在这里前一种业务数据库读写都优化的是业务性数据库后一种是分析性数据库即数据仓 库。 数据库与数据仓库的区别实际讲的是OLTP与OLAP的区别 操作型处理叫联机事务处理OLTPOn-Line Transaction Processing也可以称面向交易的处理系统它是针对具体业务在数据库联机的日常操作通常对少数记录进行查询、修改。用户较为关 心操作的响应时间、数据的安全性、完整性和并发的支持用户数等问题。传统的数据库系统作为数 据管理的主要手段主要用于操作型处理。 分析型处理叫联机分析处理OLAPOn-Line Analytical Processing一般针对某些主题历史数据进行分析支持管理决策。
OLTP与OLAP的异同如下表所示
操作型处理 分析型处理 细节的 综合的或提炼的 实体-关系ER模型 星型或雪花模型 存取瞬间数据 存储历史数据不包含最近的数据 可更新的 只读只追加 一次操作一个单元 一次操作一个集合 性能要求高响应时间短 性能要求宽松 面向事务 面向分析 一次操作数据量小 一次操作数据量大 支持日常操作 支持决策需求 数据量小 数据量大 客户订单、库存水平和银行账户等 客户收益分析、市场细分等
21. 简述数据质量是怎么保证的有哪些方法保证
1从技术层面来说需要构建一套高效、健壮的ETL程序以此保证数据清洗、转换后数据的正确性和 一致性。 2从流程上来说整个ETL是多个任务按步骤顺序执行的一个过程后置任务依赖前置任务定期执 行整个流程需要自动化并且哪个环节出现了问题给予预警通知相关维护人员及时处理。 3从管理层面上来说数据仓库是构建在公司各个业务系统之上它是一面镜子很多时候它能反映 出业务系统的问题所以需要管理层的支持和约束比如通过第一条说的事后自动检验机制反映出业务 系统的维护错误需要相应的业务系统维护人员及时处理。
数据治理流程如下 基本流程如下发现数据质量问题 定义数据质量规则 质量控制 质量评估 质量优化。
扩展内容 这里主要是阿里对数仓的一些数据质量保证原则 1、数据质量保障原则 阿里对数据仓库主要从四个方面评估数据质量 1完整性 确保数据不存在缺失 2准确性 确保数据不存在异常或错误 3一致性 体现在从业务仓库加工到数据仓库再到各个消费节点必须是同一种类型长度也需要保持一致。 4及时性 确保数据能及时产出越来越多的应用希望数据更快产出。
2、数据质量方法概述 阿里的业务复杂种类繁多的产品每天产生数以亿计的数据每天的数据量在PB级以上而数据消费端 的应用又层出不穷各类数据产品如雨后春笋般出现。为了满足这些数据应用数据仓库的规模也不断 膨胀同时数据质量的保障也越来越复杂。 基于上述背景提出一套数据质量建设方法 1消费场景知晓 主要是通过数据资产和基于元数据的应用链路分析解决消费场景知晓的问题。 2数据生成加工各个环节卡点效验 在各个数据生成环节格局不同资产等级做出相应的处理。 3风险点监控在线数据 主要是针对在线系统日常运行产出的数据进行业务规则的效验以保证数据质量其主要使用实时 业务检测平台BCPBiz-Check-Platform。 离线数据主要是针对离线系统日常运行产出的数据进行数据质量监控和实效性监控其中数据质量监控主要 是使用DQC实效性监控主要是使用摩萨德。 4质量衡量 对质量的衡量既有事前的衡量如DQC覆盖率又有事后的衡量主要用于跟进质量问题确定质量问 题原因、责任人、解决情况等并用于数据质量的复盘避免类似事件再次发生。根据质量问题对不同 等级资产的影响程度确定其是属于低影响的事件还是具有较大影响的故障。质量分则是综合事前和事 后的衡量数据进行打分。 5质量配套工具 针对数据质量的各个方面都需要相关的工具进行保证提高效率。 3、消费场景知晓 在数据快速增长数据类产品和日常决策支持等系统层出不穷数据仓库应接不暇数据工程师很难确 定几百PB的数据到底是否都是重要的是否都要进行保障是否有一些数据已经过期了是否所有需要 精确的进行保障。 基于上述疑问阿里内部提出数据资产等级解决消费场景知晓问题。 1数据等级定义毁灭性质 即数据一旦出错将会引起重大资产损失导致收益大损。记为A1Asset 全局性质 即数据直接或者间接用于集团级业务和效果的评估、重要平台的运维、对外数据产品的透露、影响 用户在阿里系网站的行为。记为A2 局部性质 即数据直接或间接用于内部一般数据产品或者运营/产品报告如果出现问题会给事业部或业务线 造成影响或者工作效率降低。记为A3 一般性质 即数据主要用于小二的日常数据分析出现问题不会带来太大的影响。记为A4 未知性质 不能明确说出数据的应用场景则标注为未知。记为A5 2数据资产等级落地 先给不同数据产品或应用划分数据资产等级再依托元数据的上下游血缘可以将整个加工消费链打上 该数据资产等级。 总结解决了消费场景知晓的问题就知道了数据的重要等级针对不同的等级也将采取不同的保障 措施。 4、数据加工过程卡点校验 1在线系统卡点效验 主要是指在线系统 的数据生成过程中进行的卡点效验。要向数据保障数据准确性主要使用工具。 发布平台 在业务进行重大变更时订阅这个发布过程然后给到离线开发人员。当然不会频繁通知离 线开发人员会根据数据资产等级通知相应人员 数据库表的变化感知 数据库扩容对表的DDL变化都需要主动通知离线开发人员。有了开发工具开发人员更重要 须知哪些是重要的核心数据资产须知哪些只是内部分析数据使用
2离线系统卡点效验 首先代码提交时的卡点效验 由于开发人员素质不同代码能力也有差异所以需要工具代码扫描SQL SCAN对每次提交代码进行扫描将风险点提出来。 其次是任务发布上线时卡点效验 发布上线前测试代码评审和回归测试 回归测试指修改了旧代码后重新进行测试以确认修改没引入新的错误。冒烟测试指开发人员修复一个bug测试人员专门针对这个问题测试。 发布上线后测试Dry-Run测试或真实环境运行测试。 Dry-Run不执行代码仅运行执行计划避免由于上线下环境不一致导致语法错误。 最后是节点变更或数据重刷前的变更通知 一般指使用通知中心将变更原因、变更逻辑、变更测试报告和变更时间等自动通知下游下游对此 次变更没有异议后再按约定时间执行发布变更将变更对下游影响降至最低。
5、风险点监控 主要是针对数据在日常运行过程中容易出现的风险进行监控并设置报警机制 1在线数据风险点监控 采用实时业务检测平台BCP保障重要数据资产的质量。BCP制定效验规则用于验证数据的准确性 2离线数据风险监控 数据准确性 使用DQC来监控数据数据及时性 需要进行一系列的报警和优先级设置使得重要的任务优先且正确产出。使用的工具有摩萨德。
6、质量衡量 评估各种数据仓库质量保障方案有以下指标 1数据质量起夜率及夜晚处理数据问题 2数据质量事件 3数据质量故障体系指的是严重的数据质量事件处理方案 故障定义
故障等级故障处理故障REview
22. 简述怎么衡量数仓的数据质量有哪些指标
1数据的准确性 数据准确性Accuracy是指数据采集值或者观测值和真实值之间的接近程度也叫做误差值误差越 大准确度越低。 指数据中记录的信息和数据是否准确数据记录的信息是否存在异常或错误。准确性关注的是数据记录 中存在的错误如字符型数据的乱码现象就存在着准确性的问题还有就是异常的数值异常大或者异 常小的数值、不符合有效性要求的数值等。
2数据的精确性 数据的精确性Precision是指对同一对象的观测数据在重复测量时所得到不同数据间的接近程度。精 确性也可以叫精准性。精确性与我们数据采集的精度有关系。精度高要求数据采集的粒度越细误 差的容忍程度越低。 比如测量人的身高我们可以精确到厘米多次测量差异只会在厘米级别测量北京到上海的距离我 们精确到公里多次测量结果间的差异会 在公里级别:采用游标卡尺测量一个零件的厚度可以精确到1/50毫米多次测量的结果间的误差也只会 在1/50毫米间。采用的测量方法和手段直接影响着数据的精确性。
3数据的真实性 数据的真实性也叫数据的正确性(Rightness)。数据的正确性取决于数据采集过程的可控程度可控程 度高可追溯情况好数据的真实性容易得到保障而可控程度低或者无法追溯数据造假后无法追 溯则真实性难以保证。为了提高数据的真实性采用无人进行过程干涉的智能终端直接采集数据能 够更好地保证所采集数据的真实性减少人为干预减少数据造假从而让数据更加正确地反应客观事物。
4数据的及时性 数据的及时性In-time就是指数据能否在需要的时候得到保证。 比如月初会对上个月的经营和管理数据进行统计汇总这些数据能否及时处理完成财务能否在月度关 账后及时核算。数据的及时性是我们数据分析和挖掘及时性的保障。如果公司的财务核算复杂核算速 度缓慢上个月的数据在月中才能统计汇总完成等需要调整财务策略的时候已经到了月底了一个 月已经快过完了。特别是公司做大了之后业务覆盖多个市场多个国家数据不能及时汇总会影响 到高层决策的及时程度数据的及时性与企业数据处理的速度和效率有直接的关系为了提高数据的及 时性越来越多的公司采用管理信息系统并在管理信息系统中附加各种自动数据外理功能能够在数 据上传系统之后自动完成绝大部分报表从而保证数据外理的效率。计算机自动外理中间层数据是提高 企业数据处理效率的有效手段。 除了保证数据采集的及时性和数据外理的效率问题外还需要从制度和流程上保证数据传输的及时性 数据报表完成了要及时或者在要求的时间范围内发送到指定的部门或者上传到指定的存储空间。
5数据的即时性 指数据采集时间节点和数据传输的时间节点一个数据在数据源头采集后立即存储并立即加工呈现 就是即时数据而经过一段时间之后再传输到信息系统中则数据即时性就稍差。 比如微博的数据采集当用户发布了微博数据立即能够被抓取和加工会生成即时微博数据报告并 随着时间推移数据不断变化我们可以称作是即时采集和处理的。一个生产设备的仪表即时反应着设 备的温度、电压、电流、气压等数据这些数据生成数据流随时监控设备的运行状况这个数据可以 看作是即时数据。而当设备的即时运行数据存储下来用来分析设备运行状况与设备寿命的关系这些 数据就成为历史数据。
6数据的完整性 数据的完整性是从数据采集到的程度来衡量的是应采集和实际采集到数据之间的比例。 比如一条信息采集12个数据点如我们采集员工信息数据的时候要求填写姓名出生日期性别民 族、籍贯身高、血型、婚姻状况最高学历最高学历专业、最高学历毕业院校、最高学历毕业时间 等12项信息而某一员工仅仅填写了部分信息如只填写了其中的5项则该员工所填写数据的完整性 只有一半。 一个公司数据的完整性体现着这个公司对数据的重视程度。要求采集数据而实际上并未完整采集只采 集了一部分这就是不完整的往往是公司对数据采集质量要求不到位导致的。公司要求每个人都填写 完整的个人信息表而有部分员工拒绝填写公司2000员工只有1200人填写了完整的个人信息表则 这个数据集就是不完整的。 另外对干动态数据还要从时间轴上去衡量数据采集的完整性。比如我们要求每小时采集一次数 据每天会形成24个数据点记录为24条数据但是员工渎职只记录了20次那么这个数据集也是不完整的。
7数据的全面性 数据的全面性和完整性不同完整性衡量的是应采集和实际采集的差异。而全面性指的是数据采集点的 遗漏情况。 比如说我们要采集员工行为数据我们只采集了员工上班打卡和下班打卡的数据上班时间的员工行 为数据并未采集或者没有找到合适的方法来采集。那么这个数据集就是不全面的。 比如描述一个产品的包装仅仅描述了产品包装的正面和背面没有记录产品包装的侧面则就是不全 面的。我们记录一个客户的交易数据我们只采集了客户订单中的产品、订单中产品的价格和数量而 没有采集客户送货地址采购时间这个数据采集就是不全面的。 比如腾讯OO和微信的用户数据记录了客户交流沟通的数据阿里和京东的用户数据记录了用户的购买 交易数据百度地图记录了用户出行的数据大众点评和美团记录了客户餐饮娱乐的数据。对于全面描 述一个人的生活的衣食住行各方面这些公司的数据都是不全面的而如果把他们的数据整合起来则 会形成更加全面的数据。所以说数据的全面性是一个相对的概念。过度追求数据的全面性是不现实的。
8数据的关联性 数据的关联性是指各个数据集之间的关联关系。 比如员工工资数据和工绩效考核数据是通过员工这个资源关联在一起来的而且绩效数据直接关系到工 资的多少。采购订单数据与生产订单数据之间通过物料的追溯机制进行关联而生产订单又是由员工完 成的即通过员工作业数据与员工信息数据关联起来
23. 简述什么是增量表、全量表和拉链表
在数据仓库中全量表、增量表和拉链表是常见的数据存储方式。它们各自具有不同的特点和应用场景下面将详细介绍这些数据存储方式的概念和优缺点。
一、全量表
全量表是指将数据源中的数据完全加载到数据仓库中以便进行分析和查询。全量表的特点是数据完整、详细任何查询都可以在全量表上进行。但是全量表需要占用较大的存储空间数据加载和更新也需要较长的时间。
全量表的应用场景主要是数据仓库的初始建设阶段或者是对数据源数据变化不频繁的情况。全量表适用于一次性查询和批量处理例如数据分析、报表生成等。
二、增量表
增量表是指只将数据源中发生变化的数据加载到数据仓库中以减少数据仓库的存储空间和数据加载时间。增量表的特点是数据更新快速、存储空间较小适用于数据源数据变化频繁的情况。但是增量表无法支持一些复杂的查询和数据分析操作。
增量表的应用场景主要是数据源数据变化频繁的情况例如电商、金融等行业的交易数据。增量表适用于实时查询和实时数据分析可以为业务决策提供快速支持。
三、拉链表
拉链表是指将数据源中的历史数据和当前数据分别存储在不同的表中并通过链接字段将它们关联起来。拉链表的特点是可以在不删除历史数据的情况下对当前数据进行更新和插入操作。拉链表适用于需要保留历史数据的情况例如订单管理、商品管理等。
拉链表的应用场景主要是需要保留历史数据的情况例如订单管理、商品管理等。拉链表适用于需要分析历史数据和当前数据的场景例如销售分析、产品分析等。
在实际应用中根据不同的业务需求和数据特点可以选择不同的数据存储方式。全量表、增量表和拉链表各有其优点和缺点可以根据实际需求进行选择和组合使用。
需要注意的是数据仓库的建设是一个长期的过程需要不断地完善和优化。在建设数据仓库时需要考虑数据的质量、安全性和可操作性等方面的问题以确保数据的准确性和可靠性。同时也需要定期对数据仓库进行清理和优化以提高数据的处理效率和查询性能。
总之数据仓库的全量表、增量表和拉链表是数据存储的常见方式各有其优点和缺点。在建设数据仓库时需要根据实际需求和数据特点选择合适的数据存储方式并注意数据的质量和安全性。同时也需要不断地优化和改进数据仓库的建设以提高数据的处理效率和查询性能。
