精华内容
下载资源
问答
  • 百度开放云张琪:开源大数据系统运维不会永远是核心竞争力
    2016-05-19 17:49:16

    2016中国云计算技术大会(CCTC 2016,专题报道)上,百度高级产品经理、百度开放云大数据平台产品负责人张琪做了题为《大数据时代的数据仓储实现技术实战》的分享,并接受CSDN记者专访,深入介绍百度在大数据平台技术和产品化方面的实践经验,包括在人工智能以及物联网(IoT)相关的一些努力。

    张琪认为,大数据的利用重要的是产生洞察力,而不是系统运维能力。百度开放云是百度技术输出的窗口,对企业而言大大降低了运维的投入,其上的大数据平台提供各种大数据工具以灵活地应对结构化与非结构化数据处理的需求,并基于这些工具也搭建了一些大数据应用,包括人工智能、物联网的服务。未来,百度开放云会将托管集群服务PaaS化,并基于IDL的研究、百度的数据和训练提供更多的人工智能API。

    图片描述

    百度高级产品经理、百度开放云大数据平台产品负责人张琪

    百度大数据:从踩坑到服务

    CSDN:请简单介绍下您和目前的工作,以及关注的技术领域。

    张琪:百度是一家技术公司,希望通过百度开放云这个窗口把百度把技术输出。我现在负责大数据的产品,包括托管Hadoop服务BMR、数据仓库服务Palo和托管机器学习服务BML等;基于这些工具,我们还搭建了一些解决方案,用于数字营销等各种业务场景。

    CSDN:这些工具和产品的研发打磨,您认为最大的挑战是什么?

    张琪:百度开放云只是做云端的服务,中国的整个企业和开发者,对于上云是有一些顾虑的,会由于不熟悉而产生一些想法,包括安全等。其实从整个产业往前看,云端是不可逆转的趋势,接受托管服务可以避免运维。按需购买,很快就能够获得一个集群,不像在企业内部,从批预算、采购、搭建、部署,整个流程非常长,所以企业和开发者应该更多地拥抱云端,更早地占据优势,在商业上占据先机。

    另一方面,企业对开源技术感兴趣,这是一个非常好的举动,但到底是花费精力在运维上,还是通过这些技术来获得企业的洞察力,找到一些别人没有的知识?我认为后者才是核心,运维大数据平台并不是核心竞争力——若干年前帮别人安装一个Windows操作系统就能赚很多钱,放到现在就是笑话——大数据目前正处于这样的时代,运维或者说踩一些坑看来是一个很高级的事情,这其实只是一个过程,最终还是要通过这些工具,把数据分析出别人所不知道的洞察力,这才是真正的核心价值。这也是需要(和用户)沟通的。

    CSDN:到目前为止,百度开放云踩过的哪些坑让您印象最为深刻?

    张琪:百度开放云的整个策略,要么我们提供开源产品的运维,如Elasticsearch、Hadoop等;要么是自研一些产品,同时提供一些开源兼容的接口,如Palo兼容MySQL。前者的坑会更多,开源产品的好处,是从代码的层面来说是免费的,没有成本,但真正使用的时候会有这样那样的坑。百度虽然不是那些开源技术的发明者,但是是最早的实践者,在实践上做了很多,根据业务的需要踩过各种各样的坑,把这些坑填补之后,我们才放到开放云上提供托管服务。可以说百度踩过的坑不计其数。不说血泪史,我们希望跟用户说的是,自己不要去踩,跟我们一起合作共同成长,我们会把坑踩了,把成熟的服务再分享给大家。

    CSDN:把支撑百度内部业务的技术和产品拿出来,做成能够开放的托管服务,还需要做一些附加的开发工作吗?

    张琪:那是肯定的。百度开放云背后的技术,也是百度自己使用的技术,但是由于百度有很多水平很高的工程师做运维一些小工具或者说有一些代码自己开发就可以满足运维需求了。但是在云端使用的产品是完全不一样的,比如说从一个系统产生的数据,怎么灌到另外一个系统中去,这其中需要注意什么,这些就是百度在提供产品之外要提供的解决方案,把这些东西配套使用。打一个比方,产品就像是乐高积木,但积木怎么有机组合,真正地解决客户业务场景中的问题,这是百度想要做的。

    数据仓储就是一个很典型的例子。有的用户说我可以拿Hadoop做,有的用户说用传统关系型数据库就能解决,但是两者在技术上其实各有优略,应该怎么选型,能否结合起来使用,上面怎么用BI工具来做可视化的交互式查询,这些坑,或者说这些结合,是百度很核心的商务能力。对于客户来说,希望他们能够真正地专注于自己的业务,而不是说要到处去踩坑、选型,那不是他们核心的能力。真正能快速地解决企业的商务目的,这是百度开放云技术内部使用和外部使用最大的不同,我们做的是2B的业务。

    数据仓储:未来PaaS化

    CSDN:传统的数据仓储提供商有更多2B的经验,也在做云化,也和开源结合。采用传统技术的升级版,和采用百度开放云的数据仓储技术,有多大的差别?

    张琪:我是这样理解的,传统的数据仓库非常成熟,是没有问题的,但是百度是一个互联网公司,我们做同样的技术,但是是不同的实现。

    1. 首先我们的关系型数据库是基于MPP的,但是下面没有定制的机器,用的是面向云端的商品化的硬件,就像Hadoop不一样,下面是普通的x86机器,甚至我们可以用虚机来搭建这个系统,所以成本是传统技术的1/10,甚至更低。

    2. 在云端我们强调的是托管服务,传统采购集群硬件、采购软件许可,要扩容的时候,整个流程会非常长,但是在云端,一个滚动条往右边/左边一滚,集群就可以扩容/缩容了,甚至业务不需要数据仓储的时候可以把它给关掉,只支付使用部分的费用就可以了。

    所以从整个的性价、敏捷性来说,云端的优势是更大的。

    CSDN:百度开放云的数据仓储还关注哪些特性?

    张琪:以下几点是我们在设计这个产品的时候看得比较重的。

    1. MPP架构已经比较成熟,在云端我们还是结合托管服务,整个运维都在百度开放云上,不需要企业操心,不像企业内部使用Teradata或者类似的产品,需要专门的人来运维,做24×7×365的运维保证系统不间断。

    2. 接口的兼容也是百度非常看重的一点。百度数据仓储也是提供了MySQL的兼容,用MySQL Workbench直接就连上去,和连接MySQL是一样的,所有的输入查询,结果就立刻出来。

    3. 和Hadoop集群的交互,我们觉得也是一个优势。有些传统企业的做法,是通过一个一体机,可以用Hadoop,也可以用MPP,可以做交互,甚至可以做SQL的联邦式查询(Federated Query),但我们在云端就比较的灵活,这边是一个托管Hadoop集群做处理,那边是一个托管的Palo,它们通过存储来交互,这样就把两者的优势结合。

    CSDN:还有一个比较重要的方面就是数据建模,百度开放云有什么经验可以分享?

    张琪:这个还是结合具体的场景。

    1. 传统的企业数据,如ERP和eHR里面的数据,都是很结构化的,这样的数据,建模的时候,还是按照传统数据仓库的星型模型建模,这样的模型可以几乎1:1打到Palo里面直接使用,报表工具或者BI工具,不用修改任何代码就可以进行分析,但是速度会提高非常高的倍数。

    2. 弱结构化的数据,如日志、视频、舆情等方面的数据,更适合用Hadoop来处理,这个时候Hadoop的建模就不要多表,Hadoop上大多数的OLAP系统做JOIN其实不是擅长的。这样的数据结构,索性做成一张大表(有一点冗余也没问题,HDFS很便宜),然后分区来进行查询,效果会比较好。

    传统的数据用结构化的Palo,而新型的非结构化或弱结构化数据用Hadoop技术,在做结构化的处理之后,如果对查询的速度要求更高,导入到Palo里面也是可以的。

    CSDN:百度开放云数据仓储未来重点关注哪些技术?

    张琪:我们今天很多的服务都叫做托管集群,如Hadoop集群、Palo数据仓库集群,仍然可以看到集群的概念。百度会慢慢地是把很多技术要PaaS化,比如说在自己的Spark SQL集群上做一个复杂的查询,首先需要先把计算能力扩容之后才能够计算,我们有一个产品叫做BigSQL,你只要把数据放在存储上,直接输入query,就有可能用尽量多的资源进行快速计算,然后把结果给到你,我们把开源的产品PaaS化,之后不是按照集群来计费,而是按照使用来计算成本,这样对于客户来说成本就会低很多。

    人工智能:基于业务痛点研发

    CSDN:人工智能方面,百度开放云有哪些比较成熟的应用?

    张琪:人工智能是百度非常大的特点。我们结合自己的优势,提供工具层次的和服务级别的产品。

    1. BML是一个分布式机器学习运行框架,或者说托管服务,提供了很多的机器学习模型,包括深度神经网络算法在里面。

    2. 百度有吴恩达的实验室,我们很多时候把底下的算法,和用来训练的原始数据,进行建模之后,把模型进行输出。目前百度开放云上有图像识别、语音识别等,将来会开放人脸识别、文字识别,可以做一些主题的萃取,把后面的人工智能服务和底层的数据训练好之后,做成为一个托管服务,或者说以分析即服务的形态发布出来。

    所以我觉得我们是比较灵活的,如果你需要下面运行的模型,你自己有数据,你自己去训练。另外有一些非常常用的场景我们都训练好了,比如说要识别一个驾照,用百度OCR的服务,就可以出结果。

    CSDN:目前有没有一些实际的应用案例?

    张琪:这是非常多的。

    • 比如前一段时间,一家餐饮店用了百度的度秘——度秘是百度推出的为用户提供秘书化搜索服务的机器人助理,它能够基于百度的搜索及智能交互技术,借助机器不断学习和替代人的行为——有了度秘之后,餐饮店的客户可以通过自然语言直接下单、支付,然后到前台拿了东西就可以走了。而以前都要跑到柜台去点单,支付和找零都很麻烦。

    • 再说一个具体业务上的实现,我们和一家保险公司合作,通过基于深度学习的机器视觉技术,帮助这家公司从用户驾照很快地检索到上面的重要信息,不用人工输入,节省了大量的人力。

    • 再说一个比较远的,就是无人车,其中整合了视觉分析、听觉分析等很多人工智能方面的东西。百度在无人车方面已经做了很多探索。

    CSDN:未来还有什么样的规划?

    张琪:我想还是结合我们在深度神经网络方面的优势,逐步把我们内部的一些能力开放出来。借助吴恩达一句著名的话,就好比造火箭要有原料有引擎,大数据是下面的原料,而云计算是引擎,两者结合之后,才能够使整个人工智能有更多的发展。因为深度学习和原来的算法不一样的地方是在于,(模型性能)不会随着数据量的增长而衰减,几乎还是呈线性关系的,所以我们会利用百度本身的大量数据,包括图片、文字,形成更精准的API发布出来,帮助我们的客户更方便地拥抱大数据和利用人工智能,在业务上做得更先进。

    CSDN:来自吴恩达团队的技术研究成果,和百度开放云上成功的商业化产品之间,有什么样的鸿沟需要跨越吗?百度如何跨越?

    张琪:一个好的技术需要产业化帮助到客户,最核心的一点是对客户和市场的理解,如果脱离客户的需求去做一些高大上的研究,意义不是很大。对百度来说,要弥补这个鸿沟,一个很好的方法就是和市场、客户进行更多的交流,基于一个具体的场景来解决业务的需求和痛点,这是百度把人工智能技术产品化最好的方法。

    物联网:数据化的关键

    CSDN:百度展台也展示了IoT托管服务,大数据平台为什么需要IoT的能力?

    张琪:因为我们看到整个物联网正在蓬勃发展。除了各种智能家居产品,其实物联网在工业、农业上发展得非常快。例如,之前很多农村扶贫措施可能就是直接钱,现在一些企业的做法是,我把一些小鸡苗给你来养,并让我的消费者在很远的地方就可以看到这个视频,甚至可以随时了解鸡的大小、重量、温度、通风情况,形成很好的绿色食品提供给消费者,同时农民也不是钱用完了就没了,而是获得了一个高附加值的能力,而把这个流程打通的一个关键就是物联网技术。

    基于物联网,我可以通过的远程的感知器,设置通风的情况,可以设置小鸡在喝水时自动称体重,能够把这一切数据化,一方面可以远程做监控,更重要的是通过数据分析能够知道怎么进行更好的饲养。(养殖)数据化是我们非常欠缺的,而物联网能够帮助实现这一点。通过对感知器、传感器产生和收集的大量数据进行分析,农民和饲料企业能够从中找到洞察力。

    百度非常看好这一点,所以推出了一个基于MQTT的原生IoT服务,能够享受MQTT的很多特性,包括Pub-Sub等。业界的另外一种做法,是有一个类似于消息系统挂到一个转接服务,看上去是MQTT,但是不是原生的,则无法实现这些。

    总结

    张琪介绍了百度的大数据技术视野,包括百度在IaaS、PaaS和SaaS层的一些努力和未来规划,以及百度选择各种技术路线的思路:解放企业和开发人员,真正地解决企业业务场景中的问题。百度开放云提供的大数据服务,希望让企业和开发人员脱离后端运维工作,更快速地实现大数据应用,从大数据中获得商业洞察。当然,开发人员也要了解各种新技术,以便对云服务做出最合适的评估和选择。而对于新技术的学习,张琪推荐了采用阅读最新论文的方式——每周至少看两篇论文。

    更多相关内容
  • 一.大数据运维与架构课程体系 1.0课程与老师介绍 ...课程以企业大数据集群运维实战和招聘需求为出发点,深入浅出,有重点地为大家系统化地讲解整个大数据运维需要的知识点,实战教学,多年运维经验分享

    一.大数据运维相关答疑与概述

    1.0 Class介绍

             本课程是专门培养大数据运维与架构方向专业人才的体系化课程。课程所有讲师小伙伴全部是在职的知名企业大数据开发专家,大数据技术专家职位员工,非专门的培训机构老师(小伙伴当前在职企业阿里巴巴,哔哩哔哩,平安集团,苏宁易购,美团等,运维集群规模大到10000+节点,课程内容可以满足市面上80%以上企业的大数据运维工作)。

            课程以企业大数据集群运维实战和招聘需求为出发点,深入浅出,有重点地为大家系统化地讲解整个大数据运维需要的知识点,实战教学,多年运维经验分享,拒绝demo教学,让学员在大数据红利时代,顺利拿到高薪,华丽转型职业。

    1.1 为啥是大数据运维课程not大数据开发?

    1.企业中大数据运维的职责,干什么的?

             其实对于主流的中小厂来说,大数据运维其实主要就是负责(数据中台)大数据平台的建设(集群搭建这种都是小概率,一般公司集群都搭建好了),集群的维护,调优,升级,监控,故障排查处理,其次解决大数据用户(开发)使用集群的日常一些问题等,保障生产上的SLA。相对来说不接触业务层面。当然小公司因为没有基础运维,所以你需要掌握一些基础运维的工作,比如服务器系统的安装等等,不过这些问题都比较简单,用工具批量化模板化处理即可,当然小公司一般上云的比较多,自有服务器成本高,维护麻烦,所以一般不牵扯到硬件问题。

             故:小公司的大数据运维≈大数据集群/组件运维+基础运维

            但是对于大厂来说一个数据中台都是上百人的规模,以某站为例,负责各个组件的开发都有很多人,会要求更加严格的术业有专攻,分工更加明细。比如你们几个就做主机层面的监控,你们一拨人就做hbase组件的二次开发维护优化。中大型公司如果是自有服务器,一般都有专门的基础运维,管理底层的网络架构,服务器维修处理,硬件布置,系统的安装,权限的管理等等。大数据运维更偏向于大数据生态的大数据应用运维。

            故:中大型公司大数据运维≈大数据组件/应用的运维

    2.为啥选择大数据运维课程而不是大数据开发

    https://img-blog.csdnimg.cn/20210923181733479.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5rak55Sf5omL6K6w,size_20,color_FFFFFF,t_70,g_se,x_16

            小厂来说,有些大数据部们就几个人,开发和集群运维管理都是一起的。你懂集群,懂组件优化,做大数据开发很容易,就是熟悉一些函数结合业务应用。反之,开发做运维很难。懂集群运维管理去中小公司找公司更加有优势,他们更看重这点。

            当然这些大数据运维课程学完,你也完全可以胜任一些大数据开发工作,如果你想转行大数据开发也很容易。后面我们会上大数据开发课程,其实大数据开发和大数据运维课程很多跟运维课程是重叠的,只是掌握的着重点不同。  

    1.2 开Class的目的

            当前小伙伴都是企业在职的,对技术也有一定的沉淀。给大家攒到一起开课的目的之一就是为了赚点散碎的银子,小金库私房钱(小伙伴年薪总包都在40w以上了)。所以为了保障课程的质量,本着负责任的态度,课程的收费不会特别便宜,不适合白嫖。其次希望通过我们的技术教学,对有需要的小伙伴有所帮助,在高性价比的投入下能找到一份高薪的工作。

    • 如果你是大学计算机/网络/通信等大类相关专业毕业,毕业两年以上薪水还没有达到20k,对现在工作,薪水不满意,可以考虑下我们的课程,我们有信心让你实现小目标!
    •  如果你是非计算机大类相关专业想转行进入IT,当前薪水没有20k也可以,但是相对难度会大点,虽然说IT相对最不看重出生,但是很多企业会要求专业属于IT大类相关专业,尤其是头部大厂。当然小厂一般只要能干活,技术不错,这些都不是问题。毕竟中小厂占比80%,大厂才那几十家。我身边也有很多小伙伴是其他专业转行进入大数据行业的,也混的风生水起。

    1.3  课程适合哪些人群

    1. 传统IT运维人员,想升职加薪(最容易转行)
    2. 大专以上学历非科班想入行大数据的人
    3. 其他IT行业开发人员想转行大数据
    4. 在职大数据开发,运维想提升技术

            题外话,非常不建议小白自学。自学适合进阶的学习,网上最不缺的就是免费教程,甚至体系化的教程,但你见有几个小白靠免费教程自学后拿到高薪了,或者转行成功了。首先很难坚持下去,其次期间会遇到各种问题,苦苦摸索无法解决,其次学的知识都是零散的,不知道如何应用也不知道如何找工作,不是非要自己撞得头破血流得到的才是经验,专业的事交给专业的人做,就像考研政治大家都会报一个辅导班一样,有些事花点钱给中介黄牛去做不香嘛等。)

    1.4Class亮点与区别

    1.系统性知识体系,但有重点教学

            课程系统化全面化教学很容易,但是短时间内学员根本没法掌握,举个例子教你学英语,短时间带你把牛津词典翻了一遍,看上去全面,实际效果可想而知。所以本次课程会在系统化教学中告诉大家什么程度人应该掌握成什么样,比如工作2年的人应该掌握哪些,什么深度,5年的人该是什么样,让大家有重点的学习掌握,结合自己的实际情况掌握,而不是一视同仁没有重点的学习,最终都是万精油。学技术记住一句话,术业有专攻,要有专攻

    2.专注于实战,拒绝demo

            课程以完全企业生产模式教学,包含linux基础掌握,重点掌握,大数据集群规划,集群部署实施,集群调优(重点,没有性能瓶颈的调优都是耍流氓),集群监控管理,集群日常运维,大数据组件原理剖析,源码演示,二次组件开发等。小伙伴基于日常工作内容演示教学,学到的就是实战,学到甚至是很多小厂的人几年都没有的经验(接触不到)。实战才能让你学有所用,知道怎么用,才知道怎么学,也让你在面试中披荆斩棘。

    3.定制化学习,职业规划与辅导

            互联网时代学习最不缺乏的就是资源。因材施教,重点会针对每个小伙伴的情况,基本水平,确立职业规划,基于职业规划定制学习计划。比如有基础和没基础的人学习方式,学习深度肯定都不一样。我们会结合个人经验,企业实际招聘需求,企业实际应用情况会每个小伙伴定制化学习。

    1.5 Class相关问题解答

    1.课程授课方式与时间

            课程第一期授课方式以网络录播的视频为主,以部分直播为辅,定期更新,方便大家在不耽误现有工作的同时学习。注意课程其次最主要的是课后辅导,让你有问题可以及时得到解决,答疑解惑,帮你规划学习,定期check,抱团学习成长,一个人自学坚持还是比较难的,会有考核考勤,督促大家进步。

            课程我们预期3-5个月,看你实际的学习情况,结合大家整体情况会对课程的深度有所调整。课程我们第一期预期教学内容的价值在15k-30k工作薪水之间。所以第一期适合当前薪水低于25k的小伙伴报名。后面会上线高阶课程,所以课程非常适合收入低于20k的小伙伴学习。因为更高的薪水很难靠短时间培训了,我们也都是很多年的积累(学历+工作经历+工作经验)才拿到这个薪水。

    2.课程收费问题

            大数据开发课程,运维课程网上有很多,也有很多免费的,注意有些课程不全面,或者纯粹demo。也有专门培训机构在开课,平均课程授课时长4个月,价格平均2万左右。加上生活开销,吃喝住行,全职培训下来花费四万左右。也有纯粹网络视频课程卖1.5万元左右的(课后辅导)。当然也有分章节卖(没有辅导的)几百元课程,拍即发货。

            本次课程收费初步定价1000-3000之间(可能会有调整,结合成本,主要我们想让每一个小伙伴学有所成,也会针对小伙伴的情况进行减免)。我们的目标是绝对低于你学完课程后的单月薪资涨幅,让你的付出有回报。有些人不要看到收费课程就柠檬精,排斥,培训机构,培训课程式的看不起。上士闻道,勤而行之;中士闻道,若存若亡;下士闻道,大笑之,不笑不足以为道。最终判断的标准很简单,看自己的投入与产出比。

            注意,注意,注意,网络课程最重要就两点,其一课程质量,其二就是辅导,两者缺一不可,缺一都难走下去。没有辅导,如学习规划,答疑解惑,职业规划,简历指导,面试指导,更难走下去。所以小白建议要不选个靠谱的培训机构前天后地去学,要不一定要选择有辅导的网络课程。

    3.课程购买与课程的学习

          注意,无论是什么课程,最主要的还是靠自己学。就像国家扶贫一样,重点是扶,最终还是要靠自己努力改变命运,你要是自己躺在地上不起来谁都没办法人最难的就是选择,面对选择时会有迟疑,犹豫,彷徨,不安,因为选择意味着走出舒适区,意味着不确定。那首先要看你要不要选择,失去和得到的分别是什么,选择了就要义无反顾。这一点要想清楚,想明白。

         课程的重点都是我们自己设计的,自己录制的。但是也会根据小伙伴的基本情况,针对每个人私人定制规划,也会从网络上找一些篇章优秀的课程,讲的非常好的课程送给小伙伴自学或者深入学习,我们进行辅导,也会补充一讲解些核心的内容。

    二. 大数据运维课程框架与内容体系

         课程大致分成如下几个大类模块,现在比较粗放,很多细节会在教学中不断丰富完善。

            IT基础和linux基础这是大数据运维重点需要掌握的基础知识,尤其中小型公司大数据运维和基础运维职责区分的不是很细。当然这些重点掌握也要分了解,理解,掌握,有些命令知识知道就行,实际使用的去百度查询一下即可。不然一个linux系列可以深入讲2个月,但是实际很多是暂时用不着的,课程中会给大家标记出来,有重点学习即可,后期在企业中可以根据实际需求深入自我学习,初学者不要贪多。

    如下是课程模块大类和大章节,具体其中细节小类还在不断完善中,每个章节实际可能会分成多个细节小类课程讲解。注意,下面只有课程的大类和章节,实际的小类还没有完全编写完上线哈。

    1.IT基础知识运维与开发应知应会(大类)

       1.服务器构成,计算机,硬盘,内存,CPU等基础硬件讲解(章节)

            1.1 服务器基本构成,硬件组成原理扫盲(细节)

            1.2 生产常用服务器各种类型配置,价格,选型原则

            1.3 服务器核心cpu,硬盘,内存等讲解

            1.4磁盘阵列raid,raid0,raid1,raidn原理与介绍,实现

       2.硬件组成以及操作系统概念

       3.网卡,路由器,交换机,局域网,机架,IDC等相关知识讲解

      4.网络IP分类,DNS相关网络知识讲解

      5.云服务,虚拟机原理与应用等基础知识讲解

    2 需要的掌握的linux系统与shell编程

       1.linux入门概述与介绍

       2.vm,linux版本选型与安装实施

       3.linux生产配置与远程连接操作

       4.linux的文件系统介绍与配置讲解

       5.linux shell介绍与讲解

       6.linxu文件系统操作与相关命令分类讲解

       7.linux系统生产常用基本配置讲解与实施

       8.linux的内核了解与功能模块介绍

       9.linux权限管理系统与命令讲解

      10.linux生产运维与开发常用命令详解与演示

      11.linux磁盘管理,挂载与相关操作命令

      12.linux线程分析与相关操作命令

      13.linux文本文件处理三剑客grep,sed,awk详解

      14linux软件的安装,管理,卸载等

      15.linux yum仓库配置与相关命令

      16.linux定时任务,任务管理等相关操作

      17.linux远程挂载,NFS等相关操作

      18.shell编程基础语法讲解与演示

      19.shell编程常用高阶语法讲解

      20.生产常用shell脚本讲解与剖析,重点掌握

      21.PXE的使用介绍与生产应用

      22.ansible等工具生产应用

      23.linux的日志管理与审计

      24.linux的服务管理与生产应用

      25.生产常见问题分析与解决

      26.案例:生产mysql的安装,使用与简介

      27.docker.k8s等使用介绍与分析

    3.Hadoop大数据生态概述与集群搭建

            大数据本质就解决两件事:海量数据的存储和海量数据的计算。其他所有的组件都是围绕这两件事展开的。会根据企业的实际情况选用不同的组件实现,比如时效性,比如性能,比如成本而选型不同组件等等。这一章节主要是了解大数据生态的框架,基本情况,然后搭建基于cdh版本的集群,先不用深入了解组件的原理。后续基于此集群介绍其中组件的原理。

      1.分布式计算与分布式存储思想引入与讲解

      2.大数据生态概述,大数据生态前世今生

      3.大数据生态组件架构与组件功能初探

      4.见森林:大数据集群基本架构与功能模块介绍

      5.见树木:大数据集群架构选型与设计,部署实施流程

      6.基础cdh6.x大数据集群的生产搭建与部署实施流程

      7.cdh集群部署后必须调整的常见参数与优化注意事项

      8.cdh集群常见的操作与配置,指标查看与使用注意事项
     

    4.大数据生态组件原理初级剖析

            本章主要是剖析大数据存储框架,资源调度框架,集群计算框架的基本原理,要熟悉掌握部分组件的核心原理,架构情况。其中的操作,组件的原理剖析,应用实施都是基于上面搭建的集群。

            这里先不用着急掌握集群的调优,参数的配置,常见故障的处理等等。先掌握组件原理,基本应用,命令操作等。这一章节是核心章节,也是后面学习的基础。

    4.1 zookeeper组件

      1.zookeeper概述与数据模型,应用场景

      2.zookeeper的架构与命令操作

      3.zookeeper的原理剖析与集群架构介绍

    4.2 Hadoop之HDFS组件

      1.HDFS分布式存储概述与应用场景

      2.HDFS架构剖析,集群存储原理解析

      3.Namenode原理剖析与应用

      4.Datanode与Namenode的配合使用,文件读写流程

      5.Datanode的副本机制解析与存储原理

      6.HDFS的常用命令操作与演示解析

      7.HDFS高级管理员命令解析与演示

      8.HDFS集群的主从,主备剖析

      9.集群的机架感知,拓扑,联邦剖析与演示

      10.HDFS集群的扩容,退役,节点的管理等

      11.集群的安全,权限管理,用户管理等

      12.集群的元数据管理,解析,生产应用等

    4.3 Hadoop之MapReduce组件

      1.mapreduce概述,前世今生介绍

      2.mapreduce分布式编程模型剖析与原理剖析

      3.mapredcue分布式计算使用演示与解析

      4.mapredcue之map原理剖析

      5. mapredcue之reduce原理剖析

      6.结合案例代码解析MapReduce原理

      7.结合集群使用MR进行作业计算与监控管理

      8.MR常用的参数介绍与集群注意事项

    4.4 Hadoop之YARN组件

      1.YARN组件概述与原理初探

      2.YARN的架构剖析,组成原理介绍

      3.YARN三大组件之ResourceManager原理剖析与应用

      4. YARN三大组件之NodeManager原理剖析与应用

      5. YARN三大组件之APPMaster原理剖析与应用

      6.YARN调度器重点介绍与使用

      7.探查YARN集群的架构,管理,实施,应用

      8.YARN的监控,资源管理,常见操作介绍

    4.5 Hive/Impala组件

      1.Hive概述,基本概念,前生今生

      2.Hive的基本原理剖析,架构剖析

      3.Hive的常见生产操作,命令讲解演示

      4Hive的维护,集群的配置,操作,监控管理

      5.Hive的生产使用,项目剖析

      6.数据仓库概述,基本概念介绍

      7.数仓架构设计剖析,建模介绍

    4.6 Spark组件原理与常见使用操作

      1.Spark概述,基本概念,前生今生

      2.Spark的基本原理剖析,架构剖析

      3.Spark的常见生产操作,命令讲解演示

      4.Spark的维护,集群的配置,操作,监控管理

      5.Spark的生产使用,项目剖析,调优管理

    4.7 工具DataX、Sqoop,Flume组件原理与使用介绍

           这些组件都比较简单,实际结合情况使用。

    5.大数据集群的维护和优化

          大数据集群的优化维护并不像网上统一模板的答案一样,参数应该设置多少,开启什么参数。实际优化调优需要结合公司集群的实际情况,如负载,集群的架构,业务类型等不断尝试优化,所以要清楚集群组件的原理,参数的核心原理,这样才能结合实际进行优化。所以参数的优化,集群问题的排查都需要结合实际去处理,没有什么合不合适,只有好不好用,甚至需要结合业务对组件进行二次开发。

       5.1 HDFS集群的优化,参数调优

       5.2 HDFS集群日常运维监控管理

       5.3HDFS集群的常见运维问题排查

       5.4 YARN的优化,几十个参数调优

       5.5 YARN集群日常运维监控管理 

       5.6YARN集群的常见运维问题排查

       5.7 Hive/MR生产集群几十个核心参数调优,参数讲解

       5.8Hive/MR生产集群常见故障排查

       5.9 Spark生产集群调优,参数讲解

       5.10 Spark生产集群常见故障排查

       5.11 集群其他如zk等组件的优化与整体维护

       5.12大数据集群常见日常管理,工作剖析

    6. Hbase/Kakfa/presto集群的建设与生产维护,优化

       Hbase/Kakfa集群生产是相对独立的一套集群,依赖HDFS,有些公司有这个需求,有些公司没有这个需求,这里单独剖析,Hbase/Kakfa的原理,常见的操作,生产集群的配置搭建,优化,生产常见故障的排查。

       1. Hbase的组件原理学习,概述

       2.Hbase集群的搭建与配置优化

       3.Hbase的常见操作与原理剖析,应用

       4.Hbase生产集群的常见管理,调优,监控等

       5.Hbase集群常见故障分析,总结

       1. Kakfa的组件原理学习,概述

       2.Kakfa集群的搭建与配置优化

       3.Kakfa的常见操作与原理剖析,应用

       4.Kakfa生产集群的常见管理,调优,监控等

       5.Kakfa集群常见故障分析,总结

    7.大数据集群监控与告警建设

             集群的监控与告警是运维的核心,监控指标的采集,有主机层面的指标采集,服务层面的指标采集,这些监控指标是日常运维需要排查问题,解决问题,集群管理必备的数据。告警,简单来说基于采集的监控指标配置告警,集群出任何问题运维都能知道,分不同情况配置不同的告警,如邮件告警,钉钉告警,电话告警等等。

       1.集群监控采集,配置与处理

       2.生产集群服务监控与调优

       3.集群安全,权限管理

       4.Prometheus+Grafana+自定义

    8.集群运维实战与案例剖析(几十个生产案例)

            集群生产应用中面临者各种各样的治理,如存储治理,如何规范化使用,集群常见的治理有哪些?集群资源不足时如何进行治理,任务监控治理,元数据安全,元数据治理等等,如何模块化系统化治理,避免人为暴力治理。大集群如何规划,从硬件网络的规划,到管理规划,应用规划等等,可以剖析的地方很多。这里会结合上千节点集群的日常实战,几家公司的生产剖析,几十个案例逐一剖析。

      1.集群数据治理篇

      2.集群算力治理篇

      3.集群架构与规划篇

      4.集群管理篇

    9. 求职:面试题,简历与面试

           为什么你投递的简历如泥牛入海?为什么技术不如你的人顺利通过而你不幸被刷?为什么跟你差不多的人薪水职级比你高很多?同样的简历,如何给人耳目一新的感觉,如何避免简历投递踩坑。大数据面试不同阶段,不同职级的面试题分类总结剖析,公司面试模拟,一线企业面试官直接面试,模拟即实战。工作推荐,面试经验分享总结,薪资谈判,背调注意事项等等。避免大家最后100米踩坑。

      1.大数据运维面试题分类总结剖析

      2.简历编写一对一指导

      3.求职模拟面试一对一指导

      4.面试经验分享与工作推荐  

    毕业工作几年,月入还不到2万的建议速看_涤生手记-CSDN博客

    尖叫提示:双击放大图片即可查看详细内容

    展开全文
  • 作者:秦海龙,杭州以数科技有限公司大数据工程师。Java及Scala语言,Hadoop生态、Spark大数据处理技术爱好者。  责编:郭芮,关注大数据领域,寻求报道或投稿请联系guorui@csdn.net。 公安行业存在数以万计...

    声明:本文为《程序员》原创文章,未经允许不得转载,更多精彩文章请订阅2017年《程序员》。 
    作者:秦海龙,杭州以数科技有限公司大数据工程师。Java及Scala语言,Hadoop生态、Spark大数据处理技术爱好者。 
    责编:郭芮,关注大数据领域,寻求报道或投稿请联系guorui@csdn.net。

    公安行业存在数以万计的前后端设备,前端设备包括相机、检测器及感应器,后端设备包括各级中心机房中的服务器、应用服务器、网络设备及机房动力系统,数量巨大、种类繁多的设备给公安内部运维管理带来了巨大挑战。传统通过ICMP/SNMP、Trap/Syslog等工具对设备进行诊断分析的方式已不能满足实际要求,由于公安内部运维管理的特殊性,现行通过ELK等架构的方式同样也满足不了需要。为寻求合理的方案,我们将目光转向开源架构,构建了一套适用于公安行业的实时运维管理平台。

    实时运维平台整体架构

    • 数据采集层:Logstash+Flume,负责在不同场景下收集、过滤各类前后端硬件设备输出的Snmp Trap、Syslog日志信息以及应用服务器自身产生的系统和业务日志;
    • 数据传输层:采用高吞吐的分布式消息队列Kafka集群,保证汇聚的日志、消息的可靠传输;
    • 数据处理层:由Spark实时Pull Kafka数据,通过Spark Streaming以及RDD操作进行数据流的处理以及逻辑分析;
    • 数据存储层:实时数据存入MySQL中便于实时的业务应用和展示;全量数据存入ES以及HBase中便于后续的检索分析;
    • 业务服务层:基于存储层,后续的整体业务应用涵盖了APM、网络监控、拓扑、告警、工单、CMDB等。

    整体系统涉及的主要开源框架情况如下:

    另外,整体环境基于JDK 8以及Scala 2.10.4。公安系统设备种类繁多,接下来将以交换机Syslog日志为例,详细介绍日志处理分析的整体流程。

    图1  公安实时运维平台整体架构
    图1 公安实时运维平台整体架构

    Flume+Logstash日志收集

    Flume是Cloudera贡献的一个分布式、可靠及高可用的海量日志采集系统,支持定制各类Source(数据源)用于数据收集,同时提供对数据的简单处理以及通过缓存写入Sink(数据接收端)的能力。

    Flume中,Source、Channel及Sink的配置如下:

    # 为该Flume Agent的source、channel以及sink命名
    a1.sources = r1
    a1.sinks = k1
    a1.channels = c1
    
    # 配置Syslog源
    a1.sources.r1.type = syslogtcp
    a1.sources.r1.port = 5140
    a1.sources.r1.host = localhost
    
    # Kafka Sink的相关配置
    a1.sinks.k1.type = org.apache.flume.sink.kafka.KafkaSink
    a1.sinks.k1.topic = syslog-kafka
    a1.sinks.k1.brokerList = gtcluster-slave01:9092
    a1.sinks.k1.requiredAcks = 1
    a1.sinks.k1.batchSize = 20
    a1.sinks.k1.channel = c1
    
    # Channel基于内存作为缓存
    a1.channels.c1.type = memory
    a1.channels.c1.capacity = 1000
    a1.channels.c1.transactionCapacity = 100
    
    # 将Source以及Sink绑定至Channel
    a1.sources.r1.channels = c1
    a1.sinks.k1.channel = c1

    该配置通过syslog source配置localhost tcp 5140端口来接收网络设备发送的Syslog信息,event缓存在内存中,再通过KafkaSink将日志发送到kafka集群中名为“syslog-kafka”的topic中。

    Logstash来自Elastic公司,专为收集、分析和传输各类日志、事件以及非结构化的数据所设计。它有三个主要功能:事件输入(Input)、事件过滤器(Filter)以及事件输出(Output),在后缀为.conf的配置文件中设置,本例中Syslog配置如下:

    # syslog.conf
    input {
        Syslog {
            port => "514"
        }
    }
    filter {
    }
    output {
        kafka {
            bootstrap_servers => "192.168.8.65:9092"
            topic_id => "syslog-kafka"
            compression_type => "snappy"
            codec => plain {
               format => "%{host} %{@timestamp} %{message}"
            }
        }
    }

    Input(输入)插件用于指定各种数据源,本例中的Logstash通过udp 514端口接收Syslog信息;

    Filter(过滤器)插件虽然在本例中不需要配置,但它的功能非常强大,可以进行复杂的逻辑处理,包括正则表达式处理、编解码、k/v切分以及各种数值、时间等数据处理,具体可根据实际场景设置;

    Output(输出)插件用于将处理后的事件数据发送到指定目的地,指定了Kafka的位置、topic以及压缩类型。在最后的Codec编码插件中,指定来源主机的IP地址(host)、Logstash处理的时间戳(@timestamp)作为前缀并整合原始的事件消息(message),方便在事件传输过程中判断Syslog信息来源。单条原始Syslog信息流样例如下:

    147>12164: Oct  9 18:04:10.735: %LINK-3-UPDOWN: Interface GigabitEthernet0/16, changed state to down

    Logstash Output插件处理后的信息流变成为:

    19.1.1.12 2016-10-13T10:04:54.520Z <147>12164: Oct  9 18:04:10.735: %LINK-3-UPDOWN: Interface GigabitEthernet0/16, changed state to down

    其中红色字段就是codec编码插件植入的host以及timestamp信息。处理后的Syslog信息会发送至Kafka集群中进行消息的缓存。

    Kafka日志缓冲

    Kafka是一个高吞吐的分布式消息队列,也是一个订阅/发布系统。Kafka集群中每个节点都有一个被称为broker的实例,负责缓存数据。Kafka有两类客户端,Producer(消息生产者的)和Consumer(消息消费者)。Kafka中不同业务系统的消息可通过topic进行区分,每个消息都会被分区,用以分担消息读写负载,每个分区又可以有多个副本来防止数据丢失。消费者在具体消费某个topic消息时,指定起始偏移量。Kafka通过Zero-Copy、Exactly Once等技术语义保证了消息传输的实时、高效、可靠以及容错性。

    Kafka集群中某个broker的配置文件server.properties的部分配置如下:

    ########## Server Basics ###########
    # 为每一个broker设置独立的数字作为id
    broker.id=1
    
    ###### Socket Server Settings ######
    # socket监听端口
    port=9092
    
    ########### Zookeeper ##############
    # Zookeeper的连接配置
    zookeeper.connect=gtcluster-slave02:2181,gtcluster-slave03:2181,gtcluster-slave04:2181
    
    # Timeout in ms for connecting to zookeeper
    zookeeper.connection.timeout.ms=3000

    其中需指定集群里不同broker的id,此台broker的id为1,默认监听9092端口,然后配置Zookeeper(后续简称zk)集群,再启动broker即可。

    Kafka集群名为syslog-kafka的topic:

    bin/kafka-topics.sh
    --create
    --zookeeper gtcluster-slave02:2181,gtcluster-slave03:2181,gtcluster-slave04:2181
    --replication-factor 3 --partitions 3
    --topic syslog-kafka

    Kafka集群的topic以及partition等信息也可以通过登录zk来观察。然后再通过下列命令查看Kafka接收到的所有交换机日志信息:

    bin/kafka-console-consumer.sh--zookeeper gtcluster-slave02:2181--from-beginning
    --topic Syslog-kafka

    部分日志样例如下:

    10.1.1.10 2016-10-18T05:23:04.015Z <163>5585: Oct 18 13:22:45: %LINK-3-UPDOWN: Interface FastEthernet0/9, changed state to down
    19.1.1.113 2016-10-18T05:24:04.425Z <149>10857: Oct 18 13:25:23.019 cmt: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/3, changed state to down
    19.1.1.113 2016-10-18T05:24:08.312Z <149>10860: Oct 18 13:25:27.935 cmt: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/3, changed state to up

    Spark日志处理逻辑

    Spark是一个为大规模数据处理而生的快速、通用的引擎,在速度、效率及通用性上表现极为优异。

    在Spark主程序中,通过Scala的正则表达式解析Kafka Source中名为“syslog-kafka” 的topic中的所有Syslog信息,再将解析后的有效字段封装为结果对象,最后通过MyBatis近实时地写入MySQL中,供前端应用进行实时地可视化展示。另外,全量数据存储进入HBase及ES中,为后续海量日志的检索分析及其它更高级的应用提供支持。主程序示例代码如下:

    object SwSyslogProcessor {
        def main(args: Array[String]): Unit = {
            // 初始化SparkContext,批处理间隔5秒
            val sparkConf: SparkConf = new SparkConf().setAppName("SwSyslogProcessorApp ")
                .set("spark.serializer", "org.apache.spark.serializer.KryoSerializer")
            val ssc = new StreamingContext(sparkConf, Seconds(5))
            // 定义topic
            val topic = Set("syslog-kafka")
            // 定义kafka的broker list地址
            val brokers = "192.168.8.65:9092,192.168.8.66:9092,192.168.8.67:9092"
            val kafkaParams = Map[String, String]("metadata.broker.list" -> brokers, "serializer.class" -> "kafka.serializer.StringDecoder")
            // 通过topic以及brokers,创建从kafka获取的数据流
            val swSyslogDstream = KafkaUtils.createDirectStream[String, String, StringDecoder, StringDecoder](
                ssc, kafkaParams, topic)
            val totalcounts = ssc.sparkContext.accumulator(0L, "Total count")
            val lines = swSyslogDstream.map(x => x._2)
            // 将一行一行数据映射成SwSyslog对象
            lines.filter(x => !x.isEmpty
                && x.contains("%LIN")
    && x.contains("Ethernet")
                .map(
                    x => {
                        SwSyslogService.encapsulateSwSyslog(x) // 封装并返回SwSyslog
                    }).foreachRDD((s: RDD[SwSyslog], time: Time) => {
                // 遍历DStream中的RDD
                if (!s.isEmpty()) {
                    // 遍历RDD中的分区记录
                    s.foreachPartition {
                        records => {
                            if (!records.isEmpty) records.toSet.foreach {
                                r: SwSyslog => // 统计当前处理的记录总数
                                    totalcounts.add(1L) // 保存SwSyslog信息到MySQL
                                    SwSyslogService.saveSwSyslog(r)
                            }
                        }
                    }
                }
            }
            )
    
            //启动程序
            ssc.start()
            // 阻塞等待
            ssc.awaitTermination()
     }

    整体的处理分析主要分为4步:

    1. 初始化SparkContext并指定Application的参数;
    2. 创建基于Kafka topic “syslog-kafka” 的DirectStream;
    3. 将获取的每一行数据映射为Syslog对象,调用Service进行对象封装并返回;
    4. 遍历RDD,记录不为空时保存或者更新Syslog信息到MySQL中。

    Syslog POJO的部分基本属性如下:

    @Table(name = "sw_syslog")
    public class SwSyslog {
        /**
         * 日志ID
         */
        @Id
        @GeneratedValue(strategy = GenerationType.IDENTITY)
        private Long id;
    
        /**
         * 设备IP
         */
        @Column(name = "dev_ip")
        private String devIp;
    
        /**
         * 服务器时间
         */
        @Column(name = "server_time")
        private String serverTime;
    
        /**
         * 信息序号
         */
        @Column(name = "syslog_num")
        private Long syslogNum;
    
        ……
    }

    SwSyslog实体中的基本属性对应Syslog中的接口信息,注解中的name对应MySQL中的表sw_syslog 以及各个字段,MyBatis完成成员属性和数据库结构的ORM(对象关系映射)。

    程序中的SwSyslogService有两个主要功能:

    public static SwSyslog encapsulateSwSyslog(String syslogInfo) {
        SwSyslog swsyslog = new SwSyslog();
        swsyslog.setDevIp(SwSyslogExtractorUtil.extractDevIp(syslogInfo));
        swsyslog.setServerTime(SwSyslogExtractorUtil.extractServerTime(syslogInfo));
        swsyslog.setSyslogNum(SwSyslogExtractorUtil.extractSyslogNum(syslogInfo));
        swsyslog.setDevTime(SwSyslogExtractorUtil.extractDevTime(syslogInfo));
        swsyslog.setSyslogType(SwSyslogExtractorUtil.extractSyslogType(syslogInfo));
        swsyslog.setInfoType(SwSyslogExtractorUtil.extractInfoType(syslogInfo));
        swsyslog.setDevInterface(SwSyslogExtractorUtil
                                    .extractDevInterface(syslogInfo));
        swsyslog.setInterfaceState(SwSyslogExtractorUtil
                                    .extractInterfaceState(syslogInfo));
        return swsyslog;
    }
    
    public static void saveSwSyslog(SwSyslog swSyslog) {
        LOGGER.debug("开始保存或更新SwSyslog", swSyslog);
        // 根据ip查询所有Syslog
        List<swsyslog> list = swSyslogMapper.queryAllByIp(swSyslog.getDevIp());
        //  如果list非空,即查到对应IP的SwSyslog
        if (list != null && !list.isEmpty()) {
            for (SwSyslog sys : list) {
                // 若IP的接口相同,则更新信息
                if (sys.getDevInterface().equals(swSyslog.getDevInterface())) {
                    LOGGER.debug("有相同IP相同接口的记录,开始更新SwSyslog");
                    sys.setServerTime(swSyslog.getServerTime());
                    sys.setSyslogNum(swSyslog.getSyslogNum());
                    sys.setDevTime(swSyslog.getDevTime());
                    sys.setSyslogType(swSyslog.getSyslogType());
                    sys.setInfoType(swSyslog.getInfoType());
                    sys.setInterfaceState(swSyslog.getInterfaceState());
                    sys.setUpdated(new Date());
                    swSyslogMapper.update(sys);
                } else {
                    // 若接口不同,则直接保存
                    LOGGER.debug("相同IP无对应接口,保存SwSyslog");
                    swSyslog.setCreated(new Date());
                    swSyslog.setUpdated(swSyslog.getCreated());
                    swSyslogMapper.insert(swSyslog);
                }
            }
        } else {
            // 没有对应的IP记录,直接保存信息
            LOGGER.debug("没有相同IP记录,直接保存SwSyslog");
            swSyslog.setCreated(new Date());
            swSyslog.setUpdated(swSyslog.getCreated());
            swSyslogMapper.insert(swSyslog);
        }
    }</swsyslog>

    encapsulateSwSyslog()将Spark处理后的每一行Syslog通过Scala的正则表达式解析为不同的字段,然后封装并返回Syslog对象;遍历RDD分区生成的每一个Syslog对象中都有ip以及接口信息,saveSwSyslog()会据此判断该插入还是更新Syslog信息至数据库。另外,封装好的Syslog对象通过ORM工具MyBatis与MySQL进行互操作。

    获取到的每一行Syslog信息如之前所述:

    19.1.1.12 2016-10-13T10:04:54.520Z <147>12164: Oct  9 18:04:10.735: %LINK-3-UPDOWN: Interface GigabitEthernet0/16, changed state to down

    这段信息需解析为设备ip、服务器时间、信息序号、设备时间、Syslog类型、属性、设备接口、接口状态等字段。Scala正则解析逻辑如下:

    /**
          * 抽取服务器时间
          * 样例:2016-10-09T10:04:54.517Z
          * @param line
          * @return
          */
        def extractServerTime(line: String): String = {
            val regex1 = "20\\d{2}-\\d{2}-\\d{2}".r
            val regex2 = "\\d{2}:\\d{2}:\\d{2}.?(\\d{3})?".r
            val matchedDate = regex1.findFirstIn(line)
            val matchedTime = regex2.findFirstIn(line)
            val result1 = matchedDate match {
                case Some(date) => date
                case None => " "
            }
            val result2 = matchedTime match {
                case Some(time) => time
                case None => " "
            }
            result1 + " " + result2
    }
    
    /**
          * 抽取设备时间
          * 样例:Sep 29 09:33:06
          *       Oct  9 18:04:09.733
          * @param line
          * @return
          */
        def extractDevTime(line: String): String = {
            val regex = "[a-zA-Z]{3}\\s+\\d+\\s\\d{2}:\\d{2}:\\d{2}((.\\d{3})|())".r
            val matchedDevTime = regex.findFirstIn(line)
            val result = matchedDevTime match {
                case Some(devTime) => devTime
                case None => " "
            }
            result
        }

    通过正则过滤、Syslog封装以及MyBatis持久层映射,Syslog接口状态信息最终解析如下:

    最后,诸如APM、网络监控或者告警等业务应用便可以基于MySQL做可视化展示。

    总结

    本文首先对公安运维管理现状做了简要介绍,然后介绍公安实时运维平台的整体架构,再以交换机Syslog信息为例,详细介绍如何使用Flume+Logstash+Kafka+Spark Streaming进行实时日志处理分析,对处理过程中大量的技术细节进行了描述并通过代码详细地介绍整体处理步骤。本文中的示例实时地将数据写入MySQL存在一定的性能瓶颈,后期会对包含本例的相关代码重构,数据将会实时写入HBase来提高性能。

    展开全文
  • 讲师简介:徐小飞,阿里巴巴技术专家,目前就职于阿里计算平台大数据基础工程技术团队,主要负责支撑阿里大数据智能运维体系(公司内部产品名称——Tesla)的建设,团队致力于打造通用的智能化SRE中台,目前该中台运维...

    本文根据徐小飞在2018年5月12日【第九届中国数据库技术大会(DTCC)】现场演讲内容整理而成。

    讲师简介:

    阿里海量大数据平台的运维智能化实践

    徐小飞,阿里巴巴技术专家,目前就职于阿里计算平台大数据基础工程技术团队,主要负责支撑阿里大数据智能运维体系(公司内部产品名称——Tesla)的建设,团队致力于打造通用的智能化SRE中台,目前该中台运维体系承载阿里10w+规模节点运维工作。

    本文摘要:

    介绍Tesla如何支撑阿里离线计算和实时计算两大海量大数据平台的标准化日常运维运营,以及探索如何构筑运维领域的知识图谱,打造针对大数据平台和大数据业务的数据化全息投影,实现多维的立体化监控、智能决策分析、自动化执行的运维闭环。Tesla是面向企业级复杂业务系统的数据化驱动运维解决方案,解决方案包含一个统一运维门户(运维工单、运维垂直搜索)和四个运维基础平台(流程平台、配置平台、作业平台、数据平台),集日常运维工单管理、自动化发布变更、统一配置管理、统一任务调度、智能监控告警管理、异常检测预测、故障自愈等。

    分享大纲:

    • 运维新趋势
    • Tesla运维解决方案
    • DataOps数据化运维
    • 数据价值转化
    • AIOps征程

    演讲正文:

    大家好,我叫徐小飞,很开心能够有这样的一个机会在这里和大家交流。今天主要给大家介绍一下围绕阿里大数据体系的的运维智能化实践。

    我所在的团队叫大数据基础工程技术,通俗点说就是大数据SRE(为什么起基础工程技术这个名字? SRE文化里有个最核心的点就是使用软件工程的思想来解决运维问题),我们团队支撑的是整个阿里大数据生态的运维运营,并沉淀出一套自己的运维解决方案体系——Tesla,这套体系是一个分层体系,包含了面向运维领域功能的运维中台和面向具体大数据平台业务的运维应用。目前Tesla承载了阿里大数据平台及业务共10w+规模节点的日常运维工作。相信了解阿里的人都听过这样一个词——“大中台和小前台”战略,同样在运维领域,我们也是利用这个战略来构筑我们的业务:大中台提供通用的运维领域功能,而小前台可以基于业务场景快速试错、创新。首先我们先看下运维的新趋势。

    一.运维新趋势

    刚好这几天Google IO大会也正在召开,相信在座的很多同学都会关注,今年的大会中有一个很吸引眼球的话题,就是在开场第一天放出来的两段Demo视频,是个电话录音视频,内容是Google助手帮助客户打电话到发廊或餐厅去做预约。那么亮点在哪里呢?在整个电话预约的过程中,发廊和餐厅的人完全没有感知到和他们交流的是AI机器人。换句话说,AI机器人已经达到了以假乱真的效果,不仅在交流过程中有语气词和思考,而且当话题出现中断时,还会提出反问句,能让话题回到机器人所要的情景进行下去。

    Google对外宣称在某些特定领域,例如预约领域,他们已经通过了图灵测试。图灵测试大家可以去了解一下,图灵有一篇针对未来机器智能的论文,一句话解释论文里的图灵测试:当人机交互时,人类完全感觉不到对方是个机器人,那么就标志着进入了机器智能的时代。

    阿里海量大数据平台的运维智能化实践

    大概在三年前,Google提出了AI战略。时至今日,我们看到Google在很多领域都渗透了AI,Google的AI并不是做一个全新的AI产品,而是将AI赋能到它的顶尖产品中。所以,我们表面看到的是预约服务,但其实为了达到这个效果是需要很强大的数据+算法的支撑。我们经常提到的ABC(AI,BigData,Cloud),想要实现AI,前提一定是大数据和云计算,而在运维领域也同样是如此。这两年AIOps特别火,同样地我们认为要实现AIOps,一定是先有运维的数据和计算,就是说从DevOps到AIOps之间,有一段DataOps必经之路。

    如何理解DataOps呢?首先,我们要拿数据来感知我们所运维的系统,继而利用数据分析做一些决策,再往下就是去触发自动化的智能闭环。我们认为DataOps中最核心的过程就是运维感知、决策和执行。

    我们把无人驾驶和无人运维做了一个类比。无人驾驶也是Google第一个提出来的,现在有很多厂商投身其中,如果细看无人驾驶,其实我们发现与无人运维类似——无人驾驶是在传统汽车上附加智能感知、决策、智能控制系统。但是真正的无人驾驶还没有达到,即使是Tesla(马斯克的特斯拉)也不例外。而终极AIOps想要达到的是也是无人运维的效果,即在DataOps 的感知、决策和执行三个阶段都附加上AI智能。接下来先看下整体的Tesla运维解决方案。

    二.Tesla运维解决方案

    阿里海量大数据平台的运维智能化实践

    上面这张图是阿里大数据的体系,左边最底层是基础设施,包含了底层依赖,机房、天基、Staragent;其上有两大基础平台,一个是飞天平台,这是完全自研的,另一个是Hadoop平台。这两套平台之上分别对应的是MaxCompute和StreamCompute两大存储计算平台;再往上是数据应用层。而右边是Tesla大数据运维解决方案,我们可以看到Tesla贯穿了整个阿里的大数据体系,负责从基础设施到基础平台到存储计算平台的所有产品的运维支撑。

    简而言之,Tesla就是在为阿里的大数据保驾护航。

    阿里海量大数据平台的运维智能化实践

    MaxCompute是大数据的核心业务,而DataWorks可以理解为是一个面向开发者的前端,是MaxCompute的门户。 MaxCompute基本上承载了集团90%以上的计算和存储。在阿里,凡是和数据打交道同学都会用到DataWorks。StreamCompute承载了集团几十个BU的实时作业。大家可能感触最多的是每年的双11大屏,这背后都是由StreamCompute实时作业传上去的,可以达到秒级、毫秒级。最后是我们内部的机器学习PAI和AnalyticDB。

    阿里海量大数据平台的运维智能化实践

    这张图是Tesla运维解决方案架构图。整个Tesla运维解决方案是一个分层的体系,从SRE中台到SRE应用。整体是一个垂直体系,也可以拿SPI来分,中台最底层是IaaS,IaaS层是最基础的公共集团的设施,之上是核心运维PaaS层,其中包含四大平台+两大类服务。 四大平台与运维人日常的工作相关,分别是配置平台、作业平台、流程事件平台和数据分析平台。再往上就是SaaS层,提供了所有的平台和服务。Tesla平台支撑了阿里大数据的十几个平台,因为每个大数据平台业务产品的运维特性都是不一样的,肯定无法做到一套运维系统支撑所有的产品运维运营,所以我们就采用了分层战略: 运维开发团队提供平台,而针对具体产品的运维应用由SRE同学利用平台去构筑。典型的SRE应用包括常见的集群管理、资源管理、监控告警、故障管理等。在这张图里我们可以看到DataOps体现在数据分析平台这一层。

    阿里海量大数据平台的运维智能化实践

    这张图是应用维度。SRE应用这一层的功能也是分层的,最下面是其所依赖的基础平台,往上是面向业务的功能(包含业务中心、服务管控、平台运营、工具服务、运维中心和运筹优化),利用这些功能向上支撑具体的运维场景(围绕稳定性、成本、质量、效率、安全以及体验的维度),最终服务好业务的各类用户。

    在运维/运营平台中抽象出了几块内容,开发框架、资源整合、运维数据化和智能分析。因为最终系统都是相似的,所以我们会给提供前后端框架、服务网关、二方依赖包以及工具插件,业务SRE只需在环境上去获取数据,做数据处理、元数据管理以及提供数据查询的服务。运维数据化(DataOps)就是我们前面提到的,智能分析支撑常见的运维场景,比如最典型的故障处理、监控分析、大促保障以及值班客服等,他们面临的客户是一堆客户,这也是DataOps在SRE应用上的体现。接下来我们重点解释到底什么是DataOps。

    三.DataOps数据化运维

    阿里海量大数据平台的运维智能化实践

    什么是DataOps?如何做DataOps?阿里五新战略中有一个新能源,我们认为数据就是新能源,现在已经进入到信息爆炸的时代,大家刷淘宝天猫时的每一次行为都会触发日志,这些日志最终都流到我们的平台里。如此海量的数据,如果能有效的组织管理好,那么就可以从中挖掘出价值,但如果管理不好,就可能会是个大灾难。

    算法+技术,再结合数据就会产生新能源,而现在比较通用的数据挑战是我们怎么有效的去收集、清洗数据?如何保证数据的实时性、准确性?如何将无序的、没有结构的数据有序、有结构的分类、组织、存储管理起来?如何通过算法去打通数据,连接、分析数据,并从中提炼出价值?这一系列的问题就是DataOps需要解决的。

    阿里海量大数据平台的运维智能化实践

    什么是数据化运维? 我们这样定义:就是把所有系统的运维数据全部采集起来、真正打通,深度挖掘这些数据的价值,为运维提供数据决策基础和依赖。 从系统“稳定性、成本、效率、安全”多个维度去驱动自动化、智能化的运维运营,从而助力实现真正的AIOps。

    相比于传统运维,DataOps的改变可能就是把传统的使用命令、人工决策的运维过程转变成数据+算法的模式。

    阿里海量大数据平台的运维智能化实践

    DataOps是实现AIOps的一个必经之路,是一个运维闭环。如何做数据化运维呢?右边这张图来自《大数据之路》这本书,当然这张图说的是阿里整个的数据中台,阿里数据中台把全公司所有和数据相关的东西都整合了起来,提供了一套统一的数据中台。其中,最下面是数据采集层,往上是数据库同步工具,中间是MaxCompute和StreamCompute,也就是数据存储计算层,最上面是数据服务层和数据应用层。

    数据中台中的方案体系是OneData,它是用来规范数据中台,如何维护、组织、管理和使用数据的。OneData之上是OneService,有了这套组织管理和两大计算平台之后,就可以提供各式各样的数据服务,并再向上提供数据应用。在阿里,基本上所有的业务部门都是按照这个套路来做的。

    如何做数据化运维?其实就是利用这套大数据体系来构筑大数据的数据化运营体系。这句话可能有点难以理解,更直白一点说,这套体系是由我们来运维保障的,但是过程中我们也利用其来构筑了运维运营体系。因为我们的使命是为阿里大数据保驾护航,而我们的做法也是用阿里大数据来做运维分析,数据化运维分解下来就是运维的数据采集、运维的数据计算、运维的数据服务以及运维的数据应用。

    阿里海量大数据平台的运维智能化实践

    前面讲的是方法论,现在讲讲具体的实操。利用数据中台,我们首先做的是按照OneData规范建立运维的数据仓库,然后把所有运维相关的数据做分类抽象,包含公共数据、业务数据、元数据,runtime实时数据。基于这些数据抽象,我们提供了大量的运维服务和数据服务,比如异常检测分析、故障自愈、可视化流程、运维搜索、运筹优化、全链路诊断以及业务驱动。下面结合几个例子来具体解释下如何做数据化运维。

    以全链路分析诊断为例,MaxCompute是一套离线计算平台框架,每天有百万级的任务在跑,这些任务都是由开发同学提交,当作业因为各种原因出现不可预知的错误,大家就会@运维值班人员看看是哪里的问题。后来我们发现,大部分问题是相似的,所以就总结经验,从用户都在这个平台上提交作业到最后执行的每个阶段都去打点、采集分析,做了一套全链路作业诊断工具。

    阿里海量大数据平台的运维智能化实践

    这是一个自助式的全链路诊断产品,提供一个入口,用户只要输入作业ID,我们就能延伸到整个上下游去查询所有的有可能的问题,包括它的资源申请情况、配置是否正确、数据依赖是否都已满足、历史情况如何、是否有长尾倾斜等等。

    上图中有我们工具的页面截图,可以看到左边是有分类的,其实在做这个全链路分析工具的时候,我们就把这个场景和去医院体检做了个类比,体检时医生要针对病人的各个环节做判断,然后输出病人的状态,OK还是不OK?如果有问题,立即提出来让病人去某诊室随诊。同样的,我们也是针对作业做了多个维度的检测,而且还会将诊断详情、时间分析、图表分析以及历史对比等,全部都透视给用户。最后的结果报告是用图表分析的,例如稀疏图形资源争抢,毛刺图形部分长尾、任意机器进程CPU消耗分析。

    第二个案例场景是硬件自愈,目前我们已经有10万+台物理机了,每天有大量的硬件故障在发生,比如硬盘坏了,主板坏了等等。如果机器比较少,那么我们可能人肉或者直接提单就可以了,但是当量级到了一定程度,每天几十单或者是上百单的硬件故障,这种方式就不适用了。

    阿里海量大数据平台的运维智能化实践

    所以我们就利用这套数据化的思路做了一个硬件自愈的流程。我们也是从服务器上采集到数据,然后流进流计算平台Blink再到数据仓库,做检测分析并得出决策。决策触发流程平台做一些自动化执行的action,调用集群操作系统去做机器维修等。

    硬件自愈的本质也是一个三阶段的闭环,在这其中我们的角色有很多。例如有些故障重启一下服务或者双向配置即可解决,而有些故障需要使用万能大法,重启机器才能解决。如果碰到解决不了的问题就要进入无盘状态,去做业务隔离、重新克隆、整机维修,维修完之后自动上线。整套流程全部是自动流转,我们是无人值守的状态。

    四.数据价值转化

    通过前文的方法论和两个案例,我们大概解释了一下如何做数据化运维,接下来,我们再透视一下数据化运维的本质——从运维数据到知识的价值提取。

    阿里海量大数据平台的运维智能化实践

    这里会涉及到几个概念,数据化运维的前提是先将一切对象数据化,也就是运维的全域数据,构筑完之后,使用知识图谱将这些数据连接起来,之后将数据当做服务提供给人,利用运维搜索去提供一些快速直达的服务。然后让数据说话,数据即视图,最后数据如果能清洗到一个决策时——有价值的知识,那么我们就认为数据可以驱动决策。

    阿里海量大数据平台的运维智能化实践

    全域数据,基本上是运维相关的日志、事件、指标、报警等,特征也比较多,多维度、多层次、时效性、关联性等。这些东西的本质其实就是运维对象和运维事件。

    有了全域数据之后,如何把数据连接起来?我们就利用实体与关系这两个概念来构筑运维知识图谱。下面图片是一个全息投影,可以比较形象地描述我们利用图谱来做的事情。我们就是尽可能的利用实体及实体之间的关系,再结合一些外部runtime的数据去还原当时系统的运行情况,然后把它映射到现实场景上去做精细粒度的感知。

    阿里海量大数据平台的运维智能化实践

    当前我们整套知识图谱的数据量,实体数据大概在百万级,关联数据在千万级,同时我们还关联了很多外部runtime数据。

    有了知识图谱之后,要给SRE同学使用。我们提供了一套运维垂直搜索功能,这是一个工作模式的改变,之前运维同学都是将很多功能分门别类的排布好,但是当功能堆得越来越多时,用户可能不知道要去哪里找他要的东西。而我们提供的搜索功能,它可以通过关键词来搜索相关的信息,例如搜索一个机器,那么我们就把这个机器相关的信息都推给他,包括这个机器当前安装的软件、进程状态、CPU内存、IO曲线等。

    阿里海量大数据平台的运维智能化实践

    除此之外,我们还整合了阿里集团的所有运维资源,目的是为SRE提供一个垂直领域的搜索服务,改变运维习惯。同时,还提供了一个功能就是嵌入到某一个站点,提供站内的垂直搜索。

    数据即视图,当有了大量的数据之后,我们会希望在很多地方将这些数据展示出来。但我们发现这其中有很多事情都是重复工作,所以我们就基于运维的可视化整合了这条链路,我们把所有的数据都按照要展示的格式规范起来。这样的话,只需要提供数据就可以在任意的地方展示,相当于数据本身是结构化的、可视化的。

    阿里海量大数据平台的运维智能化实践

    可视化是基于Grafana,对接了很多的数据源。不过,由于Grafana是angularjs写的,而我们的很多前端站点都是React,所以我们做了一套基于React的前端组件来适配Grafana后端数据源,提供无缝的图表能力。根据SRE同学的反馈,几分钟之内就可以完成一张可靠的图表开发。

    阿里海量大数据平台的运维智能化实践

    数据决策。以前都是人去提单,然后由工单来驱动运维操作来对所用的对象进行管理。但是现在整个思路发生了逆转,首先我们通过事件、监控等透视运维对象,并通过规则、算法等决策服务做出决策,最终完成action执行。简单来说,以前是人围着机器转,现在可能是机器围着人转。

    以ChatOps智能运维助理为例,这个场景是某个同学想要知道某一台机器当前是什么情况,他在工作群里@一下助理,然后输入hostname,机器人就会返回这台机器的状态,机器所在的分组、隶属的集群、当前系统状态是不是OK、硬件状态是不是OK、安装的服务软件的状态是不是OK……这其中每个状态的结果都是一个链接,点击之后就会跳转到针对这个问题的详细情况。

    阿里海量大数据平台的运维智能化实践

    现在,针对服务状态、机器状态,我们正在把更多的场景都往ChatOps这套理念来推。它所做的就是将一些简单重复的工作沉淀下来,让这些信息直达用户,缩短用户与功能之间的距离。同时,我们还有一个兜底的意图,因为ChatOps毕竟还是通过一些意图去规则、处理东西,当没有匹配到你的意图的时候,可能就找不到了。这时,怎么办呢?我们把前面做的运维搜索来兜底,如果根据关键词没有搜索到,那么我们就调用搜索接口来做反馈。

    五.AIOps征程

    说了这么多,到底什么是AIOps?AIOps中的AI经过修改后,目前最新的释义是Artificial Intelligence。为什么说实现AIOps必须要经过DataOps阶段?因为我们认为AIOps其实就是在传统的DataOps之上附加智能,如果在感知、决策、执行每个阶段都附加上AI的附加值之后,我们认为这才真正实现了AIOps。常见的AI手段包括算法、深度学习、神经网络等等。

    阿里海量大数据平台的运维智能化实践

    AIOps绝对不是从无到有,它一定是随着你在某个领域持续地构筑、持续地积累,然后在每个阶段附加上新的AI。

    阿里海量大数据平台的运维智能化实践

    这张图是我们团队头脑风暴出来的,我们发现无人驾驶和无人运维很像。SAE将无人驾驶划分了六级L0到L5,他们认为当前市面上大部分的车都处于L2阶段,即实现了一些基础自动化,比如ABS防抱死系统、自动定速巡航等等。L1阶段可能就是乞丐版,不具备这些功能的车。L3是有条件的自动驾驶(马斯克的Tesla实际上只是L2.5), L4是高度的自动驾驶,如果说L3还需要驾驶员坐在旁边,出现问题时接管,而L4基本上在特定条件的路上完全无需驾驶员介入,车子能自动判断做出决策。L5是完全自动驾驶,是一种理想状态,可能很难达到。根据文档的描述,L5阶段,给定车辆一个起始地点和结束地点,其它就不用去管了(跨越国家、左道右道都能自动切换),它自己会去判断、处理一切,淡化了司机的概念。

    类比无人驾驶,无人运维也可以分为6个阶段,L0是人肉运维,L1是脚本、工具化运维,是当前各大公司都具备的一个状态,L2是开发运维一体化DevOps,它的最大特征是有一些简单的规则、阈值的判断,L3是数据化运维DataOps,最核心的东西就是数据化算法,L4是高度智能化运维,这时系统已经完全具备了自动运维的能力,并能够提供人机对话的交互。L5是 完全智能化运维,可能就像电影里的天网系统完全自主防御,你想破坏它都不可能。最后以一个案例来介绍下我们在AIOps上的尝试。

    阿里海量大数据平台的运维智能化实践

    以Project智能迁移场景为例,在计算平台中,所有用户的资源管理都是申请一个Project,计算平台根据配额组来分配资源,当前配额组的资源是不是够用,有没有超过预算?同时,对于系统我们也会有个期望,系统应该运行在一个什么样的状态,核心指标应该是多少,水位是百分之多少,正常情况下不会触发哪些相关事件……一旦系统在后台触发了事件,系统会做自动判断,执行智能迁移的Plan计算。如果想要达到系统所期望的运行状态,需要将哪些Project做迁移,迁移到哪些集群,这时我们会通过ChatOps与人做一个确认的交互报备,通过自动智能的Project迁移之后,系统再次回到我们期望的状态。在整个过程中,我们可以做到无人值守。

    阿里海量大数据平台的运维智能化实践

    最后再整体回顾一下,首先,我们讲了DevOps到AIOps的一个概念,重点讲述了什么是Tesla;然后定义了DataOps数据化运维,并以两个案例讲述了如何做DataOps;接下来,我们分析了数据化运维的本质,包括运维全域数据、知识图谱和搜素、数据即视图、数据驱动业务;最后,我们讲述了AIOps并不是无中生有,而是DataOps+AI,并与无人驾驶做了类比。最后再来个广告。

    阿里海量大数据平台的运维智能化实践

    我们这里有很多优势也有很多挑战。来阿里最大的优势就是这套大数据体系实在太成熟了,以前我做数据化运维的相关工作都需要我去从无到有构筑数据化体系,但在阿里,这一套触手可用;同时我们所运维的对象本身就是阿里大数据,这又是一个可以跟阿里大数据亲密接触的地方;我们的舞台足够大,量级至少在国内可以称得上No.1,同时所运维的对象也很复杂,所以我们需要更高效更智能的手段。

    简而言之,玩数据,来阿里,准没错!

    展开全文
  • 本文来源于网络,如有侵权,联系浪尖删除:langjianliaodashuju转自:数据中心运维管理立足数据中心运维管理的现状,顺应时代发展的潮流,充分利用信息技術的机遇,利用现有资源对数...
  • Hadoop是什么: – Hadoop是一种分析和处理海量数据的软件平台; – Hadoop是一款开源软件,...Hadoop常用组件:(下面三个组件是针对于运维,其他的不在此论述) • HDFS: Hadoop分布式文件系统(核心组件) • MapReduce: ...
  • 这算是一个新的系列,记录我们是怎么在一个一穷二白的状态下,开始搭建一个互联网企业的数据库管理系统,与思路,希望也能在这个维度认识更多的朋友...实际上做一个数据库运维管理系统是一件困难的事情,摆在我们面...
  • 魅族大数据运维平台实践

    千次阅读 2017-10-14 10:01:16
    一、大数据平台介绍 1.1大数据平台架构演变 如图所示魅族大数据平台架构演变历程: 2013年底,我们开始实践大数据,并部署了测试集群。当时只有三个节点,因为我们起步比较晚,没有赶上Hadoop1.0,直接是...
  • 主要实现对 ETL 作业、存储过程、SQL 语句、shell 脚本、DS 作业等多类型作业的自动化编排和调度,既可用于帮助用户轻松构建自动化、规范化批量调度管理平台,也可用于支撑大数据时代下数据流向的调度管理自动化等,...
  • 大数据认知实习的实习目的With internship season well underway, we reached out to some Alteryx ACEs, top analytics experts and participants in the Alteryx Community, to see what advice they’d offer to ...
  • 环境准备 1.1实验目的 1.2实践操作 2.部署HDFS 2.1实验步骤 2.2实践操作 3.实验三 HDFS shell操作 3.1实验目的 3.2实践操作 3.2.1练习对HDFS文件创建、查看、删除、复制、粘贴等文件操作 3.2.2练习本地文件与HDFS...
  • 关于DKHadoop下载安装基本已经讲清楚了,这几天有点空闲把大快DKM大数据运维管理平台的内容整理了一些,作为DKHadoop相配套的管理平台,是有必要对DKM有所了解的。 DKM 是DKHadoop管理平台。作为...
  • 大数据实习报告.doc

    万次阅读 2020-12-23 08:00:27
    大数据实习报告大数据实习报告大数据实习报告目录一、摘要1.1项目背景……………………………………………………………21.2课程设计目的………………………………………………………21.3题目名称……………………...
  • 在整个数据中心生命周期中,数据中心运维管理是历时最长的一个阶段。数据中心运维管理主要目的是为提供符合要求的系统服务,而对与有关的数据中心各项管理对象进行系统的计划、组织、协调与...
  • 系统运维技能 web运维技能 大数据运维技能 容器运维技能 1.实时监控:对软硬件系统进行不间断的监控 2.实时监控的目的 3.监控方法 4.监控工具 5.监控流程 6.监控指标 7.监控报警 8.报警处理 9.面试题
  • 关于DKHadoop下载安装基本已经讲清楚了,这几天有点空闲把大快DKM大数据运维管理平台的内容整理了一些,作为DKHadoop相配套的管理平台,是有必要对DKM有所了解的。 DKM 是DKHadoop管理平台。作为大数据平台端到端...
  • 大数据模式已经到来!个体既是数据的创造者也是数据的使用者,医疗,科技,教育领域都早已参与其中。并创造无数的好产品和价值。核心数据搜索和推荐、电商定点广告和推送,基因健康预测等都在不断重新定义互联网的...
  • 关于DKHadoop下载安装基本已经讲清楚了,这几天有点空闲把大快DKM大数据运维管理平台的内容整理了一些,作为DKHadoop相配套的管理平台,是有必要对DKM有所了解的。DKM 是DKHadoop管理平台。作为大数据平台端到端Apac...
  • 【2021 高校大数据挑战赛-智能运维中的异常检测与趋势预测】1 赛后总结与分析 1 题目 异常检测(异常诊断/发现)、异常预测、趋势预测,是智能运维中首当其冲需要解决的问题。这类问题是通过业务、系统、产品直接...
  • (1)、Flume:Flume最早是Cloudera提供的日志收集系统,目前是Apache下的一个孵化项目,是一个高可用的,高可靠的,分布式的海量日志采集、聚合和传输的系统,Flume支持在日志系统中定制各类数据发送方,用于收集...
  • 杨慰民中国移动通信集团福建有限公司,福建 福州 350003‍‍摘要:‍对于非话音的移动互联网业务,即使网络指标是完好的,仍然存在用户感知不佳的现象。基于大数据技术研究用...
  • 深度解析大快DKM大数据运维管理平台功能之前几周的时间一直是在围绕DKhadoop的运行环境搭建写分享,有一些朋友留言索要了dkhadoop安装包,不知道有没有去下载安装一探究竟。关于DKHadoop下载安装基本已经讲清楚了,...
  • 系统运维架构师体系

    2022-05-15 19:19:55
    一、系统运维架构师体系1. 系统运维架构体系排列:2. Linux运维架构的薪资水平:3. Linux运维的技能进化论4. Linux运维大致的知识框架4-1. Linux系统初级体系4-2. Linux系统中高级体系5. Linux运维的具体规划实践5-1...
  • 如何做好企业级IT系统运维 谈起运维工作,估计很多人会下意识的认为就是修电脑的、网管(上不去网,第一个被召唤的那种)。其实不能说这是错误的理解,IT运维人员的工作小到修电脑、理网线,大到部署整个数据中心...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 18,263
精华内容 7,305
关键字:

大数据系统运维的目的