乐意数据库

❶ 数据仓库和数据库有什么区别和联系

简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。

数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。

数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。

数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。

单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。

显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。

数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。

“面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。

“与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。

“不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此，数据仓库中的数据是极少或根本不修改的;当然，向数据仓库添加数据是允许的。

数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。

补充一下，数据仓库的方案建设的目的，是为前端查询和分析作为基础，由于有较大的冗余，所以需要的存储也较大。为了更好地为前端应用服务，数据仓库必须有如下几点优点，否则是失败的数据仓库方案。

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

2.数据质量。客户要看各种信息，肯定要准确的数据，但由于数据仓库流程至少分为3步，2次ETL，复杂的架构会更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据失真，客户看到错误的信息就可能导致分析出错误的决策，造成损失，而不是效益。

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

❷ 什么是基础数据信息平台

一直想整理一下这块内容，既然是漫谈，就想起什么说什么吧。我一直是在互联网行业，就以互联网行业来说。
先大概列一下互联网行业数据仓库、数据平台的用途：

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

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

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

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

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

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

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

• 。。。。。。




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




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




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




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




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




• 我们从下往上看：




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





• 数据源的种类比较多：




• 网站日志：




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




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




• 业务数据库：




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




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




• 来自于Ftp/Http的数据源：




• 有可能一些合作伙伴提供的数据，需要通过Ftp/Http等定时获取，DataX也可以满足该需求；




• 其他数据源：




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





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





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




• 当然，使用Hadoop框架自然而然也提供了MapRece接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapRece来做分析与计算；Spark是这两年非常火的，经过实践，它的性能的确比MapRece要好很多，而且和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开发，然后配置到调度系统就可以了，如果任务异常，会收到告警。这样，可以使更多的资源专注于业务之上。

❸ 如何做成一个DBA，有没有好的学习计划

一、DBA技术
1、作为一个DBA，你必须要精通SQL命令、各种数据库架构、数据库管理和维护、数据库调优，必要的时候，还需要为开发人员搭建一个健壮、结构良好、性能稳定的数据库环境。
2、数据库是构建在操作系统之上的，你还需要精通系统技术。当然，完全不必要学习系统管理员那样高深的技术理论。
3、你还需要掌握服务器硬件、软件技术理论。便于数据库基于服务器问题出现的时候，能够及时提出解决方案。
4、还要理解数据库在服务器、系统软件中如何实现和运作的。

二、了解DBA职责：
1、监视数据库。
2、记录和统计系统和性能的表现技术信息。
3、构造数据库框架、配置数据库实例。
4、维护数据库网络安全，过滤非法查询信息。
5、及时备份数据库
6、利用备份，还原数据库，甚至是迁移数据库。
7、为开发人员定制、配置专用的测试服务器。
8、数据库技术最新的研发方向。
9、数据库调优。
10、完整熟悉数据库操作流程。
11、诊断数据库，找出数据库的不足之处和生成数据库解决方案。
12、完整培训数据库系统那个环境。
13、与系统管理员保持良好的合作关系。
14、创建有效的、定期维护的安全的数据库。
三、初级DBA学习
1、关系数据库理论
这是很多DBA的入门基础理论。目前市场上主流的数据库都是关系型数据库，当然关系型数据库理论也成为了DBA的基础技术理论。只有对于关系型数据库理论达到了一个层次，对于关系型数据库管理系统(RDBMS)才能更好地应用，无论是Oracle数据库，IBM的DB2，还是微软的SQL Server。目前，很多的大学都有关系型数据库理论的课程。推荐一本关系型数据库理论书籍，Elmasri and Navathe编写的数据库系统基础，Bejamin/Cummings Press。
2、系统学习SQL语句
对于DBA而言，使用得最多的还是SQL查询语句。因此，掌握SQL语言是非常必要的。只有当SQL查询语言，成为了一种你DBA生涯的职业习惯的时候，你才能真正意义上成为合格的DBA。在目前所有的数据库中，SQL查询语言全部通用。本质上来讲，SQL查询语言是DBA和数据库交互的必要工具。这里有一本非常好的书籍，《Oracle Database 11g完全参考手册》，属于DBA非常重要的技术参考文档。
3、逐渐参与基本的数据库管理工作
对于数据库管理而言，有两本比较好的书籍，《Oracle Database 11g DBA手册》和《Oracle Database 11g备份与恢复指导》。这都是Oracle比较好的技术文档，同时也是基本的数据库管理工作的理论基础。对于DBA而言，关系型数据库理论和SQl查询语言理论是DBA真正的技术理论基础，数据库管理工作更多的时候只是一种工具。而且，实践才是检验和提高DBA技术的唯一标准。从数据库日常管理工作中学习，从实践中提高，才是DBA成长的唯一出路。
4、继续学习数据库技术
参与Oracle培训，获得Oracle认证其实对于DBA而言，还远远不够。IT行业是一个技术更新速度非常频繁的行业。而DBA行业的技术更新，更是远胜于IT行业。以Oracle为代表的数据库厂商，都投入了大量的资金和资源到技术研发中去，Oracle的技术基本都是每三个就会进行一次大的更新。这也是很多的Oracle官方培训机构普遍采用PDF电子教材的根本原因所在。去阅读，去学习，去不断丰富自己的技术理论和实践能力。
5、不断尝试参与案例
对于DBA而言，日常的数据库管理工作，还只是基本职能之一。要想在DBA行业走得更远，丰富自己的技术实力才是王道。所以，尝试不断地去测试案例，不断地去数据库中寻找疑难杂症，不断地提出解决方案，从众多的解决方案中寻找优秀的方案，吸取经验，也是DBA学习的另外一种非常有效的手段。毕竟，日常的数据库管理都不会遇到太多的问题，需要自己去创建模型，自己去创建案例。当然，如果日常管理的数据库都能不断出现各种各样的问题，那说明你在DBA的道路上，还仍重而道远。
6、寻找良师
在DBA行业发展，一个优秀的引路人是DBA生涯最好的指明灯。他们往往能够在你的DBA生涯中，给予你比较宝贵的建议，传授给你比较好的经验的积累，使你在DBA的道路上，尽可能少地走弯路。
7、参与本地讨论组
目前，各种交互平台上，DBA技术讨论组非常多，甚至还有很多跨城市、跨国家的用户讨论组。这其中，本地讨论组是一种非常好的资源，很多时候还会举行线下的聚会，讨论数据库相关的话题。
四、中级DBA进阶
请记住，SQL语言、关系型数据库理论和基本的数据库管理任务，是作为一名初级DBA所必备的技术理论和实践基础。如果你已经成为初级DBA，并确信掌握了上面三种技术，而且也开始厌倦不断地阅读技术文档。那么接下来的建议将带你进入中级DBA的技术殿堂。
1、学习操作系统和服务器硬件
我们知道，数据库是建立在操作系统和服务器硬件之上的。操作系统，作为硬件和数据库之间交互的中间层，在日常的数据库维护工作中，也是经常遇到诸多疑难杂症的。如果是Unix操作系统则需要熟悉和掌握Unix命令行语句。如果是Windows Server操作系统，则需要学习操作系统的维护、管理和优化。当然，作为承载数据库和操作系统的服务器硬件，也是很有必要的。
2、学习一门开发语言
对于数据库而言，并不是单独存在的。作为后台运行的数据库，很多时候都有前端的操作界面和功能的实现。毕竟，并不是所有的软件开发者都精通数据库编程。特别在一些大型的IT企业，DBA往往都需要和软件开发程序员合作，搭建软件运行和数据存储的后台数据库。学习一门开发语言，能够让你很好地理解数据库开发在程序设计中的意义和作用。并能在和软件开发程序员的合作中，更好地实现程序员理想的功能。
3、取得认证
对于已经成为DBA的你而言，认证将不再作为DBA行业的敲门砖。更多的时候，认证对于初级DBA而言，是一种学习的过程，同时也是自我价值的实现过程。同时，在参与认证考试的时候，也能够从和其他DBA的交流中，学习一些从未接触过的技术或者经验。
成为一名中级DBA，OCP(Oracle Certified Professional)是你必须考取的认证。作为数据库行业的大佬，Oracle的技术实力是不言而喻的。而且，DBA行业的最高级别认证，也是属于Oracle认证体系的。
更重要的是，取得一门认证，对于你的DBA生涯的发展而言，是大有裨益的。所以，去取得认证吧。
4、获得技术资源库
对于DBA而言，Technet账户是必须的。这是众多DBA少有的技术、资源交流聚集地。在共享Oracle知识，分享Oracle资源的同时，也能够寻找并获取对你而言有价值的Oracle资源。
5、更多的交流
随着新一代互联网技术的兴起和发展，越来越多的新奇的交互手段层出不穷。即时交流工具、新闻组、论坛、irc、聊天室，都可以成为DBA们交流的舞台。但是，传统的新闻组和论坛，依然保有无可比拟的技术优势，可以回答你提出的数据库问题。真正优秀的交流社区，数据库高手们是乐意与你分享他们的技术经验的。
Usenet newsgroup------comp.databases.oracle.server和comp.databases.oracle.misc，这是两个世界性的Oracle数据库技术新闻组。当然，需要比较好的英文功底。
Quest Pipelines------中等的Pipelines，笔者的最爱。
五、成就高级DBA
高级DBA更多的时候，被人成为数据库专家。经过长期的学习和实践，你已经准备好像高级DBA发起冲刺了。如果准备好了，下面的内容将帮你在DBA的道路上走得更远。
1、阅读数据库技术文档
对于DBA而言，真正的技术宝库，就是数据库厂商给出的官方技术文档几乎所以的技术理论都涵盖到这些技术文档中。而且，原版的技术文章更具价值。目前市面上，几乎所有的数据库书籍都是技术文档的解读。当然，这需要你有过硬的英文阅读能力。而且，每个版本的技术文档都有区别。Oracle Database 11g就在Oracle Database 10g的基础上，加入了11g的新特征和新技术。当然，有的高级DBA并没有读过技术文档，这在很大程度上，只是特例。如果一个版本的技术文档，你通读至少12次以上，相信每次都会有新的感悟，你也会逐渐了解到数据库真正的技术核心价值。
2、探寻各个领域的专家之路
高级DBA几乎是数据库领域真正的专家。而涉及到数据库领域，备份与恢复、调优等领域很多。从最简单的开始，尝试了解全部的技术手段和解决问题方案，尝试成为这个领域的专家。之后再逐渐扩展到其他领域。对于IT行业而言，技术更新换代的速度非常快，而以Oracle为代表的数据库厂商，都拥有自己强大的数据库技术研发团队。几乎每3个月，Oracle技术就会更新一次。去学习，保持技术水平的领先性，你一定能成为数据库专家。
3、继续参与社会化媒体的讨论
经过长期的学习和实践，相信你已经积累了自己的社会化媒体DBA技术交流平台。积极地去参与数据库技术讨论，将会让你在DBA的道路上走得更远。如果一个平台没有什么有价值的技术讨论，不妨尝试换一个平台。
4、总结自己的技术经验
学习只是一个成长的经历，总结才能在不断学习中，找出自己的不足之处。所以，以学技术白皮书的方式，去尝试总结自己多年来所学到的技术和积累的经验。不断梳理数据库技术和理论架构，你会发现，自己技术的不足之处很难有所建树。针对这些不足之处可以适当得强化和提高。当你尝试总结的时候，你会吃惊地发现，曾经都快遗忘的技术理论又开始出现在脑海里，这是非常美妙的体验。
5、成为Oracle解决方案专家
对于DBA而言，不断积累遇到的数据库问题，甚至是故意破坏数据库以探寻数据库疑难问题，是每个DBA几乎都要经历的过程。高级DBA基本都是Oracle解决方案专家，能够根据Oracle数据库出现各种问题，很快地提出解决方案。
6、成为Oracle性能调优专家
Oracle数据库日常问题的解决、性能优化，几乎成为了每个雇用DBA企业都十分关注的问题。性能调优对于企业而言，能够在很大程度上节约企业的成本。一个Oracle性能调优专家能够在很大程度上，以最优的Oracle数据库解决方案来实现最好的Oracle数据库存储。
7、成为承载能力计划专家
评估一个数据库的承载能力，几乎成为了高级DBA的必修课。如何准确预估数据增长量、交易增长量，从而更好的规划、设计数据库的承载能力，以最优的软硬件配置实现企业利益的最大化，这才是高级DBA的价值所在。
8、关注新技术
虽然，在国内，新技术的实现需要一段很长的时间。但是，尽早掌握数据库新技术，对于高级DBA而言是非常必要的。总有大型的企业，需要不断革新和改进自己的数据库技术，这就要求高级DBA不断关注新技术，学习新技术。