数据仓库的特点

1、数据仓库是面向主题的； *** 作型数据库的数据组织面向事务处理任务，而数据仓库中的数据是按照一定的主题域进行组织。主题是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个 *** 作型信息系统相关。

2、数据仓库是集成的，数据仓库的数据有来自于分散的 *** 作型数据，将所需数据从原来的数据中抽取出来，进行加工与集成，统一与综合之后才能进入数据仓库；

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

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

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

3、数据仓库是不可更新的，数据仓库主要是为决策分析提供数据，所涉及的 *** 作主要是数据的查询；

4、数据仓库是随时间而变化的，传统的关系数据库系统比较适合处理格式化的数据，能够较好的满足商业商务处理的需求。稳定的数据以只读格式保存，且不随时间改变。

5、汇总的。 *** 作性数据映射成决策可用的格式。

6、大容量。时间序列数据集合通常都非常大。

7、非规范化的。Dw数据可以是而且经常是冗余的。

8、元数据。将描述数据的数据保存起来。

9、数据源。数据来自内部的和外部的非集成 *** 作系统。

数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它并不是所谓的“大型数据库”。数据仓库的方案建设的目的，是为前端查询和分析作为基础，由于有较大的冗余，所以需要的存储也较大。为了更好地为前端应用服务，数据仓库往往有如下几点特点：

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

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

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

从上面的介绍中可以看出，数据仓库技术可以将企业多年积累的数据唤醒，不仅为企业管理好这些海量数据，而且挖掘数据潜在的价值，从而成为通信企业运营维护系统的亮点之一。正因为如此，

广义的说，基于数据仓库的决策支持系统由三个部件组成：数据仓库技术，联机分析处理技术和数据挖掘技术，其中数据仓库技术是系统的核心，在这个系列后面的文章里，将围绕数据仓库技术，介绍现代数据仓库的主要技术和数据处理的主要步骤，讨论在通信运营维护系统中如何使用这些技术为运营维护带来帮助。

4面向主题

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

数据仓库，英文名称为 Data Warehouse，可简写为 DW 或 DWH。数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它是单个数据存储，出于分析性报告和决策支持目的而创建。 为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。

数据仓库是决策支持系统（dss）和联机分析应用数据源的结构化数据环境。数据仓库研究和解决从数据库中获取信息的问题。数据仓库的特征在于面向主题、集成性、稳定性和时变性。

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

数据仓库之父比尔·恩门（Bill Inmon）在 1991 年出版的“Building the Data Warehouse”（《建立数据仓库》）一书中所提出的定义被广泛接受——数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。

1、数据仓库是面向主题的； *** 作型数据库的数据组织面向事务处理任务，而数据仓库中的数据是按照一定的主题与进行组织。主题是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个 *** 作性信息系统相关。

2、数据仓库是集成的，数据仓库的数据有来自于分散的 *** 作型数据，将所需数据从原来的数据中抽取出来，进行加工与集成，统一与综合之后才能进入数据仓库；

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

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

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

3、数据仓库是不可更新的，数据仓库主要是为决策分析提供数据，所涉及的 *** 作主要是数据的查询；

4、数据仓库是随时间而变化的，传统的关系数据库系统比较适合处理格式化的数据，能够较好地满足商业商务处理的需求。稳定的数据以只读格式保存，且不随时间改变。

5、汇总的。 *** 作性数据映射成决策可用的格式。

6、大容量。时间序列数据集合通常都非常大。

7、非规范化的。Dw 数据可以是而且经常是冗余的。

8、元数据。将描述数据的数据保存起来。

9、数据源。数据来自内部的和外部的非集成 *** 作系统。

数据仓库之父Bill Inmon在1991年出版的“Building the Data Warehouse”一书中所提出的定义被广泛接受——数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。

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

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

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

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

1、首先你得搞清楚建设数仓的目的是什么

是偏向于整合各系统数据，为数据分析决策服务，还是偏向于快速的完成分析决策需求？

如果是前者，那么在数据仓库建模的时候一般会选择ER建模方法；

如果是后者，一般会选择维度建模方法。

ER建模：即实体关系建模，由数据仓库之父BIll Inmon提出，核心思想是从全企业的高度去设计三范式模型，用实体关系描述企业服务。主张的是自上而下的架构，将不同的OLTP数据集中到面向主题的数据仓库中。

维度建模：由Kimball提出，核心思想是从分析决策的需求出发构建模型。这种模型由事实表和维表组成，即星型模型和雪花模型。Kimball倡导自下而上的架构，可以针对独立部门建立数据集市，再递增的构建，汇总成数据仓库。

2、其次你得进行深入的业务调研和数据调研

业务调研：深入的业务调研能使你更加明确数仓建设的目的；同时也利于后续的建模设计，随着调研的开展，如何将实体业务抽象为数仓模型会更加明朗。

数据调研：各部门或各科室的数据现状了解，包括数据分类、数据存储方式、数据量、具体的数据内容等等。这对后续的主数据串联或者维度一致性处理等等都是必须的基础。

3、然后是数据仓库工具选型

传统型数据仓库：一般会选择第三方厂家的数据库和配套ETL工具。因为有第三方支持，相对有保障；但缺点也很明显，受约束以及成本较高。

NoSQL型数据仓库：一般是基于hadoop生态的数据仓库。hadoop生态已经非常强大，可以找到各种开源组件去支持数据仓库。缺点是需要招聘专门人士去摸索，并且相对会存在一些未知隐患。

4、最后是设计与实施

设计：包括数据架构中的数据层次划分以及具体的模型设计；也包括程序架构中的数据质量管理、元数据管理、调度管理等；

实施：规范化的项目管理实施，但同时也需记住一点，数据仓库不是一个项目，它是一个过程。

了解元数据，可以看下下面这篇文章，是一个90后的小美女写的，通俗易懂。\x0d\\x0d\近几年，随着90后群体逐步迈入职场，逐渐出现在社会大众的视野当中。本文出自一名90后美女程序员之手，他们是极具个性的一代，他们这代技术人的新奇想法，正是现代企业需要的创新源泉\x0d\\x0d\关于作者：\x0d\\x0d\龚菲普元信息大数据产品部90后美女程序员\x0d\\x0d\公司大数据治理正做得风生水起，各种核心产品在国内市场数一数二，终极大BOSS们将数据治理方面的经验总结成文章，篇篇干货，堪称经典。(有兴趣的同学可以看下公众号的历史文章，不过据说有一批干货文章还没发表出来，敬请期待)。作为尚未正式入职的小菜鸟，我也只能在极浅的层面发表一些我自己的看法\x0d\\x0d\我将文章分为两大部分，第一部分介绍元数据概念，第二部分从几个方面说明元数据管理的应用，最后一部分总结一下元数据的重要性，仅代表我的一些个人观点，还请各位前辈们不要见笑。\x0d\\x0d\一、元数据什么鬼\x0d\\x0d\我入职的时候刚好赶上公司的元数据产品升级换代，同事们的研发气氛正火热，作为新入职菜鸟，总得先了解一下元数据概念，不然日后怎么和小伙伴们愉快地玩耍，于是查找国内外相关材料：\x0d\\x0d\一段时间之后有了一些知识积累，才发现用“关于数据的数据”来给元数据下定义确实再准确不过了，但同时也略微抽象，新人难于快速理解，待到上周我们数据治理专家从心理学的角度来阐述元数据之后，我终于也算理解了元数据到底是个啥，今天也算是站在“巨人”的肩膀上，用一种更简单的方式来回答“元数据究竟是什么”这个问题\x0d\\x0d\元数据是关于数据的描述，存储着关于数据的信息，为人们更方便地检索信息提供了帮助。咦检索信息小蝌蚪找妈妈的过程也是一个检索信息的过程，是不是看懂这个故事就能懂元数据是什么了\x0d\\x0d\池塘里有一群小蝌蚪，他们看见鲤鱼妈妈在教小鲤鱼捕食，就迎上去，问：“鲤鱼阿姨，我们的妈妈在哪里”\x0d\\x0d\此时蝌蚪们意识到，不对啊，我们的数据库里不是应该存在着一张Mother表吗，但是蝌蚪们竟然对这张表一无所知，不知道有什么字段，也不知道各个字段对应的具体数值：\x0d\\x0d\鲤鱼妈妈说：“你们的妈妈有四条腿，宽嘴巴。你们到那边去找吧!”\x0d\\x0d\鳄鱼笑着说：“你们的妈妈有两只大眼睛，披着绿衣裳。你们到那边去找吧!”\x0d\\x0d\乌龟笑着说：“我不是你们的妈妈，你们的妈妈肚皮是白的，到前面去找吧。”\x0d\\x0d\青蛙听了“各各”地笑起来，说“唉!傻孩子，我就是你们的妈妈呀”\x0d\\x0d\整个过程可以看成是Mother这张表逐步完善的过程，数据来源分别是鲤鱼妈妈、鳄鱼妈妈和乌龟妈妈，如下图所示：\x0d\\x0d\对蝌蚪们最终获取到的信息进行进一步抽象，就可以形成一种“元数据”，该元数据描述了Mother这张表的结构：\x0d\\x0d\刚才不是说元数据能为检索信息提供帮助吗，那是不是也说明元数据能为小蝌蚪找妈妈提供帮助我们将在第二部分试着对这个故事进行改编，详细介绍小蝌蚪利用元数据快速找到妈妈的过程。\x0d\\x0d\二、元数据管理的应用\x0d\\x0d\通常一款元数据管理工具应具备元模型设计、元数据采集、元数据分析、数据地图展现等核心功能，我们试着改编小蝌蚪找妈妈这个故事，在改编的过程中理解这几个核心功能，前提是我们假设所有动物共同构成了一个庞大的数据体系，小蝌蚪们Mother的具体数据已经存在于此体系之中(鲤鱼系统、鳄鱼系统、乌龟系统)。\x0d\\x0d\1、元模型设计\x0d\\x0d\先解释一下元模型。如果说元数据是对数据的描述，那么元模型就是对元数据的描述，是对元数据的进一步抽象，三者的关系如下图所示：\x0d\\x0d\再讲一下元模型设计的过程。首先获取到系统中的所有元数据，将这些元数据汇总并进行合理规划，进一步抽象成元模型，从一定角度来说，可以把这个抽象的过程看成元模型设计的过程。\x0d\\x0d\元模型定义了各种元数据的结构以及元数据之间的关系，是元数据管理的基础，也就是说，如果我们想用元数据帮助小蝌蚪找妈妈，需要先设计出合理的元模型。下图是我试着给它们设计出的元模型(对于企业来说，真正的元模型设计过程非常复杂，受多方面因素影响)：\x0d\\x0d\我们认为小蝌蚪的妈妈(Mother)由若干个属性(Property)组成，每个属性的名称用Name表示，每个属性的类型用Type表示。\x0d\\x0d\现在元模型有了，下一步就是按照这个设计好的元模型采集小蝌蚪们需要的元数据信息，也就是我们常说的元数据采集。\x0d\\x0d\2、元数据采集\x0d\\x0d\设计好元模型之后，元数据管理工具能通过全自动的方式采集到企业所需要的元数据，在这个故事中，按照我设计好的元模型，元数据管理工具的元数据采集结果应该如下图所示：\x0d\\x0d\小蝌蚪们拿着这份元数据再去针对性地检索关于妈妈的信息，就能一步到位，将目标直接锁定到青蛙，整个故事将因元数据的出现而成功改写。\x0d\\x0d\说明：在真实的企业数据环境中，数据与元数据是已经存在于系统之中的，元数据管理就是根据企业现有的元数据设计出适合企业的元模型，然后将系统之中的元数据按照元模型集中汇总并关联到一起，达到企业对数据统一管理与应用的目的。\x0d\\x0d\3、元数据分析\x0d\\x0d\a、血缘分析\x0d\\x0d\假设动物园园长慢羊羊正管理着整个动物园的数据信息，有一天园长发现自己这里有个数据不对，需要找出错误数据的提供者并追究责任，那么这个错误数据来自于哪个动物家庭呢挨家挨户去敲门核对数据显然不够高效，元数据管理工具的血缘分析功能会自动帮助园长分析这个错误数据的上游路径，比如这个数据是由鲤鱼妈妈交给鳄鱼妈妈，鳄鱼妈妈再提交给园长的，那么此时园长只需要去敲鲤鱼和鳄鱼家的门就可以了。\x0d\\x0d\b、影响分析\x0d\\x0d\数据终于更正了，此时园长需要及时提醒大家这个数据的更正信息，只需要通知这个数据影响到的动物家庭就可以了，这让园长十分苦恼，整个动物园的数据传递这么复杂，怎么判断哪个家庭会受到这个数据的影响呢，元数据管理工具的影响分析功能会分析出这个数据的影响范并能用可视化的方式展现出来，园长只需要通知受影响的动物家庭就可以了。\x0d\\x0d\c、数据地图展现\x0d\\x0d\随着动物园规模的日益扩大，入住的动物种类日益增多，有一天园长想了解动物园的整体情况，有多少动物家庭，哪个家庭和哪个家庭比较要好，哪个家庭和哪个家庭又从来没有联系，此时元数据管理工具的数据地图可以帮助园长获取到他想要的信息，数据地图展现功能可以通过可视化的方式，让园长对整个动物园的情况了如指掌，帮助它更好地观察整个动物园的情况。\x0d\\x0d\三、元数据的重要性\x0d\\x0d\在大数据时代的背景下，数据即资产，元数据实现了信息的描述和分类的格式化，从而为机器处理创造了可能，它能帮助企业更好地对数据资产进行管理，理清数据之间的关系。元数据管理是企业提升数据质量的基础，也是企业数据治理中的关键环节。元数据管理不当，信息很容易被丢失，进而不能对业务进行有效支撑，企业内部业务人员要识别相关信息就会变得十分困难，最终用户也将失去对数据的信任。\x0d\\x0d\写在最后：\x0d\\x0d\公司正在研发针对企业级用户的数字化企业云平台，并且全面公开研发文档与技术细节，由我担任的群主的微信讨论群也会对架构设计过程进行公开，欢迎对此感兴趣的前辈和朋友入群，与我们共同讨论，共商“云”是。感兴趣或者想学习相关技术，可在百度中搜EAii了解。

一直想整理一下这块内容，既然是漫谈，就想起什么说什么吧。我一直是在互联网行业，就以互联网行业来说。

先大概列一下互联网行业数据仓库、数据平台的用途：

整合公司所有业务数据，建立统一的数据中心；

提供各种报表，有给高层的，有给各个业务的；

为网站运营提供运营上的数据支持，就是通过数据，让运营及时了解网站和产品的运营效果；

为各个业务提供线上或线下的数据支持，成为公司统一的数据交换与提供平台；

分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果；比如广告定向精准投放、用户个性化推荐等；

开发数据产品，直接或间接为公司盈利；

建设开放数据平台，开放公司数据；

。。。。。。

上面列出的内容看上去和传统行业数据仓库用途差不多，并且都要求数据仓库/数据平台有很好的稳定性、可靠性；但在互联网行业，除了数据量大之外，越来越多的业务要求时效性，甚至很多是要求实时的 ，另外，互联网行业的业务变化非常快，不可能像传统行业一样，可以使用自顶向下的方法建立数据仓库，一劳永逸，它要求新的业务很快能融入数据仓库中来，老的下线的业务，能很方便的从现有的数据仓库中下线；

其实，互联网行业的数据仓库就是所谓的敏捷数据仓库，不但要求能快速的响应数据，也要求能快速的响应业务；

建设敏捷数据仓库，除了对架构技术上的要求之外，还有一个很重要的方面，就是数据建模，如果一上来就想着建立一套能兼容所有数据和业务的数据模型，那就又回到传统数据仓库的建设上了，很难满足对业务变化的快速响应。应对这种情况，一般是先将核心的持久化的业务进行深度建模（比如：基于网站日志建立的网站统计分析模型和用户浏览轨迹模型；基于公司核心用户数据建立的用户模型），其它的业务一般都采用维度+宽表的方式来建立数据模型。这块是后话。

整体架构下面的图是我们目前使用的数据平台架构图，其实大多公司应该都差不多：

逻辑上，一般都有数据采集层、数据存储与分析层、数据共享层、数据应用层。可能叫法有所不同，本质上的角色都大同小异。

我们从下往上看：

数据采集数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。

数据源的种类比较多：

网站日志：

作为互联网行业，网站日志占的份额最大，网站日志存储在多台网站日志服务器上，

一般是在每台网站日志服务器上部署flume agent，实时的收集网站日志并存储到HDFS上；

业务数据库：

业务数据库的种类也是多种多样，有Mysql、Oracle、SqlServer等，这时候，我们迫切的需要一种能从各种数据库中将数据同步到HDFS上的工具，Sqoop是一种，但是Sqoop太过繁重，而且不管数据量大小，都需要启动MapReduce来执行，而且需要Hadoop集群的每台机器都能访问业务数据库；应对此场景，淘宝开源的DataX，是一个很好的解决方案（可参考文章 《异构数据源海量数据交换工具-Taobao DataX 下载和使用》），有资源的话，可以基于DataX之上做二次开发，就能非常好的解决，我们目前使用的DataHub也是。

当然，Flume通过配置与开发，也可以实时的从数据库中同步数据到HDFS。

来自于Ftp/>

有可能一些合作伙伴提供的数据，需要通过Ftp/也可以满足该需求；

其他数据源：

比如一些手工录入的数据，只需要提供一个接口或小程序，即可完成；

数据存储与分析毋庸置疑，HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。

离线数据分析与计算，也就是对实时性要求不高的部分，在我看来，Hive还是首当其冲的选择，丰富的数据类型、内置函数；压缩比非常高的ORC文件存储格式；非常方便的SQL支持，使得Hive在基于结构化数据上的统计分析远远比MapReduce要高效的多，一句SQL可以完成的需求，开发MR可能需要上百行代码；

当然，使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapReduce来做分析与计算；Spark是这两年非常火的，经过实践，它的性能的确比MapReduce要好很多，而且和Hive、Yarn结合的越来越好，因此，必须支持使用Spark和SparkSQL来做分析和计算。因为已经有Hadoop Yarn，使用Spark其实是非常容易的，不用单独部署Spark集群，关于Spark On Yarn的相关文章，可参考：《Spark On Yarn系列文章》

实时计算部分，后面单独说。

数据共享这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库；

前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据； 和数据采集层到HDFS刚好相反，这里需要一个从HDFS将数据同步至其他目标数据源的工具，同样，DataX也可以满足。

另外，一些实时计算的结果数据可能由实时计算模块直接写入数据共享。

数据应用

业务产品

业务产品所使用的数据，已经存在于数据共享层，他们直接从数据共享层访问即可；

报表

同业务产品，报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层；

即席查询

即席查询的用户有很多，有可能是数据开发人员、网站和产品运营人员、数据分析人员、甚至是部门老大，他们都有即席查询数据的需求；

这种即席查询通常是现有的报表和数据共享层的数据并不能满足他们的需求，需要从数据存储层直接查询。

即席查询一般是通过SQL完成，最大的难度在于响应速度上，使用Hive有点慢，目前我的解决方案是SparkSQL，它的响应速度较Hive快很多，而且能很好的与Hive兼容。

当然，你也可以使用Impala，如果不在乎平台中再多一个框架的话。

OLAP

目前，很多的OLAP工具不能很好的支持从HDFS上直接获取数据，都是通过将需要的数据同步到关系型数据库中做OLAP，但如果数据量巨大的话，关系型数据库显然不行；

这时候，需要做相应的开发，从HDFS或者HBase中获取数据，完成OLAP的功能；

比如：根据用户在界面上选择的不定的维度和指标，通过开发接口，从HBase中获取数据来展示。

其它数据接口

这种接口有通用的，有定制的。比如：一个从Redis中获取用户属性的接口是通用的，所有的业务都可以调用这个接口来获取用户属性。

实时计算现在业务对数据仓库实时性的需求越来越多，比如：实时的了解网站的整体流量；实时的获取一个广告的曝光和点击；在海量数据下，依靠传统数据库和传统实现方法基本完成不了，需要的是一种分布式的、高吞吐量的、延时低的、高可靠的实时计算框架；Storm在这块是比较成熟了，但我选择Spark Streaming，原因很简单，不想多引入一个框架到平台中，另外，Spark Streaming比Storm延时性高那么一点点，那对于我们的需要可以忽略。

 我们目前使用Spark Streaming实现了实时的网站流量统计、实时的广告效果统计两块功能。

做法也很简单，由Flume在前端日志服务器上收集网站日志和广告日志，实时的发送给Spark Streaming，由Spark Streaming完成统计，将数据存储至Redis，业务通过访问Redis实时获取。

任务调度与监控在数据仓库/数据平台中，有各种各样非常多的程序和任务，比如：数据采集任务、数据同步任务、数据分析任务等；

这些任务除了定时调度，还存在非常复杂的任务依赖关系，比如：数据分析任务必须等相应的数据采集任务完成后才能开始；数据同步任务需要等数据分析任务完成后才能开始； 这就需要一个非常完善的任务调度与监控系统，它作为数据仓库/数据平台的中枢，负责调度和监控所有任务的分配与运行。

前面有写过文章，《大数据平台中的任务调度与监控》,这里不再累赘。

总结在我看来架构并不是技术越多越新越好，而是在可以满足需求的情况下，越简单越稳定越好。目前在我们的数据平台中，开发更多的是关注业务，而不是技术，他们把业务和需求搞清楚了，基本上只需要做简单的SQL开发，然后配置到调度系统就可以了，如果任务异常，会收到告警。这样，可以使更多的资源专注于业务之上。

数据仓库的特点：

数据仓库是面向主题的； *** 作型数据库的数据组织面向事务处理任务，而数据仓库中的数据是按照一定的主题域进行组织。主题是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个 *** 作型信息系统相关。

数据仓库是集成的，数据仓库的数据有来自于分散的 *** 作型数据，将所需数据从原来的数据中抽取出来，进行加工与集成，统一与综合之后才能进入数据仓库； 数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。 数据仓库的数据主要供企业决策分析之用，所涉及的数据 *** 作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询 *** 作，但修改和删除 *** 作很少，通常只需要定期的加载、刷新。 数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到当前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。

数据仓库是不可更新的，数据仓库主要是为决策分析提供数据，所涉及的 *** 作主要是数据的查询；

数据仓库是随时间而变化的，传统的关系数据库系统比较适合处理格式化的数据，能够较好的满足商业商务处理的需求。稳定的数据以只读格式保存，且不随时间改变。

汇总的。 *** 作性数据映射成决策可用的格式。

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

非规范化的。Dw数据可以是而且经常是冗余的。

元数据。将描述数据的数据保存起来。

数据源。数据来自内部的和外部的非集成 *** 作系统。

可以参考这篇文章：数据仓库(1)什么是数据仓库 - 知乎 (zhihucom)

以上就是关于数据仓库的特点全部的内容，包括:数据仓库的特点、数据仓库有哪些、数据仓库是什么意思等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！