数极客首页

大数据运维的思考

一个企业的IT部门有业务和剖析

系统之分,这里就叫作OLTP和OLAP吧,IT部门普通
算是业务部门的乙方,而IT部门的OLAP系统则是OLTP系统的乙方,由于
OLAP系统处于OLTP的下游,普通
可用性央求

也不高,在传统企业内,CRM挂了是天大的事情,但同样的事情发作
BI等OLAP系统上则能够

容忍很长时间。

传统企业的OLAP系统偏重

对内支撑,除了必需
的消费
报表,不是必需品,更多像是朴素
品,有了可能好一点,没有影响也不大,比如

精确

营销。

随着大数据时期
到来,企业对内数据化、精益化运营的央求

越来越高, OLTP系统迫切需求
OLAP的剖析

力,OLAP则需求
嵌入到OLTP流程中发挥价值,两者相互

渗透

,我中有你,你中有我,OLTP与OLAP系统融合

的趋向
将越发明

显。

同时,很多企业开端
推进大数据价值变现, OLAP系统的位置
就发作
了基本

变化,即OLAP系统越来越跟企业的直接价值发明

相关,比如

以前OLAP挂了,只需
对内部客户做些解释或许
就能消化影响,往常

则会构成

外部客户投诉,在阿里等企业大数据平台挂了肯定是不可想象的事情。

置信
每年阿里双11前大数据平台运维的人会很忙,即便

照实
时大屏数字显现
这类都需求
强大的运维保证
才干

,而很多企业搞大型营销活动常常
只关注OLTP系统的稳定,OLAP系统的运维人员会悠闲的多,这是数字化企业和非数字化企业的差距。

DT的趋向
不会改动
,无论是对内还是对外,打造一个强壮

大数据运维体系必不可少,由于OLAP与OLTP特性
不一样,不是简单的照搬OLTP系统的运维方式就能够

了,需求
走出自己

的路,这里分享一下笔者最近关于大数据运维的一些思索

1、数据运维的组织架构

笔者阅历
过很多种BI运维组织架构,一种是开发和运维纵向一体化,BI没有交维动作,开发人员直接为维护担任
,在长达6-7年的时间,笔者所在的BI团队就是这种方式

,每个人依照

业务条线中止

划分,为这个业务条线的一切
数据担任

这种运维的效率其实是很高的,关于
个人的锻炼价值也很大,既做需求,也做开发,更做维护,还要会交流,但其最大的问题就是缺乏规范

,处置
过程不透明,无法中止

运维承诺,范围
很难扩展

第二种就是开发和运维完好

分别

,即横向切割,很多企业展开

到一定阶段,系统越来越庞大,IT部门为了保证
系统稳定制定了大量的规范

化规范

和流程,为了确保运维管理的集中高效执行,运维团队必需
从开发中剥离出来,传统的观念
以为
开发和运维的职责存在自然
的抵触
,需求
完成
制衡。

从笔者的阅历
看,这种BI运维方式

,从短期来看有效果,但长期看,存在着很多弊端,总体来讲,并不是最好的运维方式

开发和运维要完成
理想的交接,前提是交接的东西规范

化水平

要高,能够

说得分明

,通知
你这个东西不会变构成
其他东西,因而

,越稳定,越容易封装的东西越容易交接,也即越容易维护。

OLTP很多时分
是有这个特性
的,但OLAP系统则完好

不同,OLTP能分明

的说分明

提供了多少种效劳
,这些效劳
之间的关系怎样
,也即组合是能够

穷举的,但数据的指标和维度是如此之多,相互

之间的组合关系是无量
的,数据封装自身

就是个伪命题,数据要交维需求
的是关于
业务和数据的深化
了解

,而不是通知
维护这张表交给你管理,数据维护最大的一类工作数据质量稽核需求
代码级别的溯源才干

因而

BI要完成
理想交维常常
只需

一种可能,维护人员跟开发人员具备同样的技艺
,君不见核对
数据问题基本

是要开发参与的,只懂封装的数据运维人员除了能监控、告警、作业调度启停一下,可做的事情很少,因而

,这种浅层次的运维到底有多大的价值?

随着数据交维的东西越来越多,运维人员会疲于奔命,很多沟通调和

工作只是为了转述问题,一个问题的处置

流程会拉的很长,这种运维方式

称心

度其实很难提升,同时运维人员的专业技艺
也很难取得

增长。

第二种方式

短期来看的确

有效,由于
其经过
复用OLTP已有的机制、流程阅历

来取得

价值,但长期是有致命缺陷的,其缺乏生长
性,笔者不时

以为
运维是系统改进

的中心
驱动力,而不是由项目规划人员指东打西,很多时分
,规划人员提出的东西跟处置

运维的理论

问题相差甚远,谁对这个系统有真正发言权呢?或许
,专业才干

最强的人员应该放到运维,而不是开发、规划或项目,假定

稳定是企业最中心
的工作的话。

第三种方式

,笔者以为
是均衡

方式

,维护要对症下药

,倡导
中台类的系统、产品或数据中止

交维,创新、探求

、变动类的系统或数据不用交维,谁做的谁自己

管去。

何谓中台类的系统或数据,就是企业真正沉淀下来的资产,成熟一个,归入
一个,比如

基础

平台、标签库、基础

模型、融合

模型等, 关于
这类系统或数据,央求

能提出合理的监控和告警央求

并部署,运维团队要确保能自行处置
大多数的缺陷

,要能提出持续优化的倡议

,在未来

系统改进

上具有主导发言权。

2、缺陷

分级和缺陷

升级

流程

运维最中心
的就是缺陷

管理流程,这里从应用分级,缺陷

等级,升级

流程等方面给出一个理论
案例。

第一
,数据运维触及
平台、应用和数据等管理对象,这些对象又能够

依据

重要性划分为中心
、重要及普通
三个等级,以下是一个划分示例,供参考:

大数据运维的思索

每个企业应该依据

自身

理论

划分等级,诸如BDI是基础

平台,挂了数据就没法采集进来了,因而

是最重要,这里划分为中心
等级,数据类里有重要和普通
之分主要是这些数据跟重要应用相关,必需
划分为同一个等级,这个时分
血缘剖析

就很重要,需在知道

哪些数据跟这个应用相关从而判定

这个数据的重要等级,表现
的是数据和应用一体化的思想,数据变现事关直接纳
入,因而

这里也划分为重要等级。

这张表的设计其实触及
了很多的准绳
,包括平台保证
准绳
,收入优先准绳
,数据与应用分歧
性准绳
,表也是需求
动态维护的,每次纳管一个平台、数据或应用,就应该同步更新。

第二
,就到缺陷

的细致

分级了,我们将其划分为灰、蓝、黄、橙及红五个层级,第一
要思索
时间维度,即异常的持续时间,以下是一个示例:

大数据运维的思索

时间维度显然还缺乏
以表示缺陷

的严重水平

,还需加上影响范围,这里特别增加了数据完好
性这个影响指标,由于
假定

数据大范围的延迟,我们也以为
是个较大的缺陷

,即便

没有一个投诉:

大数据运维的思索

有了这些判定

规范

,维护在呈现
缺陷

时就有章可循,能够

依据

这些规范

明白
最终
的缺陷

等级,然后依据

不同的缺陷

等级走不同的升级

流程。

最终
,是一个缺陷

处置
升级

流程示例,明白
了什么时辰
需求
做什么事:

大数据运维的思索

以下是缺陷

短信发送对象的一个示例,缺陷

严重的时分
,需求
让老板知道

大数据运维的思索

3、数据采集保证

BDI(数据采集平台)当前采集接口2000多个,其中分钟/小时/月接口400多个,日接口1500个,日接口中重要接口300多个,采集接口触及
155个数据源(库),复杂度是比较

高的,必需
依据

接口重要性及时间央求

中止

及时性保证

以下是一个示例:2点前完成58%的“重要”级接口,4点前完成78%,6点前完成85%,8点前完成88%,12点前完成100%,鉴于集群计算性能时有动摇
,数据采集及时性保证
目的
设定各时段达成率90%以上,再不重要的接口,也要有个保证
底线,用数据来说话,很多企业的数据几个月没采集都不知道

,是由于缺乏明白
的保证
央求

数据精确

性方面也相似

,每个数据接口采集设置数据量动摇
性检查、空值检查等。

大数据运维的思索

4、数据作业保证

我们将大数据模型和应用数据的生成都归入
到DACP管理,包括融合

模型、挖掘

模型和数据应用大作业共计762个,其中月作业189个,日作业573个,日作业中重要级作业333个,依据

作业重要性及时间央求

中止

及时性保证
,其中4点前完成15% 的“重要”级作业,8点前完成65%,12点前完成85%。

大数据运维的思索

针对重要应用触及
的作业,设置了应用结果数据的质量检查机制,以便提早
发现问题,这里针对一切
变现类应用的数据做了动摇
性等告警设置,做这个事情主要是由于对外变现呈现
了多次

数据异动客户投诉的状况

,因而

尽量做到末雨绸缪,固然
不能处置

一切
问题,但能做一步算一步。

5、平台保证

基础

平台牵一发而动全身,企业曾经
大数据处置
平台归入
私有云统一运维体系,其他诸如采集平台和数据管理平台,必需
具备高可用,并能在短时间内中止

容灾切换,这是运维的底线。

大数据运营刚开端
的时分
,我们在数据管理上还是偏重

于去处置

采集、建模等问题,往前冲的比较

多,在创新上花了不少心机
,但随着运营深化
,运维逐步

成为数据管理最为中心
的工作,由于
假定

没有这个强壮

的“1”,一切
的工作都将失去意义。

最终
谈一点体会

和我们走过的路一样,很多企业BI的运维依然

像个羞答答的姑娘,很多没有明白
规范

,比如

每个接口的及时率央求

,很多杂乱无章,比如

不知道

某个数据的影响大小,很多规范

没有真正落地,比如

投诉的统一归口,大多时分
还是需求或开发人员去直面业务人员的问题。

固然
其实处置
的效率也不错,但作为管理者心是不安的,由于
很多投诉变得没有痕迹,很多问题曾经
被掩盖,意味着很难去评价真实的运维水平

,也意味很难去提升,数据管理者就这样被过顶传球了。

数据运维最怕的也不是出事情,而是完好

的事务驱动,总是去救火,投更多的人去救火,却很少有人能从运维的角度提出真正的问题和改进

央求

,这个可比救火难多了, 100个接口的时分
,假定

我们不去做规划和管理,到1万个接口的时分
,可能曾经
来不及了,所谓根深蒂固

大数据是新的机遇

,关于
运维也是重新的开端
,未来

的应战
很大,与大家共勉吧。

发表评论

评论已关闭。

相关文章