本人从事通信行业数据仓库系统集成服务已有10年，从数据分析挖掘（BI）到数据库维护管理再到ETL过程开发和hadoop生态使用和开发，随着开源技术的发展和盛行，数据仓库也在随之发生着变化，但其存在意义还是为了企业的决策支持，只是对于数据展现的及时性、多样性（丰富）有了更高的要求。（后面内容对于部分涉及企业商业部分进行了虚拟化，望谅解）
上学的时候只学过数据库概论（计算机科学与技术专业），进入到数据相关行业也是机缘巧合，从学校到职场，发现实验环境和生产环境有很大的不同，需要学习的地方有很多，生存大于兴趣，没有进行过系统化或买专业书籍的学习，都是应用到哪查阅到哪再付诸于实践。
一、数据仓库相关概述
数据仓库与数据库
数据库是面向事务的设计，数据仓库是面向主题设计的
数据库一般存储在线交易数据，数据仓库存储的一般是历史数据
数据库设计是尽量避免冗余，数据仓库在设计是有意引入冗余
数据库是为捕获数据而设计，数据仓库是为分析数据而设计
什么是数据仓库
数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。
数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。
数据仓库，是单个数据存储，出于分析性报告和决策支持目的而创建。 为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。
进入数据仓库对你的能力要求
了解并掌握数据库编程（SQL语言）
掌握一门计算机语言（数据仓库成千上万的分析过程都需要实现自动化，计算机语言是基础）
对于这门计算机语言其实初期不必在意是否与当前实际环境相符（譬如实际用的是python，但是你掌握的是C），能读懂现有的环境就能满足初期的需求了，从能读懂到能实践这是一个转换和能力成长期，需要时间和经验，[b]在以上要求下，接下来就是了解甚至掌握具体行业的业务[/b]，譬如本人所在的通信行业，话费的计算口径、用户是否活跃判断口径等。
随着开源技术的发展和盛行，对于个人能力要求也越来越高，但是切忌学的多而不精，能在一个岗位做到精进而发散去了解掌握其他岗位的技能在多数场景下才能做到事半功倍
BI:商业智能（BI，Business Intelligence）
BI（Business Intelligence）即商务智能，它是一套完整的解决方案，用来将企业中现有的数据进行有效的整合，快速准确的提供报表并提出决策依据，帮助企业做出明智的业务经营决策
二、数据仓库体系架构
通过以上介绍，我们知道数据仓库存在的意义是为了企业的决策支持，在数字化的今天，这些支持靠的是各类图表，图表需要BI人员通过BI工具或SQL开发进行数据挖掘分析，存放大量的数据我们需要数据库，那么数据库最原始的数据从哪里来呢，其他系统或是人造的，如此数据仓库体系架构就呈现出来了
通过这个体系架构我们大概能知道，数据仓库存在哪些岗位需求：
（1）BI人员：数据分析挖掘人员（需要掌握SQL语言）
（2）DBA：数据库管理人员（需要根据实际环境需求，OLAP系统和OLTP系统的）
（3）模型相关人员：数据仓库各类主题规划、模型设计等（数据仓库汇聚了大量其他系统数据，均按照主题归类）
（4）ETL开发人员：文件采集、转换和入库以及导出的人员（需要掌握相关计算机语言，文件类处理一般用的比较多的perl、python、shell等）
（5）JAVA开发人员：报表平台构建、其他工具类构建、甚至数据分析类（hadoop生态基本也都是java语言开发）
维护人员：ETL过程的维护、WEB端的维护以及其他维护配置类工作（一般大型企业硬件、网络和操作系统均有专人维护管理，中小型企业维护人员可能会兼职这块内容工作）
三、数据仓库模型设计
模型：雪花模型和星型模型（比较专业和复杂的一个模块，这块就不多讲述了，对于经验需求很高，相关理论建议百度或Google）
四、OLAP与OLTP
（1）OLAP:联机分析处理OLAP（On-Line Analytical Processing）
OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
（2）OLTP:联机事务处理OLTP（on-line transaction processing）
OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。对于并发量和响应及时性要求高。
其实两者对比最直观的例子：我们去营业厅办理业务，营业员在做配置更新入库和查询作为客户我是无法接受查个套餐信息或话单要等超过1分钟（当然有些环境较差的场景就特殊了），而且同时办理业务的量会很大，这就是典型的OLTP场景了，对比之下OLAP，我们是拿大量数据做关联计算分析，我是能接受半小时甚至一小时后拿到分析结果的，而且BI人员和营业员，并发数上就已经不是一个量级了
尽管我们知道数据仓库主要场景是数据挖掘分析，但那并不能等同于数据仓库=OLAP，数据仓库有很多场景也应用到了OLTP
譬如：ETL调度（ETL过程自动化的实现）、WEB端的展现与配置交互等
所以对照到具体的数据库环境，在数据仓库我们不仅在OLAP场景用到了MPP（分布式计算系统，如我所在场景有用到的Teradata、DB2、Vertica、HIVE等）系统，同时也在OLTP场景用到了Oracle、Mysql等传统的行式数据库
五、ETL
数据仓库的核心过程，数据采集、数据转换和数据加载，从字面上就可理解其工作内容和含义，只是我们需要明白几个问题：
（1）数据从哪里采集（有哪些外系统或人造数据可获取到）
（2）数据通过何种方式采集（是直接访问外系统的数据库采集数据还是获取数据文件，文件又需要通过哪种协议获取，ftp or sftp或其他）
（3）数据如何转换（转换方式和策略如何制定，与数据仓库主要数据库需求息息相关，如字符集、数据仓库模型结构等）
（4）调度如何实现，以上过程的自动化集成（不管以上过程量多还是量少，人工操作终归是效率低下容易犯错的）
六、数据仓库元件的选型
在有了以上经验的基础上，我们对于实际场景需要进行数据仓库元件的选型
（1）数据仓库主要数据库和数据集市：当下实现主要有三类（hadoop开源生态、MPP商业数据库、hadoop开源+MPP商业数据库），需要根据实际仓库的计算和存储需求来界定，当然成本仍然是各企业考虑的重点，当下我所在环境为第三类hadoop开源+MPP商业数据库组合架构，开源技术使用主要成本在人，商业数据库的主要成本在于license的购买，需要根据实际能力考量，个人倾向组合架构，既能多维发展又能对稳定性和严谨性需求高的数据进行保障（这点是实践所得，之前领导一股脑想全在hadoop生态实现，最后已然烂尾，不得不再次招标购买商业MPP数据库的license）
（2）ETL调度：当下开源以kettle较为流行、商业以infomatic较为出名，需要根据实际环境进行考量，我所在的环境并没用到这两类，由最早Teradata数据库厂商提供，目前在本人进行了底层源码重写（主要因为Teradata成本过高，企业已不再和Teradata合作，故而需要解决bug和去Teradata化），ETL过程的编程实现与调度底层也息息相关（我们这里均使用perl实现）
（3）BI工具：大量公司在没有专业的数据挖掘人员时，BI挖掘工具是一个比较好接受和实施的工具，就好比如界面化操作较命令化编程的天然优势，当然BI工具的使用也是一项专业性要求较高的，当然我们的场景主要以后台SQL编程+BI报表工具双向实现，一些个性化的模块BI工具兼容性较差
（4）报表平台：报表展现后台库、前段web架构等（我们基本都是java+oracle的实现方式）
（5）其他组件：元数据管理系统（如模型血缘关系、版本管理等），维护管理管理系统（如数据质量管理）以及其他工具，这个根据实际场景需求建设
七、数据仓库的变化
数据仓库数据主要来自各业务生产系统，如通信行业来源于计费系统、CRM系统等，在传统仓库业务中我们是不做准实时或实时数据分析的，主要分析的对象均是历史的存量数据，即所谓历史数据的分析、对未来的决策思维
随着kafka、hbase、storm、spark以及kudu的出现在新的数据仓库架构中，对于数据分析的及时性越来越高，实时和准实时业务场景越来越多（人总是贪婪的，特别是领导，越早看到数据越好），当然传统分析性业务仍是大头
可以想象，数据仓库的架构在变化，对人员需求也在变化，如今这些也正在发生
如果你有兴趣，欢迎入坑