数据仓库形象解释
业务场景如下图
举例说明：
在很久很久以前，世界上生活着许多种族，有人类，有矮人，有精灵......他们有着不同的信仰，不同的文化，彼此相安无事。可是，有一个猥琐男却偏偏想要统治整个世界。如何统治这么多不同文化信仰的种族呢？猥琐男想出一个馊主意，打造出几枚拥有魔力的戒指，免费送给不同种族的领袖，让他们可以更好地统治各自的族人。当各个种族的领袖美滋滋地戴上各自的魔戒，走上人生巅峰的时候，猥琐男又打造出一枚独一无二的至尊魔戒。他利用至尊魔戒的力量控制了所有的魔戒，从而控制了各个种族的领袖，继而控制了整个世界。
这个故事告诉我们，数据库和数据仓库之间的关系：
如果说，那个世界的每一个生命个体都是一条数据记录，那么普通的魔戒的地位就好比是数据库，而至尊魔戒的地位就好比是数据仓库。
数据仓库，英文名称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.数据定位差别
这里说的定位，主要是指以何种目的组织起来。操作型数据库是为了支撑具体业务的，因此也被称为"面向应用型数据库"；分析型数据库则是针对各特定业务主题域的分析任务创建的，因此也被称为"面向主题型数据库"。
1887
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
