大数据作为国家近年来支持的一项重要项目，许多相关企业围绕大数据的商业价值利用进行了数据仓库、数据安全、数据分析、数据挖掘等大数据分析项目开发，逐渐成为业界人士追求的利润焦点，但大数据分析往往容易出现各种问题，导致分析结果不准确，导致项目开发失败。下面我们就一起来了解一下，影响大数据技术发展的因素都有哪些。
 
 
 
 
　　影响大数据发展的因素：
 
 
 
　　1.中小企业如何在大数据和算法决策时代开展竞争
 
 
 
　　没有互联网巨头或全球快速消费品公司的海量数据集的中小公司如何能够在大数据和算法决策时代开展竞争。大公司利用网络服务的网络效应巩固其地位，这对于良性创新圈是一个风险，或许人们已经看到了这种风险。
 
 
 
　　2.开放数据需要像开源软件一样认真对待
 
 
 
　　众所周知，开源软件背后是大数据和机器学习产品和服务的兴起。开放源码的商业和技术案例的重要性多年前就得到了证实。然而，人们对开放数据对创新的重要性的关注却少之又少。
 
 
 
　　全球大的开放式公司数据库提供商OpenCorporations公司联合创始人兼席执行官ChrisTaggart强调了企业在依赖专有数据集时遇到的问题，指出这些数据源可能是粗略的，并且元数据不会在产品间共享。开放数据更透明，不会将企业锁定在昂贵的商业合同中，而这些合同对于企业来说很难放弃。
 
 
 
　　3.捕获和管理实时数据的重要性
 
 
 
　　虽然人工智能和机器学习项目并不总是需要实时或接近实时的数据，但构建能够处理数据的系统的能力可能是一种具有价值的竞争优势形式。随着数据驱动的决策越来越多地嵌入到组织中，竞争优势有时会转移到那些能够对事件作出更快响应的组织中。亚马逊网络服务在这方面的规模和广度表明，实现这一点的工具变得越来越容易和便宜。
 
 
 
　　4.法律和道德问题开始改变企业的创新方式
 
 
 
　　牛津大学SandraWachter博士在会上的演讲强调了一个问题，而在未来一两年内，这个问题可能会得到更多讨论。她指出，许多公司现在意识到他们有义务保护个人数据，因为GDPR法规等相关法律已经生效。然而，一个讨论较少的问题也是监管机构仍在努力解决的问题是，推理以及由嵌入式算法需要根据其处理的数据做出的决定。
 
 
 
　　至少在欧洲，用户有权查看持有的数据，并在不同程度上纠正或删除。但是，由于信用检查和健康保险等领域的数据，企业可能会自动对用户做出假设，因此用户没有相同的补救措施。
 
 
 
　　大数据如浪潮般席卷全球。越来越多的国家开始从战略层面认识大数据，然而任何发展都不应盲目跟从，而应该在发展中不断认识其发展的意义与遇到的困难挑战，要做到及时发现总结，才能更好的发展。

数据库与数据仓库的区别
 
简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。 
 
数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。 
 
数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。 
 
数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。 
 
单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。 
 
显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。 
 
数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。 
 
“面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。 
 
“与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。 
 
“不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此，数据仓库中的数据是极少或根本不修改的;当然，向数据仓库添加数据是允许的。 
 
数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。 
 
补充一下，数据仓库的方案建设的目的，是为前端查询和分析作为基础，由于有较大的冗余，所以需要的存储也较大。为了更好地为前端应用服务，数据仓库必须有如下几点优点，否则是失败的数据仓库方案。 
 
1.效率足够高。客户要求的分析数据一般分为日、周、月、季、年等，可以看出，日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，设计不好的数据仓库经常会出问题，延迟1-3日才能给出数据，显然不行的。 
 
2.数据质量。客户要看各种信息，肯定要准确的数据，但由于数据仓库流程至少分为3步，2次ETL，复杂的架构会更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据失真，客户看到错误的信息就可能导致分析出错误的决策，造成损失，而不是效益。 
 
3.扩展性。之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，这样的话，客户不用太快花钱去重建数据仓库系统，就能很稳定运行。主要体现在数据建模的合理性，数据仓库方案中多出一些中间层，使海量数据流有足够的缓冲，不至于数据量大很多，就运行不起来了。
 
数据仓库组成
 
数据处理平台：接口+工具
 
ETL是数据抽取（Extract）、清洗（Cleaning）、转换（Transform）、装载（Load）的过程。是构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗,最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。
 
3.5.1 数据源分析 
 数据源是数据仓库系统所有信息的源头，主要是操作型业务应用系统存放的数据集合。数据源分析是指对业务数据源中的原始数据进行分析，得到数据的范围、格式，以及其更新方式、更新频率、质量等方面的信息。商业智能系统本身就是一个数据分析的系统，对数据源的分析是开启商业智能项目大门的过程，数据仓库系统需要支持多种数据源格式，为了确定抽取方式，需要对数据源进行详细的分析。 
 在分析的过程中，需要确定业务源数据中哪些数据需要被抽取。为了确定合适的抽取方式，需要在抽取之前对数据源进行分析，分析的范围一般包括数据的格式、数据的范围、更新的方式、数据质量的好坏。在分析的过程中，应该尽可能获取分析的结果，形成数据源分析报告，在仔细研究分析报告后，再选择合适的抽取、加载方式。 
 在分析时，应该抛弃实际的应用系统，在逻辑上重新确定目标表中需要哪些业务数据，然后再根据业务系统的实现方式，分析业务源数据的存储格式、更新频率、更新方式和数据质量。 
 可以得出这样的结论：所谓数据源分析，就是对源数据进行分析和总结，得出源数据的范围、格式、更新方式、更新频率和质量好坏的过程。 
 数据源分析的过程分为范围分析、格式分析、更新方式分析、质量分析4个方面，如图3-13所示。 
  
 1）范围分析是指分析数据的范围。用户需要确定数据仓库系统需要数据源中的哪些原始数据。例如，在某电力行业的销售电量分析主题中，所有的数据均来自某管理信息系统，由此可以确定，这个销售电量分析主题的数据源都来自该管理信息系统，可能是与这个管理系统中的客户相关的数据，或者与电量相关的数据。而与财务数据或用户欠费相关的业务数据不相关。 
 2）格式分析是指对原始数据在数据库中的物理存储方式进行分析。内容包括在数据库中的存储类型、存储长度、数据精度等指标。 
 3）更新方式分析是指对原始数据在应用系统中的更新方式、更新频率、更新内容进行分析判断。内容包括原始数据何时更新、更新方式、具体更新哪些内容等。例如，在某销售电量主题分析中，需要考虑用户的抄表数据和电量数据，一般都是每月增量更新的，而用户的档案信息也有可能进行更新，用户的欠费信息也随着用户的缴费行为而随时发生相应的变化。 
 4）质量分析是指分析业务源数据的质量。主要分析数据完整性、数据准确性、数据一致性等内容。一般步骤包括：设计数据质量定义文档，内容包括数据质量验收的依据，数据质量等级的划分，数据质量检查的流程等内容；再根据数据质量定义文档进行数据质量检查，最终形成质量报告；根据数据质量报告进行深入分析，将分析结果提交给相关人员，协助设计人员完成数据清洗规则的制定。通常，质量分析是数据源分析中最重要、工作量最多的部分。 
 总结：除以上所述的对数据源进行分析外，还需要对各项指标数据的确切含义，统计口径等信息进行明确的界定，以避免产生二义性。例如，在销售电量主题分析中，需要明确销售电量的确切含义，是否包含线损电量、变损电量等。
 
元数据; 
 什么是元数据 
 任何文件系统中的数据分为数据和元数据。数据是指普通文件中的实际数据，而元数据指用来描述一个文件的特征的系统数据，诸如访问权限、文件拥有者以及文件\数据块的分布信息(inode…)等等。在集群文件系统中，分布信息包括文件在磁盘上的位置以及磁盘在集群中的位置。用户需要操作一个文件必须首先得到它的元数据，才能定位到文件的位置并且得到文件的内容或相关属性。
 
元数据管理方式 
 元数据管理有两种方式。集中式管理和分布式管理。集中式管理是指在系统中有一个节点专门司职元数据管理，所有元数据都存储在该节点的存储设备上。所有客户端对文件的请求前，都要先对该元数据管理器请求元数据。分布式管理是指将元数据存放在系统的任意节点并且能动态的迁移。对元数据管理的职责也分布到各个不同的节点上。大多数集群文件系统都采用集中式的元数据管理。因为集中式管理实现简单，一致性维护容易，在一定的操作频繁度内可以提供较满意的性能。缺点是单一失效点问题，若该服务器失效，整个系统将无法正常工作。而且，当对元数据的操作过于频繁时，集中的元数据管理成为整个系统的性能瓶颈。 
 分布式元数据管理的好处是解决了集中式管理的单一失效点问题， 而且性能不会随着操作频繁而出现瓶颈。其缺点是，实现复杂，一致性维护复杂，对性能有一定影响。 
 一、基本概念
 
数据仓库一词尚没有一个统一的定义,著名的数据仓库专家W. H. Inmon 在其著作《Buildingthe Data Warehouse》一书中给予如下描述:数据仓库(Data Warehouse) 是一个面向主题的(SubjectOri2ented) 、集成的( Integrate ) 、相对稳定的(Non -Volatile ) 、反映历史变化( TimeVariant) 的数据集合用于支持管理决策。对于数据仓库的概念我们可以从两个层次予以理解,首先,数据仓库用于支持决策,面向分析型数据处理,它不同于企业现有的操作型数据库;其次,数据仓库是对多个异构的数据源有效集成,集成后按照主题进行了重组,并包含历史数据,而且存放在数据仓库中的数据一般不再修改。
 
为最大限度地实现灵活性，集成的数据仓库的数据应该存储在标准RDBMS 中，并经过规范的数据库设计，以及为了提高性能而增加一些小结性信息和不规范设计。这种类型的数据仓库设计被称为原子数据仓库。原子数据仓库的子集,又称为数据集市。原子仓库存在的主要目的是作为数据集市的工作基础，同时也作为参照性数据仓库。原子仓库的大小、集中存放和数据库设计可能无法满足特殊类型用户的各种需求。其子集,即各个数据集市被拷贝到其它计算机上,可作为它们自己的数据仓库。数据集市可以和产生它们的原子数据仓库一样大,甚至更大。它们可以位于原子数据仓库的附近，或分布到更靠近用户的位置，放置在何处取决于使用和通讯成本。数据集市是用来满足特殊用户的应用需求的数据仓库，它们的规模可能达到数百GB。使其成为数据集市的关键是它的使用目标、范围，而非规模大小。 
 数据集市可以理解为是一个小型的部门或者工作组级别的数据仓库。有两种类型的数据集市（如下图）：
 
独立型（直接从操作型环境中获取数据）：这些数据集市是由特定的工作组、部门或业务线进行控制的，完全是为满足其需求而构建的。实际上，它们甚至与其他工作组、部门或业务线中的数据集市没有任何连通性 
 从属型（从企业级数据仓库中获取数据）：这样的数据集市往往以分布式的方式实现。虽然不同的数据集市是在特定的工作组、部门或生产线中实现的，但它们可以是集成、互连的，以提供更加全局的业务范围的数据视图。实际上，在最高的集成层次上，它们可以成为业务范围的数据仓库。这意味着一个部门中的终端用户可以访问和使用另一部门中数据集市中的数据
 
二、为什么提出数据集市
 
虽然 OLTP 和遗留系统拥有宝贵的信息，但是可能难以从这些系统中提取有意义的信息并且速度也较慢。而且这些系统虽然一般可支持预先定义操作的报表，但却经常无法支持一个组织对于历史的、联合的、智能的或易于访问的信息的需求。因为数据分布在许多跨系统和平台的表中，而且通常是“脏的”，包含了不一致的和无效的值，使得难于分析。
 
数据集市将合并不同系统的数据源来满足业务信息需求。若能有效地得以实现，数据集市将可以快速且方便地访问简单信息以及系统的和历史的视图。一个设计良好的数据集市有如下特点（有些特点数据仓库也具有，有些特点是相对于数据仓库来讲的）： 
 (1) 特定用户群体所需的信息，通常是一个部门或者一个特定组织的用户，且无需受制于源系统的大量需求和操作性危机（想对于数据仓库）。 
 (2) 支持访问非易变（nonvolatile）的业务信息。（非易变的信息是以预定的时间间隔进行更新的，并且不受 OLTP 系统进行中的更新的影响。） 
 (3) 调和来自于组织里多个运行系统的信息，比如账目、销售、库存和客户管理以及组织外部的行业数据。 
 (4) 通过默认有效值、使各系统的值保持一致以及添加描述以使隐含代码有意义，从而提供净化的（cleansed）数据。 
 (5) 为即席分析和预定义报表提供合理的查询响应时间（由于数据集市是部门级的，相对于庞大的数据仓库来讲，其查询和分析的响应时间会大大缩短）。
 
三、数据仓库设计方法论
 
在数据仓库建立之前，会考虑其实现方法，通常有自顶向下、自底向上和两者综合进行的这样三种实现方案，下面分别对其做简要阐述：
 
(1)自顶向下的实现 
 自顶向下的方法就是在单个项目阶段中实现数据仓库。自顶向下的实现需要在项目开始时完成更多计划和设计工作。这就需要涉及参与数据仓库实现的每个工作组、部门或业务线中的人员。要使用的数据源、安全性、数据结构、数据质量、数据标准和整个数据模型的有关决策一般需要在真正的实现开始之前就完成。
 
(2)自底向上的实现 
 自底向上的实现包含数据仓库的计划和设计，无需等待安置好更大业务范围的数据仓库设计。这并不意味着不会开发更大业务范围的数据仓库设计；随着初始数据仓库实现的扩展，将逐渐增加对它的构建。现在，该方法得到了比自顶向下方法更广泛的接受，因为数据仓库的直接结果可以实现，并可以用作扩展更大业务范围实现的证明。
 
(3)一种折中方案 
 每种实现方法都有利弊。在许多情况下，最好的方法可能是某两种的组合。该方法的关键之一就是确定业务范围的架构需要用于支持集成的计划和设计的程度，因为数据仓库是用自底向上的方法进行构建。在使用自底向上或阶段性数据仓库项目模型来构建业务范围架构中的一系列数据集市时，您可以一个接一个地集成不同业务主题领域中的数据集市，从而形成设计良好的业务数据仓库。这样的方法可以极好地适用于业务。在这种方法中，可以把数据集市理解为整个数据仓库系统的逻辑子集，换句话说数据仓库就是一致化了的数据集市的集合。这种方案的实施步骤通常分如下几步： 
 (6) 从整个企业的角度定义计划和需求 
 (7) 构建完整的仓库体系结构 
 (8) 使数据内容一致而且标准化 
 (9) 将数据仓库作为一种超级数据集市来实施
 
关于Inmon 和 Kimball的大辩论： 
 Ralph Kimball 和 Bill Inmon 一直是商业智能领域中的革新者，开发并测试了新的技术和体系结构。 
 Bill Inmon 将数据仓库定义为“一个面向主题的、集成的、随时间变化的、非易变的用于支持管理的决策过程的数据集合”；他通过“面向主题”表示应该围绕主题来组织数据仓库中的数据，例如客户、销售、产品等等。每个主题区域仅仅包含该主题相关的信息。数据仓库应该一次增加一个主题，并且当需要容易地访问多个主题时，应该创建以数据仓库为来源的数据集市。换言之，某个特定数据集市中的所有数据都应该来自于面向主题的数据存储。 Inmon 的方法包含了更多上述工作而减少了对于信息的初始访问。但他认为这个集中式的体系结构持续下去将提供更强的一致性和灵活性，并且从长远来看将真正节省资源和工作。下图是他的设计方法图解：
 
Ralph Kimball 说“数据仓库仅仅是构成它的数据集市的联合”，他认为“可以通过一系列维数相同的数据集市递增地构建数据仓库”。每个数据集市将联合多个数据源来满足特定的业务需求。通过使用“一致的”维，能够共同看到不同数据集市中的信息，这表示它们拥有公共定义的元素。设计方法如下图：
 
Kimball 的方法将提供集成的数据来回答组织迫切的业务问题并且要快于 Inmon 的方法。Inmon 的方法是只有在构建几个单主题区域之后，集中式的数据仓库才创建数据集市。而 Kimball 认为该方法缺乏灵活性并且在现在的商业环境中所花时间太长。 
 实际上，方法的选择取决于项目的主要商业驱动。如果该组织正忍受糟糕的数据管理和不一致的数据，或者希望为今后打下良好的基础，那么 Inmon 的方法就更好一些。 如果该组织迫切需要给用户提供信息，那么 Kimball 的方法将满足该需求。而一旦满足了迫切的信息需求后，就应该考虑包含独立数据仓库的数据体系结构的转换计划。数据仓库将使数据集市与遗留系统和 OLTP 系统隔离，并且支持更快地创建将来的数据集市。由于数据仓库在整个发展中一直承担了重任，所以它将支持极力关注数据集市。实际上基于商业驱动的需要，采用上面三种设计方案中的最后一种方法：自顶向下和自底向上综合的方案会很好的适应数据仓库建立过程中的不同需求。
 
四、数据仓库与数据集市的区别
 
数据仓库是企业级的，能为整个企业各个部门的运行提供决策支持手段；而数据集市则是一种微型的数据仓库,它通常有更少的数据,更少的主题区域,以及更少的历史数据,因此是部门级的，一般只能为某个局部范围内的管理人员服务，因此也称之为部门级数据仓库。数据仓库和数据集市之间的区别如下图：
 
数据仓库和数据集市的区别可从如下三个方面进行理解： 
 （1） 数据仓库向各个数据集市提供数据 
 （2） 几个部门的数据集市组成一个数据仓库
 
（3） 下面从其数据内容特征进行分析，数据仓库中数据结构采用规范化模式，数据集市中的数据结构采用星型模式，通常仓库中数据粒度比集市的粒度要细，下图反映了数据结构和数据内容特征的区别
 
星形模型PK雪花形模型:
 
一、概述 
 在多维分析的商业智能解决方案中，根据事实表和维度表的关系，又可将常见的模型分为星型模型和雪花型模型。在设计逻辑型数据的模型的时候，就应考虑数据是按照星型模型还是雪花型模型进行组织。 
 当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故将该模型称为星型模型，如图 1 。 
 星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余，如在地域维度表中，存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余。 
 图1. 销售数据仓库中的星型模型 
 当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 ” 层次 ” 区域，这些被分解的表都连接到主维度表而不是事实表。如图 2，将地域维表又分解为国家，省份，城市等维表。它的优点是 : 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。 
  
 星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。星型结构不用考虑很多正规化的因素，设计与实现都比较简单。雪花型模型由于去除了冗余，有些统计就需要通过表的联接才能产生，所以效率不一定有星型模型高。正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的 ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率。 
 二、使用选择 
 星形模型(Star Schema)和雪花模型(Snowflake Schema)是数据仓库中常用到的两种方式，而它们之间的对比要从四个角度来进行讨论。 
 　　1.数据优化 
 雪花模型使用的是规范化数据，也就是说数据在数据库内部是组织好的，以便消除冗余，因此它能够有效地减少数据量。通过引用完整性，其业务层级和维度都将存储在数据模型之中。 
  
 相比较而言，星形模型实用的是反规范化数据。在星形模型中，维度直接指的是事实表，业务层级不会通过维度之间的参照完整性来部署。 
  
 　2.业务模型 
 主键是一个单独的唯一键(数据属性)，为特殊数据所选择。在上面的例子中，Advertiser_ID就将是一个主键。外键(参考属性)仅仅是一个表中的字段，用来匹配其他维度表中的主键。在我们所引用的例子中，Advertiser_ID将是Account_dimension的一个外键。 
 在雪花模型中，数据模型的业务层级是由一个不同维度表主键-外键的关系来代表的。而在星形模型中，所有必要的维度表在事实表中都只拥有外键。 
 　　3.性能 
 第三个区别在于性能的不同。雪花模型在维度表、事实表之间的连接很多，因此性能方面会比较低。举个例子，如果你想要知道Advertiser 的详细信息，雪花模型就会请求许多信息，比如Advertiser Name、ID以及那些广告主和客户表的地址需要连接起来，然后再与事实表连接。 
 而星形模型的连接就少的多，在这个模型中，如果你需要上述信息，你只要将Advertiser的维度表和事实表连接即可。 
 　　4.ETL 
 雪花模型加载数据集市，因此ETL操作在设计上更加复杂，而且由于附属模型的限制，不能并行化。 
 星形模型加载维度表，不需要再维度之间添加附属模型，因此ETL就相对简单，而且可以实现高度的并行化。 
 　　总结 
 雪花模型使得维度分析更加容易，比如“针对特定的广告主，有哪些客户或者公司是在线的?”星形模型用来做指标分析更适合，比如“给定的一个客户他们的收入是多少?”

数据仓库（以Hive为例）和数据库比较
 
Hive是一个翻译工具，将sql翻译为底层mr程序的，它不是数据库，只不过在表现形式上和数据库有很多类似而已（比如表、database、字段等）
 数据库可以用在 Online（在线） 的应用中，但是Hive 是为数据仓库而设计的
 数据库可以增删查改，数据仓库只可以增删查
 数据仓库支持很大规模的数据；数据库支持的数据规模较小
 数据仓库没有索引，数据库有
 数据仓库可扩展性强，数据库弱
 
具体有以下几点：
 
数据存储位置
 
Hive 是建立在 Hadoop 之上的，所有 Hive 的数据都是存储在 HDFS 中的。而数据库则可以将数据保存在块设备或者本地文件系统中。
 
数据更新
 
由于Hive是针对数据仓库应用设计的，而数据仓库的内容是读多写少的。因此，Hive中不建议对数据的改写，所有的数据都是在加载的时候确定好的。而数据库中的数据通常是需要经常进行修改的。
 
索引
 
hive没有索引
 Hive在加载数据的过程中不会对数据进行任何处理，甚至不会对数据进行扫描，因此也没有对数据中的某些Key建立索引。Hive要访问数据中满足条件的特定值时，需要暴力扫描整个数据，因此访问延迟较高。由于 MapReduce 的引入， Hive 可以并行访问数据，因此即使没有索引，对于大数据量的访问，Hive 仍然可以体现出优势。数据库中，通常会针对一个或者几个列建立索引，因此对于少量的特定条件的数据的访问，数据库可以有很高的效率，较低的延迟。由于数据的访问延迟较高，决定了 Hive 不适合在线数据查询。
 
执行
 
Hive中大多数查询的执行是通过 Hadoop 提供的 MapReduce 来实现的。而数据库通常有自己的执行引擎。innoDb引擎
 
执行延迟
 
Hive 在查询数据的时候，由于没有索引，需要扫描整个表，因此延迟较高。另外一个导致 Hive 执行延迟高的因素是 MapReduce框架。由于MapReduce 本身具有较高的延迟，因此在利用MapReduce 执行Hive查询时，也会有较高的延迟。相对的，数据库的执行延迟较低。当然，这个低是有条件的，即数据规模较小，当数据规模大到超过数据库的处理能力的时候，Hive的并行计算显然能体现出优势。
 
可扩展性
 
由于Hive是建立在Hadoop之上的，因此Hive的可扩展性是和Hadoop的可扩展性是一致的（世界上最大的Hadoop 集群在 百度!，2015年的规模在1.3万 台节点左右）。而数据库由于 ACID 语义的严格限制，扩展行非常有限。目前最先进的并行数据库 Oracle 在理论上的扩展能力也只有100台左右。
 
数据规模
 
由于Hive建立在集群上并可以利用MapReduce进行并行计算，因此可以支持很大规模的数据；对应的，数据库可以支持的数据规模较小。

数据仓库概念
 数据仓库是一个面向主题的、集成的、非易失的、随时间变化的用来支持管理人员决策的数据集合
 面向主题:操作型数据库的数据组织面向事务处理任务，而数据仓库中的数据是按照一定的主题域进行组织。主题是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。
 集成:数据仓库的数据有来自于分散的操作型数据，将所需数据从原来的数据中抽取出数据仓库的核心工具来，进行加工与集成，统一与综合之后才能进入数据仓库；
 非易失的:数据仓库中的数据通常以批量方式载入和访问，在数据仓库环境中一般不进行更新
 随时间而变化:数据仓库中的每个数据单元只是在某一时间是准确的。在一些情况下，数据中加有时戳，而在另一些情况下记录则包含一个事务的时间。总之，在任何情况下，记录都包含某种形式的时间标志用以说明数据在那一时间是准确的。
 
 数据仓库发展
 数据仓库和决策支持系统的起源可以追溯到计算机与信息系统发展的初期。
 1. 20世纪60年代：穿孔卡和纸带作为最常用的存储介质，应用以报表处理为特征。
 主文件和磁带的使用量的迅速增长，出现了大量冗余数据，导致：
 1）更新数据时需要保持数据一致性
 2）程序维护的复杂性
 3）开发新程序的复杂性
 4）支持所有主文件需要大量硬件
 2. 20世纪70年代：出现磁盘存储器，数据库管理系统以及在线事务处理（OLTP）
 3. 20世纪80年代：出现个人计算机和第四代编程语言，最终用户直接控制系统和数据，早期的管理信息系统MIS（Management Infomation System）可以实现。
 4. 自然演化体系结构：大型在线事务处理系统出现后不久，出现了用于“抽取”处理的程序。抽取程序搜索整个文件或数据库，使用某些标准选择合乎要求的数据，并将这些数据传送到其他文件或数据库中。随着抽取程序应用的普遍，抽取程序的蜘蛛网开始形成。
 自然演化体系结构带来了一些问题：
 1）数据缺乏可信性
 2）生产率问题
 3）无法将数据转化为信息
 5.体系结构化的数据仓库环境：主要存在两种数据，原始数据（操作型数据）和导出数据（DSS型数据）|
 
 体系结构化数据仓库环境
 主要包括四个层次的数据：
 1. 操作层：包含面向应用的原始数据，主要服务于高性能事务处理领域
 2. 数据仓库层：存储不可更新的集成的原始历史数据
 3. 部门层（数据集市层）：根据用户的需求为满足部门的特殊需求而建立
 4. 个体层：常常是暂时的，小规模的，主要完成大多数的启发式分析。
 数据集成：
 当数据从操作型层到数据仓库层，如果不进行数据集成就没有意义。当数据以非集成状态到达数据仓库，它就无法支持数据的企业试图。数据集成通过ETL进行，只需进行一次。
 
 数据仓库用户
 数据仓库用户也成为DSS分析员，他们的主要工作是定义和发现在企业决策中使用的信息。
 DSS分析员在发现模式下工作，只有看到报表时，他们才开始探讨是否有必要进行DSS分析。
 传统的SDLC（软件开发生命周期）不适用于DSS分析员，SDLC假设在设计之初，需求是已知的，但是，DSS分析员眼中，到DSS开发生命周期的最后才发现真正的需求。
 
 数据粒度
 数据粒度是数据仓库中保存数据的细化和综合程度。数据粒度的设计，直接影响到存储量及查询质量，并且直接影响到用户的分析需求。
 选择合适的粒度级别是数据仓库建设好坏的重要关键内容。选择粒度级别的一般方法，是先利用常识建立数据仓库的一小部分，并让用户去访问这些数据；然后根据系统运行情况及客户的反映，适当调整粒度的级别。在设计数据粒度时，通常需重点考虑以下因素：
 1. 要接受的分析类型、可接受的数据最低粒度和能存储的数据量
 2. 粒度的层次定义越高，就越不能在该仓库中进行更细致的分析
 3. 在同一模式中使用多重粒度
 4. 如果存储资源有一定的限制，就只能采用较高粒度的数据粒度划分策
 5. 粒度的确定实质上是业务决策分析、硬件、软件和数据仓库使用方法的一个折衷
 6. 数据粒度划分策略一定要保证数据的粒度确实能够满足用户的决策分析需要，这是数据粒度划分策略中最重要的一个准则。
 
 数据分区
 在数据仓库环境中，我们的问题不是要不要对细节数据进行分区，而是如何分区。恰当地数据分区使得数据可以增长，并且可以进行管理。
 对数据进行分区的目的是把数据划分成小的可管理的物理单元。当数据存放在大的物理单元时，以下任务无法轻松完成：
 1.重构
 2.索引
 3.扫描
 4.重组
 5.恢复
 6.监控
 
 活样本数据库
 活样本数据库是从数据仓库中取得的真实数据或轻度综合数据的一个子集。当对于正常的存取和分析，如果数据仓库中的数据是在是太多，可以考虑使用活样本数据库。
 建立活样本数据库的一个重要问题是如何装载数据，这决定了活样本数据库中的数据量以及其中的数据随机程度。
 活样本数据库的最大好处是存取效率非常高，因为活样本数据库的大小要比从中导出它的大数据库小的多。
 
 数据仓库开发生命周期
 传统SDLC：收集需求->分析->设计->编程->测试->集成->实现
 数据仓库SDLC：实现数据仓库->集成数据->检验偏差->针对数据编程->设计DSS系统->分析结果->理解需求
 数据仓库的开发和传统的SDLC相反，我们可以称这种周期为CLDS，传统的SDLC需求驱动，首先必须理解需求，然后进入设计和开发阶段。
 CLDS刚好相反，它由数据开始，得到数据后，将数据集成，然后检验数据存在什么偏差。之后，针对数据写程序、分析程序的执行结果，最后，需求才得到理解。一旦系统需求得到理解，就需要对系统的设计进行调整，针对不同的数据集开发新的开发周期。因为开发生命周期不断地重新安排不同类型的数据，所以，CLDS常称为螺旋式开发。
 
 数据仓库监控
 监控数据仓库环境中的数据对有效管理数据仓库环境是最基本的，包括：
 1.哪些数据被使用
 2.数据增长状况
 3.最终用户的响应时间
 4.谁在使用数据仓库
 5.用户在使用数据仓库中的多少数据
 6.数据仓库何时被使用
 7.确定数据仓库中有多少数据正在被使用
 8.数据仓库的使用率水平
 
 数据仓库中的错误数据
 数据仓库设计人员必须清楚如何对数据仓库中的错误数据进行处理。
 如果数据仓库中的错误数据时由于ETL问题而批量进入的，我们必须找出ETL工具并作出调整。
 即使最好的ETL处理工具，仍然会有错误数据进入数据仓库环境。
 假设我们有一条销售记录，销售额为1000，一段时间后我们发现这条数据是有问题的，销售额不是1000，而是100。我们可以采用以下方法纠正数据。
 1. 找出相应的数据并修正。引发的问题：数据出现不一致性、很多时候不是修正一个条目，而是很多很多条目。
 2. 加入修正条目。引发的问题：可能修正很多条目、修正公式复杂
 3. 不考虑历史数据，重设数据以保证当前数据的正确性。引发的问题：数据无法解释。
 
reference：
 <数据仓库> 美：william H.Inmon 王志海等译
 <数据仓库设计：现代原理与方法> 意大利：Matteo Golfarelli Stefan Rizzi 战晓苏等译
 数据仓库中的数据粒度确定原则