东莞做网站it s,关注公众号领红包,网站建设基本要点,绍兴聚氨酯制作公司目录
一、数据仓库概念
二、场景案例#xff1a;数据仓库为何而来#xff1f;
2.1 操作型记录的保存
2.2 分析型决策的制定
2.3 OLTP 环境开展分析可行吗#xff1f;
2.4 数据仓库的构建
三、数据仓库主要特征
3.1 面向主题性#xff08;Subject-Orient…目录
一、数据仓库概念
二、场景案例数据仓库为何而来
2.1 操作型记录的保存
2.2 分析型决策的制定
2.3 OLTP 环境开展分析可行吗
2.4 数据仓库的构建
三、数据仓库主要特征
3.1 面向主题性Subject-Oriented
3.2 集成性Integrated
3.3 非易失性、非异变性Non-Volatile
3.4 时变性Time-Variant
四、数据仓库、数据库、数据集市
4.1 OLTP、OLAP
4.2 数据仓库、数据库
4.3 数据仓库、数据集市
五、数据仓库分层架构
5.1 数仓分层思想和标准
5.2 阿里巴巴数仓 3 层架构
5.2.1 ODS 层Operation Data Store
5.2.2 DW 层Data Warehouse
5.2.3 DA 层或ADS层
5.3 分层的好处
5.4 ETL、ELT
5.4.1 背景
5.4.2 概念
六、场景分析美团点评酒旅数仓建设实践
6.1 架构变迁
6.2 主题建设
6.3 整体架构 一、数据仓库概念 数据仓库英语Data Warehouse简称数仓、DW是一个用于存储、分析、报告的数据系统。数据仓库的目的是构建面向分析的集成化数据环境为企业提供决策支持Decision Support。 数据仓库本身并不“生产”任何数据其数据来源于不同外部系统同时数据仓库自身也不需要“消费”任何的数据其结果开放给各个外部应用使用这也是为什么叫“仓库”而不叫“工厂”的原因。
二、场景案例数据仓库为何而来 先下结论为了分析数据而来分析结果给企业决策提供支撑。企业中信息总是用作两个目的
1操作型记录的保存、2分析型决策的制定。
下面以中国人寿保险公司chinalife发展为例阐述数据仓库为何而来
2.1 操作型记录的保存 中国人寿保险集团公司下辖多条业务线包括人寿险、财险、车险养老险等。各业务线的业务正常运营需要记录维护包括客户、保单、收付费、核保、理赔等信息。 联机事务处理系统OLTP正好可以满足上述业务需求开展, 其主要任务是执行联机事务处理。其基本特征是前台接收的用户数据可以立即传送到后台进行处理并在很短的时间内给出处理结果。关系型数据库RDBMS是 OLTP 典型应用比如Oracle、MySQL、SQL Server 等。 2.2 分析型决策的制定 随着集团业务的持续运营业务数据将会越来越多。由此也产生出许多运营相关的困惑能够确定哪些险种正在恶化或已成为不良险种能够用有效的方式制定新增和续保的政策吗理赔过程有欺诈的可能吗现在得到的报表是否只是某条业务线的集团整体层面数据如何 为了能够正确认识这些问题制定相关的解决措施瞎拍桌子是肯定不行的。最稳妥办法就是基于业务数据开展数据分析基于分析的结果给决策提供支撑。也就是所谓的数据驱动决策的制定。 然后面临下一个问题在哪里进行数据分析数据库可以吗
2.3 OLTP 环境开展分析可行吗
可以但是没必要。 OLTP 系统的核心是面向业务支持业务支持事务。所有的业务操作可以分为读、写两种操作一般来说读的压力明显大于写的压力。如果在 OLTP 环境直接开展各种分析有以下问题需要考虑
数据分析也是对数据进行读取操作会让读取压力倍增OLTP 仅存储数周或数月的数据数据分散在不同系统不同表中字段类型属性不统一 当分析所涉及数据规模较小的时候在业务低峰期时可以在 OLTP 系统上开展直接分析。但是为了更好的进行各种规模的数据分析同时也不影响 OLTP 系统运行此时需要构建一个集成统一的数据分析平台。 该平台的目的很简单面向分析支持分析并且和 OLTP 系统解耦合。基于这种需求数据仓库的雏形开始在企业中出现了。
2.4 数据仓库的构建 如数仓定义所说数仓是一个用于存储、分析、报告的数据系统目的是构建面向分析的集成化数据环境。我们把这种面向分析、支持分析的系统称之为 OLAP联机分析处理系统。数据仓库是 OLAP 一种。
中国人寿保险公司就可以基于分析决策需求构建数仓平台。 三、数据仓库主要特征 数据仓库目的是构建面向分析的集成化数据环境分析结果为企业提供决策支持Decision Support。数据仓库本身并不“生产”任何数据其数据来源于不同外部系统同时数据仓库自身也不需要“消费”任何的数据其结果开放给各个外部应用使用。 3.1 面向主题性Subject-Oriented 数据库中最大的特点是面向应用进行数据的组织各个业务系统可能是相互分离的。而数据仓库则是面向主题的。主题是一个抽象的概念是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象。在逻辑意义上它是对应企业中某一宏观分析领域所涉及的分析对象。 操作型处理传统数据对数据的划分并不适用于决策分析。而基于主题组织的数据则不同它们被划分为各自独立的领域每个领域有各自的逻辑内涵但互不交叉在抽象层次上对数据进行完整、一致和准确的描述。 3.2 集成性Integrated 确定主题之后就需要获取和主题相关的数据。当下企业中主题相关的数据通常会分布在多个操作型系统中彼此分散、独立、异构。 因此在数据进入数据仓库之前必然要经过统一与综合对数据进行抽取、清理、转换和汇总这一步是数据仓库建设中最关键、最复杂的一步所要完成的工作有
要统一源数据中所有矛盾之处如字段的同名异义、异名同义、单位不统一、字长不一致等等。进行数据综合和计算。数据仓库中的数据综合工作可以在从原有数据库抽取数据时生成但许多是在数据仓库内部生成的即进入数据仓库以后进行综合生成的。 下图说明了保险公司综合数据的简单处理过程其中数据仓库中与“承保”主题有关的数据来自于多个不同的操作型系统。这些系统内部数据的命名可能不同数据格式也可能不同。把不同来源的数据存储到数据仓库之前需要去除这些不一致。 3.3 非易失性、非异变性Non-Volatile 数据仓库是分析数据的平台而不是创造数据的平台。我们是通过数仓去分析数据中的规律而不是去创造修改其中的规律。因此数据进入数据仓库后它便稳定且不会改变。 操作型数据库主要服务于日常的业务操作使得数据库需要不断地对数据实时更新以便迅速获得当前最新数据不至于影响正常的业务运作。在数据仓库中只要保存过去的业务数据不需要每一笔业务都实时更新数据仓库而是根据商业需要每隔一段时间把一批较新的数据导入数据仓库。 数据仓库的数据反映的是一段相当长的时间内历史数据的内容是不同时点的数据库快照的集合以及基于这些快照进行统计、综合和重组的导出数据。 数据仓库的用户对数据的操作大多是数据查询或比较复杂的挖掘一旦数据进入数据仓库以后一般情况下被较长时间保留。数据仓库中一般有大量的查询操作但修改和删除操作很少。
3.4 时变性Time-Variant 数据仓库包含各种粒度的历史数据数据可能与某个特定日期、星期、月份、季度或者年份有关。虽然数据仓库的用户不能修改数据但并不是说数据仓库的数据是永远不变的。 分析的结果只能反映过去的情况当业务变化后挖掘出的模式会失去时效性。因此数据仓库的数据需要随着时间更新以适应决策的需要。从这个角度讲数据仓库建设是一个项目更是一个过程 。
数据仓库的数据随时间的变化表现在以下几个方面
数据仓库的数据时限一般要远远长于操作型数据的数据时限。操作型系统存储的是当前数据而数据仓库中的数据是历史数据。数据仓库中的数据是按照时间顺序追加的它们都带有时间属性。
四、数据仓库、数据库、数据集市
4.1 OLTP、OLAP 操作型处理叫联机事务处理 OLTPOn-Line Transaction Processing主要目标是做数据处理它是针对具体业务在数据库联机的日常操作通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的关系型数据库系统RDBMS作为数据管理的主要手段主要用于操作型处理。 分析型处理叫联机分析处理 OLAPOn-Line Analytical Processing主要目标是做数据分析。一般针对某些主题的历史数据进行复杂的多维分析支持管理决策。数据仓库是 OLAP 系统的一个典型示例主要用于数据分析。
下面从多个不同角度来对比 OLTP 和 OLAP OLTP OLAP 数据源 仅包含当前运行日常业务数据 整合来自多个来源的数据包括 OLTP 和外部来源 目的 面向应用面向业务支撑事务 面向主题面向分析支撑分析决策 焦点 当下 主要面向过去、面向历史 实时数仓 任务 读写操作 大量读而很少写操作 响应时间 毫秒 秒、分钟、小时或者天 取决于数据量和查询复杂性 数据量 小数据MB、GB 大数据TP、PB
4.2 数据仓库、数据库 数据库与数据仓库的区别实际讲的是 OLTP 与 OLAP 的区别。OLTP 系统的典型应用就是 RDBMS也就是我们俗称的数据库当然这里要特别强调此数据库表示的是关系型数据库 Nosql 数据库并不在讨论范围内。OLAP 系统的典型应用就是 DW也就是我们俗称的数据仓库。 数据仓库不是大型的数据库虽然数据仓库存储数据规模大。数据仓库的出现并不是要取代数据库。数据库是面向事务的设计数据仓库是面向主题设计的。数据库一般存储业务数据数据仓库存储的一般是历史数据。数据库是为捕获数据而设计数据仓库是为分析数据而设计。
4.3 数据仓库、数据集市 数据仓库Data Warehouse是面向整个集团组织的数据数据集市( Data Mart ) 是面向单个部门使用的。可以认为数据集市是数据仓库的子集也有人把数据集市叫做小型数据仓库。数据集市通常只涉及一个主题领域例如市场营销或销售。因为它们较小且更具体所以它们通常更易于管理和维护并具有更灵活的结构。 下图中各种操作型系统数据和包括文件在内的等其他数据作为数据源经过 ETL(抽取转换加载)填充到数据仓库中数据仓库中有不同主题数据数据集市则根据部门特点面向指定主题比如 Purchasing采购、Sales销售、Inventory库存用户可以基于主题数据开展各种应用数据分析、数据报表、数据挖掘。 五、数据仓库分层架构
5.1 数仓分层思想和标准 数据仓库的特点是本身不生产数据也不最终消费数据。按照数据流入流出数仓的过程进行分层就显得水到渠成。每个企业根据自己的业务需求可以分成不同的层次。但是最基础的分层思想理论上分为三个层操作型数据层ODS、数据仓库层(DW)和数据应用层(DA)。企业在实际运用中可以基于这个基础分层之上添加新的层次来满足不同的业务需求。 5.2 阿里巴巴数仓 3 层架构 为了更好的理解数据仓库分层的思想以及每层的功能意义下面结合阿里巴巴提供出的数仓分层架构图进行分析。阿里数仓是非常经典的 3 层架构从下往上依次是ODS、DW、DA。通过元数据管理和数据质量监控来把控整个数仓中数据的流转过程、血缘依赖关系和生命周期。当下我们不做深入探讨只做宏观了解掌握。
5.2.1 ODS 层Operation Data Store 操作型数据层也称之为源数据层、数据引入层、数据暂存层、临时缓存层。此层存放未经过处理的原始数据至数据仓库系统结构上与源系统保持一致是数据仓库的数据准备区。主要完成基础数据引入到数仓的职责和数据源系统进行解耦合同时记录基础数据的历史变化。
5.2.2 DW 层Data Warehouse 数据仓库层由 ODS 层数据加工而成。主要完成数据加工与整合建立一致性的维度构建可复用的面向分析和统计的明细事实表以及汇总公共粒度的指标。内部具体划分如下
公共维度层DIM基于维度建模理念思想建立整个企业一致性维度。公共汇总粒度事实层DWS、DWB以分析的主题对象作为建模驱动基于上层的应用和产品的指标需求构建公共粒度的汇总指标事实表以宽表化手段物理化模型明细粒度事实层DWD: 将明细事实表的某些重要维度属性字段做适当冗余即宽表化处理。
5.2.3 DA 层或ADS层 数据应用层面向最终用户面向业务定制提供给产品和数据分析使用的数据。包括前端报表、分析图表、KPI、仪表盘、OLAP 专题、数据挖掘等分析。
5.3 分层的好处 分层的主要原因是在管理数据的时候能对数据有一个更加清晰的掌控详细来讲主要有下面几个原因
清晰数据结构
每一个数据分层都有它的作用域在使用表的时候能更方便地定位和理解。
数据血缘追踪 简单来说我们最终给业务呈现的是一个能直接使用业务表但是它的来源有很多如果有一张来源表出问题了我们希望能够快速准确地定位到问题并清楚它的危害范围。
减少重复开发
规范数据分层开发一些通用的中间层数据能够减少极大的重复计算。 把复杂问题简单化 将一个复杂的任务分解成多个步骤来完成每一层只处理单一的步骤比较简单和容易理解。而且便于维护数据的准确性当数据出现问题之后可以不用修复所有的数据只需要从有问题的步骤开始修复。
屏蔽原始数据的异常
屏蔽业务的影响不必改一次业务就需要重新接入数据。
5.4 ETL、ELT
5.4.1 背景 数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是 ETL抽取Extra转化 Transfer装载 Load的过程。但是在实际操作中将数据加载到仓库却产生了两种不同做法ETL 和 ELT。
5.4.2 概念
ExtractTransformLoad ETL 首先从数据源池中提取数据这些数据源通常是事务性数据库。数据保存在临时暂存数据库中ODS。然后执行转换操作将数据结构化并转换为适合目标数据仓库系统的形式。然后将结构化数据加载到仓库中以备分析。 ExtractLoadTransform ELT 使用 ELT数据在从源数据池中提取后立即加载。没有专门的临时数据库ODS这意味着数据会立即加载到单一的集中存储库中。数据在数据仓库系统中进行转换以便与商业智能工具BI 工具一起使用。大数据时代的数仓这个特点很明显。
六、场景分析美团点评酒旅数仓建设实践
6.1 架构变迁 在美团点评酒旅事业群内业务由传统的团购形式转向预订、直连等更加丰富的产品形式业务系统也在迅速的迭代变化这些都对数据仓库的扩展性、稳定性、易用性提出了更高要求。基于此美团采取了分层次、分主题的方式不断优化并调整层次结构下图展示了技术架构的变迁。 第一代数仓模型由于当时美团整体的业务系统所支持的产品形式比较单一团购业务系统中包含了所有业务品类的数据所以由平台的角色来加工数据仓库基础层是非常合适的平台统一建设支持各个业务线使用所以在本阶段中酒旅只是建立了一个相对比较简单的数据集市所谓的小型数据仓库。 第二代数仓模型由建设数据集市的形式转变成了直接建设酒旅数据仓库成为了酒旅自身业务系统数据的唯一加工者。 随着美团和点评融合同时酒旅自身的业务系统重构的频率也相对较高对第二代数仓模型稳定性造成了非常大的影响原本的维度模型非常难适配这么迅速的变化。核心问题是在用业务系统和业务线关系错综复杂业务系统之间差异性明显且变更频繁。 于是在 ODS 与多维明细层中间加入了数据整合层由业务驱动调整成了由技术驱动的方式来建设数据仓库基础层。使用本基础层的最根本出发点还是在于美团的供应链、业务、数据它们本身的多样性如果业务、数据相对比较单一、简单本层次的架构方案很可能将不再适用。
6.2 主题建设 实际上在传统的一些如银行、制造业、电信、零售等行业里都有一些比较成熟的模型如耳熟能详的 BDWM银行数据模型它们都是经过一些具有相类似行业的企业在二三十年数据仓库建设中所积累的行业经验不断的优化并通用化。 但美团所处的 O2O 行业本身就没有可借鉴的成熟的数据仓库主题以及模型所以在摸索建设两年的时间里美团总结了下面比较适合现状的七大主题后续可能还会新增。
6.3 整体架构 确定好技术和业务主题之后数仓的整体架构就比较清晰了。美团酒旅数仓七个主题基本上都采用 6 层结构的方式来建设划分主题更多是从业务的角度出发而层次划分则是基于技术实质上就是基于业务与技术的结合完成了整体的数据仓库架构。 以订单主题为例。在订单主题的建设过程中美团是按照由分到总的结构思路来进行建设首先分供应链建设订单相关实体数据整合中间层然后再进行适度抽象把分供应链的相关订单实体进行合并后生成订单实体数据整合层后续在数据整合层的订单实体基础上再扩展部分维度信息来完成后续层次的建设。
