数据库运维平台？数据库运维服务具体有哪些
大家好，关于数据库运维平台很多朋友都还不太明白，不过没关系，因为今天小编就来为大家分享关于数据库运维服务具体有哪些的知识点，相信应该可以解决大家的一些困惑和问题，如果碰巧可以解决您的问题，还望关注下本站哦，希望对各位有所帮助！
什么是基础数据信息平台
一直想整理一下这块内容，既然是漫谈，就想起什么说什么吧。我一直是在互联网行业，就以互联网行业来说。
先大概列一下互联网行业数据仓库、数据平台的用途：
整合公司所有业务数据，建立统一的数据中心；
提供各种报表，有给高层的，有给各个业务的；
为网站运营提供运营上的数据支持，就是通过数据，让运营及时了解网站和产品的运营效果；
为各个业务提供线上或线下的数据支持，成为公司统一的数据交换与提供平台；
分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果；比如广告定向精准投放、用户个性化推荐等；
开发数据产品，直接或间接为公司盈利；
建设开放数据平台，开放公司数据；
。。。。。。
上面列出的内容看上去和传统行业数据仓库用途差不多，并且都要求数据仓库/数据平台有很好的稳定性、可靠性；但在互联网行业，除了数据量大之外，越来越多的业务要求时效性，甚至很多是要求实时的，另外，互联网行业的业务变化非常快，不可能像传统行业一样，可以使用自顶向下的方法建立数据仓库，一劳永逸，它要求新的业务很快能融入数据仓库中来，老的下线的业务，能很方便的从现有的数据仓库中下线；
其实，互联网行业的数据仓库就是所谓的敏捷数据仓库，不但要求能快速的响应数据，也要求能快速的响应业务；
建设敏捷数据仓库，除了对架构技术上的要求之外，还有一个很重要的方面，就是数据建模，如果一上来就想着建立一套能兼容所有数据和业务的数据模型，那就又回到传统数据仓库的建设上了，很难满足对业务变化的快速响应。应对这种情况，一般是先将核心的持久化的业务进行深度建模（比如：基于网站日志建立的网站统计分析模型和用户浏览轨迹模型；基于公司核心用户数据建立的用户模型），其它的业务一般都采用维度+宽表的方式来建立数据模型。这块是后话。
整体架构下面的图是我们目前使用的数据平台架构图，其实大多公司应该都差不多：
请点击输入图片描述
逻辑上，一般都有数据采集层、数据存储与分析层、数据共享层、数据应用层。可能叫法有所不同，本质上的角色都大同小异。
我们从下往上看：
数据采集数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。
数据源的种类比较多：
网站日志：
作为互联网行业，网站日志占的份额最大，网站日志存储在多台网站日志服务器上，
一般是在每台网站日志服务器上部署flume agent，实时的收集网站日志并存储到HDFS上；
业务数据库：
业务数据库的种类也是多种多样，有Mysql、Oracle、SqlServer等，这时候，我们迫切的需要一种能从各种数据库中将数据同步到HDFS上的工具，Sqoop是一种，但是Sqoop太过繁重，而且不管数据量大小，都需要启动MapReduce来执行，而且需要Hadoop集群的每台机器都能访问业务数据库；应对此场景，淘宝开源的DataX，是一个很好的解决方案（可参考文章《异构数据源海量数据交换工具-Taobao DataX下载和使用》），有资源的话，可以基于DataX之上做二次开发，就能非常好的解决，我们目前使用的DataHub也是。
当然，Flume通过配置与开发，也可以实时的从数据库中同步数据到HDFS。
来自于Ftp/Http的数据源：
有可能一些合作伙伴提供的数据，需要通过Ftp/Http等定时获取，DataX也可以满足该需求；
其他数据源：
比如一些手工录入的数据，只需要提供一个接口或小程序，即可完成；
数据存储与分析毋庸置疑，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开发，然后配置到调度系统就可以了，如果任务异常，会收到告警。这样，可以使更多的资源专注于业务之上。
请点击输入图片描述
数据库运维服务具体有哪些
数据库运维服务是指：针对用户数据库开展的软件安装、配置优化、备份策略选择及实施、数据恢复、数据迁移、故障排除、预防性巡检等一系列服务。
主要服务内容如下：
1、数据库安装与配置；主要指定制数据库安装配置方案，检查软件安装环境，安装数据库软件，完成数据库配置，并测试之；
2、数据库性能优化：主要是指核心参数调优，SQL语句调优，性能评估方案的提供。
3、数据库备份与恢复；主要是指本地、异地、同步、实时的分级备份与恢复方案及实施；
4、数据迁移：不同版本、不同厂商、不同结构数据库间的数据迁移；
5、故障排除；通过远程、上门等方式按服务级别实施故障排除
6、预防性巡检；定期提供预防性巡检，并完成系统参数、配置调优，及补丁分发、安装服务。
数据库运维做些什么
一.数据库生命周期结合软件生命周期、项目的开展，数据库的生命周期，大致可分为这么几个阶段。1.规划在立项后，对于数据库平台的软硬件选型，以及大致的数据库
一.数据库生命周期
结合软件生命周期、项目的开展，数据库的生命周期，大致可分为这么几个阶段。
1.规划
在立项后，对于数据库平台的软硬件选型，以及大致的数据库架构。
1.1配置多少台服务器，服务器的内存大小/磁盘空间、IOPS/CPU核数/网络带宽等；
1.2选择的操作系统与数据库产品，及相应版本；
1.3整体架构，比如是否考虑：HA,Scale out, load balance,读写分离等策略。
2.开发
开发的工作，通常是在测试环境上进行的，开发结束后搬到生产环境。
2.1数据库设计；
2.2 SQL编程及调试；
2.3开发过程中的SQL优化。
3.实施
开发的数据库程序到生产环境的部署。到这里，基本是项目上线了。后面就进入了运维阶段。
二.运维做些什么
从上面的图来看，运维是项目上线后的工作。看看从项目上线开始，运维都做了什么。
1.部署环境
1.1数据库安装（如果服务器太多，可以选择静默安装）；
1.2参数配置（实例、数据库参数）；
1.3权限分配（登录、数据库用户权限）。
2.备份/还原
对于数据库来说，有个可用的备份是非常重要的，防止有数据损坏，用户误操作等造成的数据丢失。保证了数据的存在，运维才有意义，否则其他工作做的再好也是白搭。
3.监控
对于运维来说，首先要保证数据库的运行，然后就是运行中系统的性能。所以监控主要分为这两点：
3.1数据库运行状态，有没有什么数据库中断或异常、错误或警告？
3.2数据库性能，有没有什么性能问题或者性能隐患？
4.故障处理
在监控过程中发现，香港服务器租用，或者系统用户反馈出来的数据库错误或者警告，进行诊断并修复。
5.性能优化
在监控过程中发现，或者系统用户反馈出来的数据库性能问题，进行优化。
6.容灾
容灾只是手段，香港空间，最终还是为了保证系统的可用性，通常选择的策略有：故障转移集群、镜像、日志传送、异地备份等。
如果在实施时，已经部署了容灾策略，那么这时只要做一些状态监视即可。
也有系统是在上线一段时间之后，才补充部署容灾策略的。
7.升级/迁移
7.1升级
通常是在本机进行，硬件不变，比如：更换操作系统、数据库的版本、打补丁；
7.2迁移
通常是需要升级硬件，比如：更换新的服务器，所以把数据库搬到新的服务器上；
也有在本机“迁移”，只是为了移动数据库文件的位置。
7.3迁移+升级
不过很多时候，都是在迁移中做升级，网站空间，也就是换了新的服务器，也换了软件版本。
8.健康检查
通常叫做巡检或者HealthCheck。可能是每天、每月、每年的。
事实上如果把巡检的内容做到每天、每小时、甚至每X分钟，那就是一个准实时的系统监控。
9.系统用户反馈的数据库问题
用户反馈出来的任何数据库问题，需要DBA去做处理，即便有时诊断出来并非数据库的问题。
从广义上来看，除去数据库开发外的其他任务，都应该算在运维职责之内。
问：那么数据库运维到底都有哪些日常任务？
答：把上面的每项任务要做的事情一个个罗列出来就可以了。
比如，数据库运行状态监控包括：数据库服务是否中断、磁盘空间、错误日志检查、数据库一致性检查、作业运行状态、索引碎片检查等等。
后面会逐个分解各项任务的详细清单。
三.运维过程中的问题解决
运维过程中遇到问题时，如果能够通过自己/他人的经验解决，那么固然好；
但如果没有解决思路的话，通常是这样去查：
1.查日志：操作系统/数据库/应用程序日志中，有没有相关的错误/信息提示；
2.查错误号：官方文档/网友分享中，有没有解决方案；
3.如果都没有找到，那么就中奖了，自己分析不出就团队分析，团队分析不出找官方支持，当然有的时候，官方支持也不是一定能解决。
注意：对于在线系统，这么慢慢查下去，时间可能消耗太久，会影响用户体验。通常是优先快速解决问题，那怕只是用临时应急方案，以保证系统的可用性，然后再去分析根本原因，彻底解决，以防止下次再发生。
本文出自“SQL Server DBA”博客，请务必保留此出处
数据库运维平台的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于数据库运维服务具体有哪些、数据库运维平台的信息别忘了在本站进行查找哦。