大数据集群部署策略是什么，集群运行状态如何监控，数据怎么采集的，采集后的存储和分析策略是什么？

最新推荐文章于 2024-01-01 09:03:07 发布

阿啄debugIT

最新推荐文章于 2024-01-01 09:03:07 发布

阅读量1.4k

点赞数 1

分类专栏：解决方案分布式集群大数据文章标签：大数据集群部署策略大数据采集后的存储策略是什么？ tsdb型数据库 Flink并行运算分析大数据Prometheus

本文链接：https://blog.csdn.net/as4589sd/article/details/115737144

版权

解决方案同时被 3 个专栏收录

80 篇文章 2 订阅

订阅专栏

大数据

13 篇文章 0 订阅

订阅专栏

分布式集群

6 篇文章 0 订阅

订阅专栏

前言

集群部署策略是什么，集群运行状态如何监控，数据怎么采集的，采集后的存储和分析策略是什么？

集群部署策略是什么

简单的节点部署策略

因为在一般情况下，Hadoop节点需要占用的磁盘空间是最紧张的资源，所以最基本的节点部署策略，是按照磁盘空间的大小来考虑的。
首先将所有Hadoop节点按照磁盘空间的要求从大到小进行排序，再将可用的Host按照剩余磁盘空间从大到小进行排序。
第一步将磁盘空间需求最大的Hadoop节点部署到剩余磁盘空间最大的主机上去，
第二步将磁盘空间需求次大的Hadoop节点部署到剩余磁盘空间次大的主机上去，以此类推。
当然，如果后面碰到主机的剩余磁盘空间不够部署某个节点的话，前面拥有较大剩余磁盘空间的主机就会被考虑。
这种策略的目的是，尽量利用所有可用的主机来部署Hadoop节点，这样每个节点都有更多的资源可供使用，导致图中有2个数据节点（DN）被放在了一个主机上，而有2个计算节点（CN）被放在了没有数据节点的主机上。

数据和计算分离的节点部署策略

随着Hadoop的发展，为了提供更好的弹性和实现真正的多租户，Hadoop数据节点（DataNode）和计算节点（ComputeNode）分开部署的方式开始流行起来。在这种模式下，为了提供最好的性能，需要把数据节点和计算节点尽可能的部署在相同的主机上。
为了实现数据节点和计算节点分离下的最优部署，需要在定义Hadoop集群时指定一些参数。

机架（Rack）感知的节点部署策略

对于大规模的Hadoop集群，会在数据中心内使用多个机架（Rack）。通过指定机架名称，可以把特定的Hadoop节点组，部署在指定的机架上。这种部署方式，可以在某个机架出现问题的时候，让Hadoop集群能够在正常工作的机架上持续运行。

集群运行状态如何监控及数据采集

选择Prometheus+Alertmanager

可以解决告警信息推送无法分类，无法针对某部分人进行特定告警、重复告警或无用告警过多，重要告警易被埋没，监控系统无法提供可视化展示，或仅能部分展示，监控历史数据不能二次查询或多维度查询，故障排查缺少依据。

对于业务量、平台主机量级较大的公司来说，使用以nagios+ganglia为首的传统的监控平台往往会遇到以上情况，显得力不从心。

经过大量、丰富的实战工作后，最后选择Prometheus+Alertmanager+钉钉的搭配作为大数据监控平台的告警分析、处理及发送工具组合。

这套组合不仅能够针对以上痛点一一解决，也可以说是运维人员保障集群平台稳定运行、故障排查、问题定位的一把利器。

Prometheus-数据存储及分析

Prometheus简介

Prometheus实际上是一个tsdb型数据库，所有的采集数据以metric的形式保存在其中，且能够将数据落到本地磁盘中，供使用人员二次查询数据。
Prometheus同时附加了强大的计算与分析功能，能够利用各种labels与promql语句，来完成多维度的监控数据查询，从而为故障排查与问题定位提供可靠的证据。

监控规则方面，Prometheus可以根据promql来获取数据，并且与固定阈值进行计算比较，若超出正常范围，则标记为告警信息，并且可以分组分标签定义告警描述，供后续Alertmanager使用。
在拓展性方面，Prometheus可以轻松的完成服务发现功能，并拥有每秒上万数据点的监控数据收集与分析的处理能力，完全摆脱了传统监控系统对监控主机数量的要求。

目前大数据平台机器几千余台，监控实例过十万，监控实例指标过千万，Prometheus优良的性能可以做到完美支撑。

Prometheus特点

监控数据存储功能及多维度查询

下图中以一个简单例子说明：该条查询可以看到某集群，接口机15分钟内的系统负载，涉及到的标签维度为集群、主机IP、主机类型等。

在实际线上环境中，还可以添加多个标签来完成查询，并且可以利用promql特有的查询语句(sum、count_values、topk等)，来完成更加丰富的多维度查询，提供可靠、便捷、直观的监控数据供运维人员使用。

优秀的自定义及第三方监控拓展功能

Pushgateway是Prometheus环境中的一个data_collector，把它定义为采集者的原因很简单，标准的Prometheus会采用pull模式，从target中获取监控数据，但当由于外力原因(如网络、硬件等)，无法直接从target中拉取数据时，就要依靠Pushgateway了，请看下图：

大致流程为，client上部署的脚本(支持多语言shell、python等)，会收集target中的数据，并且以metric形式，传送到Pushgateway中，只要保证client和Pushgateway，能够正常通信即可。

Prometheus会按照配置时间，定时到Pushgateway上拉取监控数据，从而达到收集target的目的。

下图为Pushgetway发送数据的代码过程：

那么是否可以这么理解：对于常见组件(redis、mysql、nginx、haproxy等)，我们可以依靠现有的丰富client库，直接进行监控纳管？

对于一些特殊组件或自定义业务，可通过多语言脚本采集监控数据或业务埋点方式，把Pushgateway作为一个data_collector，来收集各方数据，从而完成监控纳管。

良好的监控生态圈之常见client库

由于近年Prometheus的兴起，开源社区中越来越多的人将自己的代码贡献出来，使得Prometheus拥有庞大的client库(redis、mysql、nginx、haproxy等)，运维人员可以利用这些client，实现即开即用即监控的功能。

Prometheus配置

# 全局配置
global:
  scrape_interval:     15s   # 多久 收集 一次数据
  evaluation_interval: 30s   # 多久评估一次 规则
  scrape_timeout:      10s   # 每次 收集数据的 超时时间
  
  # 当Prometheus和外部系统(联邦, 远程存储, Alertmanager)通信的时候，添加标签到任意的时间序列或者报警
  external_labels:
    monitor: codelab
    foo:     bar
  
# 规则文件, 可以使用通配符
rule_files:
- "first.rules"
- "my/*.rules"
  
# 远程写入功能相关的设置
remote_write:
  - url: http://remote1/push
    write_relabel_configs:
    - source_labels: [__name__]
      regex:         expensive.*
      action:        drop
  - url: http://remote2/push
  
# 远程读取相关功能的设置
remote_read:
  - url: http://remote1/read
    read_recent: true
  - url: http://remote3/read
    read_recent: false
    required_matchers:
      job: special
  
# 收集数据 配置 列表
scrape_configs:
- job_name: prometheus  # 必须配置, 自动附加的job labels, 必须唯一
  
  honor_labels: true   # 标签冲突, true 为以抓取的数据为准 并 忽略 服务器中的, false 为 通过重命名来解决冲突
  # scrape_interval is defined by the configured global (15s).
  # scrape_timeout is defined by the global default (10s).
  
  metrics_path:     '/metrics'
  # scheme defaults to 'http'.
  
  
  # 文件服务发现配置 列表
  file_sd_configs:
    - files:  # 从这些文件中提取目标
      - foo/*.slow.json
      - foo/*.slow.yml
      - single/file.yml
      refresh_interval: 10m  # 刷新文件的 时间间隔
    - files:
      - bar/*.yaml
  
  
  # 使用job名作为label的 静态配置目录 的 列表
  static_configs:
  - targets: ['localhost:9090', 'localhost:9191']
    labels:
      my:   label
      your: label
  
  
  # 目标节点 重新打标签 的配置 列表.  重新标记是一个功能强大的工具，可以在抓取目标之前动态重写目标的标签集。 可以配置多个，按照先后顺序应用
  relabel_configs:
  - source_labels: [job, __meta_dns_name]   # 从现有的标签中选择源标签, 最后会被 替换， 保持， 丢弃
    regex:         (.*)some-[regex]  # 正则表达式, 将会提取source_labels中匹配的值
    target_label:  job   # 在替换动作中将结果值写入的标签.
    replacement:   foo-${1}  # 如果正则表达匹配, 那么替换值. 可以使用正则表达中的 捕获组
    # action defaults to 'replace'
  - source_labels: [abc]  # 将abc标签的内容复制到cde标签中
    target_label:  cde
  - replacement:   static
    target_label:  abc
  - regex:
    replacement:   static
    target_label:  abc
  
  bearer_token_file: valid_token_file  # 可选的, bearer token 文件的信息
  
  
- job_name: service-x
  
  # HTTP basic 认证信息
  basic_auth:
    username: admin_name
    password: "multiline\nmysecret\ntest"
  
  scrape_interval: 50s  # 对于该job, 多久收集一次数据
  scrape_timeout:  5s
  
  sample_limit: 1000  # 每次 收集 样本数据的限制. 0 为不限制
  
  metrics_path: /my_path  # 从目标 获取数据的 HTTP 路径
  scheme: https  # 配置用于请求的协议方案
  
  
  # DNS 服务发现 配置列表
  dns_sd_configs:
  - refresh_interval: 15s
    names:  # 要查询的DNS域名列表
    - first.dns.address.domain.com
    - second.dns.address.domain.com
  - names:
    - first.dns.address.domain.com
    # refresh_interval defaults to 30s.
  
  
  # 目标节点 重新打标签 的配置 列表
  relabel_configs:
  - source_labels: [job]
    regex:         (.*)some-[regex]
    action:        drop
  - source_labels: [__address__]
    modulus:       8
    target_label:  __tmp_hash
    action:        hashmod
  - source_labels: [__tmp_hash]
    regex:         1
    action:        keep
  - action:        labelmap
    regex:         1
  - action:        labeldrop
    regex:         d
  - action:        labelkeep
    regex:         k
  
  
  # metric 重新打标签的 配置列表
  metric_relabel_configs:
  - source_labels: [__name__]
    regex:         expensive_metric.*
    action:        drop
  
  
- job_name: service-y
  
  # consul 服务发现 配置列表
  consul_sd_configs:
  - server: 'localhost:1234'  # consul API 地址
    token: mysecret
    services: ['nginx', 'cache', 'mysql']  # 被检索目标的 服务 列表. 如果不定义那么 所有 服务 都会被 收集
    scheme: https
    tls_config:
      ca_file: valid_ca_file
      cert_file: valid_cert_file
      key_file:  valid_key_file
      insecure_skip_verify: false
  
  relabel_configs:
  - source_labels: [__meta_sd_consul_tags]
    separator:     ','
    regex:         label:([^=]+)=([^,]+)
    target_label:  ${1}
    replacement:   ${2}
  
- job_name: service-z
  
  # 收集 数据的 TLS 设置
  tls_config:
    cert_file: valid_cert_file
    key_file: valid_key_file
  
  bearer_token: mysecret
  
- job_name: service-kubernetes
  
  # kubernetes 服务 发现 列表
  kubernetes_sd_configs:
  - role: endpoints   # 必须写, 必须是endpoints, service, pod, node, 或者 ingress
    api_server: 'https://localhost:1234'
  
    basic_auth:  # HTTP basic 认证信息
      username: 'myusername'
      password: 'mysecret'
  
- job_name: service-kubernetes-namespaces
  
  kubernetes_sd_configs:
  - role: endpoints  # 应该被发现的 kubernetes 对象 实体
    api_server: 'https://localhost:1234'  # API Server的地址
    namespaces:  # 可选的命名空间发现, 如果省略 那么所有的命名空间都会被使用
      names:
        - default
  
- job_name: service-marathon
  # Marathon 服务发现 列表
  marathon_sd_configs:
  - servers:
    - 'https://marathon.example.com:443'
  
    tls_config:
      cert_file: valid_cert_file
      key_file: valid_key_file
  
- job_name: service-ec2
  ec2_sd_configs:
    - region: us-east-1
      access_key: access
      secret_key: mysecret
      profile: profile
  
- job_name: service-azure
  azure_sd_configs:
    - subscription_id: 11AAAA11-A11A-111A-A111-1111A1111A11
      tenant_id: BBBB222B-B2B2-2B22-B222-2BB2222BB2B2
      client_id: 333333CC-3C33-3333-CCC3-33C3CCCCC33C
      client_secret: mysecret
      port: 9100
  
- job_name: service-nerve
  nerve_sd_configs:
    - servers:
      - localhost
      paths:
      - /monitoring
  
- job_name: 0123service-xxx
  metrics_path: /metrics
  static_configs:
    - targets:
      - localhost:9090
  
- job_name: 測試
  metrics_path: /metrics
  static_configs:
    - targets:
      - localhost:9090
  
- job_name: service-triton
  triton_sd_configs:
  - account: 'testAccount'
    dns_suffix: 'triton.example.com'
    endpoint: 'triton.example.com'
    port: 9163
    refresh_interval: 1m
    version: 1
    tls_config:
      cert_file: testdata/valid_cert_file
      key_file: testdata/valid_key_file
  
# Alertmanager相关的配置
alerting:
  alertmanagers:
  - scheme: https
    static_configs:
    - targets:
      - "1.2.3.4:9093"
      - "1.2.3.5:9093"
      - "1.2.3.6:9093"

Alertmanager-告警的分类搬运工

Alertmanager简介

Alertmanager在监控系统中的定位，是接收Prometheus发送来的告警，并逐一按照配置中route进行分类，并且通过silencing、inhibition的规则计算，最终得到有效告警信息，通过邮件、钉钉、微信等方式，发送给各类业务人群。

Alertmanager特点

分组

可以用一个业务场景来解释该特点：某大数据集群，由于网络问题大面积瘫痪，上百个datanode触发断开告警，如果按照传统监控模式的话，收到的将是上百条的告警短信，形成短信轰炸。但如果使用分组特性，Alertmanager会将具有共同属性的告警，归为一条发送到接收端，清晰明了。

抑制

还是用业务场景来解释该特点：某主机上运行了一个mysql实例，若该主机宕机，则会收到多条关于mysql各项监控的告警信息，但如果配置了抑制用法，只要触发该主机的宕机告警，上面mysql所触发的告警便会被抑制掉。

沉默

举例来说，某主机硬件主板损坏，但厂商反馈要2天后，才能更换主板，一般情况下在更换主板前，该警报会一直大量重复发送。如果此时利用沉默功能，在页面上配置沉默选项，即可暂停此告警，待修复完成后取消沉默规则即可。

Alertmanager配置

global:
  smtp_smarthost: 'smtp.exmail.qq.com:25'       # smtp地址
  smtp_from: 'sijy@jubaozhu.com'                # 谁发邮件
  smtp_auth_username: 'sijy@jubaozhu.com'       # 邮箱用户
  smtp_auth_password: 'xxxxx'                   # 邮箱密码
  smtp_require_tls: false

route:
  group_by: ["instance"]            # 分组名
  group_wait: 30s                   # 当收到告警的时候，等待三十秒看是否还有告警，如果有就一起发出去
  group_interval: 5m                # 发送警告间隔时间
  repeat_interval: 3h               # 重复报警的间隔时间
  receiver: mail                    # 全局报警组，这个参数是必选的，和下面报警组名要相同

receivers:
- name: 'mail'                      # 报警组名
  email_configs:
  - to: 'sijiayong000@163.com'      # 发送给谁

Alertmanager启动

nohup /opt/alertmanager-0.19/bin/alertmanager --log.level=info --log.format=json --web.listen-address="10.0.20.12:9093" --config.file="/opt/alertmanager-0.19/config/alertmanager.yml" --storage.path="/opt/alertmanager-0.19/data/" --data.retention=120h &>>/opt/alertmanager-0.19/logs/alertmanager.log &

--log.level 日志级别
--log.format 日志输出格式
--web.listen-addres 监听地址端口
--config.file 配置配置文件
--storage.path 配置数据保存目录
--data.retention 配置数据保留时间

启动后即可访问页面

配置prometheus监控Alertmanager

因为后面会部署alertmanager集群，所以这里使用SRV解析的自动发现

修改prometheus配置

[root@es01 config]# cat prometheus.yml
global:
  scrape_interval:     15s
  evaluation_interval: 15s

alerting:
  alertmanagers:
    - dns_sd_configs:               # 同样配置DNS自动发现
      - names: ["_alertmanager._tcp_k8s.com."]  # 加入SRV解析的自动发现

rule_files:

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
    - targets: ['localhost:9090']

  - job_name: 'node_srv'
    metrics_path: "/metrics"
    dns_sd_configs:
    - names: ['_prometheus._tcp.k8s.com']

  - job_name: 'alertmanager'
    metrics_path: "/metrics"
    dns_sd_configs:
    - names: ['_alertmanager._tcp.k8s.com']

上面配置好后，在DNS上做好对应的SRV解析接口。

让prometheus重新加载配置文件

检查配置文件，并重新加载

# 检查配置文件
[root@es01 config]# /opt/prometheus-2.14/bin/promtool check config /opt/prometheus-2.14/config/prometheus.yml
Checking /opt/prometheus-2.14/config/prometheus.yml
  SUCCESS: 0 rule files found
# 重新加载配置文件
[root@es01 config]# curl -X POST httP://10.0.20.11:9090/-/reload
[root@es01 config]#

钉钉-最终告警接收查阅

运维人员常用的发送告警工具有短信、邮件、企业微信和钉钉，之所以选择钉钉的原因如下：

短信：

一般是通过往oracle插入告警信息，走短信网关发送;
优点是及时高效，但缺点是oracle支持的并发量有限。

邮件：

邮件告警的及时性是一个很大的问题，并且如果没有合理设置阈值，邮件轰炸会影响其他工作邮件的阅读。

企业微信：

企业微信不存在短信网关的并发限制，但弊端在于告警条数有限。

钉钉：

有强大的分组功能，且不限制告警条数;可按项目创建告警群，也方便解除。

使用钉钉作为告警接收工具，简单来说，就是在钉钉群聊中，配置机器人，每个机器人，会有一条唯一的webhook，当接收到来自Alertmanager的告警后，就可以发送到手机端。

大数据采集后的存储和分析策略是什么？

大数据采集后的存储

云存储

云存储是在云计算（cloud computing）概念上延伸和发展出来的一个新的概念，是一种新兴的网络存储技术，是指通过集群应用、网络技术或分布式文件系统等功能，将网络中大量各种不同类型的存储设备，通过应用软件集合起来协同工作，共同对外提供数据存储，和业务访问功能的一个系统。云存储不仅是存储设备或技术，更是一种服务的创新。

特点：可靠性、可用性、安全性、规范化、低成本。
架构：访问层、应用接口层、基础管理层。
技术：存储虚拟化、分布式存储、数据缩减、负载均衡。

云存储的虚拟化，将存储资源虚拟化为全局命名空间，并通过多租户技术给使用者提供存储资源。
分布式存储分，为分布式块存储，分布式对象存储以及分布式文件系统。
数据缩减，一定程度上节约企业存储成本，提高效率。包括自动精简配置，自动存储分层（超市摆放物品），重复数据删除（自己产生的数据）。
负载均衡技术，节点的负载均衡，能够更好的实现系统的动态扩展，即若系统收到的请求，均匀分配给每个节点后，超出节点的处理能力，只需通过扩充节点的数目，就可以减少系统所有节点的压力，而无需对内部的负载均衡机制做任何处理。

大数据存储

大数据存储系统架构分为DAS，NAS以及SAN。

DAS(直接连接存储：Direct Attached Storage)

DAS的数据分散在应用服务器各自的存储设备上，不变集中管理、分析和使用数据

适用环境：

服务器地理分布很分散，通过SAN或NAS互联困难。
存储系统必须直接与应用服务器连接。
小型网络。

缺点：

扩展性差。
资源利用率低。
可管理性差。
异构化严重。

NAS(网络附加存储服务器：Network Attached Storage)

优点：

即插即用，可以基于已有的企业网络方便连接到应用服务器。
专用操作系统支持不同的文件系统，从而可以支持应用服务器不同操作系统之间的文件共享。
专用服务器上经过优化的文件系统提高了文件的访问效率。
独立于应用服务器，即使应用服务器故障或停止工作，仍然可以读出数据。

缺点：

共用网络的模式使网络带宽成为存储性能瓶颈。
NAS访问要经过文件系统格式转换，故只能以文件一级访问，不适合块级的应用。

SAN(存储区域网络：Storage Area Network)

SAN是通过专用高速网，将一个或多个网络存储设备和服务器连接起来的专用存储系统。可以把SAN理解成一个网络，这个网络里包含着各种各样的元素，比如磁盘阵列，FC交换机。

SAN几乎接近主机内部内存的访问效率，而NAS要经过以太网，一般来说要慢很多，特别是对大块的数据的读取。
但是，当速度的瓶颈在磁盘等存储介质上时，光纤网络的优势不再时，NAS由于经过优化的文件系统(并发、分布式)会展示出比SAN更加优越的性能！

数据仓库

大数据分析策略

数据分析是大数据价值链中最终和最重要的阶段，其目的是挖掘数据中潜在的价值以提供相应的建议或决策。
数据分析( Data Analysis)是一个检查、清理、转换和建模数据的过程，目的是发现有用的信息，得出结论和推动决策制定。
数据挖掘（Data mining）是指用人工智能、机器学习、统计学和数据库的交叉方法在相对较大型的数据集中发现模式的计算过程。
数据分析流程（下图）（两句话，①数据分析是从业务中来，到业务中去；②脱离了业务的数据分析都是耍流氓）。

传统数据分析策略

比较有代表性的传统数据分析方法：统计分析，相关分析，回归分析，聚类分析，因子分析，A / B测试；

①统计分析

②相关分析：一种用于确定观测现象之间的相关规律，从而进行预测和控制的分析方法。相关分析是利用现有统计数据研究关系的强度的过程（例子是身高与年龄）。同时，相关不等于因果（睡眠与收入）。

③回归分析：揭示一个变量和其他几个变量之间的相关性的数学工具。
回归分析能够识别随机隐藏的变量之间的依赖关系（一元线性回归）。

④聚类分析：一种将对象进行分组的统计方法。聚类分析，用于区分具有某些特征的对象，并根据这些特征，将它们分成不同的类别。同一类别中的对象具有高同质性，不同类别中的对象具有高异质性。

⑤因子分析：主要是通过少数几个因子，来描述大量指标或元素之间的关系（例子是找对象，以自己中意的几个典型的维度，对另一半进行刻画。如白富美，地域，教养，品行，性格等等）。

⑥A/B测试，也称为水桶测试。它通过比较测试组，制定能改善目标变量的计划（更多地应用在产品或网页的设计中，根据用户体验，与反馈对产品进行完善）。

大数据分析策略

对大数据存储效率，以及读取速度进行优化的大数据分析策略。

①布隆过滤器：由一个位数组和一系列的哈希函数组成。

布隆过滤器的原理，是通过利用位数组来存储数据本身之外的数据的哈希值。

位数组本质，是使用哈希函数来进行数据的有损压缩，从而存储其位图索引。

布隆过滤器算法的核心思想：利用多个不同的哈希函数来解决“冲突”。

例如：教室里是否有同学，门口会有一排灯，某几个灯亮表示有同学，为了避免冲突，灯亮以颜色进行区分。灯亮表示1，不亮表示0

②散列法：一种将数据变换为较短的固定长度数值，或索引值的基本方法。

特点：快速读取、快速写入和高查询速度。

难点：如何找到健全的散列函数。

优点：空间效率高、查询速度快。

缺点：具有一定的误识别率、删除困难等。

例如：谍战片里面传递情报场景，最重要的是找到密码本（散列法的难点）。

③索引法：是减少磁盘读取和写入成本的有效方法。

索引法能够提高插入、删除、修改和查询速度。

索引一般分为两类：聚集索引和非聚集索引。

例如：索引类似于书籍的目录，mysql聚集索引clustered index(id), 非聚集索引index(username)。

④字典树：又称单词查找树，是一种哈希树的变体。

它主要应用于快速检索和字频统计。

主要思想是：利用字符串的常见前缀，来最大限度地减少字符串的比较，从而提高查询效率。

⑤并行计算：并行计算是指利用若干计算资源来完成计算任务。

其基本思想是：分解一个问题，并将其分配给几个独立的进程，以便独立完成，从而实现协同处理。

Spark并行运算分析

Spark核心概念

RDD（Resilient Distributed Datasets,弹性分布式数据集）

分布在集群中的只读对象集合（由多个Partition构成）；
可以存储在磁盘或内存中（多种存储级别）；
通过并行“转换”操作构造；
失效后自动重构；
RDD基本操作（operator）

Spark在企业中的应用场景

基于日志数据的快速查询系统业务；
构建于Spark之上的SparkSQL ,利用其快速以及内存表等优势，承担了日志数据的即席查询工作。
典型算法的Spark实现
预测用户的广告点击概率；
计算两个好友间的共同好友数；
用于ETL的SparkSQL和DAG任务；

Flink并行运算分析

Flink特点及概念

Apache Flink是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。Flink设计为在所有常见的集群环境中运行，以内存速度和任何规模执行计算。
1）流计算
数据源源不断产生，我们的需求是源源不断的处理。程序需要一直保持在计算的状态。
2）批处理
计算一段完整的数据集，计算成功后释放资源，那么此时工作结束。

Flink并行运算

Flink 运行时架构主要包含几个部分：Client、JobManager(master节点)和TaskManger(slave节点)。

分布式计算中，Flink 将算子（operator）的 subtask *链接（chain）*成 task【类似于Spark中的Stage阶段】。

每个 task 由一个线程执行，把算子链接成 tasks ，能够减少线程间切换，和缓冲的开销，在降低延迟的同时，提高了整体吞吐量。

当前的flink应用由3个Task，5个SubTask构成，每一个SubTask会由1个Thread处理

–Flink中的Task等价于Spark中的Stage
–Flink根据Operator Chain划分任务Task，两种依据：Forward和Hash | Rebalance

每个 worker（TaskManager）都是一个 JVM 进程，并且可以在不同的线程中，执行一个或多个 subtasks。为了控制 worker 接收 task 的数量，worker 拥有所谓的 task slots （至少一个）。

每个 task slots 代表 TaskManager 的一份固定资源子集。例如，具有三个 slots 的 TaskManager ，会将其管理的内存资源，分成三等份给每个 slot。划分资源，意味着 subtask 之间不会竞争资源，但是也意味着，它们只拥有固定的资源。注意这里并没有 CPU 隔离，当前 slots 之间只是划分任务的内存资源。

通过调整 slot 的数量，用户可以决定 subtasks 的隔离方式。每个 TaskManager 有一个 slot ，意味着每组 task 在一个单独的 JVM 中运行（例如，在一个单独的容器中启动）。

拥有多个 slots 意味着多个 subtasks 共享同一个 JVM。 Tasks 在同一个 JVM 中共享 TCP 连接（通过多路复用技术）和心跳信息（heartbeat messages）。它们还可能共享数据集和数据结构，从而降低每个 task 的开销。

默认情况下，Flink 允许 subtasks 共享 slots，即使它们是不同 tasks 的 subtasks，只要它们来自同一个 job。

因此，一个 slot 可能会负责这个 job 的整个管道（pipeline）。

允许 slot sharing 有两个好处：

Flink 集群需要与 job 中使用的最高并行度一样多的 slots。这样不需要计算作业总共包含多少个 tasks（具有不同并行度）。
更好的资源利用率。在没有 slot sharing 的情况下，简单的 subtasks（source/map()），将会占用和复杂的 subtasks （window）一样多的资源。通过 slot sharing，将示例中的并行度从 2 增加到 6 可以充分利用 slot 的资源，同时确保繁重的 subtask 在 TaskManagers 之间公平地获取资源。

APIs 还包含了resource group 机制，它可以用来防止不必要的 slot sharing。

根据经验，合理的 slots 数量应该和 CPU 核数相同。在使用超线程（hyper-threading）时，每个 slot 将会占用 2 个或更多的硬件线程上下文（hardware thread contexts）。

阿啄debugIT

关注

1
点赞
踩
3

收藏

觉得还不错? 一键收藏
打赏
0
评论
大数据集群部署策略是什么，集群运行状态如何监控，数据怎么采集的，采集后的存储和分析策略是什么？

前言集群部署策略是什么，集群运行状态如何监控，数据怎么采集的，采集后的存储和分析策略是什么？集群部署策略是什么简单的节点部署策略因为在一般情况下，Hadoop节点需要占用的磁盘空间是最紧张的资源，所以最基本的节点部署策略，是按照磁盘空间的大小来考虑的。首先将所有Hadoop节点按照磁盘空间的要求从大到小进行排序，再将可用的Host按照剩余磁盘空间从大到小进行排序。第一步将磁盘空间需求最大的Hadoop节点部署到剩余磁盘空间最大的主机上去，第二步将磁盘空间需求次大的Hadoop节点部署到
复制链接

扫一扫