gitweixin
  • 首页
  • 小程序代码
    • 资讯读书
    • 工具类
    • O2O
    • 地图定位
    • 社交
    • 行业软件
    • 电商类
    • 互联网类
    • 企业类
    • UI控件
  • 大数据开发
    • Hadoop
    • Spark
    • Hbase
    • Elasticsearch
    • Kafka
    • Flink
    • 数据仓库
    • 数据挖掘
    • flume
    • Kafka
    • Hive
    • shardingsphere
    • solr
  • 开发博客
    • Android
    • php
    • python
    • 运维
    • 技术架构
    • 数据库
  • 程序员网赚
  • bug清单
  • 量化投资
  • 在线查询工具
    • 去行号
    • 在线时间戳转换工具
    • 免费图片批量修改尺寸在线工具
    • SVG转JPG在线工具

在 Kubernetes 上开始使用 Spark 的快速指南

精品微信小程序开发门户,代码全部亲测可用

  • 首页   /  
  • 作者: east
  • ( 页面40 )
Spark 5月 11,2023

在 Kubernetes 上开始使用 Spark 的快速指南

Apache Spark 与 Kubernetes?或两者?在过去的几年里,使用 Spark on Kubernetes (K8s) 的公司数量急剧增加。考虑到 K8s 带来的好处,这并不奇怪。根据我们最近的调查,77% 的企业正在采用 Kubernetes 技术来提高资源利用率并减少云费用。

在向云的广泛迁移的推动下,在 Kubernetes 上部署 Spark 的公司数量正在增长。然而,公司应该知道以这种方式在 Kubernetes 上运行 Spark 有其缺点。使用 Kubernetes 运行 Spark 的企业必须准备好应对此解决方案带来的挑战。最重要的是,他们需要对其基础架构具有可观察性,并轻松优化其性能的多个方面。

Spark 是一种开源分析引擎,旨在处理大量数据。它为用户提供了一个统一的接口,用于使用数据并行性和容错对整个集群进行编程。 Kubernetes 是一个开源容器编排平台,可自动执行计算机应用程序部署、扩展和管理。

将 Kubernetes 上的 Apache Spark 想象成这样:Spark 提供计算框架,而 Kubernetes 管理集群。 Kubernetes 为用户提供了一种用于管理多个集群的操作系统。因此,该技术提供了卓越的集群使用和分配灵活性,从而节省了大量成本。

没有 Spark 与 Kubernetes 的争论。我们建议企业在 Kubernetes 上部署 Spark,因为与在 YARN 上运行 Spark 相比,这是一种更符合逻辑和实用的方法。一方面,Spark K8s 环境没有 YARN 的限制。 YARN 的集群很复杂,消耗的计算资源比作业所需的多。此外,用户需要为 YARN 中的每个作业创建和拆除集群。这种设置不仅会浪费大量资源,转化为更多成本,还会导致任务管理效率低下。

另一方面,Kubernetes在大数据场景中爆发,几乎触及了包括Spark在内的所有企业技术。随着其日益流行和无处不在,以及其用户社区的迅速扩大,Kubernetes 将取代 YARN 成为世界主要的大数据处理引擎。

Spark 与 Kubernetes 的争论是否有道理?最近的趋势表明我们正朝着这个方向前进。

许多 Spark 用户指出了在 Kubernetes 上运行 Spark 作业比 YARN 有优势。首先,将 Spark 应用程序部署到组织现有的 Kubernetes 基础设施中并不困难。这导致跨多个软件交付团队的努力和目标快速无缝地对齐。

其次,最新的 Spark 版本 (3.2) 已经解决了 Kubernetes 之前的性能和可靠性问题。使用 Kubernetes 管理 Spark 作业可带来更好的性能和成本节约,超过 YARN 提供的功能。 Amazon 进行的多次测试表明,使用 Kubernetes 而非 YARN 可节省 5% 的时间。

在 K8s 上运行 Spark 的其他好处现在正在显现。但企业应该采用 Kubernetes 的最大原因是什么?企业和云供应商已经通过 CNCF(云原生计算基金会)表达了对该框架的支持。 Kubernetes 上的 Spark 简直就是大数据分析的未来。

是的。当您在 Kubernetes 上运行 Spark 时,Spark 会生成一个在 Kubernetes pod 内部运行的 Spark 驱动程序。然后驱动程序创建执行器,这些执行器在 Kubernetes pod 中运行,连接到它们,并实现应用程序代码。

一旦应用程序完成,执行器 pod 就会终止。然后这些被清理,但驱动程序 pod 继续记录并在 Kubernetes API 中保持“完成”状态。它一直保持这种状态,直到最终成为收集或手动清理的垃圾。

企业正在采用 Spark Kubernetes 设置来提高云资源的利用率。 Spark Kubernetes 动态分配资源有助于简化云流程并缩短部署时间。根据我们的调查,近 30% 的企业转向 Kubernetes 以实现高效的资源利用。最重要的是,超过 17% 的受访者表示他们采用了 Kubernetes Spark,旨在加快他们的应用程序部署周期。

软件工程师、开发人员和 IT 专家都喜欢 Spark,因为它能够以比 MapReduce 框架快 100 倍的速度实施和执行计算任务。

现在,如果他们使用 Spark Kubernetes 方法,由于容器化,迭代周期最多可加快 10 倍,五分钟的开发工作流程报告可缩短至 30 秒。 Spark Kubernetes 动态分配不仅导致处理量急剧增加,使用 Kubernetes 的容器化也不像硬件级虚拟化那样占用资源。

对于 Kubernetes Spark 项目来说,混合可用于数据处理和 Spark 作业编排的不同元素是很常见的。当用户将这些 Spark 组件作为类似 Kubernetes 集群中的工作负载运行时,这些组件可以包括各种后端和 Spark SQL 数据存储(仅举几例),从而获得更好的性能。这是因为 Kubernetes 确保每个工作负载都有足够的资源和与所有依赖项的连接,无论是在同一个集群中还是在集群外。

在大数据、云计算、按需付费的时代,每个企业都想降低成本。这就是为什么许多企业希望通过 K8s Spark 来实现高效的资源共享和利用。

在我们调查的 IT 领导者中,近 30% 正在考虑使用 Kubernetes 来帮助降低他们的云成本。在 K8s 上运行 Apache Spark 已被证明可以通过完全隔离和强大的资源共享帮助企业大幅降低云成本。
这种成本降低是如何发生的?用户可以将所有应用程序部署在一个 Kubernetes 集群中。当应用程序完成时,Kubernetes 可以快速拆除其容器并将资源快速重新分配给另一个应用程序,并根据 Spark 指标和其他性能基准优化 Spark Kubernetes 配置。整个过程只需要 10 秒钟就可以将资源转移到其他地方。

那么我们说的是节省多少呢?在一个案例中,一家公司在从 YARN 切换到 Kubernetes 模型上的 Spark 后削减了 65% 的云成本。

Kubernetes 对于统一的 IT 基础架构越来越重要,而 Spark 是第一个迁移到云端的大数据应用程序。然而,Spark 应用程序往往效率很低。

这些低效率表现在各种方面。我们向受访者询问了他们在流程中使用 Kubernetes Spark 设置时面临的主要挑战。以下是他们最大的三个绊脚石:

初始部署

一些 Spark 挑战阻碍了成功实施。我们的调查将初始部署列为受访者在 Kubernetes 上运行 Spark 时面临的最大挑战。技术很复杂。对于那些不熟悉 Kubernetes Spark 平台的人来说,框架、语言、工具等可能会让人望而生畏。

在 Kubernetes 基础设施上大规模运行 Spark 应用程序需要大量的技术专业知识。即使那些具有丰富 Kubernetes 知识的人也认识到在部署之前需要构建一些部分,例如集群、节点池、spark-operator、K8s 自动缩放器、docker 注册表等。

移民

迁移到 Kubernetes 可以让您的企业处于优势地位,就像迁移到云端或采用大数据一样。但这只有在您在迁移之前有一个健全而强大的策略时才有可能。迁移到 Kubernetes 可能很困难(或导致彻底失败)的众多原因之一是,领导者决定采用一项技术,但没有明确的理由进行如此大的迁移。

此外,许多企业在其组织内不具备必备技能。在 K8s 架构上切换到 Spark 需要相当多的人才才能使过渡顺利和成功。忽略或未能识别应用程序或基础架构的潜在问题,例如扩展或可靠性,可能会导致迁移挑战。

监控和警报

Kubernetes 是一项复杂的技术,监控可能很困难。当您将 Spark 与 Kubernetes 结合使用时更是如此。选择合适的工具来监控和评估您的 Kubernetes 实施增加了这种复杂性。根据我们的调查,28% 的受访者使用手动方法或自行开发的解决方案,而 27% 的受访者利用应用程序性能监控 (APM) 软件。

性能监控和优化已经超出了人类的能力范围。通用 APM 通常未设计或配置为处理 K8s 工作负载和其他大数据基础设施上的大型 Spark。有效而强大的 Kubernetes 和 Spark 监控现在需要全面而强大的工具,这些工具专为 Kubernetes 上的大数据工作负载而设计。

随着 Spark Kubernetes 设置的优势变得更加明显,整个 Spark 与 Kubernetes 的争论已经退居二线。在 Kubernetes 上运行 Spark 有效地实现了加速产品周期和持续运营。

数据科学和机器学习技术的扩展加速了容器化的采用。这一发展有效地推动了 Spark on Kubernetes 方法成为数据集群和建模生态系统的首选设置。 Spark on Kubernetes 为用户提供了抽象弹性 GPU 和 CPU 的能力,以及它的按需可扩展性。

作者 east
doris, Flink 5月 11,2023

同步 MySQL 数据到 Doris 的常用方案

  1. 使用Flink CDC

优点:

  • 实时同步,可支持增量同步和全量同步
  • 可以按需调整并发度和流水线等参数,可弹性伸缩
  • 高可靠性和灵活性,能够处理多种场景下的同步需求

缺点:

  • 实现和部署比较复杂,需要掌握 Flink 的相关知识
  • 对系统资源和性能要求较高,需要有一定的硬件配置
  • 需要进行一定的性能测试和优化,才能支持实际业务量

2.使用Doris MySQL Proxy

优点:

  • 部署和使用比较简单,不需要修改 MySQL 应用程序
  • 对 MySQL 应用程序和数据库系统无侵入
  • 可以保证数据的一致性和可靠性

缺点:

  • 过程中需要对数据库 Proxy 进行自定义集成
  • 不支持多库多表的同步,只能同步一个 MySQL 数据库
  • 可能存在数据丢失或者漏读的问题

3.使用Canal

优点:

  • 存在简单,部署方便
  • 支持 MySQL 的多种版本
  • 可用于实时同步 MySQL 数据
  • 对系统资源和性能需求较低,适合小数据量同步

缺点:

  • 不支持多库多表同步
  • 可能存在数据丢失或者漏读的问题
  • 官方不再维护
作者 east
Flink 5月 11,2023

Flink Web UI中Task Managers和Job Manager分别起到什么作用,怎样使用

在 Flink 中,Job Manager 和 Task Managers 扮演着非常重要的角色,它们负责执行和管理 Flink 作业。具体来说:

  • Job Manager:作为 Flink 集群的控制中心,负责协调和分配任务,包括将 JobGraph(Flink 作业的数据流图)转换成 ExecutionGraph(Flink 作业的执行图),将任务分配到 Task Managers 上运行,并监视整个作业的执行情况。
  • Task Manager:在 Flink 集群中,每个 Task Manager 负责管理一段物理资源,包括处理器、内存等,并承担执行 Flink 任务的责任。Task Manager 会定期向 Job Manager 汇报执行情况,并通知 Job Manager 当前任务的状态和进度。

在 Flink Web UI 中,我们可以方便地查看和监控 Job Manager 和 Task Managers 的信息,并进行相应的操作。具体来说,我们可以:

  • 查看 Job Manager 的信息:登录 Flink Web UI 后,我们可以在 Job Manager 标签页中查看当前 Job Manager 的状态、运行的作业以及作业的执行图;此外,我们还可以在该页面上提交新的作业、取消执行中的作业,或者重启已经完成的作业。
  • 查看 Task Managers 的信息:在 Task Managers 标签页中,我们可以查看整个 Flink 集群中所有 Task Manager 的状态,包括已分配任务的数量、总共可用的内存和 CPU 等信息;此外,我们还可以在该页面上指定 Task Manager 并查看其详细信息,包括该 Task Manager 上正在运行的任务、任务的状态和进度等。

需要注意的是,在 Flink Web UI 中对 Job Manager 和 Task Managers 的操作都需慎重考虑,避免误操作导致 Flink 作业的执行出现异常。

作者 east
doris 5月 11,2023

mysql text、longtext类型转化为doris

MySQL有四种类型的文本数据:TINYTEXT,TEXT,MEDIUMTEXT和LONGTEXT。它们分别可以存储最多255,65,535,16,777,215和4,294,967,295个字符。Doris有一种类似的类型叫VARCHAR,它可以存储最多64K字节的数据。但是,Doris不支持BLOB或TEXT类型。

要将MySQL的text或longtext转换为Doris的类型,你可以使用适当长度的VARCHAR。例如,如果你的MySQL text列有小于64K个字符,你可以在Doris中使用VARCHAR(65535)。如果你的MySQL longtext列有超过64K个字符但小于4G个字符,你可以在Doris中使用VARCHAR(4294967295)。但是,请注意,使用这样大的VARCHAR列可能会影响Doris的性能和内存使用。

另外,你也可以考虑使用不同的存储系统来存储长字符串,比如NoSQL数据库,并且只在Doris中存储一个引用或一个ID。

作者 east
Spark 5月 10,2023

今天如何成功地将大数据与 Spark 结合使用

您可能很难找到从未听说过 Apache Spark 或从未将大数据与 Spark 结合使用的大数据从业者。我们甚至可以说这几乎是不可能的——这是有充分理由的。 Spark 众所周知,因为它快速、可靠且功能强大。让我们深入探讨其中的原因,回答有关 Spark 计算的一些常见问题,如何轻松使用它来取得成功等等。

Apache Spark 是一种用于大规模数据处理的快速开源统一分析引擎。为应对 MapReduce 的限制,它于 2012 年在加州大学伯克利分校的 AMPLab 开发,其代码库现在由 Apache 软件基金会维护。

Spark 以速度快着称,因为与其前身 MapReduce 不同,它能够在内存 (RAM) 而不是磁盘驱动器上运行。由于它是开源软件,任何人都可以免费使用。开发人员可以制作量身定制的 Spark 版本来解决特定问题或用例。

可以使用 Spark 代替 Hadoop,而且随着开发人员开始认识到 Spark 的优势,这种做法越来越频繁。您可以在 Hadoop 上使用 Spark,也可以在没有 Hadoop 的情况下使用它,也可以将两者结合使用。

如果您已经拥有 Hadoop,则没有理由围绕它构建 Spark。如果您是从头开始,并且追求 Spark 提供的速度和实时数据分析,那么没有理由首先构建 Hadoop。

然而,答案实际上取决于您尝试使用 Spark 运行大数据的目的。 Hadoop 旨在高效处理批处理,而 Spark 旨在高效处理实时数据。因此,如果您的目标是分析实时事件,Spark Streaming 可能是最佳选择。当您需要从 Hadoop 的资源管理器获得复杂的资源管理时,使用 Spark on Hadoop 将是最佳选择。

您使用 Spark 来分析和操作大数据,以检测模式并获得实时洞察力。它可以在任何类 UNIX 系统(Mac OS 或 Linux)、Windows 或任何运行当前支持的 Java 版本的系统上运行。 (有关更多详细信息,请查看文档。Spark 有许多使用大数据的用例,从零售商使用它来分析消费者行为,到医疗保健领域为患者提供更好的治疗建议。

优化 Spark 大数据工作负载的 3 个技巧

一旦开始运行 Spark 工作负载,您可能会遇到常见的 Spark 问题,例如滞后或作业失败。以下是我们发誓可以提供帮助的三个提示。

有些公司选择在没有额外工具的情况下运行 Spark,但我们建议使用 APM 工具来确保您满足 SLA、实现业务目标并保持在预算之内。

作者 east
云计算 5月 10,2023

云计算可扩展性:更复杂意味着更高的成本

云计算可扩展性可帮助企业将其云基础设施保持在最佳水平,无论资源需求或突然使用高峰如何。但是,这种可扩展性可能很难解锁。云很复杂,很难实现可见性,而且成本会不断上升。公司如何处理这种复杂性并有效地扩展他们的云计算?

不提大数据就不可能讨论云计算。企业使用大数据并通过分析从该数据中获得洞察力。这些见解可帮助企业推动关键业务流程、简化创新周期并推动战略决策。

为了收集和处理海量大数据,企业传统上需要更大的 IT 基础设施来容纳更多服务器。云计算的出现使企业能够从物理服务器转移并将其流程和 IT 堆栈(包括 Kafka、Hadoop 和 Spark)转移到云端,从而使他们能够使用和分析更多大数据以进行分析和洞察,甚至是实时的.

然而,许多企业很快意识到,在云中处理和分析大数据提出了非常复杂的技术要求,以至于他们的云 IT 基础架构设计难以应对。被吹捧为解决云 IT 性能问题的解决方案,有效地扩展它比听起来更难。在没有有效框架或正确技术堆栈的情况下进行扩展很快就会出错。

据埃森哲称,87% 的组织实施了混合云计划,而 93% 的组织采取了多云立场。混合云是公共云和私有云服务的组合,通常用于在两者之间协调一个 IT 系统。另一方面,多云涉及使用来自一个或多个云提供商(例如 AWS 或 Microsoft Azure)的多种云产品或服务。

虽然定义不同,但两种云实施都需要使用多个云服务提供商。这样企业就可以访问一个供应商无法提供的工具和资源。简而言之,他们获得了任一系统的最佳工具和服务。

然而,混合云和多云部署的最大缺点之一是增加了资源管理的复杂性。默认的云计算可扩展性配置因供应商而异。如果不进行优化,资源消耗会很快失控。

更复杂的是,云服务提供商之间不存在标准化的计费机制。这使得在跨云混合和匹配时评估资源成本变得越来越困难。

尽管云供应商声称自己是成本削减者,但根据我们的调查,超过 39% 的业务和 IT 领导者将“成本管理和控制”列为他们在云计算和大数据方面面临的最大问题。同一项调查显示,“复杂性”是第二个最紧迫的问题。

为什么是这样?

随着企业转向云端,支出模式也从资本支出 (CapEx) 转变为运营支出 (OpEx)。虽然运营支出模型在纸面上似乎更好,但它可能存在灾难性的成本管理问题。但怎么会呢?

改用 OpEx 可以消除数据中心、物理服务器和其他昂贵的网络设施和设备等资本支出。从理论上讲,OpEx 有望节省大量资金。

但是,OpEx 非常不稳定。这对扩展云计算意味着什么?云团队在云支出方面可以自由支配,尤其是在他们没有任何支出检查或治理模型的情况下。他们可以不受控制地扩展,导致云计算费用增加,远远超出他们最初分配的预算。

尽管解锁真正的云计算可扩展性非常复杂,但企业仍在将其关键业务流程和应用程序迁移到云端。

除了降低成本的承诺之外,灵活性是云最突出的优势之一。企业可以毫不费力地随意启动和关闭他们的服务。凭借无限的存储容量,用户可以快速扩展存储以满足他们的需求。

可扩展性可确保在流量增加和工作负载增加时计算资源可用。

由于云计算几乎消除了本地基础设施中存在的限制,因此工作负载/应用程序性能得到显着提高。

云计算的可扩展性现在已经超出了人类的能力。企业要想有效扩展云计算并实现最佳性能,就必须依赖自动扩展和可观察性。

借助我们的托管自动扩展功能,您的云基础设施可以根据您设置的配置和规则即时扩展您的计算、数据库和存储资源。

当网络使用、存储或流量等特定指标高于或低于正常阈值时,自动缩放机制就会激活。它根据您的规则而不是云供应商的默认配置进行扩展。在您控制扩展能力的情况下,您的应用程序、工作负载和任务有足够的资源可供使用,确保满足 SLA。

可观察性使您的云团队能够全面、详细、实时地了解您企业的云基础设施及其所有流程。

清楚地了解您的云可以简化云计算的可扩展性。它使您的 IT 团队和开发人员能够专注于修复错误,而不是花费宝贵的时间来搜索基础架构来查找它们。从一个集中位置,您的云用户可以快速查看和解决整个平台的性能问题。

可观察性使用户能够找到资源密集型应用程序和用户,并实施调整以降低成本。

真正的可观察性不仅可以帮助您了解问题发生的原因,还可以了解问题的原因。 (有关更多信息,请在此处查看我们的网络研讨会。)在扩展云计算的背景下,可观察性使您的云团队能够充分了解您的系统,以便他们可以动态扩展。

没有为云计算的复杂性做好准备的企业一旦采取行动,就会发现自己的支出超出了预算。我们的研究表明,超过三分之一的企业经历了高达 40% 的云预算超支。

面对价格冲击,企业要么 (1) 返回到他们以前的本地 IT 架构,要么 (2) 改善他们对监控和管理工具的访问,以更好地了解和控制他们的云 IT 基础设施。

云遣返或取消云化是指从云中提取工作负载和应用程序并将它们移回其物理基础架构环境的过程。

根据数字,这是一个大趋势。最近一项关于这种云逆转的研究发现,72% 的组织下令将其应用程序遣返,高成本和性能问题是主要因素。

同一份报告将云遣返归因于组织在迁移到云之前的“规划不足”。为了在技术先进的环境中保持竞争力,许多企业领导者一头扎进了云,而没有执行任何确保迁移成功所需的评估和规划。

提高跨多个/混合云的可见性和可管理性现在是寻求继续云投资的组织的必要条件。为此,您需要专门从事以下工作的工具:

可观察性。随着移动和部署云托管流程、工作负载和动态微服务架构的企业数量增加,对可观察性的需求变得更加明显。云用户必须能够看到他们的大数据是如何执行的并快速识别问题。更重要的是,他们需要了解问题发生的原因。

自动缩放。自动缩放可确保您的应用程序、工作负载和流程充分配备计算资源和其他资源。随着资源消耗的增加,平台会自动扩展以满足不断增长的需求,有效防止中断、滞后和停机。但是,当使用供应商的配置执行自动缩放时,它会成为一个问题,因为它可能导致资源分配不当和管理不善。要完全发挥自动缩放的潜力,必须使用最理想的缩放配置来执行。

退款。 Chargeback 通过将 IT 资源的成本分配给使用它们的部门或员工来帮助企业控制 IT 支出。这在不同部门和个人共享专用 IT 资源的情况下非常有效。

如果 IT 资源由多方共享和使用,但没有标准方法来衡量和收费资源消耗,用户可能会提供和消耗比必要更多的资源。如果用户可以自由分配计算并且没有防止超支的上限,这可能会出现问题。

实施退款让用户了解他们的云支出,从而鼓励他们控制。 IT 管理员可以使用来自扣款的数据来获取洞察力,然后他们可以使用这些洞察力来提高利用率并减少他们必须管理的资源数量。

热存储与冷存储。有效的云计算可扩展性在很大程度上依赖于数据来改进和优化关键业务操作和应用程序的性能。

通常,不断访问和处理的数据存储在热数据存储介质中。其中包括更耐用、更快、功能更强大但非常昂贵的 SSD。相反,很少使用的数据被放置在冷库中,就优先级而言位置很靠后。

但此设置需要持续监控。热数据可以瞬间变成冷数据。存储在冷驱动器中的数据需要更多时间才能到达、提取和处理。在您必须扩展并需要冷存储数据的情况下,该过程可能需要更长的时间,从而导致性能下降和延迟。

考虑到扩展的复杂性,实现针对性能和成本进行完全优化的云计算可扩展性可能很困难。为了动态扩展,企业需要一个能够管理云计算复杂方面的平台,并提供基于实时数据的最佳扩展配置。

作者 east
Flink 5月 10,2023

Flink Web UI用于开发看运行结果的教程

Flink Web UI是Flink提供的一个可视化界面,可以用于监控正在运行的任务并查看其状态、性能以及事件日志等信息。以下是如何在Flink Web UI中查看运行结果的步骤:

  1. 打开Flink Web UI
    在浏览器中输入Flink集群的Web UI地址,并登录。默认情况下,Flink Web UI运行在8081端口,地址为http://<flink-master>:8081。
  2. 选择运行的任务
    在Flink Web UI首页,您可以看到正在运行的任务列表。选择您要查看的任务名称,进入任务详情页面。
  3. 查看任务状态
    在任务详情页面的“任务管理”选项卡中,您可以看到当前任务的状态、开始时间、运行时间、并行度等信息。如果您的任务已经完成,您可以在“任务Events”选项卡中查看任务完成后的事件日志。
  4. 查看任务输出
    在任务详情页面的“任务Metrics”选项卡中,您可以找到“收集器”选项,并在其下找到“输出”指标。这将显示您的任务输出的数量和大小信息。
  5. 查看任务日志
    在Flink Web UI中,您可以查看任务的运行日志。在任务详情页面的“任务Logs”选项卡中,您可以找到Flink的日志输出,并查找任何错误或异常信息。

总之,在Flink Web UI中,您可以通过多种途径来监控和了解您的任务:查看任务状态、了解任务的性能表现、查看任务输出和事件日志以及跟踪任务的日志。这些信息将有助于您分析任务的运行情况并调试任何出现的问题。

作者 east
云计算 5月 8,2023

云成本高的 5 个原因

高得惊人的云账单带来的账单冲击仍然是已迁移到云的企业持续关注的问题。

云服务提供商通常将云作为降低运营成本的高效手段进行营销。通过将应用程序和流程迁移到云托管基础架构,组织可以节省本应用于数据中心、硬件和人员的资金。虽然降低成本的承诺是许多企业云迁移的主要驱动力,但事实是,众所周知,FinOps 预算可能非常复杂,研究发现,超过三分之一的企业在迁移后超过云预算的 40%。

导致企业增加云成本的因素有很多——这里有五个可以帮助 FinOps 成本控制,而不是迫使您削减成本。

即用即付云计算的主要优势之一是快速、简单和按需提供资源。用户只需单击几下即可轻松订购新的和额外的供应,使您的应用程序能够处理流量激增,并在启动新的 IT 项目和服务时实现企业敏捷性。

但由于在云中启动新的虚拟机很容易,许多 DevOps 团队往往会忘记他们购买的实例和资源。

不健康实例是突然受损并停止运行的实例。通常,不健康的实例会被自动删除并被新实例替换——但不健康的实例仍然会接收流量和请求,直到您平台的负载均衡器发现其不健康状态。如果您的云基础设施在不健康时没有分析它接收到的流量就终止了实例,那么宝贵的数据可能已经浪费了。

Rightsizing 是指使用足够的计算资源保留云计算实例(容器、VM 或裸机)的过程。这包括 RAM、CPU、存储和网络。合理调整旨在确保所有实例都拥有实现足够性能所需的所有资源,同时保持成本可控。

但是,如果实例大小不正确,用户可能会遭受以下两个主要后果:

自动缩放旨在让组织根据其流量需求、预测的资源利用率水平等来缩放虚拟机、实例和服务器容量等云服务。

虽然被宣传为降低云成本的一种手段,但不受监管的自动缩放可能会导致资源过度配置。如果没有合适的云监控工具,您的企业团队可能会看到极高的云计算成本。

然而,云中的工作负载本质上是极其动态的。实例可能只需要在高峰流量时间快速扩展,然后再缩减。

当 IT 团队缺乏对其云基础架构和流程的可见性时,就很难实现最佳性能和成本控制。

借助可跟踪使用情况、成本和应用程序趋势的全堆栈可观察性工具,您可以放心地知道您的大数据基础设施得到了真正的优化。

如果您的 DevOps 团队需要不断调整其大数据平台,就无法专注于创新和扩展其企业。为了有效管理您的数据堆栈并避免云账单冲击,自动化、自动缩放和可见性等功能必不可少。

作者 east
云计算 5月 8,2023

通过容量优化器在 Kubernetes 中实现卓越的云成本优化

Kubernetes 正迅速成为世界上最受欢迎的开源容器编排工具。用于构建和管理基于云原生微服务的应用程序以及现有应用程序的容器化,其采用率不断增加。已经有 61% 的企业采用了 Kubernetes,30% 的企业计划在未来 12 个月内采用它。

Kubernetes 或任何云环境中的自动缩放对于企业来说至关重要,因为它使用户能够自动添加和删除实例以满足工作负载的需求。这是一种有效的云成本优化方法,特别是对于依赖 Kubernetes 进行流程的企业而言。

然而,Kubernetes 中的自动缩放可能会导致与企业意图相反的结果。旨在最大限度减少浪费的云成本优化解决方案反而会增加您的成本并导致您的云环境过度配置资源。

这是怎么发生的?大多数应用程序开发人员请求将大量资源分配给他们的应用程序,以减轻最坏情况的影响。如果这次输入数据大 10 倍怎么办?如果这次新代码需要两倍的内存和两倍的 CPU 怎么办?开发人员通常没有信息来确切知道他们需要分配多少资源来处理典型的最坏情况。有时,他们甚至不知道要分配多少来处理典型场景。

开发人员希望他们的应用程序能够在合理的时间内成功完成,即使是在那些最坏的情况下。这种愿望构成了他们的云成本优化方法的基础。这就是为什么他们要求大量分配。事实上,这种最坏的情况很少发生。平均而言,应用程序仅使用分配资源的一小部分。事实上,一些研究表明 32% 的云预算被浪费了,部分原因是过度分配。

云自动缩放器的低效

不幸的是,自动缩放是根据资源分配与资源利用率来实现的。为了优化云成本,当调度程序无法向集群添加更多应用程序时,云自动缩放器会添加更多实例,因为所有现有资源都已分配。

想象一个有两个节点的集群。假设一个应用程序请求两个节点。应用程序可能最终只使用八个内核,但自动缩放器并不知道这一点。

随着越来越多的应用程序被提交请求更多的核心,自动缩放器将添加更多的实例,即使现有实例的利用率仅为 50%。如果新应用程序也只使用分配的一小部分,则新实例也将未得到充分利用。

结果是更多的浪费实例,并最终导致云计算费用膨胀。

Pepperdata Capacity Optimizer:卓越的云成本优化

Pepperdata Capacity Optimizer 将云成本优化提升到一个更高的水平。它通过使调度程序或集群管理器能够在 YARN 和 Kubernetes 中基于资源利用率而不是资源分配来调度工作负载,从而解决了云自动缩放器效率低下的问题。

一旦达到配置的资源利用率,自动缩放器就会添加更多实例。通过 Pepperdata Capacity Optimizer 进行的云成本优化不仅可以最大化每个现有实例的利用率,还可以确保仅当现有实例在自动缩放环境中得到充分利用时才添加新实例。 Pepperdata 管理云平台的自动缩放行为,因此您不必这样做。

为了优化 Kubernetes 和 YARN 中的云成本,Capacity Optimizer 执行以下操作:

同样,即使许多实例接近空闲或空闲,云平台也不会缩减实例。在这种情况下,如果一定数量实例的利用率低于特定阈值,Capacity Optimizer 会指示自动缩放器缩减。

通过 Pepperdata Capacity Optimizer 优化云成本,可以减少用于完成相同工作的实例,从而为您节省直接成本。

事实上,当在运行标准大数据分析基准的 Kubernetes 集群上启用 Capacity Optimizer 时,Pepperdata 发现查询持续时间减少了 30%,工作负载容量增加了 35%。

作者 east
Flink 5月 8,2023

Flink CDC的日志解析

在开发Flink CDC时,可以看到类似下面的日志:

com.ververica.cdc.connectors.mysql.source.reader.MySqlSourceReader [] – Binlog offset on checkpoint 83: {transaction_id=null, ts_sec=0, file=mysql_binary_log.000031, pos=488646219, kind=SPECIFIC, gtids=0ada2b25-c265-11e9-8a8d-fa163e713fa8:1-2781408, row=0, event=0, server_id=1}

根据日志可以做下面的解析:

  • 你的Flink任务是使用Flink CDC Connector来从MySQL读取数据,并且使用MySqlSourceReader来读取MySQL的binlog。
  • 你的Flink任务在checkpoint 83时,记录了当前的binlog偏移量,用于在故障恢复时重新定位数据源。
  • 你的binlog偏移量包含了以下几个字段:
    • transaction_id: 当前事务的ID,如果没有事务,则为null。
    • ts_sec: 当前事件的时间戳,单位为秒。
    • file: 当前binlog文件的名称。
    • pos: 当前binlog文件的位置,单位为字节。
    • kind: 当前事件的类型,可以是SPECIFIC(特定事件),ROW(行事件),DDL(数据定义语言事件)或DML(数据操作语言事件)。
    • gtids: 当前全局事务标识符集合,用于跨多个MySQL服务器标识事务。
    • row: 当前行事件的行号,从0开始。
    • event: 当前行事件的事件号,从0开始。
    • server_id: 当前MySQL服务器的ID。
作者 east
Flink 5月 8,2023

运行flink出错:Could not acquire the minimum required resources.

运行flink任务报下面错误:

Caused by: java.util.concurrent.CompletionException: org.apache.flink.runtime.jobmanager.scheduler.NoResourceAvailableException: Could not acquire the minimum required resources. at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:292) at java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:308) at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:593) at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) … 37 more Caused by: org.apache.flink.runtime.jobmanager.scheduler.NoResourceAvailableException: Could not acquire the minimum required resources.

这个错误表示你的Flink集群没有足够的任务槽来满足你的作业需求。你需要增加每个TaskManager的槽数或者增加TaskManager的实例数12。Flink本身不能触发动态扩缩容,你只能手动启动更多的TaskManager或者修改TaskManager的配置并重启1。如果你的TaskManager在作业运行时挂掉了,你可以定义一个重启策略(注意你需要开启检查点)3。

作者 east
大数据开发 5月 8,2023

xxjob可以调度spark、flink等大数据任务吗,推荐几款最好用的大数据调度器

是的,XXL-Job可以调度Spark、Flink等大数据任务。除了XXL-Job,还有许多其他好用的大数据调度器,下面为您推荐几款:

  1. Apache Airflow:基于Python的开源数据流编排和调度平台,可轻松管理跨越各种数据源、处理引擎和机器学习框架的复杂工作流。
  2. Apache NiFi:开源数据集成和分发平台,支持从不同来源(例如文件、JDBC、MQTT、HTTP等)提取、转换和传输数据。
  3. Apache Oozie:基于Hadoop的开源工作流和调度器,可以轻松管理各种复杂工作流,并可以扩展到不同的处理引擎和服务。
  4. Azkaban:分布式批处理工作流平台,提供易于使用的界面和高度可配置的任务调度。
  5. DolphinScheduler:分布式的易用可靠的任务调度平台,支持多类型任务(包括Hadoop、Spark、Flink等),提供可扩展、高效和高可用性的特性。

以上仅是一些常见的大数据调度工具,用户可根据自身实际情况选择合适的工具。

作者 east

上一 1 … 39 40 41 … 93 下一个

关注公众号“大模型全栈程序员”回复“小程序”获取1000个小程序打包源码。回复”chatgpt”获取免注册可用chatgpt。回复“大数据”获取多本大数据电子书

标签

AIGC AI创作 bert chatgpt github GPT-3 gpt3 GTP-3 hive mysql O2O tensorflow UI控件 不含后台 交流 共享经济 出行 图像 地图定位 外卖 多媒体 娱乐 小程序 布局 带后台完整项目 开源项目 搜索 支付 效率 教育 日历 机器学习 深度学习 物流 用户系统 电商 画图 画布(canvas) 社交 签到 联网 读书 资讯 阅读 预订

官方QQ群

小程序开发群:74052405

大数据开发群: 952493060

近期文章

  • spark内存溢出怎样区分是软件还是代码原因
  • MQTT完全解析和实践
  • 解决运行Selenium报错:self.driver = webdriver.Chrome(service=service) TypeError: __init__() got an unexpected keyword argument ‘service’
  • python 3.6使用mysql-connector-python报错:SyntaxError: future feature annotations is not defined
  • 详解Python当中的pip常用命令
  • AUTOSAR如何在多个供应商交付的配置中避免ARXML不兼容?
  • C++thread pool(线程池)设计应关注哪些扩展性问题?
  • 各类MCAL(Microcontroller Abstraction Layer)如何与AUTOSAR工具链解耦?
  • 如何设计AUTOSAR中的“域控制器”以支持未来扩展?
  • C++ 中避免悬挂引用的企业策略有哪些?

文章归档

  • 2025年7月
  • 2025年6月
  • 2025年5月
  • 2025年4月
  • 2025年3月
  • 2025年2月
  • 2025年1月
  • 2024年12月
  • 2024年11月
  • 2024年10月
  • 2024年9月
  • 2024年8月
  • 2024年7月
  • 2024年6月
  • 2024年5月
  • 2024年4月
  • 2024年3月
  • 2023年11月
  • 2023年10月
  • 2023年9月
  • 2023年8月
  • 2023年7月
  • 2023年6月
  • 2023年5月
  • 2023年4月
  • 2023年3月
  • 2023年1月
  • 2022年11月
  • 2022年10月
  • 2022年9月
  • 2022年8月
  • 2022年7月
  • 2022年6月
  • 2022年5月
  • 2022年4月
  • 2022年3月
  • 2022年2月
  • 2022年1月
  • 2021年12月
  • 2021年11月
  • 2021年9月
  • 2021年8月
  • 2021年7月
  • 2021年6月
  • 2021年5月
  • 2021年4月
  • 2021年3月
  • 2021年2月
  • 2021年1月
  • 2020年12月
  • 2020年11月
  • 2020年10月
  • 2020年9月
  • 2020年8月
  • 2020年7月
  • 2020年6月
  • 2020年5月
  • 2020年4月
  • 2020年3月
  • 2020年2月
  • 2020年1月
  • 2019年7月
  • 2019年6月
  • 2019年5月
  • 2019年4月
  • 2019年3月
  • 2019年2月
  • 2019年1月
  • 2018年12月
  • 2018年7月
  • 2018年6月

分类目录

  • Android (73)
  • bug清单 (79)
  • C++ (34)
  • Fuchsia (15)
  • php (4)
  • python (45)
  • sklearn (1)
  • 云计算 (20)
  • 人工智能 (61)
    • chatgpt (21)
      • 提示词 (6)
    • Keras (1)
    • Tensorflow (3)
    • 大模型 (1)
    • 智能体 (4)
    • 深度学习 (14)
  • 储能 (44)
  • 前端 (4)
  • 大数据开发 (491)
    • CDH (6)
    • datax (4)
    • doris (31)
    • Elasticsearch (15)
    • Flink (78)
    • flume (7)
    • Hadoop (19)
    • Hbase (23)
    • Hive (41)
    • Impala (2)
    • Java (71)
    • Kafka (10)
    • neo4j (5)
    • shardingsphere (6)
    • solr (5)
    • Spark (100)
    • spring (11)
    • 数据仓库 (9)
    • 数据挖掘 (7)
    • 海豚调度器 (10)
    • 运维 (34)
      • Docker (3)
  • 小游戏代码 (1)
  • 小程序代码 (139)
    • O2O (16)
    • UI控件 (5)
    • 互联网类 (23)
    • 企业类 (6)
    • 地图定位 (9)
    • 多媒体 (6)
    • 工具类 (25)
    • 电商类 (22)
    • 社交 (7)
    • 行业软件 (7)
    • 资讯读书 (11)
  • 嵌入式 (71)
    • autosar (63)
    • RTOS (1)
    • 总线 (1)
  • 开发博客 (16)
    • Harmony (9)
  • 技术架构 (6)
  • 数据库 (32)
    • mongodb (1)
    • mysql (13)
    • pgsql (2)
    • redis (1)
    • tdengine (4)
  • 未分类 (7)
  • 程序员网赚 (20)
    • 广告联盟 (3)
    • 私域流量 (5)
    • 自媒体 (5)
  • 量化投资 (4)
  • 面试 (14)

功能

  • 登录
  • 文章RSS
  • 评论RSS
  • WordPress.org

All Rights Reserved by Gitweixin.本站收集网友上传代码, 如有侵犯版权,请发邮件联系yiyuyos@gmail.com删除.