精华内容
下载资源
问答
  • 企业级的数据集群往往有PB 级的数据、成百上千的各类型运算任务 在一套集群上运行。 所以它的维护是充满挑战的: 庞大的数据量、复杂的运算逻辑、相互关联的大数据组件、数以万计的运行任务 都是要克服的难点。 SRE...

    背景

        企业级的数据集群往往有PB 级的数据、成百上千的各类型运算任务 在一套集群上运行。 所以它的维护是充满挑战的: 庞大的数据量、复杂的运算逻辑、相互关联的大数据组件、数以万计的运行任务 都是要克服的难点。 SRE 如果不想被动的话,就必须做好各式监控。预防风险、提前发现风险、然后分析问题、进而针对性的处理问题。 

    凡是成体量的分布式系统,一旦出现性能问题,往往很难在短时间内作出有效处理。 所以  监控要前置,有趋势预测、有风险评估 才行。

     

    一、大数据监控体系

    截止目前,集团数据中台下离线数据集群 近 千台 物理机,数据存量近数10 PB+,每天数据增量 百TB+ ,运行任务 11w + ,Hdfs、Hive 等大数据组件 10+ 套。 那么如何对这些集群组件具有较强的掌控力?  我们需要一套 成体系 的监控方案。

    1.1、 Not Only Monitor

    首先,我们要明确监控在 好未来大数据运维体系中 是怎样的定位。 在整个体系中,监控处于承上启下,贯穿全局的角色。 

          

    这里为什么说 Not Only Monitor 呢 ?  是因为数据监控所包含的范围其实很大,不只是传统的运维底层监控。 还包含了比如 数据质量监控、任务状态监控、组件性能监控、趋势预测监控、同比环比分析 等。 

    1.2、大数据监控体系整体架构

    整个大数据集群的监控体系分为如下七个维度:

    大数据运维监控体系
    监控维度主要监控项 
    底层基础监控机房 与 网络(路由器、交换机等)、专线、服务器(CPU、内存、IO、磁盘、文件等)各类型日常的基础监控
    服务状态监控各类型标准组件存活状态(从业务的 SLB、Nginx、Java、Hdfs、Hive、ZK 等组件存活状态)
    组件性能监控每种组件的 Metrics 性能监控,以 Hive 为例 (QPS、RPC、Metastore Canary、connection 等)
    Runtime监控顾名思义,模拟客户端去 不间断循环 与 各式 组件发起基本请求与操作,确认组件状态,比如 每隔5 分钟去 与 HDFS 交互,完成 新增、修改、删除、查询 等基本操作,并获得操作结果状态与响应时间。
    集群指标监控集群的 核心指标监控,比如 文件大小分布、集群整体计算资源、集群整体存储资源 等指标。
    趋势预测监控存储与计算 同比、环比 上涨趋势、小文件同比环比上涨趋势、SLA 趋势预测
    任务状态监控任务状态、任务占用资源、任务延迟 等。


    其实上面每个维度,都包含了很多的监控项 与 监控指标,而针对不同的 告警 维度,它的监控方式也不尽相同。   

    • 一些监控是不断读取它的状态,比如常见的 CPU 、内存,然后设定阈值触发告警动作。  

    • 一些监控是需要有时序性的聚合统计,比如 HDFS 存储增量,当增量斜率比平时高的时候触发告警动作。

    • 一些监控是需要和其他监控做 与 操作,或者 联动,同时满足才会触发告警动作。 

    • 等等 。。。

    针对这些不同的监控指标,单纯的一个监控组件 或者 数据采集方式是不能满足的。  光靠开源的监控手段也无法全部覆盖,所以我们做了各式组件 + 自研的监控脚本与程序去实现整体的监控框架。 

    整个7 个维度,我们按照不同的框架与组件实现,主要分为两个实现。

     

    二、基础监控实现

     

    2.1、基础监控框架

     

    基础监控包含:底层基础监控、服务状态监控、组件性能监控、Runtime监控 这四部分。 我们用 Zabbix + Prometheus + 基于 Flask 框架的 Exporter + Python Runtime Monitor 框架体系:

    基础监控框架 主要分为 3 大块,我们分别简单介绍一下。

    2.2、第一块:基于 Zabbix 的底层基础监控  

     

    这部分比较简单,就是基于 Zabbix + 云监控 对所有的 网络、服务器 进行实时监控数据收集。  

    因为我们同时负责了不同的事业部 与 部门的运维工作,所以进行了 分组、分模版、分告警渠道 的形式,实现对不同部门的告警。 但同时为了避免重复维护,我们尽量复用告警模版。

    比如培优大数据、数据中台业务侧的 很多业务类型的告警都是类似的,所有的项目模块都需要对 Java 进程,Nginx 进程进行监控,那我们就划分两个 分组,同时和 一个 Java 进程告警模版相关联。 而不是创建两个:

     如上,业务模块 对应的 主机群组,不同的主机群组可以 复用 相同的告警模版。  比如不管是培优还是网校、不管是业务还是集群、底层服务器的 CPU、内存等基础监控都得有。  所以就可以复用同一个告警模版。  

     

    PS: 有时候会遇到 相同告警模版,相同监控项,但是监控阈值不同。  比如 虽然业务服务器 和 大数据集群服务器 都需要监控 CPU ,但是业务服务器只要超过 65% ,我们就认为是异常,但是大数据服务器在高峰期可能长时间处于 90% 左右的 CPU 利用率,那么它的阈值要更高,并且持续时长也要更高些。 

    对于 Zabbix 我们只是力求把它用好,尽可能通过 划分组、复用模版 的方式让它更清晰、整洁、高效。 

    2.3、第二块:基于 Prometheus + AlertManager + Grafana 的集群性能监控

     

    对 大数据 组件的性能监控,我们借助 Prometheus + AlertManager + Grafana 的架构方式。 主要分为四个简要步骤:

    • 自建 Flask exporter ,从 Cloudera Manager 的 API 中取出各式组件需要监控的 Metrics 。

    • 通过 Alertmanager 对需要的 metrics 进行告警。

    • 自建 知音楼 + 电话告警 API 供 Alertmanager 调用。

    • 将 Prometheus data source 接入 Grafana 做报表展示。

     

    这里具体的代码与实现细节,不展开了,否则太多,主要是将大概的思路和实现方式以及官网地址交待清楚:

     

    2.3.1、明确要获取的 Metrics 

    首先我们要明确有哪些Metrics 可以供我们获取,从官网我们可以看到每个组件自带的各种类型的 Metrics:

    是的,因为我们用的是 CDH 版的集群,所以不用跑去查每个组件的接口与调用类型 等。  可以直接走 CM 的 API 去调用获取。 CM API 对应的官方文档里面有大量的接口调用方式,包括一些动作、状态、Metrics 获取等。这里我们暂时只关注 Metrics 获取,我们会发现,官方文档中所有的 Metrics 获取都建议我们走时序型接口:

    这里贴一个最简单的 Python 代码调用示例如下:

    [root@aly-bigdata-hadoop-op-manager01 cdh_exporter]# cat test.py  
    import os 
    import requests 
    import pdb 
    import urllib 
    import json 
    import re,pdb 
    
    
    uri = "http://admin:xxxxxxxxxx@10.x.x.x:7180/api/v11/timeseries?query=" 
    cut_metrics_list = ['health_good_rate'] 
    
    if __name__ == "__main__":     
         for key in cut_metrics_list:         
             url = "%sselect%s%s" % (uri, '%20', key)         
             request = requests.get(url=url)         
             jsondata = json.loads(request.text)         
             print(jsondata)

     

    得到的结果如下(代码有点多,截图表示了):

    如上,我们就可以获取到对应 Metrics 相关值 。

     

    2.3.2、 自建 Exporter 从 CM 获取想要 Metrics 数据

    用 Python 自建写一个 Exporter ,获取数据吐到 Prometheus ,因为涉及到的 Metrics 很多,所以采取多线程并发的方式去获取。

    这里主要借助 Python的这个库:https://github.com/prometheus/client_python#instrumenting ,非常简单,这里就不再详细赘述。 

    总体来说,开 30个线程并发,取 几百个 Item,最终入Prometheus 的时候大概 几万个 Metric ,总共需要约 8 s 多。

     

    2.3.3、配置 AlertManager,实现自定义知音楼告警

    数据入到 Prometheus 之后,我们当然要去设置针对一些Metrics 的告警阈值,这里借助和Prometheus 的告警插件 AlertManager。 

    AlertManager 的安装很简单,这里不再详赘,关于相关配置可以参考官方文档:https://prometheus.io/docs/alerting/configuration/

     

    2.3.4、自定义告警网关

    正如上面所说,我们自己实现一个简单的告警接收器,用 Flask 实现,可以让 AlertManager 通过 5000 端口调用发送钉钉告警,这里主要是要注意处理发送与接收格式。 将告警格式处理为我们能简单易懂的格式,非常简单,具体代码这里就不再详细赘述,贴上格式对齐片段截图。

      

    这样,我们的 组件 Metrics 数据就已经到 Prometheus 里面了,对应可以收到相关的 告警 与 恢复信息,当然单纯的收到告警信息不行,我们需要一个有维度的监控展示。  

    Grafana 是很好的选择,我们只需要将 Prometheus 作为 Datasource 纳入 Grafana,即可构建丰富的报表展示:

    2.4、第三块:Runtime Monitor 

     

    所谓 Runtime Monitor 其实给它的定位 是 轻量级的模拟客户端交互 监控程序。  即用 Python 编写客户端,循环的每隔一段时间 去 和 HDFS 、Hive 等组件进行基本交互。 

    与每个核心组件进行 链接、新增、修改、更新、删除 等基本操作,每次一个小闭环。  

    这样做的意义在于兜底。 因为我们虽然加了很多基础监控,但是你不能 100% 确定采集到的 Metrics 是准确、无延迟 并且高可用的。  我们线上曾经出现过 Zabbix 自己挂了,从而所有基础告警本身失效,从而漏报核心业务模块故障的 Case 。 

    Runtime Monitor 作为一个客观独立存在的 小闭环,它确保你的服务最基础的核心 能力在正常运行。   一旦Runtime Monitor 出现异常,那往往是线上服务就出现核心异常了。

    Runtime 最好做成一个 体系化的 架构,不要变成 东一个小脚本、西一个 小定时。  

    具体这块的代码架构这里就不再详细赘述了。  


    截止目前,基础监控三大块 就讲完了。  其实每一块都有很多细节,这里主要是想同步监控的 框架和 维度,后续可能会单独针对每一块做一些专项深入的交流和分享。 

     

    三、监控升级

     

    基础监控三大块是生命线,它能保证对基础环境运行状态的监测。  但还不够,集群指标监控、趋势预测监控、任务运行监控 也是我们必须要关注的东西,这些是属于升级监控。 

    升级监控体系略微复杂一些,需要有一些数据采集、聚合、分析 等能力。  而且一些集群数据需要有 运维数仓,进行 T+1 的任务计算,以及 多指标关联分析等。 

    这里我们用到了 ES、Kakfa、Logstash、Flink、Hive 各种分析组件,也基于 Flask 框架进行了很多数据加工,甚至运用了一些大数据思想。  给一些核心组件 比如 NameNode RPC 做了 运维画像。  引入了 Dr Elephant 对集群的任务进行了 各式分析。 

    目前增强监控体系如下:

     

    如上,升级监控分为了很多模块,详细的我们留在下篇再进行分享,这里我们先简单附上升级监控的一些结果。 

    CPU、内存的 周环比、集群存储剩余可用时长预测、每日各维度数据增量:

    数据表分布、活跃用户分布、活跃任务分布等:

    任务相关分布分析:  

     

    还有很多,包括实现方式,这里就不再展开了,下篇会专门再专门讲一下 升级监控的架构 与 具体实现原理与细节。 

     

    四、漫谈 告警收敛 与 告警分级

     

    其实光是告警收敛 和 告警分级 每个都可以单拉出来,有很多内容。 很重要,做深了也很有挑战。 我自己这方面的经验也不深,只是做了一些简单的探索和实践。 这里将仅有的实践和大家探讨一下。 

    我觉得一条有效的 告警,它的 生命旅程 是非常坎坷的,理想情况下它 应该经历 这样的旅程:

      

     

     

    如上,它得经过一层层的筛选、过滤、汇总、定向 才发给真正需要知道它的人,从而实现自己的生命价值。 

     

    这里我将告警收敛 和 告警分级都标注出来了,下面谈谈。  其他的这里就不再展开了,其实做好监控是非常复杂的一件事情。  如何与组织树和值班信息联动,如何进行 告警的分类分级统计,如何进行告警流量清洗,这些都是很值得深入研究的。 

     

    4.1、监控告警收敛

     

    我经常给伙伴们强调的一句话:  理想情况下,要么不报,只要报出来那就是一定是需要我们立刻关注处理的。  

     

    • 目前,我们负责 四个事业部、十几个部门、4套大数据集群、各种组件,所以分了将近 12 个 告警群。   

    • 每天的告警消息数大概 平均保持在  60 - 100 之间。 

    • 每天有效告警只占所有告警的不到 10%。 

    • 而由于大数据夜间是高峰期,所以一些核心报警是加了电话通知的,如果你不想半夜被叫醒却发现是误报,那就必须要进行告警收敛。  

     

    其实告警收敛的核心目的是提升告警有效性,确保问题能在第一时间得到妥善处理。 

    目前我们的高级收敛做的比较糙,主要分为三部分:

     

    • Zabbix 部分就单纯的根据进一步细分 主机群组 和 监控模版,比如 Datanode 独立一个基础监控,将阈值调高,不至于频繁告警。 

    • Prometheus 本身是支持 告警分组 与 告警收敛的,就 基于 Prometheus 的告警分组特性进行了一些常态化的告警收敛。 

    • 自建升级监控 目前 是根据一些简单计算公式进行收敛策略,我一直觉得这块其实大有可为,后面我们逐步要做 DataOps 和 AiOPS 的时候可以基于Flink 等通过大量的实时算法策略做告警收敛。

    这里也附上我对告警收敛的一点思考。  首先,它是一个细活,当到一定规模和体量的时候,必然要深入算法,去建模,对监控流量进行分析。从而达到 类似 AIOPS 的效果,进行故障自愈和智能巡检等效果。 而想要做到这一步还是要有比较专业的团队去聚焦,做监控平台。  而监控平台一个很大的挑战将会是,平台如何有通用的产品能力,去适配不同业务场景的监控告警 功能。   

     

     

    4.2、监控告警分级

     

    监控告警分级也是至关重要的,当监控的东西越来越多的时候,就得给这些家伙进行分级管理了。   有些监控告警是 P0 级,它很重要,一旦出现就需要引起我们的高度重视,快速响应,一般我们要求是触发电话通知,并通知到对应的值班人、负责人等。  而有些监控项它更多的是偏提示或者预警,那么就要做好分类管理。  

    针对线上的一些告警,进行了如下分类分级(内容太多,这里只截取了一小部分):

    如上,根据不同的监控项、监控类型,分别针对线上的监控做了告警分级处理。  

    我们规定,所有的 P0 级告警,全部走 电话 +  知音楼 通知,所有的 P1 级告警都走 对应的知音楼核心群通知。 P2 及以上告警收敛覆盖率要达到 80%。 

    监控告警级别监控告警通知对象监控告警响应要求监控告警通知方式
    P0值班人 + 组长 5分钟之内电话、知音楼核心告警群
    P1值班人5 - 15 分钟之内知音楼核心告警群
    P2 及 以上值班人保持关注知音楼告警群

     

    好的告警分级 能减轻运维人员自己的负担,也能使告警更有效清晰。 但如何打造一套完整的告警分级体系,还需要贴合业务场景 并且有监控数据分析,综合去评定。  一旦有了这样的体系,那么后面要做的就是不断补充完善这个体系。 出故障的时候也能按图索骥,根据监控告警分级策略不断打磨完善。  

    关于基础监控体系,就先谈到到这里,篇幅有限,感觉文章中很多点,都可以单拉出来去进一步讨论。 

    未完待续 ~

    作者:好未来高级专家王鑫宇

    关于好未来技术更多内容请:微信扫码关注「好未来技术」微信公众号

    展开全文
  • 大数据学习(一)搭建大数据集群新建虚拟机网络配置关闭防火墙SSH免密配置 新建虚拟机 打开vmware,新建虚拟机 典型安装 稍后安装操作系统 我这里用的是CentOS-7-x86_64-Minimal-1708,所以选择CentOS7 选一个...

    大数据学习(一)搭建大数据集群

    新建虚拟机

    打开vmware,新建虚拟机
    在这里插入图片描述
    典型安装
    在这里插入图片描述
    稍后安装操作系统
    在这里插入图片描述
    我这里用的是CentOS-7-x86_64-Minimal-1708,所以选择CentOS7

    在这里插入图片描述
    选一个位置进行安装
    在这里插入图片描述
    这里可以默认
    在这里插入图片描述
    点击自定义硬件
    在这里插入图片描述
    我们添加一下镜像文件
    在这里插入图片描述
    内存和处理器核数想改也可以改一下
    在这里插入图片描述
    开启虚拟机
    在这里插入图片描述
    安装
    在这里插入图片描述
    按下enter键
    在这里插入图片描述
    这里安装过程的语言选中文
    在这里插入图片描述
    这里可以默认,主机名和网络可以安装好再进行修改
    在这里插入图片描述
    设置下root密码,如果密码太过简单的话需要点击两下完成
    在这里插入图片描述
    安装好重启

    网络配置

    进行登录(注意:在linux中输入密码不会显示)
    在这里插入图片描述
    vi /etc/sysconfig/network-script/ifcfg-ens33配置

    修改成如图所示,ip网段根据自己电脑实际情况修改

    BOOTPROTO=static #静态连接
    ONBOOT=yes #网络设备开机启动
    IPADDR=192.168.115.101 #ip地址
    GATEWAY=192.168.115.2 #网关
    NETMASK=255.255.255.0 #子网掩码
    DNS1=8.8.8.8
    DNS2=8.8.8.4
    
    

    在这里插入图片描述

    保存退出
    命令systemctl restart network对网络进行重启
    ip addr查看ip地址
    在这里插入图片描述
    vi /etc/hostname修改主机名为master

    关闭防火墙

    在这里插入图片描述

    systemctl status firewared.service #查询防火墙状态
    systemctl stop firewared.service #关闭防火墙
    systemctl disable firewared.service #永久关闭防火墙
    

    我们搭建集群需要至少3台机器,我们先把虚拟机关机,然后克隆出来两台
    在这里插入图片描述
    选择完整克隆
    在这里插入图片描述
    克隆完成之后分别对slave1、slave2进行网络配置

    SSH免密配置
    # 映射
    192.168.115.101 master
    192.168.115.102 slave1
    192.168.115.103 slave2
    

    生成密钥ssh-keygen -t rsa
    在这里插入图片描述
    将公钥发送到三台节点上

    ssh-copy-id master
    ssh-copy-id slave1
    ssh-copy-id slave2
    

    上述步骤分别在三台节点执行
    能实现下图效果就说明成功了
    在这里插入图片描述

    展开全文
  • 我是用hadoop用户来安装集群,如果用root用户的话可以不用管这一步 Linux/CentOS 配置普通用户配置免密切换root 2.所有虚拟机之间配置免密登录 3.准备好存放安装包及安装软件的目录,以及存放数据的目录 我存放...

    1.至少准备三台虚拟机(我用五台)并按如下文章做好配置
    服务器配置NTP时钟同步
    我是用hadoop用户来安装集群,如果用root用户的话可以不用管这一步
    Linux/CentOS 配置普通用户配置免密切换root
    2.所有虚拟机之间配置免密登录
    3.准备好存放安装包及安装软件的目录,以及存放数据的目录
    我存放软件包的位置是/opt/packages,安装目录是/opt/apps
    数据目录是/data 且/data目录的权限要设置为755,权限太大的话安装HDFS的时候会报错
    4.下载好各个软件包
    推荐在清华镜像站下载:https://mirrors.tuna.tsinghua.edu.cn/apache/
    或者从我的百度网盘下载:https://pan.baidu.com/s/1dLw1nuP9ahlIwrVykVNiGw
    提取码:kofd
    apache-flume-1.9.0-bin.tar.gz
    apache-hive-3.1.2-bin.tar.gz
    apache-zookeeper-3.5.9-bin.tar.gz
    cmak-3.0.0.5.zip
    flink-1.13.0-bin-scala_2.12.tgz
    hadoop-3.2.2.tar.gz
    hbase-2.3.5-bin.tar.gz
    hbase-2.3.5-client-bin.tar.gz
    jdk-11.0.10_linux-x64_bin.tar.gz
    kafka_2.12-2.6.2.tgz
    mysql-5.7.33-el7-x86_64.tar.gz
    redis-6.2.3.tar.gz
    spark-2.4.8-bin-hadoop2.7.tgz

    展开全文
  • 1、大数据平台前期调研 1.1业务需求调研 从运维角度看,主要调研公司的有哪业务的数据运营需求,是离线计算需求还是实时计算需求。 1)离线计算组件需求: 数据采集组件:FlinkX/DataX 数据存储组件:HDFS ...

    1、大数据平台前期调研

    1.1业务需求调研

    从运维角度看,主要调研公司的有哪业务的数据运营需求,是离线计算需求还是实时计算需求。

    1)离线计算组件需求:

    数据采集组件:FlinkX/DataX  

    数据存储组件:HDFS

    数据加工组件:YARN/Hive/Spark/Flink

    数据服务组件:HBase/Elasticsearch/Geomesa(时空数据库)/Kylin(OLAP 引擎)/MPP 数据库(可以用作即席交互查询,如 Greenplum、HAWQ)

    2)实时计算组件需求:

    数据采集组件:flume/filebeat/Kafka  

    数据存储组件:Kafka

    数据加工组件:Strom/Spark Stream/Flink Stream/Phoenix

    数据服务组件:HBase/Elasticsearch/Geomesa(时空数据库)/MPP 数据库(可以用作即席交互查询,如 Greenplum、HAWQ)

    1.2、业务数据量需求调研&数据保留周期调研

    主要调研各个业务系统的历史数据量、每天的数据增量以及数据保留周期等指标,用来评估大数据平台的存储规划,历史数据量和数据增量需要跟业务方系统的 DBA 沟通,数据保留周期需要跟业务方数据运营人员沟通。

    2、集群节点与硬件规划

    比如业务系统数据量每天增量 50T,保

    展开全文
  • 1 集群启动及初始化配置问题 集群配置修改好后,往往需要重启。每个集群的重启方式不一样,需要根据集群具体设定。 例如:我们现有第三方平台的重启方式为:sh /opt/workspace/executor-proxy/sbin/app.sh restart...
  • CDH版本的大数据集群 1. CDH和ClouderaManager简介 1.1 CDH版本的集群和Apache版本对比 apache版本: 优点:开源,更新快 缺点:部署过程复杂(组件版本的兼容性)这里有一个实际的例子可以列举,在学习HBase的...
  • 二、集群的部署,实现无密登录 1、进行首页输入密码登录; 2、打开命令台(点击鼠标右键选择open in terminal),首先输入ifconfig查看虚拟机是否连网,如果出现命令不存在,则可以根据提示下载这个工具(sudo apt-...
  • 公司使用的大数据集群是Cloudera,定期巡检,还是查出不少问题,后面进行优化。mark下供大家参考。发现主要的几个问题如下, 1. HDFS 小文件过多 小文件问题是目前HDFS上存在的最大问题。可以使用hadoop fs -count...
  • 大数据集群报错集锦及解决方案
  • Ambari在大数据集群部署方面有得天独厚的优势,但是集群操作系统安装准备工作以及基础包的安装还是需要花费很多的时间。为了节省大数据集群的部署时间接下来我们用Docker容器化的方案部署Ambari。 费话少说,放码...
  • 摘要:2021年4月21日,中国太平洋保险集团联合华为云完成了全球首例大数据集群跨多版本的大数据集群滚动升级。
  • 仅供参考 一、Linux自带jdk查看并删除 rpm -qa | grep jdk查看jdk的具体信息, 用rpm -e --nodeps java-1.5.0-gcj-1.5.0.0-29.1.el6.x86_64命令卸载相应的jdk 注:rpm 执行安装包 二、Hadoop安装后报错 ...
  • 大数据环境安装和配置(Hadoop2.7.7,Hive2.3.4,Zookeeper3.4.10,Kafka2.1.0,Flume1.8.0,Hbase2.1.1,Spark2.4.0等) 前言 本篇文章是以Hadoop为基础,搭建各种可能会用到的环境的基本步骤,包括:Hadoop,Hive...
  • ① 学会查看linux各种状态,包括:网络IO、磁盘、CPU、内存等; ② 学会理解命令所代表的含义,能够迅速发现集群存在的问题。
  • 某日笔者接到大数据集群使用人员紧急求救,反馈其在用的星环大数据tdh集群遇到以下故障无法解决,影响集群使用无法运行大数据计算任务。其反馈的问题现象如下: tdh集...
  • CDH6大数据集群离线安装前言、为什么要用离线的方式安装CDH6大数据集群一、下载安装包二、开通CentOS7云服务器三、编辑映射文件四、配置SSH免密登录五、编写集群分发脚本六、上传CDH6安装包到云服务器七、安装MySQL...
  • 先上效果: 这是由三块pine64+开发板搭建的mini集群,网上有用树莓派搭建Hadoop文章,不过由于树莓派的性能实在太差了(很老的CPU,1G内存),所以最终我选择了与之价格相近(200左右一块)的pine64+(官方链接在此:...
  • 大数据集群搭建笔记

    2021-05-22 16:06:25
    大数据集群搭建笔记 时间同步 所有datanode服务器时间跟NameNode时间同步 ssh 配置 namenode到每台datanode的免密码访问都要配,datanode和datanode之间非必需,可以把namenode的ssh pubkey内容追加到所有datanode的...
  • 大数据集群部署过程中,各集群节点的服务器时间可能不一致,会导致数据出错,这里使用syncDate进行批量时间同步。 2 配置集群hostname 2.1 配置hostname文件 1 服务器hadoop01 [root@localhost ~]# echo ...
  • 关闭虚拟机,删除虚拟机的.lck文件,使用ccleaner清理一下,然后重启试试
  • 适用于中小型企业,仅供参考!!! 一、磁盘容量预估 用户数基本固定 总用户数(个):A 每个用户每天产生的数据条数(条):B 每条数据的大小(KB):C 日均数据总量(TB):D = A·B·C/1024/1024/1024 ...
  • 文章目录1.查看namenode状态2.查看ResouceManager 状态 1.查看namenode状态 [root@hadoop01 ~]# hdfs haadmin -getServiceState nn1 active [root@hadoop01 ~]# hdfs haadmin -getServiceState nn2 ...
  • 大数据集群基础环境搭建创建3台虚拟机并联网(centos7)环境准备 创建3台虚拟机并联网(centos7) 三台机器规划 IP地址 主机名 第一台机器 192.168.1.100 node01.hadoop.com 第二台机器 192.168.1.110 node02.hadoop...
  • 1、集群准备 环境:阿里云(三台) 查看并关闭防火墙 systemctl status firewalld --查看防火墙 systemctl stop firewalld --关闭 systemctl disable firewalld.service --关闭开机启动 关闭selinux 查看 cat /etc/...
  • 从零开始搭建个人大数据集群——环境准备篇 我准备搭建的是高可用集群,所以要先安装zookeeper 环境准备 1.由于zookeeper的选举机制是leader选举,要求 可用节点数量 > 总节点数量/2 。注意 是 > , 不是 ≥。...
  • 大数据集群部署过程中,需要查询各个集群节点运行的服务状态,可使用批量命令脚本。 2 配置集群hostname 2.1 配置hostname文件 1 服务器hadoop01 [root@localhost ~]# echo hostname1 > /etc/hostname ...
  • typora-root-url: 大数据环境部署.assets Hadoop # 安装解压,移动到/usr/local/src/ export HADOOP_HOME=/usr/local/src/hadoop-3.3.1 export JAVA_HOME=/usr/local/src/jdk1.8.0_211 export export PATH=$HADOOP_...
  • 从零开始搭建个人大数据集群——环境准备篇 从零开始搭建个人大数据集群(1)——zookeeper 从零开始搭建个人大数据集群(2)——HDFS 从零开始搭建个人大数据集群(3)——YARN 从零开始搭建个人大数据集群(4)...
  • 大数据集群缓存清理

    2021-07-20 15:35:30
    1.在集群中编写shell脚本:vim drop_cache 2.添加执行权限:chmod +x drop_cache 3.执行文件:bash drop_cache echo "开始清理集群缓存~" && sync && for i in {13,12,11} do ssh 10.105.198.$i ...
  • 一、VMware安装Linux系统 1、准备Linux版本 2、VMware安装Linux ---------持续更新中

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 163,356
精华内容 65,342
关键字:

大数据集群