精华内容
下载资源
问答
  • 建设数据仓库需要考虑的因素

    千次阅读 2016-10-09 17:01:54
    1.系统分析,确定主题 建立数据仓库的第一个步骤就是通过与业务部门的充分交流,了解建立...一旦确定问题以后,信息部门的人员还需要确定一下几个因素: ·操作出现的频率,即业务部门每隔多长时间做一次查询
    1.系统分析,确定主题

    建立 数据仓库 的第一个步骤就是通过与业务部门的充分交流,了解建立 数据仓库 所要解决的问题的真正含义,确定各个主题下的查询分析要求。

    业务人员往往会罗列出很多想解决的问题,信息部门的人员应该对这些问题进行分类汇总,确定 数据仓库 所实现的业务功能。一旦确定问题以后,信息部门的人员还需要确定一下几个因素:

    ·操作出现的频率,即业务部门每隔多长时间做一次查询分析。

    ·在系统中需要保存多久的数据,是一年、两年还是五年、十年。

    ·用户查询数据的主要方式,如在时间维度上是按照自然年,还是财政年。

    ·用户所能接受的响应时间是多长、是几秒钟,还是几小时。

    由于双方在理解上的差异,确定问题和了解问题可能是一个需要多次往复的过程,信息部门的人员可能需要做一些原型演示给业务部门的人员看,以最终确定系统将要实现的功能确实是业务部门所需要的。

    2.选择满足数据仓库系统要求的软件平台

    数据仓库 所要解决的问题确定后,第二个步骤就是选择合适的软件平台,包括数据库、建模工具、分析工具等。这里有许多因素要考虑,如系统对数据量、响应时间、分析功能的要求等,以下是一些公认的选择标准:

    ·厂商的背景和支持能力,能否提供全方位的技术支持和咨询服务。

    ·数据库对大数据量(TB级)的支持能力。

    ·数据库是否支持并行操作。

    ·能否提供 数据仓库 的建模工具,是否支持对 元数据 的管理。

    ·能否提供支持大数据量的数据加载、转换、传输工具(ETT)。

    ·能否提供完整的决策支持工具集,满足 数据仓库 中各类用户的需要。

    3.建立数据仓库的逻辑模型

    具体步骤如下:

    (1)确定建立 数据仓库 逻辑模型的基本方法。

    (2)基于主题视图,把主题视图中的数据定义转到逻辑数据模型中。

    (3)识别主题之间的关系。

    (4)分解多对多的关系。

    (5)用范式理论检验逻辑数据模型。

    (6)由用户审核逻辑数据模型。

    4.逻辑数据模型转化为数据仓库数据模型

    具体步骤如下:

    (1)删除非战略性数据: 数据仓库 模型中不需要包含逻辑数据模型中的全部数据项,某些用于操作处理的数据项要删除。

    (2)增加时间主键: 数据仓库 中的数据一定是时间的快照,因此必须增加时间主键。

    (3)增加派生数据:对于用户经常需要分析的数据,或者为了提高性能,可以增加派生数据。

    (4)加入不同级别粒度的汇总数据:数据粒度代表数据细化程度,粒度越大,数据的汇总程度越高。粒度是 数据仓库 设计的一个重要因素,它直接影响到驻留在 数据仓库 中的数据量和可以执行的查询类型。显然,粒度级别越低,则支持的查询越多;反之,能支持的查询就有限。

    对数据操作的效率与能得到数据的详细程度是一对矛盾,通常,人们希望建成的系统既有较高的效率,又能得到所需的详细资料。实施 数据仓库 的一个重要原则就是不要试图包括所有详细数据,因为90%的分析需求是在汇总数据上进行的。试图将粒度细化到最低层,只会增加系统的开销,降低系统的性能。 5.数据仓库数据模型优化

    数据仓库 设计时,性能是一项主要考虑因素。在 数据仓库 建成后,也需要经常对其性能进行监控,并随着需求和数据量的变更进行调整。

    优化 数据仓库 设计的主要方法是:

    ·合并不同的数据表。

    ·通过增加汇总表避免数据的动态汇总。

    ·通过冗余字段减少表连接的数量,不要超过3~5个。

    ·用ID代码而不是描述信息作为键值。

    ·对数据表做分区。

    6.数据清洗转换和传输

    由于业务系统所使用的软硬件平台不同,编码方法不同,业务系统中的数据在加载到 数据仓库 之前,必须进行数据的清洗和转换,保证 数据仓库 中数据的一致性。

    在设计 数据仓库 的数据加载方案时,必须考虑以下几项要求:

    ·加载方案必须能够支持访问不同的数据库和文件系统。

    ·数据的清洗、转换和传输必须满足时间要求,能够在规定的时间范围内完成。

    ·支持各种转换方法,各种转换方法可以构成一个工作流。

    ·支持增量加载,只把自上一次加载以来变化的数据加载到 数据仓库

    7.开发数据仓库的分析应用

    建立 数据仓库 的最终目的是为业务部门提供决策支持能力,必须为业务部门选择合适的工具实现其对 数据仓库 中的数据进行分析的要求。

    信息部门所选择的开发工具必须能够:

    ·满足用户的全部分析功能要求。 数据仓库 中的用户包括了企业中各个业务部门,他们的业务不同,要求的分析功能也不同。如有的用户只是简单的分析报表,有些用户则要求做预测和趋势分析。

    ·提供灵活的表现方式。分析的结果必须能够以直观、灵活的方式表现,支持复杂的图表。使用方式上,可以是客户机/服务器方式,也可以是浏览器方式。

    事实上,没有一种工具能够满足 数据仓库 的全部分析功能需求,一个完整的 数据仓库 系统的功能可能是由多种工具来实现,因此必须考虑多个工具之间的接口和集成性问题,对于用户来说,希望看到的是一致的界面。

    8.数据仓库的管理

    只重视 数据仓库 的建立,而忽视 数据仓库 的管理必然导致 数据仓库 项目的失败。 数据仓库 管理主要包括数据库管理和 元数据 管理。

    数据库管理需要考以下几个方面:

    ·安全性管理。 数据仓库 中的用户只能访问到他的授权范围内的数据,数据在传输过程中的加密策略。

    · 数据仓库 的备份和恢复。 数据仓库 的大小和备份的频率直接影响到备份策略。

    ·如何保证 数据仓库 系统的可用性,硬件还是软件方法。

    ·数据老化。设计 数据仓库 中数据的存放时间周期和对过期数据的老化方法,如历史数据只保存汇总数据,当年数据保存详细记录。

    然而, 元数据 管理贯穿于整个系统的建设过程中, 元数据 是描述数据的数据。在数据采集阶段, 元数据 主要包括下列信息:

    ·源数据的描述定义:类型、位置、结构。

    ·数据转换规则:编码规则、行业标准。

    ·目标 数据仓库 的模型描述:星型/雪花模型定义,维/事实结构定义。

    ·源数据到目标 数据仓库 的映射关系:函数/表达式定义。

    ·代码:生成转换程序、自动加载程序等。

    在数据管理阶段, 元数据 主要包括下列信息:

    ·汇总数据的描述:汇总/聚合层次、物化视图结构定义。

    ·历史数据存储规则:位置、存储粒度。

    ·多维数据结构描述:立方体定义、维结构、度量值、钻取层次定义等。

    在数据展现阶段, 元数据 主要包括以下信息:

    ·报表的描述:报表结构的定义。

    ·统计函数的描述:各类统计分析函数的定义。

    ·结果输出的描述:图、表输出的定义。

    元数据 不但是独立存放,而且对用户是透明的,标准 元数据 之间可以互相转换。
    展开全文
  • 数据仓库基本知识

    万次阅读 多人点赞 2017-10-31 17:35:04
    数据仓库是什么 根据统计,每个企业的数据量每2~3年时间就会成倍增长,这些数据蕴含着巨大的商业价值,而企业所关注的通常只占在总数据量的2%~4%左右。 因此,企业仍然没有最大化地利用已存在的数据资源,以...
     
    

    数据仓库是什么

    根据统计,每个企业的数据量每2~3年时间就会成倍增长,这些数据蕴含着巨大的商业价值,而企业所关注的通常只占在总数据量的2%~4%左右。
    因此,企业仍然没有最大化地利用已存在的数据资源,以至于浪费了更多的时间和资金,也失去制定关键商业决策的最佳契机。
    于是,企业如何通过各种技术手段,并把数据转换为信息、知识避免各种无知状态和瞎猜行为,已经成了提高其核心竞争力的主要瓶颈。
    数据仓库是把数据转换为信息、知识的一种主要技术手段。
    数据仓库是面向分析的存储系统
    数据仓库,是为企业所有级别的决策制定过程,提供所有类型数据支持的数据集合。
    这些数据集合出于分析性报告和决策支持目的而创建,用于支持研究管理决策。
    一是为调查研究作数据支撑,二是为实现需要业务智能的企业,提供指导业务流程改进、监视时间、成本、量以及控制。
    数据仓库是一个过程而不是一个项目;数据仓库是一个环境,而不是一件产品。
    数据仓库提供用户用于决策支持的当前和历史数据,这些数据在传统的操作型数据库中很难或不能得到。

    [903014-20160322154102745-1726255952.jpg]


    目标和DEMO

    将联机事务处理(OLTP)经年累月所累积的大量数据资料,透过数据仓库理论所特有的资料储存架构,做数据的清理保存,提供给各种分析方法使用,如联机分析处理(OLAP)、数据挖掘(Data Mining),并进而创建 决策支持系统(DSS)、主管资讯系统(EIS)、研究支持系统,帮助决策者研究者快速有效的自大量资料中,分析出有价值的资讯,能够快速回应外在环境变动,帮助建构商业智能(BI),挖掘内部数据价值,产生更多高质量的内容。

    数据仓库给组织带来了巨大的变化。数据仓库的建立给企业带来了一些新的工作流程,其他的流程也因此而改变。

    数据仓库为企业带来了一些“以数据为基础的知识”,它们主要应用于对市场战略的评价,和为企业发现新的市场商机,同时,也用来控制库存、检查生产方法和定义客户群。

    通过数据仓库,可以建立企业的数据模型,这对于企业的生产与销售、成本控制与收支分配有着重要的意义,极大的节约了企业的成本,提高了经济效益,同时,用数据仓库可以分析企业人力资源与基础数据之间的关系,可以用于返回分析,保障人力资源的最大化利用,亦可以进行人力资源绩效评估,使得企业管理更加科学合理。数据仓库将企业的数据按照特定的方式组织,从而产生新的商业知识,并为企业的运作带来新的视角。

    国外知名的Garnter关于数据集市产品报告中,位于第一象限的敏捷商业智能产品有QlikView, Tableau和SpotView,都是全内存计算的数据集市产品,在大数据方面对传统商业智能产品巨头形成了挑战。

    国内BI产品起步较晚,知名的敏捷型商业智能产品有PowerBI, 永洪科技的Z-Suite,SmartBI,FineBI商业智能软件等,其中永洪科技的Z-Data Mart是一款热内存计算的数据集市产品。

    国内的德昂信息也是一家数据集市产品的系统集成商。

    [v2-da8260eae1a66096e3b61cd598b06596_hd.png]

    [v2-da8260eae1a66096e3b61cd598b06596_hd.png]

    阿里数加
    https://data.aliyun.com/


    数据仓库的特点

    数据仓库是一个面向主题的(Subject Oriented)、集成的(Integrate)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合

    1、面向主题

    操作型数据库的数据组织面向事务处理任务,各个业务系统之间各自分离,而数据仓库中的数据是按照一定的主题域进行组织的。

    2、集成的

    数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的,必须消除源数据中的不一致性,以保证数据仓库内的信息是关于整个企业的一致的全局信息。

    3、相对稳定的

    数据仓库的数据主要供企业决策分析之用,所涉及的数据操作主要是数据查询,一旦某个数据进入数据仓库以后,一般情况下将被长期保留,也就是数据仓库中一般有大量的查询操作,但修改和删除操作很少,通常只需要定期的加载、刷新。

    4、反映历史变化

    数据仓库中的数据通常包含历史信息,系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息,通过这些信息,可以对企业的发展历程和未来趋势做出定量分析和预测。

    5、效率足够高
    数据仓库的分析数据一般分为日、周、月、季、年等,可以看出,日为周期的数据要求的效率最高,要求24小时甚至12小时内,客户能看到昨天的数据分析。由于有的企业每日的数据量很大,设计不好的数据仓库经常会出问题,延迟1-3日才能给出数据,显然不行的。


    数据仓库技术

    数据仓库技术是为了有效的把操作形数据集成到统一的环境中以提供决策型数据访问的各种技术和模块的总称。所做的一切都是为了让用户更快更方便查询所需要的信息,提供决策支持。

    从功能结构划分,数据仓库系统至少应该包含数据获取(Data Acquisition)、数据存储(Data Storage)、数据访问(Data Access)三个关键部分。

    数据获取

    数据源

    数据源是数据仓库系统的基础,是整个系统的数据源泉。通常包括企业内部信息和外部信息。内部信息包括存放于RDBMS中的各种业务处理数据和各类文档数据。外部信息包括各类法律法规、市场信息和竞争对手的信息等等;

    元数据

    对业务数据本身及其运行环境的描述与定义的数据,称之为元数据(metadata)。 元数据是描述数据的数据。 元数据的典型表现为对象的描述,即对数据库、表、列、列属性(类型、格式、约束等)以及主键/外部键关联等等的描述。 特别是现行应用的异构性与分布性越来越普遍的情况下,统一的元数据就愈发重要了。“信息孤岛”曾经是很多企业对其应用现状的一种抱怨和概括,而合理的元数据则会有效地描绘出信息的关联性。 而元数据对于ETL的集中表现为:定义数据源的位置及数据源的属性、确定从源数据到目标数据的对应规则、确定相关的业务逻辑、在数据实际加载前的其他必要的准备工作,等等,它一般贯穿整个数据仓库项目,而ETL的所有过程必须最大化地参照元数据,这样才能快速实现ETL。

    数据转换工具

    1)数据转换工具要能从各种不同的数据源中读取数据。 2)支持平面文件、索引文件、和legacyDBMS。 3)能以不同类型数据源为输入整合数据。 4)具有规范的数据访问接口 5)最好具有从数据字典中读取数据的能力 6)工具生成的代码必须是在开发环境中可维护的 7)能只抽取满足指定条件的数据,和源数据的指定部分 8)能在抽取中进行数据类型转换和字符集转换 9)能在抽取的过程中计算生成衍生字段 10)能让数据仓库管理系统自动调用以定期进行数据抽取工作,或能将结果生成平面文件 11)必须对软件供应商的生命力和产品支持能力进行仔细评估 主要数据抽取工具供应商:Prismsolutions. Carleton'sPASSPORT. InformationBuildersInc.'s EDA/SQL. SASInstituteInc.

    数据清洗ETL

    ETL分别代表:提取extraction、转换transformation、加载load。

    其中提取过程表示操作型数据库搜集指定数据,转换过程表示将数据转化为指定格式并进行数据清洗保证数据质量,加载过程表示将转换过后满足指定格式的数据加载进数据仓库。

    数据仓库会周期不断地从源数据库提取清洗好了的数据,因此也被称为"目标系统";

    实现ETL,首先要实现ETL转换的过程。体现为以下几个方面:
    1、空值处理:可捕获字段空值,进行加载或替换为其他含义数据,并可根据字段空值实现分流加载到不同目标库。
    2、规范化数据格式:可实现字段格式约束定义,对于数据源中时间、数值、字符等数据,可自定义加载格式。
    3、拆分数据:依据业务需求对字段可进行分解。例,主叫号 861082585313-8148,可进行区域码和电话号码分解。
    4、验证数据正确性:可利用Lookup及拆分功能进行数据验证。例如,主叫号861082585313-8148,进行区域码和电话号码分解后,可利用Lookup返回主叫网关或交换机记载的主叫地区,进行数据验证。
    5、数据替换:对于因业务因素,可实现无效数据、缺失数据的替换。
    6、Lookup:查获丢失数据 Lookup实现子查询,并返回用其他手段获取的缺失字段,保证字段完整性。
    7、建立ETL过程的主外键约束:对无依赖性的非法数据,可替换或导出到错误数据文件中,保证主键唯一记录的加载。

    根据以往数据仓库项目的经验,在一个数据仓库项目中,ETL设计和实施的工作量一般要占总项目工作量的40%-60%,而且数据仓库项目一般会存在二次需求的问题,客户在项目的实施过程中或者使用过程中会提出新的业务需求,而任何前端业务模型的改变都会涉及到ETL设计,因此ETL工具的选择对于整个数据仓库项目的成功是非常重要的。

    选型

    ETL工具的典型代表有:Informatica powercenter、Datastage、Oracle OWB(oracle warehouse builder)、ODI、微软DTS、Beeload、Kettle、Talend 、DataSprider、Spark、等等……

    开源的工具有eclipse的etl插件:CloverETL和Octupus

    在购买现成的工具之外,还有自己从头开发ETL程序的。

    ETL工作看起来并不复杂,特别是在数据量小、没有什么转换逻辑的时候,自己开发似乎非常节省成本。的确,主流的ETL工具价格不菲,动辄几十万;而从头开发无非就是费点人力而已,可以控制。至于性能,人大多是相信自己的,认为自己开发出来的东西知根知底,至少这些程序可以完全由自己控制。

    就目前自主开发的ETL程序而言,有人用c语言编写,有人用存储过程,还有人用各种语言混杂开发,程序之间各自独立。这很危险,虽然能够让开发者过足编码的瘾,却根本不存在架构。

    有位银行的朋友,他们几年前上的数据仓库系统,就是集成商自己用c语言专门为他们的项目开发的。单从性能上看似乎还不赖,然而一两年下来,项目组成员风雨飘零,早已物是人非,只有那套程序还在那里;而且,按照国内目前的软件工程惯例,程序注释和文档是不全或者是不一致的,这样的程序已经对日常业务造成很大阻碍。最近,他们已经开始考虑使用ETL工具重新改造了。

    扩展阅读

    数据仓库项目应该如何选择ETL工具:ETL or E-LT? http://blog.csdn.net/mengdebin/article/details/41151533

    ETL构建企业级数据仓库五步法
    http://blog.csdn.net/xcbsdu/article/details/6637775

    数据存储

    数据集市(Data Marts)

    为了特定的应用目的或应用范围,而从数据仓库中独立出来的一部分数据,也可称为部门数据或主题数据(subjectarea)。在数据仓库的实施过程中往往可以从一个部门的数据集市着手,以后再用几个数据集市组成一个完整的数据仓库。需要注意的就是再实施不同的数据集市时,同一含义的字段定义一定要相容,这样再以后实施数据仓库时才不会造成大麻烦。

    数据仓库管理

    安全和特权管理;跟踪数据的更新;数据质量检查;管理和更新元数据;审计和报告数据仓库的使用和状态;删除数据;复制、分割和分发数据;备份和恢复;存储管理。

    选型

    在大数据时代,数据仓库的重要性更胜以往。Hadoop平台下的Hive,Spark平台下的Spark SQL都是各自生态圈内应用最热门的配套工具,而它们的本质就是开源分布式数据仓库。

    在国内最优秀的互联网公司里(如阿里、腾讯),很多数据引擎是架构在数据仓库之上的(如数据分析引擎、数据挖掘引擎、推荐引擎、可视化引擎等等)。不少员工认为,开发成本应更多集中在数据仓库层,不断加大数据建设的投入。因为一旦规范、标准、高性能的数据仓库建立好了,在之上进行数据分析、数据挖掘、跑推荐算法等都是轻松惬意的事情。
    反之如果业务数据没梳理好,各种脏乱数据会搞得人焦头烂额,苦不堪言。

    数据访问

    数据仓库通常需要提供具有直接访问数据仓库功能的前端应用,这些应用也被称为BI(商务智能)应用

    有数据查询和报表工具

    应用开发工具

    经理信息系统(EIS)工具

    联机分析处理(OLAP)工具

    数据仓库建设好以后,用户就可以编写SQL语句对其进行访问并对其中数据进行分析。但每次查询都要编写SQL语句的话,未免太麻烦,而且对维度建模数据进行分析的SQL代码套路比较固定。

    于是,便有了OLAP工具,它专用于维度建模数据的分析。而BI工具则是能够将OLAP的结果以图表的方式展现出来,它和OLAP通常出现在一起。(注:本文所指的OLAP工具均指代这两者。)

    这种情况下,OLAP不允许访问中心数据库。一方面中心数据库是采取规范化建模的,而OLAP只支持对维度建模数据的分析;另一方面规范化数据仓库的中心数据库本身就不允许上层开发人员访问。而在维度建模数据仓库中,OLAP/BI工具和数据仓库的关系则是这样的:

    在维度建模数据仓库中,OLAP不但可以从数据仓库中直接取数进行分析,还能对架构在其上的数据集市群做同样工作。

    数据挖掘工具。

    信息发布系统

    把数据仓库中的数据或其他相关的数据发送给不同的地点或用户。基于Web的信息发布系统是对付多用户访问的最有效方法。

    数据可视化选型

    你想知道的经典图表全在这
    https://zhuanlan.zhihu.com/p/24168144

    R语言
    http://www.cnblogs.com/muchen/p/5332359.html

    pentaho

    FineBI

    PowerBI
    http://www.cnblogs.com/muchen/p/5389960.html

    http://www.cnblogs.com/muchen/p/5391101.html

    深入浅出BI
    https://zhuanlan.zhihu.com/p/24573880

    [903014-20160328190120316-616433149.jpg]

    [903014-20160328185819613-1426949688.jpg]


    案例

    facebook的ppt上了解到的是他们在hive上做大数据量的分析,计算结果放到oracle上做BI展示和计算 hadoop MR or hive上ETL计算完的结果表,同步到oracle中,连接传统BI工具,呈现报表,阿里、腾讯、盛大都是这样的

    [v2-3e6958278b96043f5a2379778054deae_hd.png]


    与传统数据库的对比

    企业的数据处理大致分为两类:
    一类是操作型处理,也称为联机事务处理,它是针对具体业务在数据库联机的日常操作,通常对少数记录进行查询、修改。
    另一类是分析型处理,一般针对某些主题的历史数据进行分析,支持管理决策。

    数据库:传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。

    数据仓库:数据仓库系统的主要应用主要是OLAP(On-Line Analytical Processing),支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。

    举个最常见的例子,拿电商行业来说好了。基本每家电商公司都会经历,从只需要业务数据库到要数据仓库的阶段。

    电商早期启动非常容易,入行门槛低。找个外包团队,做了一个可以下单的网页前端 + 几台服务器 + 一个MySQL,就能开门迎客了。这好比手工作坊时期。

    第二阶段,流量来了,客户和订单都多起来了,普通查询已经有压力了,这个时候就需要升级架构变成多台服务器和多个业务数据库(量大+分库分表),这个阶段的业务数字和指标还可以勉强从业务数据库里查询。初步进入工业化。

    第三个阶段,一般需要 3-5 年左右的时间,随着业务指数级的增长,数据量的会陡增,公司角色也开始多了起来,开始有了 CEO、CMO、CIO,大家需要面临的问题越来越复杂,越来越深入。

    高管们关心的问题,从最初非常粗放的:“昨天的收入是多少”、“上个月的 PV、UV 是多少”,逐渐演化到非常精细化和具体的用户的集群分析,特定用户在某种使用场景中,例如“20~30岁女性用户在过去五年的第一季度化妆品类商品的购买行为与公司进行的促销活动方案之间的关系”。这类非常具体,且能够对公司决策起到关键性作用的问题,基本很难从业务数据库从调取出来。

    原因在于:业务数据库中的数据结构是为了完成交易而设计的,不是为了而查询和分析的便利设计的。

    业务数据库大多是读写优化的,即又要读(查看商品信息),也要写(产生订单,完成支付)。

    因此对于大量数据的读(查询指标,一般是复杂的只读类型查询)是支持不足的。而怎么解决这个问题,此时我们就需要建立一个数据仓库了,公司也算开始进入信息化阶段了。

    数据仓库的作用在于:数据结构为了分析和查询的便利;只读优化的数据库,即不需要它写入速度多么快,只要做大量数据的复杂查询的速度足够快就行了。

    那么在这里前一种业务数据库(读写都优化)的是业务性数据库,后一种是分析性数据库,即数据仓库。

    最后总结一下:
    数据库 比较流行的有:MySQL, Oracle, SqlServer等
    数据仓库 比较流行的有:AWS Redshift, Greenplum, Hive等。
    这样把数据从业务性的数据库中提取、加工、导入分析性的数据库就是传统的 ETL 工作。

    数据仓库的方案建设的目的,是为前端查询和分析作为基础,由于有较大的冗余,所以需要的存储也较大。
    为了更好地为前端应用服务,数据仓库必须有如下几点优点,否则是失败的数据仓库方案。
    1.效率足够高。
    2.数据质量。
    3.扩展性。

    两类数据库的不同点:

    1.数据组成差别 - 数据时间范围差别

    一般来讲,操作型数据库只会存放90天以内的数据,而分析型数据库存放的则是数年内的数据。这点也是将操作型数据和分析型数据进行物理分离的主要原因。

    2.数据组成差别 - 数据细节层次差别

    操作型数据库存放的主要是细节数据,而分析型数据库中虽然既有细节数据,又有汇总数据,但对于用户来说,重点关注的是汇总数据部分。

    操作型数据库中自然也有汇总需求,但汇总数据本身不存储而只存储其生成公式。这是因为操作型数据是动态变化的,因此汇总数据会在每次查询时动态生成。

    而对于分析型数据库来说,因为汇总数据比较稳定不会发生改变,而且其计算量也比较大(因为时间跨度大),因此它的汇总数据可考虑事先计算好,以避免重复计算。

    3.数据组成差别 - 数据时间表示差别

    操作型数据通常反映的是现实世界的当前状态;而分析型数据库既有当前状态,还有过去各时刻的快照,分析型数据库的使用者可以综合所有快照对各个历史阶段进行统计分析。

    4.技术差别 - 查询数据总量和查询频度差别

    操作型查询的数据量少而频率多,分析型查询则反过来,数据量大而频率少。要想同时实现这两种情况的配置优化是不可能的,这也是将两类数据库物理分隔的原因之一。

    5.技术差别 - 数据更新差别

    操作型数据库允许用户进行增,删,改,查;分析型数据库用户则只能进行查询。

    6.技术差别 - 数据冗余差别

    数据的意义是什么?就是减少数据冗余,避免更新异常。而如5所述,分析型数据库中没有更新操作。因此,减少数据冗余也就没那么重要了。

    例如Hive是一种数据仓库,而数据仓库和分析型数据库的关系非常紧密。它只提供查询接口,不提供更新接口,这就使得消除冗余的诸多措施不需要被特别严格地执行了,可以保留冗余。

    7.功能差别 - 数据读者差别

    操作型数据库的使用者是业务环境内的各个角色,如用户,商家,进货商等;分析型数据库则只被少量用户用来做综合性决策。

    8.功能差别 - 数据定位差别

    这里说的定位,主要是指以何种目的组织起来。操作型数据库是为了支撑具体业务的,因此也被称为"面向应用型数据库";分析型数据库则是针对各特定业务主题域的分析任务创建的,因此也被称为"面向主题型数据库"。
    [4abe15bd7b3bcbc10f6b3846951b16d9_hd.jpg]


    怎么做

    1)收集和分析业务需求 确定指标

    基础数据的架构

    关键问题
    一般问题 (不完全是技术或文化,但很重要) 包括但不限于以下几点:
    业务用户想要执行什么样的分析?
    你现在收集的数据需要支持那些分析吗?
    数据在哪儿?
    数据清洗范围
    数据的清洁度如何?
    相似的数据有多个数据源吗?
    什么样的结构最适合核心数据仓库 (例如维度或关系型)?
    技术问题包括但不限于以下几点:
    在你的网络中要流通多少数据?它能处理吗?
    需要多少硬盘空间?
    硬盘存储需要多快?
    你会使用固态还是虚拟化的存储?

    2)建立数据模型和数据仓库的物理设计
    3)定义数据源
    4)选择数据仓库技术和平台
    5)从操作型数据库中抽取、净化、和转换数据到数据仓库–ETL依照模型进行初始加载、增量加载、缓慢增长维、慢速变化维、事实表加载等数据集成
    6)选择访问和报表工具
    7)选择数据库连接软件
    8)选择数据分析和数据展示软件
    9)更新数据仓库–并根据业务需求制定相应的加载策略、刷新策略、汇总策略、维护策略。

    较之数据库系统开发,数据仓库开发只多出ETL工程部分。然而这一部分极有可能是整个数据仓库开发流程中最为耗时耗资源的一个环节。
    因为该环节要整理各大业务系统中杂乱无章的数据并协调元数据上的差别,所以工作量很大。在很多公司都专门设有ETL工程师这样的岗位,大的公司甚至专门聘请ETL专家。

    [903014-20160322160747995-1497680833.jpg]

    展开全文
  • 数据仓库模型数据仓库四大模型

    千次阅读 2020-09-02 22:02:13
    1,整体性考虑:全面了解企业业务和数据 2,实施周期长 3,建模人员的能力要求高 步骤: 高层模型:考虑所有上层主题,主题之间的关系 中层模型:细化上层主题数据项 物理模型:基于性能,存储,平台特点,...

    ER模型(Bill Inmon 比尔·恩门)提出  (大型企业底层构建)

    1,整体性考虑:全面了解企业业务和数据

    2,实施周期长

    3,建模人员的能力要求高

    步骤:

    高层模型:考虑所有上层主题,主题之间的关系

    中层模型:细化 上层主题 数据项

    物理模型:基于性能,存储,平台特点,数据合并,分区设计

     

    维度建模(Ralph Kimball 拉尔夫·金博尔)提出 (当前最主流的模型)

    星型:所有维表直接连接到事实表

    雪花型: 当有一个或多个维表没有直接连接到事实表上,而是通过其他维表连接到事实表上

    (雪花型场景:

       1, 大型客户维度,客户属性需要隐匿

       2,银行、金融多种产品属性无法共享

       3,多切页日历维,结账期、季度、假期

    建模过程

    1,选择需要进行分析决策的业务过程

    2,选择粒度:时间维度

    3,识别维表:基于粒度设计维表,包括维度属性,用于分析时进行分组和筛选

    4,选择事实:确定分析需要衡量的指标,筛选有用字段

     

    Data Vault 模型:ER模型的衍生,设计出发点是为了实现数据整合,但不能直接用于数据分析决策。强调数据的历史性、可追溯性和原子性。范化程度较高

    Anchor 模型:对Data Vault进一步范化处理,核心思想是所有的扩展都是添加而不是修改,模型高度范化,6NF。基本变成k-v结构模型

    展开全文
  • 数据仓库知识点汇总

    千次阅读 多人点赞 2019-10-09 15:04:01
    数据仓库形象解释 业务场景如下图 举例说明: 在很久很久以前,世界上生活着许多种族,有人类,有矮人,有精灵......他们有着不同的信仰,不同的文化,彼此相安无事。可是,有一个猥琐男却偏偏想要统治整个世界...

    数据仓库形象解释

    业务场景如下图

    举例说明:

    在很久很久以前,世界上生活着许多种族,有人类,有矮人,有精灵......他们有着不同的信仰,不同的文化,彼此相安无事。可是,有一个猥琐男却偏偏想要统治整个世界。如何统治这么多不同文化信仰的种族呢?猥琐男想出一个馊主意,打造出几枚拥有魔力的戒指,免费送给不同种族的领袖,让他们可以更好地统治各自的族人。当各个种族的领袖美滋滋地戴上各自的魔戒,走上人生巅峰的时候,猥琐男又打造出一枚独一无二的至尊魔戒。他利用至尊魔戒的力量控制了所有的魔戒,从而控制了各个种族的领袖,继而控制了整个世界。

    这个故事告诉我们,数据库和数据仓库之间的关系:

    如果说,那个世界的每一个生命个体都是一条数据记录,那么普通的魔戒的地位就好比是数据库,而至尊魔戒的地位就好比是数据仓库。

    数据仓库,英文名称Data Warehouse,简写为DW。数据仓库顾名思义,是一个很大的数据存储集合,出于企业的分析性报告和决策支持目的而创建,对多样的业务数据进行筛选与整合。它为企业提供一定的BI(商业智能)能力,指导业务流程改进、监视时间、成本、质量以及控制。数据仓库的输入方是各种各样的数据源,最终的输出用于企业的数据分析、数据挖掘、数据报表等方向。

    数据仓库概述

    数据仓库,英文名称为Data Warehouse,可简写为DW或DWH。数据仓库,是为企业所有级别的决策制定过程,提供所有类型数据支持的战略集合。它是单个数据存储,出于分析性报告和决策支持目的而创建。为需要业务智能的企业,提供指导业务流程改进、监视时间、成本、质量以及控制。数据仓库是决策支持系统(DSS)和联机分析应用数据源的结构化数据环境。数据仓库研究和解决从数据库中获取信息的问题。

    数据仓库,由数据仓库之父比尔·恩门(Bill Inmon)于1990年提出,主要功能仍是将组织透过资讯系统之联机事务处理(OLTP)经年累月所累积的大量资料,透过数据仓库理论所特有的资料储存架构,作已有系统的分析整理,以利各种分析方法如联机分析处理(OLAP)、数据挖掘(Data Mining)之进行,并进而支持如决策支持系统(DSS)、主管资讯系统(EIS)、研究支持系统之创建,帮助决策者能快速有效的自大量资料中,分析出有价值的资讯,以利决策拟定及快速回应外在环境变动,帮助构建商业智能(BI)。挖掘内部数据价值,产生更多高质量的内容。

    根据统计,每个企业的数据量每2~3年时间就会成倍增长,这些数据蕴含着巨大的商业价值,而企业所关注的通常只占在总数据量的2%~4%左右

    因此,企业仍然没有最大化地利用已存在的数据资源,以至于浪费了更多的时间和资金,也失去制定关键商业决策的最佳契机。于是,企业如何通过各种技术手段,并把数据转换为信息、知识避免各种无知状态和瞎猜行为,已经成了提高其核心竞争力的主要瓶颈。数据仓库是把数据转换为信息、知识的一种主要技术手段。数据仓库是面向分析、挖掘的存储系统。数据仓库,是为企业所有级别的决策制定过程,提供所有类型数据支持的数据集合。这些数据集合出于分析性报告和决策支持目的而创建,用于支持研究管理决策。一是为调查研究作数据支撑,二是为实现需要业务智能的企业,提供指导业务流程改进、监视时间、成本、量以及控制。

    数据仓库是一个过程而不是一个项目;数据仓库是一个环境,而不是一件产品。

    数据仓库提供用户用于决策支持的当前和历史数据,这些数据在传统的操作型数据库中很难或不能得到。

    数据仓库就是整合多个数据源的历史数据进行细粒度的、多维的分析,帮助高层管理者或者业务分析人员做出商业战略决策或商业报表。

    数据仓库特点

    1、面向主题

    数据仓库是面向主题的;操作型数据库的数据组织面向事务处理任务,而数据仓库中的数据是按照一定的主题域进行组织。主题是指用户使用数据仓库进行决策时所关心的重点方面,一个主题通常与多个操作型信息系统相关。操作型数据库的数据组织面向事务处理任务,各个业务系统之间各自分离,而数据仓库中的数据是按照一定的主题域进行组织的。主题是与传统数据库的面向应用相对应的,是一个抽象概念,是在较高层次上将企业信息系统中的数据综合、归类并进行分析利用的抽象。每一个主题对应一个宏观的分析领域。数据仓库排除对于决策无用的数据,提供特定主题的简明视图。

    不同于传统数据库对应于某一个或多个项目,数据仓库根据使用者实际需求,将不同数据源的数据在一个较高的抽象层次上做整合,所有数据都围绕某一主题来组织。这里的主题怎么来理解呢?比如对于滴滴出行,“司机行为分析”就是一个主题,对于链家网,“成交分析”就是一个主题。收入、成本、客户、销售渠道等宏观方向也可以作为主题。

    2、数据集成

    数据仓库的数据有来自于分散的操作型数据,将所需数据从原来的数据中抽取出,进行加工与集成,统一与综合之后才能进入数据仓库;数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的,必须消除源数据中的不一致性,以保证数据仓库内的信息是关于整个企业的一致的全局信息。数据仓库的数据主要供企业决策分析之用,所涉及的数据操作主要是数据查询,一旦某个数据进入数据仓库以后,一般情况下将被长期保留,也就是数据仓库中一般有大量的查询操作,但修改和删除操作很少,通常只需要定期的加载、刷新。

    说简单的总结:数据仓库中存储的数据是来源于多个数据源的集成,原始数据来自不同的数据源,存储方式各不相同。要整合成为最终的数据集合,需要从数据源经过一系列抽取、清洗、转换的过程。

    3、相对稳定

    数据仓库是不可更新的,数据仓库主要是为决策分析提供数据,所涉及的数据操作主要是数据查询,一旦某个数据进入数据仓库以后,一般情况下将被长期保留,也就是数据仓库中一般有大量的查询操作,但修改和删除操作很少,通常只需要定期的加载、刷新。数据仓库中保存的数据是一系列历史快照,不允许被修改。用户只能通过分析工具进行查询和分析。

    4、历史变化

    数据仓库是随时间而变化的,传统的关系数据库系统比较适合处理格式化的数据,能够较好的满足商业商务处理的需求。稳定的数据以只读格式保存,且不随时间改变。数据仓库中的数据通常包含历史信息,系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到当前的各个阶段的信息,通过这些信息,可以对企业的发展历程和未来趋势做出定量分析和预测。

    5、汇总的

    操作性数据映射成决策可用的格式。

    6、大容量

    时间序列数据集合通常都非常大。

    7、非规范化

    数据仓库中数据大多数是冗余的数据。

    8、高效率

    数据仓库的分析数据一般分为日、周、月、季、年等,可以看出,日为周期的数据要求的效率最高,要求24小时甚至12小时内,客户能看到昨天的数据分析。由于有的企业每日的数据量很大,设计不好的数据仓库经常会出问题,延迟1-3日才能给出数据,显然不行的。

    9、数据质量

    数据仓库所提供的各种信息,肯定要准确的数据,但由于数据仓库流程通常分为多个步骤,包括数据清洗,装载,查询,展现等等,复杂的架构会更多层次,那么由于数据源有脏数据或者代码不严谨,都可以导致数据失真,客户看到错误的信息就可能导致分析出错误的决策,造成损失,而不是效益。

    10、扩展性

    之所以有的大型数据仓库系统架构设计复杂,是因为考虑到了未来3-5年的扩展性,这样的话,未来不用太快花钱去重建数据仓库系统,就能很稳定运行。主要体现在数据建模的合理性,数据仓库方案中多出一些中间层,使海量数据流有足够的缓冲,不至于数据量大很多,就运行不起来了。

    常用数据仓库工具

    Hive大数据数据仓库工具,一般结合HDFS用,Hive主要优势是免费其它常用数据仓库还有Oracle,DB2,AWS Redshift,Greenplum等数据仓库业界老大当属Teradata,其特点:数据仓库配备性能最高、最可靠的大规模并行处理 (MPP) 平台,能够高速处理海量数据,其性能远远高于Hive。它使得企业可以专注于业务,无需花费大量精力管理技术,因而可以更加快速地做出明智的决策,实现 ROI(投资回报率) 最大化。不过价钱较贵。

    数据仓库用途

    数据仓库技术可以将企业多年积累的数据唤醒,不仅为企业管理海量数据,分析数据,而且挖掘数据潜在的价值,从而成为通信企业运营维护系统的亮点之一。广义的说,基于数据仓库的决策支持系统由三个部件组成:①数据仓库技术②联机分析处理技术③数据挖掘技术。其中数据仓库技术是系统的核心。

    数据仓库应用主要使用的技术如下:

    ①并行

    计算的硬件环境、操作系统环境、数据库管理系统和所有相关的数据库操作、查询工具和技术、应用程序等各个领域都可以从并行的最新成就中获益。

    ②分区

    分区功能使得支持大型表和索引更容易,同时也提高了数据管理和查询性能。

    ③数据压缩

    数据压缩功能降低了数据仓库环境中通常需要的用于存储大量数据的磁盘系统的成本,新的数据压缩技术也已经消除了压缩数据对查询性能造成的负面影响。

    ④可以轻松地管理大小超过 1 TB 的仓库中的超大量数据。(大约30亿条)
    ⑤64 位体系结构提升了服务器的容量和速度。
    ⑥改进的索引技术(位图索引、散列索引、星形联接)提供了快速数据访问。
    ⑦仓库工具变得更为可靠且成本更低。仓库工具变得更为可靠且成本更低。
    ⑧许可策略更为经济合理且有大量开放系统。
    ⑨用户群现在有先进、友好且直观的工具来访问所有类型的数据仓库。

    每一家公司都有自己的数据。并且,许多公司在计算机系统中储存有大量的数据,记录着企业购买、销售、生产过程中的大量信息和客户的信息。通常这些数据都储存在许多不同的地方。使用数据仓库之后,企业将所有收集来的信息存放在一个唯一的地方——数据仓库。仓库中的数据按照一定的方式组织,从而使得信息容易存取并且有使用价值。已经开发出一些专门的软件工具,使数据仓库的过程实现可以半自动化,帮助企业将数据导入数据仓库,并使用那些已经存入仓库的数据。数据仓库给组织带来了巨大的变化。数据仓库的建立给企业带来了一些新的工作流程,其他的流程也因此而改变。数据仓库为企业带来了一些“以数据为基础的知识”,它们主要应用于对市场战略的评价,和为企业发现新的市场商机,同时,也用来控制库存、检查生产方法和定义客户群。通过数据仓库,可以建立企业的数据模型,这对于企业的生产与销售、成本控制与收支分配有着重要的意义,极大的节约了企业的成本,提高了经济效益,同时,用数据仓库可以分析企业人力资源与基础数据之间的关系,可以用于返回分析,保障人力资源的最大化利用,亦可以进行人力资源绩效评估,使得企业管理更加科学合理。数据仓库将企业的数据按照特定的方式组织,从而产生新的商业知识,并为企业的运作带来新的视角。

    做好数据分析/数据挖掘,数据仓库需要提升三点:

    ①数据理解:我们都知道,数据仓库是面向主题的,所以其自身与业务结合就相对紧密和完善,更方便数据分析师基于数据理解业务。
    ②数据质量:我们在做数据分析的时候要求数据是干净、完整的,而数据仓库已经对源系统的数据进行了业务契合的转换,以及脏数据的清洗,这就为数据分析的数据质量做了较好的保障。
    ③数据跨系统关联:
    数据跨系统关联数据仓库的一个简单架构,各业务源系统的数据经过ETL过程后流入数据仓库,当不同系统数据整合到数据仓库之后,至少解决了数据分析中的两个问题:①跨系统数据收集问题,同一个客户的储蓄交易和理财交易我们在同一张事件表就可以找到②跨系统关联问题,进行数据整合时,总是需要找到共同点来关联来自不同系统的信息,而数据仓库在ETL过程中就会整合相关客户信息,完美解决跨系统关联问题

    实际作用总结

    ①整合公司所有业务数据,建立统一的数据中心
    ②产生业务报表,用于作出决策
    ③为网站运营提供运营上的数据支持
    ④可以作为各个业务的数据源,形成业务数据互相反馈的良性循环
    ⑤分析用户行为数据,通过数据挖掘来降低投入成本,提高投入效果
    ⑥开发数据产品,直接或间接地为公司盈利

    备注:快照技术

    快照技术是一种摄影技术,随着存储应用需求的提高,用户需要在线方式进行数据保护,快照就是在线存储设备防范数据丢失的有效方法之一,在过去十年时间中,快照已经成为磁盘阵列、卷管理器文件系统甚至PCI RAID(独立磁盘冗余阵列)控制器的标准配置功能。越来越多的设备都开始支持这项功能。越来越多的存储设备支持快照功能,在这些产品的资料中宣传了各自快照技术的优势,有的是快照数量多,有的是占用空间小。
    SNIA(存储网络行业协会)对快照(Snapshot)的定义是:关于指定数据集合的一个完全可用拷贝,该拷贝包括相应数据在某个时间点(拷贝开始的时间点)的映像。快照可以是其所表示的数据的一个副本,也可以是数据的一个复制品。
    而从具体的技术细节来讲,快照是指向保存在存储设备中的数据的引用标记或指针。我们可以这样理解,快照有点像是详细的目录表,但它被计算机作为完整的数据备份来对待。

    快照有三种基本形式:基于文件系统式的、基于子系统式的和基于卷管理器/虚拟化式的,而且这三种形式差别很大。市场上已经出现了能够自动生成这些快照的实用工具,比如有代表性的有NetApp的存储设备基于文件系统实现,高中低端设备使用共同的操作系统,都能够实现快照应用;HP的EVA、HDS通用存储平台以及EMC的高端阵列则实现了子系统式快照;而Veritas则通过卷管理器实现快照。

    数据宏观分类

    企业的数据处理大致分为两类:①一类是操作型处理(大批量更新插入操作,难点:短时间内大批量变更的事务机制并发机制),也称为联机事务处理,它是针对具体业务在数据库联机的日常操作,通常对少数记录进行查询、修改。②另一类是分析型处理,一般针对某些主题的历史数据进行分析,支持管理决策。

    数据仓库可以看成是数据库的一部分,两者都是用来存储数据的,只不过一般数据库是OLTP(联机事务处是),里面存的是关系型数据,记录我们对数据的增删改查等操作。数据仓库是在数据库应用到一定程序之后而对历史数据的加工与分析;是处理两种不同用途的工具而已。两者具有不同的特征,主要体现在以下几个方面:

    1、处理性能
    日常业务涉及频繁、简单的数据存取,因此对操作型处理的性能要求是比较高的,需要数据库能够在很短时间内做出反应。
    2、数据集成
    企业的操作型处理通常较为分散,传统数据库面向应用的特性使数据集成困难。
    3、数据更新
    操作型处理主要由原子事务组成,数据更新频繁,需要并行控制和恢复机制。
    4、数据时限
    操作型处理主要服务于日常的业务操作。
    5、数据综合
    操作型处理系统通常只具有简单的统计功能。

    数据库安全防护

    计算机攻击、内部人员违法行为,以及各种监管要求,正促使组织寻求新的途径来保护其在商业数据库系统中的企业和客户数据。您可以采取八个步骤保护数据仓库并实现对关键法规的遵从:
    1、发现
    使用发现工具发现敏感数据的变化。
    2、漏洞和配置评估
    评估数据库配置,确保它们不存在安全漏洞。这包括验证在操作系统上安装数据库的方式(比如检查数据库配置文件和可执行程序的文件权限),以及验证数据库自身内部的配置选项(比如多少次登录失败之后锁定帐户,或者为关键表分配何种权限)。
    3、加强保护
    通过漏洞评估,删除不使用的所有功能和选项。
    4、变更审计☆
    通过变更审计工具加强安全保护配置,这些工具能够比较配置的快照(在操作系统和数据库两个级别上),并在发生可能影响数据库安全的变更时,立即发出警告。
    5、数据库活动监控(DAM)
    通过及时检测入侵和误用来限制信息暴露,实时监控数据库活动。
    6、审计
    必须为影响安全性状态、数据完整性或敏感数据查看的所有数据库活动生成和维护安全、防否认的审计线索。
    7、身份验证、访问控制和授权管理
    必须对用户进行身份验证,确保每个用户拥有完整的责任,并通过管理特权来限制对数据的访问。
    8、加密
    使用加密来以不可读的方式呈现敏感数据,这样攻击者就无法从数据库外部对数据进行未授权访问。

    数据监控需求

    数据,作为企业核心资产,越来越受到企业的关注,一旦发生非法访问、数据篡改、数据盗取,将给企业带来巨大损失。数据库作为数据的核心载体,其安全性就更加重要。面对数据库的安全问题,企业常常遇到以下主要挑战:数据库被恶意访问、攻击、甚至遭到数据偷窃,而不能及时地发现这些恶意的操作;不了解数据使用者对数据库的访问细节,从而不能保证您对数据安全的管理;信息安全同样会带来审计问题,当今全球对合规/ 审计要求越来越严格,由于不满足合规要求而导致处罚的事件屡见不鲜。美国《萨班斯法案》的强制性要求曾导致2007年7月5日中国第一家海外上市公司—华晨中国汽车控股有限公司从美国纽约证券交易所退市。企业面对审计面临以下挑战:    
    1、不能做到持续性审计    
    用户审计主要是针对数据库、应用系统日志做审计,这些日志内容非常庞大,DBA(数据库管理员)和信息安全审计人员的审计工作就只能做事后分析,分析时间也长。不能做到持续性审计。    
    2、审计并不规范    
    用户审计的内容和表格主要是根据外部审计人员要求和内部安全管理要素来考虑,这些审计工作的好坏基本上取决于DBA和信息安全审计人员的经验和技能,这些不能有效成为公司规范和满足外部审计要求。    
    3、数据库管理员权责没有完全区分开    
    数据库管理和审计原始数据的收集实际上都是由DBA来做的,这就导致了DBA的权责不明确,DBA没办法客观审计自己所做的工作,尽管用户设置了信息安全审计人员,但该角色的审计工作的部分证    据建立在DBA初步审计基础上,因此审计效果与可靠性存问题。    
    4、审计并不完整    
    人工审计需要面对海量的日志,不可能对所有数据进行细致审计;审计报告就未必能满足100%可见    
    性。IBM推出的CARS企业信息架构,Guardium数据库安全、合规、审计、监控解决方案

    数据仓库构建之前需考虑问题

    数据仓库具有改变业务的威力。它能帮助公司深入了解客户行为,预测销售趋势,确定某一组客户或产品的收益率。尽管如此,数据仓库的实现却是一个长期的、充满风险的过程。由DM Review发布的一项网络调查显示, 51% 受访者认为创建数据仓库的头号障碍是缺乏准确的数据。而其中最重要的一点是无法实时更新所有的数据。总结出大体的以下六点问题需要注意:    
    1、简化需求收集和设计    
    公司通常会难以确定,哪些数据重要,哪些使得他们无法利用有价值的非结构化信息来驱动关键业务流程。组织应该检查一下IT经理是否深入理解业务计划以及支持计划所需的信息。例如源数据在哪里?需要怎样的转换能让其为关键应用程序所用?    
    2、支持业务和 IT 用户协作    
    不完整、过时或不准确的数据会导致可信信息的缺乏。要注意公司是否有一个业务术语表供用户查看、用于协作并根据他们集体业务视角进行调整?    
    3、避免代价高昂的低级错误和返工    
    明确公司是否拥有一个包含界定完善的数据模型的实施策略,为应用程序提供信息?    
    4、识别匹配信息,创建单一视图    
    同一事实的多个版本会导致在管理用户、产品和合作伙伴关系方面出现问题——增加违反法规遵从性的风险。    
    5、使用最快的、最具伸缩性的方法进行转换和发布    
    明确公司是否有能够利用并行处理并重用之前转换成果的自动化过程?公司系统能否及时按需将数据发布给用户和应用程序?    
    6、通过信息服务扩展信息可访问性    
    明确企业是否能真正将信息用作共有财产?IT专家能否保存好这些财产并让被授权者使用?信息能否在合适的时间发布到合适的地方和合适的场景下?

    数据仓库的体系结构

    1、数据源    
    是数据仓库系统的基础,是整个系统的数据源泉。通常包括企业内部信息和外部信息。内部信息包括存放于RDBMS中的各种业务处理数据和各类文档数据。外部信息包括各类法律法规、市场信息和竞争对手的信息等等;数据来自内部的和外部的非集成操作系统。    
    2、数据的存储与管理    
    是整个数据仓库系统的核心。数据仓库的真正关键是数据的存储和管理。数据仓库的组织管理方式决定了它有别于传统数据库,同时也决定了其对外部数据的表现形式。要决定采用什么产品和技术来建立数据仓库的核心,则需要从数据仓库的技术特点着手分析。针对现有各业务系统的数据,进行抽取、清理,并有效集成,按照主题进行组织。数据仓库按照数据的覆盖范围可以分为企业级数据仓库和部门级数据仓库(通常称为数据集市)    
    3、OLAP服务器    
    对分析需要的数据进行有效集成,按多维模型予以组织,以便进行多角度、多层次的分析,并发现趋势。其具体实现可以分为:ROLAP(关系型在线分析处理)、MOLAP(多维在线分析处理)和HOLAP(混合型线上分析处理)。ROLAP基本数据和聚合数据均存放在RDBMS之中;MOLAP基本数据和聚合数据均存放于多维数据库中;HOLAP基本数据存放于RDBMS之中,聚合数据存放于多维数据库中。    
    4、前端工具    
    主要包括各种报表工具、查询工具、数据分析工具、数据挖掘工具以数据挖掘及各种基于数据仓库或数据集市的应用开发工具。其中数据分析工具主要针对OLAP服务器,报表工具、数据挖掘工具主要针对数据仓库。

    数据仓库的组成

    1、数据抽取工具    
    把数据从各种各样的存储方式中拿出来,进行必要的转化、整理,再存放到数据仓库内。对各种不同数据存储方式的访问能力是数据抽取工具的关键,应能生成COBOL程序、MVS作业控制语言(JCL)、UNIX脚本、和SQL语句等,以访问不同的数据。数据转换都包括:删除对决策应用没有意义的数据段;转换到统一的数据名称和定义;计算统计和衍生数据;给缺值数据赋给缺省值;把不同的数据定义方式统一。    
    2、数据库    
    是整个数据仓库环境的核心。是数据存放的地方和提供对数据检索的支持。相对于操纵型数据库来说其突出的特点是对海量数据的支持和快速的检索技术。    
    3、元数据    
    描述数据仓库内数据的结构和建立方法的数据,对业务数据本身及其运行环境的描述与定义的数据。可将其按用途分两类:技术元数据和商业元数据。    
    ①技术元数据    
    技术元数据是数据仓库的设计和管理人员用于开发和日常管理数据仓库使用的数据。    
    技术元数据包括:    
    a.数据源信息;    
    b.数据转换的描述;    
    c.数据仓库内对象和数据结构的定义;库、表、列、列属性(类型、格式、约束等)以及主键/外部键关联    
    d.数据清理和数据更新时用的规则;    
    e.源数据到目的数据的映射;    
    f.用户访问权限,数据备份历史记录,数据导入历史记录,信息发布历史记录等。    
    ②商业元数据    
    从商业业务的角度描述了数据仓库中的数据。    
    商业元数据包括:    
    a.业务主题的描述;    
    b.包含的数据、查询、报表;    
    元数据总结:    
    元数据又称中介数据、中继数据,为描述数据的数据(data about data),主要是描述数据属性(property)的信息,用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。元数据算是一种电子式目录,为了达到编制目录的目的,必须在描述并收藏数据的内容或特色,进而达成协助数据检索的目的。元数据就是关于数据的数据。将描述数据的数据保存起来。    
    元数据为访问数据仓库提供了一个信息目录(informationdirectory),这个目录全面描述了数据仓库中都有什么数据、这些数据怎么得到的、和怎么访问这些数据。是数据仓库运行和维护的中心,数据仓库服务器利用他来存贮和更新数据,用户通过他来了解和访问数据。现行应用的异构性与分布性越来越普遍的情况下,统一的元数据就愈发重要,“信息孤岛”曾经是很多企业对其应用现状的一种抱怨和概括,而合理的元数据则会有效地描绘出信息的关联性。而元数据对于ETL的集中表现为:定义数据源的位置及数据源的属性、确定从源数据到目标数据的对应规则、确定相关的业务逻辑、在数据实际加载前的其他必要的准备工作等等,它一般贯穿整个数据仓库项目,而ETL的所有过程必须最大化地参照元数据,这样才能快速实现ETL。

    4、数据集市

    为了特定的应用目的或应用范围,而从数据仓库中独立出来的一部分数据,也可称为部门数据或主题数据(subjectarea)。在数据仓库的实施过程中往往可以从一个部门的数据集市着手,以后再用几个数据集市组成一个完整的数据仓库。需要注意的就是在实施不同的数据集市时,同一含义的字段定义一定要相容,这样在以后实施数据仓库时才不会造成大麻烦。

     数据仓库数据集市
    数据来源遗留系统、CTPT系统、外部系统数据仓库
    范围企业级部门级或工作组级
    主题企业主题部门或特殊分析主题
    数据粒度最细粒度较粗粒度
    数据结构规范化结构(第3范式)星型模式、雪花模式,或二者混合
    历史数据大量历史数据适度历史数据
    优化处理海量数据,数据探索便于访问和分析,快速查询
    索引高度索引高度索引

    如何构建数据集市??    
    有关决策支持型数据库的数据集市是面向企业中的某个部门或是项目小组的。一些专家顾问将数    
    据集市的建造描述为建立数据仓库全过程中的一步:    
    ①首先,一个储存企业全部信息的数据仓库被创建,其中,数据均具备有组织的、一致的、不变的格式。    
    ②数据集市随后被创立,其目的是为不同部门提供他们所需要的那部分信息。    
    ③数据仓库聚集了所有详细的信息,而数据集市中的数据则是针对用户们的特定需求总结而出的。是分离与数据仓库的特定业务数据部分。    
    另外一批专家认为不需要首先建立一个数据仓库:    
    在这个模型中,数据直接由事务型数据库转入数据集市中。一个公司可能建立有多个数据集市,而彼此之间毫无联系。这种不在建立数据仓库的基础上创建数据集市的方式会更便宜、更快速,因为它的规模更加易于管理。    
    比较两种观点:    
    第二种观点的缺陷在于无法实现最初创建数据仓库的最主要的目的——将企业所有的数据统一为一致的格式。现有的事务处理系统的数据往往是不一致、冗余的。如果首先建立起一个全公司范围的数据仓库,组织就能够获得一个统一关于企业的活动和客户的知识库。如果先建立起一个个独立的数据集市,那么数据仓库的诸多优势都能够得以实现,但是企业远远无法做到对数据的一致的储存。

    5、数据仓库管理
    ①安全和特权管理,跟踪数据的更新②数据质量检查③管理和更新元数据    
    ④审计和报告数据仓库的使用状态⑤删除数据⑥复制、分割和分发数据⑦备份和恢复⑧存储管理    
    6、信息发布系统    
    把数据仓库中的数据或其他相关的数据发送给不同的地点或用户。基于Web的信息发布系统是对付多用户访问的最有效方法。    
    7、数据访问工具    
    为用户访问数据仓库提供手段。数据仓库通常需要提供具有直接访问数据仓库功能的前端应用,这些应用也被称为BI(商务智能)应用。    
    有如下访问工具:    
    ①数据查询和报表工具    
    ②应用开发工具    
    ③管理信息系统(EIS)工具    
    ④在线分析(OLAP)工具    
    ⑤数据挖掘工具    
    数据仓库建设好以后,用户就可以编写SQL语句对其进行访问并对其中数据进行分析。但每次查询都要编写SQL语句的话,未免太麻烦,而且对维度建模数据进行分析的SQL代码套路比较固定。于是,便有了OLAP工具,它专用于维度建模数据的分析。而BI工具则是能够将OLAP的结果以图表的方式展现出来,它和OLAP通常出现在一起。    
    这种情况下,OLAP不允许访问中心数据库。    
    一方面:中心数据库是采取规范化建模的,而OLAP只支持对维度建模数据的分析;    
    另一方面:规范化数据仓库的中心数据库本身就不允许上层开发人员访问☆☆☆;    
    在维度建模数据仓库中,OLAP不但可以从数据仓库中直接取数进行分析,还能对架构在其上的数据集市群做同样工作。

    数据仓库建模

    有别于一般联机事务处理(OLTP)系统,数据模型设计是一个数据仓库设计的地基,当前两大主流理论分别为采用正规方式(normalized approach)或多维方式(dimensional approach)进行数据模型设计。数据模型分为:

    1、逻辑模型和实体模型:
    ①逻辑数据模型
    陈述业务相关数据的关系,基本上是一种与数据库无关的结构设计,通常均会采用正规方式设计,主要精神是从企业业务领域的角度及高度订出subject area model,再逐步向下深入到entities、attributes,在设计时不会考虑未来采用的数据库管理系统,也不需考虑分析性能问题。
    ②而实体数据模型则与数据库管理系统有关,是建置在该系统上的数据架构,故设计时需考虑数据类型(data type)、空间及性能相关的议题。实体数据模型设计,则较多有采用正规方式或多维方式的讨论,但从实务上来说,不执著于理论,能与业务需要有最好的搭配,才是企业在建置数据仓库时的正确考量。
    数据仓库的建设需要考虑以下方面:
    不仅是资讯工具技术面的运用,在规划和执行方面更需对产业知识、行销管理、市场定位、策略规划等相关业务有深入的了解,才能真正发挥数据仓库以及后续分析工具的价值,提升组织竞争力。
    2、建模前基本概念
    主题(Subject)
    主题就是指我们所要分析的具体方面。例如:某年某月某地区某机型某款App的安装情况。主题有两个元素:一是各个分析角度(维度),如时间位置;二是要分析的具体量度,该量度一般通过数值体现,如App安装量。
    维(Dimension)
    维是用于从不同角度描述事物特征的,一般维都会有多层(Level:级别),每个Level都会包含一些共有
    的或特有的属性(Attribute),可以用下图来展示下维的结构和组成:

    以时间维为例,时间维一般会包含年、季、月、日这几个Level,每个Level一般都会有ID、NAME、DESCRIPTION这几个公共属性,这几个公共属性不仅适用于时间维,也同样表现在其它各种不同类型的维。分层(Hierarchy)OLAP需要基于有层级的自上而下的钻取,或者自下而上地聚合。所以我们一般会在维的基础上再次进行分层,维、分层、层级的关系如下图:

    每一级之间可能是附属关系(如市属于省、省属于国家),也可能是顺序关系(如天周年),如下图所示:

    量度
    量度就是我们要分析的具体的技术指标,诸如年销售额之类。它们一般为数值型数据。我们或者将该数据汇总,或者将该数据取次数、独立次数或取最大最小值等,这样的数据称为量度。

    粒度

    数据的细分层度,例如按天分按小时分。
    事实表是用来记录分析的内容的全量信息的,包含了每个事件的具体要素,以及具体发生的事情。事实表
    中存储数字型ID以及度量信息。维表则是对事实表中事件的要素的描述信息,就是你观察该事务的角度,
    是从哪个角度去观察这个内容的。举例:

    星形/雪花形/事实星座:

    这三者就是数据仓库多维数据模型建模的模式,上图所示就是一个标准的星形模型。雪花形就是在维度下面又细分出维度,这样切分是为了使表结构更加规范化。雪花模式可以减少冗余,但是减少的那点空间和事实表的容量相比实在是微不足道,而且多个表联结操作会降低性能,所以一般不用雪花模式设计数据仓库。事实星座模式就是星形模式的集合,包含星形模式,也就包含多个事实表。

    企业级数据仓库/数据集市

    企业级数据仓库:突出大而全,不论是细致数据和聚合数据它全都有,设计时使用事实星座模式。

    数据集市:可以看做是企业级数据仓库的一个子集,它是针对某一方面的数据设计的数据仓库,例如为公司的支付业务设计一个单独的数据集市。由于数据集市没有进行企业级的设计和规划,所以长期来看,它本身的集成将会极其复杂。其数据来源有两种,一种是直接从原生数据源得到,另一种是从企业数据仓库得到。设计时使用星形模型。

    3、建模设计步骤

    ①选择合适的主题(所要解决问题的领域)    
    主题与业务密切相关,所以设计数仓之前应当充分了解业务有哪些方面的需求,据此确定主题    
    ②确定量度    
    在确定了主题以后,我们将考虑要分析的技术指标,诸如年销售额之类。量度是要统计的指标,必须事先选择恰当,基于不同的量度将直接产生不同的决策结果。    
    ③确定数据粒度    
    考虑到量度的聚合程度不同,我们将采用“最小粒度原则”,即将量度的粒度设置到最小。例如如果知道某些数据细分到天就好了,那么设置其粒度到天;但是如果不确定的话,就将粒度设置为最小,即毫秒级别的。    
    ④确定维度    
    设计各个维度的主键、层次、层级,尽量减少冗余。    
    ⑤明确定义事实表    
    事实表中将存在维度代理键和各量度,而不应该存在描述性信息,即符合“瘦高原则”,即要求事实表数据条数尽量多(粒度最小),而描述性信息尽量少。    
    ⑥计算并存储fact表中的衍生数据段    
    ⑦转换维表    
    ⑧数据库数据采集    
    ⑨根据需求刷新维表    
    ⑩确定查询优先级和查询模式    
    ※事实表:数据仓库架构中的中央表,它包含联系事实与维度表的数字度量值和键。事实数据表包含描述业务(如银行事务或产品销售)内特定事件的数据。每个数据仓库都包含一个或者多个事实数据表。事实数据表可能包含业务销售数据,如现金登记事务所产生的数据,事实数据表通常包含大量的行。事实数据表的主要特点是包含数字数据(事实),并且这些数字信息可以汇总,以提供有关单位作为历史的数据,每个事实数据表包含一个由多个部分组成的索引,该索引包含作为外键的相关性维度表的主键,而维度表包含事实记录的特性。事实数据表不应该包含描述性的信息,也不应该包含除数字度量字段及使事实与维度表中对应项的相关索引字段之外的任何数据。

    4、其它注意---关键问题

    ①硬件平台:数据仓库的硬盘容量通常要是操作数据库硬盘容量的2-3倍--需要多少硬盘空间?
    ②通常大型机具有更可靠的性能和和稳定性,也容易与历史遗留的系统结合在一起;而PC服务器或UNIX服务器更加灵活,容易操作和提供动态生成查询请求进行查询的能力。选择硬件平台时要考虑的问题:是否提供并行的I/O吞吐?--硬盘存储需要多快?对多CPU的支持能力如何?
    ③数据仓库DBMS:他的存储大数据量的能力、查询的性能、和对并行处理的支持如何。
    ④网络结构:数据仓库的实施在那部分网络段上会产生大量的数据通信,需不需要对网络结构进行改进。---在你的网络中要流通多少数据?它能处理吗?
    ⑤业务用户想要执行什么样的分析?⑥你现在收集的数据需要支持那些分析吗?
    ⑦数据在哪儿?⑧数据的清洁度如何?纯净程度⑨相似的数据有多个数据源吗?
    ⑩什么样的结构最适合核心数据仓库 (例如维度或关系型)?
    ⑪ 你会使用固态还是虚拟化的存储?
    5、建模划分
    数据仓库的数据建模大致分为四个阶段:
    ①业务建模,这部分建模工作,主要包含以下几个部分:
    a.划分整个单位的业务,一般按照业务部门的划分,进行各个部分之间业务工作的界定,理清各业务部门之间的关系。
    b.深入了解各个业务部门的内具体业务流程并将其程序化。
    c.提出修改和改进业务部门工作流程的方法并程序化。
    d.数据建模的范围界定,整个数据仓库项目的目标和阶段划分。
    ②领域概念建模,这部分得建模工作,主要包含以下几个部分:
    a.抽取关键业务概念,并将之抽象化。
    b.将业务概念分组,按照业务主线聚合类似的分组概念。
    c.细化分组概念,理清分组概念内的业务流程并抽象化。
    d.理清分组概念之间的关联,形成完整的领域概念模型。
    ③逻辑建模,这部分的建模工作,主要包含以下几个部分:
    a.业务概念实体化,并考虑其具体的属性
    b.事件实体化,并考虑其属性内容
    c.说明实体化,并考虑其属性内容
    ④物理建模,这部分得建模工作,主要包含以下几个部分:
    a.针对特定物理化平台,做出相应的技术调整
    b.针对模型的性能考虑,对特定平台作出相应的调整
    c.针对管理的需要,结合特定的平台,做出相应的调整
    d.生成最后的执行脚本,并加以完善

    数据仓库建立步骤

    1.步骤☆☆☆
    ①收集和分析业务需求②建立数据模型和数据仓库的物理设计③定义数据源。
    ④选择数据仓库技术和平台⑤从操作型数据库中抽取、净化、和转换数据到数据仓库。
    ⑥选择访问和报表工具⑦选择数据库连接软件⑧选择数据分析和数据展示软件。
    ⑨更新数据仓库–并根据业务需求制定相应的加载策略、刷新策略、汇总策略、维护策略。

    2.数据转换工具

    1)数据转换工具要能从各种不同的数据源中读取数据
    2)支持平面文件、索引文件、和legacyDBMS
    3)能以不同类型数据源为输入整合数据
    4)具有规范的数据访问接口
    5)最好具有从数据字典中读取数据的能力
    6)工具生成的代码必须是在开发环境中可维护的
    7)能只抽取满足指定条件的数据,和源数据的指定部分
    8)能在抽取中进行数据类型转换和字符集转换
    9)能在抽取的过程中计算生成衍生字段
    10)能让数据仓库管理系统自动调用以定期进行数据抽取工作,或能将结果生成平面文件
    11)必须对软件供应商的生命力和产品支持能力进行仔细评估主要数据抽取工具参照:
    https://blog.csdn.net/luoqinglong850102/article/details/80735173
    https://blog.csdn.net/security_2015/article/details/78549499
    https://cloud.tencent.com/developer/news/203472

    什么是ETL??

    ETL的英文全称是 Extract-Transform-Load 的缩写,用来描述将数据从来源迁移到目标的几个过程:
    1.Extract,数据抽取,也就是把数据从数据源读出来。
    2.Transform,数据转换,把原始数据转换成期望的格式和维度。如果用在数据仓库的场景下,Transform也包含数据清洗,清洗掉噪音数据,保证数据质量。
    3.Load 数据加载,把处理后的数据加载到目标处,比如数据仓库。数据仓库会周期不断地从源数据库提取清洗好了的数据,因此也被称为"目标系统";实现ETL,首先要实现ETL转换的过程。体现为以下几个方面:
    ①空值处理:可捕获字段空值,进行加载或替换为其他含义数据,并可根据字段空值实现分流加载到不同目标库。
    ②规范化数据格式:可实现字段格式约束定义,对于数据源中时间、数值、字符等数据,可自定义加载格式。
    ③拆分数据:依据业务需求对字段可进行分解。例,主叫号 861082585313-8148,可进行区域码和电话号码分解。
    ④验证数据正确性:可利用Lookup及拆分功能进行数据验证。例如,主叫号861082585313-8148,进行区域码和电话号码分解后,可利用Lookup返回主叫网关或交换机记载的主叫地区,进行数据验证。
    ⑤数据替换:对于因业务因素,可实现无效数据、缺失数据的替换。
    ⑥Lookup:查获丢失数据Lookup实现子查询,并返回用其他手段获取的缺失字段,保证字段完整性。
    ⑦建立ETL过程的主外键约束:对无依赖性的非法数据,可替换或导出到错误数据文件中,保证主键唯一记录的加载。

    根据以往数据仓库项目的经验,在一个数据仓库项目中,ETL设计和实施的工作量一般要占总项目工作量的40%-60%,而且数据仓库项目一般会存在二次需求的问题,客户在项目的实施过程中或者使用过程中会提出新的业务需求,而任何前端业务模型的改变都会涉及到ETL设计,因此ETL工具的选择对于整个数据仓库项目的成功是非常重要的。

    ETL工具的典型代表有:Informatica powercenter、Datastage、Oracle OWB(oracle warehouse builder)、ODI、微软DTS、Beeload、☆Kettle☆、Talend 、DataSprider、Spark、Scriptella、Camel、Apatar、Heka、Logstash等等……     
    开源的工具有eclipse的etl插件:CloverETL和Octupus。

    除了以上可选ETL工具外,也可以从头自己开发的ETL程序。Hadoop平台下的Hive,Spark平台下的Spark SQL都是各自生态圈内应用最热门的配套工具,而它们的本质就是开源分布式数据仓库。 在国内最优秀的互联网公司里(如阿里、腾讯),很多数据引擎是架构在数据仓库之上的(如数据分析引擎、数据挖掘引擎、推荐引擎、可视化引擎等等)。不少员工认为,开发成本应更多集中在数据仓库层,不断加大数据建设的投入。因为一旦规范、标准、高性能的数据仓库建立好了,在之上进行数据分析、数据挖掘、跑推荐算法等都是轻松惬意的事情。反之如果业务数据没梳理好,各种脏乱数据会搞得人焦头烂额,苦不堪言。

    自己开发ETL程序与选择ETL工具利弊

    ETL工作看起来并不复杂,特别是在数据量小、没有什么转换逻辑的时候,自己开发似乎非常节省成本。的确,主流的ETL工具价格不菲,动辄几十万;而从头开发无非就是费点人力而已,可以控制。至于性能,人大多是相信自己的,认为自己开发出来的东西知根知底,至少这些程序可以完全由自己控制。就目前自主开发的ETL程序而言,有人用c语言编写,有人用存储过程,还有人用各种语言混杂开发,程序之间各自独立。这很危险,虽然能够让开发者过足编码的瘾,却根本不存在架构。举例:有位银行的朋友,他们几年前上的数据仓库系统,就是集成商自己用c语言专门为他们的项目开发的。单从性能上看似乎还不赖,然而一两年下来,项目组成员风雨飘零,早已物是人非,只有那套程序还在那里;而且,按照国内目前的软件工程惯例,程序注释和文档是不全或者是不一致的,这样的程序已经对日常业务造成很大阻碍。最近,他们已经开始考虑使用ETL工具重新改造了。

    总结:
    较之数据库系统开发,数据仓库开发只多出ETL工程部分。然而这一部分极有可能是整个数据仓库开发流程中最为耗时耗资源的一个环节。因为该环节要整理各大业务系统中杂乱无章的数据并协调元数据上的差别,所以工作量很大。在很多公司都专门设有ETL工程师这样的岗位,大的公司甚至专门聘请ETL专家。

    数据库与数据仓库

    1、联系    
    数据仓库的出现,并不是要取代数据库。大部分数据仓库还是用关系数据库管理系统来管理的。    
    可以说,数据库、数据仓库相辅相成、各有千秋数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的(Integrate)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策。数据仓库系统的主要应用主要是OLAP(On-Line Analytical Processing),支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。数据仓库的方案建设的目的,是为前端查询和分析作为基础,由于有较大的冗余,所以需要的存储也较大。为了更好地为前端应用服务,数据仓库必须有如下几点优点,否则是失败的数据仓库方案:①效率足够高②数据质量③扩展性    
    ①面向主题:指数据仓库中的数据是按照一定的主题域进行组织。    
    ②集成:指对原有分散的数据库数据经过系统加工, 整理得到的消除源数据中的不一致性。    
    ③相对稳定:指一旦某个数据进入数据仓库以后只需要定期的加载、刷新。    
    ④反映历史变化:指通过这些信息,对企业的发展历程和未来趋势做出定量分析预测。    
    拿电商举例:    
    从只需要业务数据库到要数据仓库的阶段。电商早期启动非常容易,入行门槛低。找个外包团队,做了一个可以下单的网页前端+几台服务器+一个MySQL,就能开门迎客了。这好比手工作坊时期。    
    第二阶段,流量来了,客户和订单都多起来了,普通查询已经有压力了,这个时候就需要升级架构变成多台服务器和多个业务数据库(量大+分库分表),这个阶段的业务数字和指标还可以勉强从业务数据库里查询。初步进入工业化。    
    第三个阶段,一般需要3-5年左右的时间,随着业务指数级的增长,数据量的会陡增,公司角色也开始多了起来,开始有了 CEO、CMO、CIO,大家需要面临的问题越来越复杂,越来越深入。高管们关心的问题,从最初非常粗放的:“昨天的收入是多少”、“上个月的 PV、UV 是多少”,逐渐演化到非常精细化和具体的用户的集群分析,特定用户在某种使用场景中,例如“20~30岁女性用户在过去五年的第一季度化妆品类商品的购买行为与公司进行的促销活动方案之间的关系”。这类非常具体,且能够对公司决策起到关键性作用的问题,基本很难从业务数据库从调取出来。    
    原因在于:业务数据库中的数据结构是为了完成交易而设计的,不是为了查询和分析的便利设计的。业务数据库大多是读写优化的,即又要读(查看商品信息),也要写(产生订单,完成支付)。因此对于大量数据的读(查询指标,一般是复杂的只读类型查询)是支持不足的。而怎么解决这个问题,此时我们就需要建立一个数据仓库了,公司也算开始进入信息化阶段了。数据仓库的作用在于:数据结构为了分析和查询的便利;只读优化的数据库,即不需要它写入速度多么快,只要做大量数据的复杂查询的速度足够快就行了。那么在这里前一种业务数据库(读写都优化)的是业务性数据库,后一种是分析性数据库,即数据仓库。

    2、区别
    ①出发点不同:数据库是面向事务的设计;数据仓库是面向主题设计的
    ②数据库一般存储在线交易数据,数据仓库存储的一般是历史数据
    ③设计规则不同:数据库设计是尽量避免冗余,一般采用符合范式的规则来设计;数据仓库在设计是有意引入冗余,采用反范式的方式来设计
    ④提供的功能不同:数据库是为捕获数据而设计,数据仓库是为分析数据而设计
    ⑤基本元素不同:数据库的基本元素是事实表,数据仓库的基本元素是维度表
    ⑥容量不同:数据库在基本容量上要比数据仓库小的多
    ⑦服务对象不同:数据库是为了高效的事务处理而设计的,服务对象为企业业务处理方面的工作人员;数据仓库是为了分析数据进行决策而设计的,服务对象为企业高层决策人员

    差异项 数据库 数据仓库
    特征  操作处理   信息处理  
    面向  事务   分析  
    用户  DBA、开发   经理、主管、分析人员  
    功能  日常操作   长期信息需求、决策支持  
    DB设计  基于ER模型,面向应用   星形/雪花模型,面向主题  
    数据  当前的、最新的   历史的、跨时间维护  
    汇总  原始的、高度详细   汇总的、统一的  
    视图  详细、一般关系   汇总的、多维的  
    工作单元  短的、简单事务   复杂查询  
    访问  读/写   大多为读  
    关注  数据进入   信息输出  
    操作  主键索引操作   大量的磁盘扫描  
    用户数  数百到数亿   数百  
    DB规模  GB到TB   >=TB  
    优先  高性能、高可用性   高灵活性  
    度量  事务吞吐量   查询吞吐量、响应时间  

     从另一个角度,分析数据库与数据仓库区别:

    从数据组成来讲
    a.数据时间范围差别:    
    一般来讲,操作型数据库只会存放90天以内的数据,而分析型数据库存放的则是数年内的数据。这点也是将操作型数据和分析型数据进行物理分离的主要原因。    
    b.数据细节层次差别:    
    操作型数据库存放的主要是细节数据,而分析型数据库中虽然既有细节数据,又有汇总数据,但对于用户来说,重点关注的是汇总数据部分。操作型数据库中自然也有汇总需求,但汇总数据本身不存储而只存储其生成公式。这是因为操作型数据是动态变化的,因此汇总数据会在每次查询时动态生成。而对于分析型数据库来说,因为汇总数据比较稳定不会发生改变,而且其计算量也比较大(因为时间跨度大),因此它的汇总数据可考虑事先计算好,以避免重复计算。    
    c.数据时间表示差别    
    操作型数据通常反映的是现实世界的当前状态;而分析型数据库既有当前状态,还有过去各时刻的快照,分析型数据库的使用者可以综合所有快照对各个历史阶段进行统计分析。

    从技术差别来讲

    a.查询数据总量和查询频度差别:
    操作型查询的数据量少而频率多,分析型查询则反过来,数据量大而频率少。要想同时实现这两种情况的配置优化是不可能的,这也是将两类数据库物理分隔的原因之一。
    b.数据更新差别:
    操作型数据库允许用户进行增,删,改,查;分析型数据库用户则只能进行查询。
    c.数据冗余差别
    数据的意义是什么?就是减少数据冗余,避免更新异常。而如"数据更新差别"所诉,分析型数据库中没有更新操作。因此,减少数据冗余也就没那么重要了。
    例如:Hive是一种数据仓库,而数据仓库和分析型数据库的关系非常紧密。它只提供查询接口,不提供更新接口,这就使得消除冗余的诸多措施不需要被特别严格地执行了,可保留冗余。

    从功能差别来讲

    a.数据读者差别
    操作型数据库的使用者是业务环境内的各个角色,如用户,商家,进货商等;分析型数据库则只被少量用户用来做综合性决策。多数为领导层提供服务。
    b.数据定位差别
    这里说的定位,主要是指以何种目的组织起来。操作型数据库是为了支撑具体业务的,因此也被称为"面向应用型数据库";分析型数据库则是针对各特定业务主题域的分析任务创建的,因此也被称为"面向主题型数据库"。

    展开全文
  • 关于数据仓库,早期分享过不少基础类文章,偶然间看到知乎上这篇关于OLAP的深度解读,从技术发展,产品选型,执行优化等方面做了详细的剖析,分享来给大家看看! 一、有哪些类型的OLAP数仓? 1、按数据量划分 对...
  • 数据仓库面试题

    万次阅读 多人点赞 2020-07-20 12:49:16
    文章目录数据仓库的定义?数据仓库和数据库的区别?如何构建数据仓库?什么是数据中台?数据中台、数据仓库、大数据平台的关键区别是什么?基础能力上的区别业务能力上的区别大数据的一些相关系统?如何建设数据中台...
  • SQL性能优化应该考虑哪些

    千次阅读 2015-03-05 22:19:47
    这一部分在开发信息系统之前完成,程序员需要考虑是否使用ORACLE数据库的分区功能,对于经常访问的数据库表是否需要建立索引等。 2、调整应用程序结构设计。这一部分也是在开发信息系统之前完成,程序员在这一步...
  • 数据仓库常见建模方法与建模实例演示

    万次阅读 多人点赞 2020-04-14 15:52:09
    一般主要从下面四点考虑 访问性能:能够快速查询所需的数据,减少数据I/O 数据成本:减少不必要的数据冗余,实现计算结果数据复用,降低大数 据系统中的存储成本和计算成本 使用效率:改善用户应用体验,提高使用...
  • 如何搭建数据仓库

    千次阅读 2020-12-10 10:31:30
    其实很多企业做数据仓库的时候,都忽略了数仓与BI、数据库的差异,只去搞底层数据,不去做数据服务和应用,其实就是把数据仓库给狭义化了。其实数据仓库可以看成是BI的基础版本、数据库的升级版本,我们可以把公司里...
  • 数据仓库多维数据模型设计

    万次阅读 多人点赞 2017-11-09 18:14:59
    建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分,那么,怎么建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍如何创建适合自己的数据模型。 数据仓库建模方法 大千世界,...
  • 数据仓库常用几种建模方法

    千次阅读 2020-12-04 08:40:00
    本文主要的主线就是回答下面三个问题:什么是数据模型 为什么需要数据模型 如何建设数据模型 最后,我们在本文的结尾给大家介绍了一个具体的数据仓库建模的样例,帮助大家来了解整个数据建模的过程...
  • 将 svn 仓库迁移到 git 仓库

    千次阅读 2019-03-04 08:13:01
    我找到了一个很久很久以前编写的项目,然而当时是使用 svn 进行版本管理的。...本文内容找回 svn 仓库的 url将 svn 仓库迁移到 git 仓库命令行TortoiseGit参考资料 找回 svn 仓库的 url 如果你能记得...
  • 浅析数据仓库与OLAP

    千次阅读 2020-10-24 11:51:08
    文章向导数据仓库1.什么是数据仓库?(1)面向主题的(2)集成的(3)相对稳定的(4)反映历史变化2.数据仓库架构(1)DB (Database 缩写)(2) ETL (抽取(extract)、转换(transform)、加载(load))(3) ODS ...
  • 数据仓库建设

    万次阅读 2018-07-18 23:31:52
    1.数据仓库概要 1.1.数据仓库起因  在建设数据仓库之前,数据散落在企业各部门应用的数据存储中,它们之间有着复杂的业务连接关系,从整体上看就如一张巨大的蜘蛛网:结构上错综复杂,却又四通八达。在企业级数据...
  • 如果选择使用数据仓库,企业需要考虑如何更好地保护内部信息系统。任何数仓安全方面的妥协都会给入侵者或网络罪犯以可乘之机,造成销售、营销、客户信息等业务数据的毁坏泄露。今年爆发的WannaCry勒索软件事件也表明...
  • Maven在某个统一的位置存储所有项目的共享的构件,这个统一的位置,我们就称之为仓库。(仓库就是存放依赖和插件的地方) 任何的构件都有唯一的坐标,Maven根据这个坐标定义了构件在仓库中的唯一存储路径, ...
  • 在具体学习数据仓库之前先看一下数据中心的整体构架以及数据流向。 DB 是现有的数据来源,可以为mysql、SQLserver、文件日志等,为数据仓库提供数据来源的一般存在于现有的业务系统之中。 ETL 是 Extract-...
  • 第十一章数据仓库和商务智能

    千次阅读 2021-12-06 11:20:29
    与数据仓库一起创建元数据 协同 不要千篇一律 业务驱动因素 运营支持智能 合规需求 商务智能活动 输入 业务需求 可扩展性、运营、基础设施和支持的要求 数据质量、安全及访问需求 IT策略 ..
  • 数据仓库选择

    千次阅读 2010-03-11 22:01:00
    author:skatetime:2010-03-11 数据仓库选择 数据仓库选择单从技术方面要从服务器硬件,数据库软件,ETL和前端展示软件,存储系统,仓库的架构设计几方面综合考虑。根据数据库的操作类型不同,数据库一般分为...
  • 问题导读:1、数据仓库的总体架构是怎样的? 2、如何进行数据采集? 3、数据是如何进行加工和处理的?1.1 数据仓库总体架构专家系统接收增购项目车辆TCMS或其他子系统通过车地通信传输的实时或离线数据,经过一系列...
  • 由于企业级数据仓库的设计、实施很困难,使得最早吃数据仓库螃蟹的公司遭到大面积的失败,因此数据仓库的建设者和分析师开始考虑只建设企业级数据仓库的一部分,然后再逐步添加,但是这有背于BillInmon的原则:各个...
  • 数据仓库架构(内含PPT)

    千次阅读 多人点赞 2020-11-18 07:00:00
    大数据篇:一文读懂@数据仓库1 网络词汇总结1.1 数据中台数据中台是聚合和治理跨域数据,将数据抽象封装成服务,提供给前台以业务价值的逻辑概念。数据中台是一套可持续“让企业的数据用起来”...
  • 目前搭建数据仓库的基本都是采用Oracle、mpp、hadoop这三种方案比较多,mpp数据库主要有teradata和greenplum。hadoop其实是一个体系,严格意义上不能说是数据仓库。 主要从以下多个方面对此进行区别。 1、架构: ...
  • 昨天 Github 迎来了2019年的第一次更新,官方宣布了量大重要特性:个人可以免费创建私有仓库了,并且数量无限制,不过有一个限制就是,免费的私有仓库同时最多只能有三个...
  • 数据仓库维度建模建设步骤

    千次阅读 2020-08-04 22:22:45
    一、数据仓库的架构 数据仓库(Data Warehouse DW)是为了便于多维分析和多角度展现而将数据按特定的模式进行存储所建立起来的关系型数据库,它的数据基于OLTP源系统。数据仓库中的数据是细节的、集成的、面向主题...
  • 数据仓库常见建模方法与大数据领域建模实例综述

    千次阅读 多人点赞 2021-05-01 14:01:51
    为什么需要数据建模? 为什么要进行数据仓库建模? 随着DT时代互联网、智能设备等信息技术的发展,数据开始井喷式的增长,如何讲这些数据进行有序、有结构地分类组织存储是我们面临的一个挑战。 如果把数据看作图书...
  • 数据仓库规范

    千次阅读 2018-06-21 09:41:25
    数据仓库层次结构规范1.1 基本分层结构系统的信息模型从存储的内容方面可以分为,STAGE接口信息模型、ODS/DWD信息模型,MID信息模型、DM信息模型、元数据信息模型。在各个信息模型中存储的内容如下描述: 1) SRC...
  • 数据仓库架构和建设方法

    千次阅读 2019-04-18 10:32:29
    1.数据仓库概要 1.1.数据仓库起因      在建设数据仓库之前,数据散落在企业各部门应用的数据存储中,它们之间有着复杂的业务连接关系,从整体上看就如一张巨大的蜘蛛网:结构上错综复杂,却又...
  • 数据仓库ER建模

    千次阅读 2020-03-04 10:57:49
    数据仓库之父Bill Inmon提出的数据仓库建模方法是自上而下的,从全企业的高度设计一个符合3NF的数据模型,用实体联系(Entity Relationship,ER)模型描述企业的业务。 二、建模步骤: 数据仓库的建模步骤分为...
  • Docker私有镜像仓库是什么?

    千次阅读 2020-08-07 10:46:49
    Docker镜像仓库概述镜像仓库作为Docker技术的核心组件之一,其主要作用就是负责镜像内容的存储和分发。Docker镜像仓库从使用范围来说分为“公有镜像仓库”和“私有镜像仓库”,公有...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 81,867
精华内容 32,746
关键字:

仓库选择需要考虑哪些