您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
DataOps数据仓库与建设
 
 
  1475  次浏览      14
 2021-7-23 
 
编辑推荐:
本文主要介绍了主要介绍大数据运维在建设DataOps数据仓库和ETL工程的思路。
本文来自csdn,由火龙果软件Linda编辑、推荐。

1.引言

当前业界都在畅谈AI、大聊AIOps,其实坊间有这样的说法——要做AI先做BI。正所谓“巧妇难为无米之炊”,AI需要数据输入,Data则是重中之重,这也是我们定义建设DataOps的初衷。下文将主要介绍大数据运维在建设DataOps数据仓库和ETL工程的思路。

2.数据视角VS运维排查

当一个交换机出现故障,SRE去排查问题的时候往往是执行一堆命令最后根据命令的结果做出结论性的判断。实际上这里有2个步骤:

是数据采集,即执行命令.

逻辑判断(根据前面执行的命令结果,如果能判断出问题则停止,否则继续执行步骤1)

那么,有没有办法让2个步骤真正解耦?

如果我们已经把相关联的数据提前采集到了数据仓库,这样的过程就变成了执行SQL进行问题排查了。那么从ETL的视角看,排查问题过程是这样的步骤:

数据采集-> 数据仓库

通过SQL排查系统问题

有同学一定会疑惑, 下面的ETL过程来排查问题,必须要求数据仓库里必须有全量的数据啊,我们该如何来建设这个全量的数据呢?

实际执行的时候,一味追求大而全的数据是不可取的,我们可以从2个方向作为出发点,基于现有数据建设数据仓库:

根据运维经验,认为需要采集的数据,且比较容易采集到的数据。

根据历史出现过的问题,复盘来看,哪些数据值得采集。

运维数据类型

在数据仓库的建设中,要充分认识我们有哪些数据类型;知己知彼,方能百战不殆。

元数据:元数据是相对静态的数据,一般用于描述对象的若干属性。 比如机器的各种信息(主机名、ip、机型等)、集群(集群名称、对应的IDC、软件版本等)。

运行时(度量):运行时一般是跟时间相关的数据,是动态的数据;比如机器运行过程中产生的指标、日志、事件等。

理解这2种基本的数据类型,对于我们建设数据仓库是有帮助的, 在建设这两类数据时,应充分考虑两者的特性:

元数据对准确度有非常高的要求,需要做准确度的强保障;而存储的数据量又是比较小的;

运行时数据对准确度要求相对较低,但对实时性和规模化存储计算要求较高.

3.统一数据分层规范

在数据仓库理论中,前面我们提到的元数据称为DIM(维度),运行时对应到ODS(原始数据)。

我们的数据仓库建设需要按照原始数据+维度数据的方法来构建,以减少数据构筑的重复性工作。

举个例子,我们现在有一份原始数据是机器的进程OOM日志记录。里面大概包含这样的信息。

这时SRE A需要分析哪种进程在什么样的kerenl下比较容易OOM,他会把进程OOM日志记录和机器信息表做Join,进而拿到进程OOM和Kernel的关系,得出相应的结论。

假设SRE B需要分析哪种进程在什么样的内存配置下比较容易OOM,他也会把进程OOM日志记录和机器信息表做Join,进而拿到进程OOM和内存大小的关系,得出相应的结论。

SRE A和SRE B 做了一件同样的事情,是把进程OOM记录表和机器表做Join,然后分别得出结论。我们可以想象,再来一个分析场景可能还要再Join一次。

那么如何避免重复的工作?

答案是:采用分层模型,以上面的例子来看,我们把OOM记录表和机器表Join后的表打造成一个宽表,即包含了未来可能分析到的所有维度的表,那么后续进一步分的分析工作都可以以这张宽表为基准了。

好,我们现在来正式理解一下整个过程, 我们把采集过来的数据叫做ODS层,把维度相关的称为DIM层(比如刚才机器的一些静态信息,如CPU、MEM配置),这时候ODS层的数据和DIM层的数据做JOIN,就把ODS层的数据扩展了,产生了维度比较丰富的数据,我们叫做DWD层(也就是我们上面的“宽表”)。之后基于DWD层的数据,按照若干个维度来打造就可以形成DWS层(汇总层),也可以经过一些ETL过程变成适合应用的数据,同步到业务数据库去使用。

好,我们现在来正式理解一下整个过程, 我们把采集过来的数据叫做ODS层,把维度相关的称为DIM层(比如刚才机器的一些静态信息,如CPU、MEM配置),这时候ODS层的数据和DIM层的数据做JOIN,就把ODS层的数据扩展了,产生了维度比较丰富的数据,我们叫做DWD层(也就是我们上面的“宽表”)。之后基于DWD层的数据,按照若干个维度来打造就可以形成DWS层(汇总层),也可以经过一些ETL过程变成适合应用的数据,同步到业务数据库去使用。

4.数据的时效性的权衡

运维场景对数据实时性的要求永远是贪婪的, 数据越实时,付出的资源和ETL复杂度的代价越大。因此,并不是所有的数据我们都要实时化,需要根据真实的场景和需求,选择合适的时效性。

一般而言, 涉及到运维决策类的场景,时效性要求是比较高的,建议使用实时的方案;而对于报表类的场景,一般用T+1的方式去做即可。

5.小结

数据仓库已经有一套成熟的技术和理论了,如何将运维与数据仓库建设结合好,打造出适合DataOps的数据仓库,实际上是一个旧瓶装新酒的问题。 让数据仓库理论在Dataops中充分体现,让DataOps的实践驱动SRE运维智能化的程度,也是我们在不断探索和追求的目标。

   
1475 次浏览       14
相关文章

基于EA的数据库建模
数据流建模(EA指南)
“数据湖”:概念、特征、架构与案例
在线商城数据库系统设计 思路+效果
 
相关文档

Greenplum数据库基础培训
MySQL5.1性能优化方案
某电商数据中台架构实践
MySQL高扩展架构设计
相关课程

数据治理、数据架构及数据标准
MongoDB实战课程
并发、大容量、高性能数据库设计与优化
PostgreSQL数据库实战培训
最新课程计划
信息架构建模(基于UML+EA)3-21[北京]
软件架构设计师 3-21[北京]
图数据库与知识图谱 3-25[北京]
业务架构设计 4-11[北京]
SysML和EA系统设计与建模 4-22[北京]
DoDAF规范、模型与实例 5-23[北京]
 
最新文章
InfluxDB概念和基本操作
InfluxDB TSM存储引擎之数据写入
深度漫谈数据系统架构——Lambda architecture
Lambda架构实践
InfluxDB TSM存储引擎之数据读取
最新课程
Oracle数据库性能优化、架构设计和运行维护
并发、大容量、高性能数据库设计与优化
NoSQL数据库(原理、应用、最佳实践)
企业级Hadoop大数据处理最佳实践
Oracle数据库性能优化最佳实践
更多...   
成功案例
某金融公司 Mysql集群与性能优化
北京 并发、大容量、高性能数据库设计与优化
知名某信息通信公司 NoSQL缓存数据库技术
北京 oracle数据库SQL优化
中国移动 IaaS云平台-主流数据库及存储技术
更多...