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

Spark Tuning 帮助您优化资源(上)

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

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

Spark Tuning 帮助您优化资源(上)

正如我们 2022 年的调查显示,Apache Spark 有望继续成为大数据最主要的大规模大数据处理平台。因此,如果 Spark 用户想充分利用他们的 Spark 环境,他们就必须学习和掌握 Spark 调优。

但是在 Spark 中调优是什么?它是如何完成的?继续阅读以了解有关 Spark 调优的更多信息。

Spark 性能调优是调整 Spark 环境配置的过程,以确保所有进程和资源都得到优化并顺利运行。为确保最佳性能并避免代价高昂的资源瓶颈,Spark 调优涉及对内存分配、核心利用率和实例配置的仔细校准。此过程可最大限度地提高系统的效率和有效性,以确保每次都能获得最佳结果。

我们已经看到许多大数据工作负载在 Spark 上运行,可以肯定的是,在可预见的未来,更多的应用程序和进程将迁移到 Spark 框架。

大多数企业都在运行 Spark,主要是在 Kubernetes 框架上。使用 Kubernetes 运行 Spark 为 Spark 应用程序提供了一个优势——支持按需自动部署,而不是利用持续运行设置的资源密集型模型。这也使您的应用程序能够轻松跨服务提供商并简化管理流程。使用 Spark-Kubernetes 配置可以提高 Spark 资源的利用率,同时降低云成本。

即使将 Spark 与 Kubernetes 一起运行具有广为人知的优势,包括更好的性能和更低的成本,但如果一切都未优化,尤其是 Spark,它可能会很快失败。我们想花一些时间更深入地探讨一个主题:通过 Spark 调优进行 Spark 优化的 Spark 优化。

Spark 开发人员在处理大量数据时需要担心很多事情:如何有效地获取数据源、执行 ETL(提取、转换、加载)操作以及大规模验证数据集。但是,当他们确保程序没有错误并在所有必要的环境中得到维护时,他们往往会忽略一些任务,例如调整 Spark 应用程序参数以获得最佳性能。

如果操作得当,调整 Spark 应用程序可以降低资源成本,同时维护关键流程的 SLA,这是本地和云环境都关心的问题。对于本地 Hadoop 环境,集群通常由多个应用程序(及其开发人员)共享。如果一个人的应用程序是资源大户,它会减慢每个人的应用程序,并冒着更高的任务失败率的风险。

随着 Spark 使用的增加,管理应用程序性能可能成为一项重大挑战。如果没有正确的方向,任何对 Spark 监控的尝试都可能很快被证明是徒劳的,而且在时间和资源上都会花费高昂的代价。这就是为什么那些缺乏关于转向哪些 Spark 指标进行优化指导的人一直在寻求专家帮助以了解这个复杂过程的原因。

大多数受访者非常关心其计算资源的资源优化,因为超过 33%(三分之一)的公司的支出超出其初始云预算的 20% 至 40%。简而言之,组织未能优化其 Spark 资源,导致超支。

在这篇博文中,我们将讨论两种 Apache Spark 优化技术:

在进入细节之前,让我们回顾一些 Spark 术语和定义:

Spark 应用程序分为多个阶段。阶段是物理执行计划中的一个步骤。它在需要随机播放(ShuffleMapStage)或阶段写入其结果并按预期终止(ResultStage)时结束。

每个阶段都分为并行执行的任务——每个分区一个任务。任务由执行者执行。

执行者是执行任务的工作者。资源(内存和 CPU 内核)在运行前由开发人员分配给执行程序。

分区是数据的逻辑块——具体来说,是弹性分布式数据集 (RDD) 的块——可以由开发人员在运行前配置。 RDD 中的分区数决定了一个阶段将执行的任务数。对于每个分区,一个任务(应用程序代码块)被提供给执行者执行。

图 1:Spark 中的数据分区

因为 Spark 应用程序可以包含许多不同类型的阶段,所以对一个阶段最佳的配置可能不适合另一个阶段。因此,Spark应用程序的Spark内存优化技术必须分阶段进行。

除了配置阶段之外,开发人员还可以控制应用程序中的任务数量(并行性)以及应用程序的执行程序大小。

使用 Spark 最大化并行性需要仔细考虑集群的核心数和分区数之间的差异。太少会导致性能低下,而太多会带来不当的间接成本。为确保并行性和效率之间的平衡,Spark 建议分区数大约是集群中核心数的三倍。

不直接的是如何选择分区的数量和执行器的大小。接下来我们将介绍它。

执行器和分区大小是开发人员通过 Spark 调优控制的两个最重要的因素。要了解它们之间的关系,我们首先需要了解 Spark 执行器如何使用内存。图 2 显示了 Spark 执行程序内存的不同区域。

图 2:Spark 执行器内存

我们可以看到有一个参数控制为执行和存储保留的执行程序内存部分:spark.memory.fraction。因此,如果我们想将 RDD 存储在内存中,我们需要我们的执行器足够大以处理存储和执行。否则,我们将面临出错的风险(在数据/计算中以及由于资源不足导致的任务失败)或应用程序运行时间过长。

另一方面,执行器的大小越大,我们可以在集群中同时运行的执行器就越少。也就是说,由于缺乏任务并行性,较大的执行程序大小经常会导致执行速度不佳。

还有为每个执行器选择 CPU 内核数量的问题,但选择是有限的。通常,1-4 个核心/执行程序的值将在实现完全写入吞吐量和不过度负担 HDFS 客户端管理并发线程的能力之间提供良好的平衡。

在处理分区和执行器时,最好的 Spark 内存优化技术之一是首先选择分区的数量,然后选择一个执行器大小来满足内存需求。

分区控制将在特定阶段的数据集上执行多少任务。在几乎没有摩擦(网络延迟、主机问题以及与任务调度和分配相关的开销)的最佳条件下,将分区数分配为集群中的可用核心数将是理想的。在这种情况下,所有任务将同时开始,同时全部完成,一步到位。

然而,真实环境并不是最佳的。在调优Spark时,我们必须考虑:

使用 Apache Spark 优化技术时,请记住这条经验法则:对于大型数据集——大于集群中单个主机上的可用内存——始终将分区数设置为集群中可用核心数的 2 或 3 倍.

但是,如果集群中的核心数量很少,而您有一个庞大的数据集,那么选择分区大小等于 Hadoop 块大小(默认情况下为 128 MB)的分区数量在以下方面具有一些优势输入/输出速度。

选择执行器大小

正如我们所讨论的,Spark 调优还涉及为您的执行程序提供足够的内存来处理存储和执行。因此,当您选择执行程序大小时,您应该考虑分区大小、整个数据集大小以及是否将数据缓存在内存中。

为了确保任务快速执行,我们需要避免磁盘溢出。当我们没有给执行者足够的内存时,就会发生磁盘溢出。这迫使 Spark 在运行时将一些任务“溢出”到磁盘。

在我们的实验中,我们发现执行程序大小的一个好的选择是不会导致磁盘溢出的最小大小。我们不想选择太大的值,因为我们会使用太少的执行器。找到避免磁盘溢出的正确大小需要进行一些试验。

图 3 显示了我们针对机器学习应用程序进行的一项实验的结果:

图 3:磁盘溢出和任务持续时间

我们多次运行同一个应用程序,只改变了执行程序的内存大小。我们将分区大小保持在 256 MB,执行程序核心数保持在 4。我们看到,在没有磁盘溢出的情况下,任务运行速度明显加快。将内存大小从 4 GB 增加一倍到 8 GB 消除了磁盘溢出,任务运行速度提高了两倍以上。但我们也可以看到,从 8 GB 到 10 GB 并没有影响任务持续时间。它并不总是如此明确,但根据我们的经验,选择不会导致磁盘溢出的最小内存大小通常是一个很好的 Spark 调优实践。

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

包含系统边界和数据流向的技术方案模板

  • 什么是系统边界和数据流向

系统边界指的是一个系统所涉及的所有参与者和资源,包括硬件、软件、人员、数据等。在编写技术方案时,需要明确系统边界,以便确定系统的组成部分和相互之间的关系。

数据流向则是指数据在整个系统中的流动路径和方向。在编写技术方案时,需要明确数据流向,以便确定数据的来源、目的地和处理方式。

具体来说,在编写技术方案时,可以包括以下内容:

1、系统边界:明确系统的组成部分和参与者,包括硬件设备、软件平台、人员组成、数据源和数据接收方等。

2、数据流向:明确数据在整个系统中的流动路径和方向,包括数据的输入、处理、输出和存储等环节。

3、数据处理流程:描述数据在整个系统中的处理流程,包括数据的采集、清洗、转换、分析和展示等环节。

4、数据安全保障:描述如何保障数据的安全性和隐私性,包括数据加密、权限控制、审计跟踪等措施。

5、可扩展性和可维护性:描述如何保证系统的可扩展性和可维护性,包括分布式架构、自动化运维、代码管理等手段。

总之,系统边界和数据流向是技术方案中非常重要的内容,需要仔细考虑和规划,以确保系统的稳定性、可靠性和高效性。

  • 包含系统边界和数据流向的方案模板

(一)、系统边界

系统组成部分

本系统由前端应用、后端服务和数据库三部分组成。前端应用负责用户界面的展示和交互,后端服务提供业务逻辑处理和数据存储,数据库用于存储和管理数据。

参与者和资源

本系统的参与者包括管理员、开发人员、测试人员和最终用户。系统资源包括硬件设备(如服务器、网络设备)、软件平台(如操作系统、Web服务器、应用服务器)和人员组成(如开发团队、运维团队)。

数据源和数据接收方

本系统的数据源包括用户输入、外部数据接口和其他系统的数据共享。数据接收方包括后端服务、数据库和前端应用。

(二)、数据流向

数据采集

前端应用通过API接口获取用户输入的数据,并将数据发送到后端服务进行处理。后端服务从数据库中读取相关数据,并将处理结果返回给前端应用。

数据处理

后端服务对前端应用发送过来的数据进行处理,包括数据清洗、转换和计算等操作。处理结果保存在数据库中,以备后续使用。

数据输出

前端应用根据业务需求从数据库中读取相关数据,并将数据显示给用户。同时,前端应用可以将处理结果返回给后端服务,以便后端服务进行进一步的处理或更新数据库中的数据。

数据存储

后端服务将处理结果保存在数据库中,以备后续使用。数据库可以是关系型数据库(如MySQL、Oracle)或非关系型数据库(如MongoDB、Redis)。同时,为了保证数据的安全性和可靠性,需要采取相应的安全措施(如加密、权限控制等)。

(三)、技术方案

前端应用

前端应用采用React框架进行开发,使用Ant Design组件库进行UI设计。前端应用通过API接口与后端服务进行数据交互,并将处理结果展示给用户。同时,前端应用还采用了一些安全措施(如CSRF Token验证、XSS过滤等)来保障用户数据的安全性。

后端服务

后端服务采用Java语言和Spring Boot框架进行开发,使用MyBatis框架进行数据库操作。后端服务实现了用户注册、登录、数据查询、数据更新和数据删除等业务逻辑,并提供了RESTful API接口供前端应用调用。同时,后端服务还采用了一些安全措施(如加密、权限控制等)来保障数据的安全性和可靠性。

数据库

数据库采用MySQL关系型数据库进行存储和管理数据。数据库中包含用户表、数据表和其他关联表等,用于存储和管理系统中的各种数据。同时,为了保证数据的安全性和可靠性,还采取了相应的安全措施(如加密、权限控制等)。

安全措施

本系统采用了多种安全措施来保障数据的安全性和可靠性,包括:

(1)加密:对传输的数据进行加密处理,防止数据被窃取或篡改。

(2)权限控制:根据用户的角色和权限限制对数据的访问和操作。

(3)CSRF Token验证:在API接口中加入CSRF Token验证,防止恶意攻击。

(4)XSS过滤:在前端应用中加入XSS过滤,防止跨站脚本攻击。

(5)SQL注入防范:在数据库操作中加入SQL注入防范,防止恶意攻击。

四、总结

本系统采用了前后端分离的开发模式,通过API接口实现前端应用和后端服务之间的数据交互。同时,本系统采用了多种安全措施来保障数据的安全性和可靠性。

作者 east
云计算 5月 11,2023

大数据云性能管理:如何做对

大数据云性能管理是在云中取得成功的关键。与云计算相结合,大数据可以改变企业——尤其是在管理得当的情况下。它不需要资本支出,支持更快的数据处理和分析,并允许快速扩展。但是,没有计划在云中正确管理大数据性能可能是实现云承诺的 ROI 和不得不失败地返回数据中心之间的区别。继续阅读以了解更多关于为什么大数据性能管理如此重要、如何正确进行以及如何使用一种工具使这一切变得更容易的信息。

分解一下:大数据指的是大量数据,这些数据来得很快,很难用传统方法进行管理。云中的大数据本质上是在任何云上运行大数据——而不仅仅是在数据中心。您无需使用自己的硬件,而是拥有“云中”空间来运行您的大数据。

在云中运行大数据流程最突出的好处之一是按需服务。一个组织的计算需求在高峰时段、平静时刻和服务的随机峰值期间可能会有很大差异。虽然维持足够数量的计算资源以满足要求已成为常态,但事实证明这种做法的成本非常高。相反,如果一个组织试图通过只维持最少的资源来降低成本,很可能没有足够的资源来满足高峰需求。

借助大数据云模型,企业可以享受这种按需功能,他们可以根据普遍要求通过单击按钮、通过 API 或通过基于规则的框架配置自动扩展或缩减计算资源。用户可以根据需要配置或取消配置计算资源,而无需与云提供商交互。

将应用程序和流程迁移到云环境的主要优势之一是显着降低基础架构成本。运营大型本地数据中心每年会使组织损失 1000 万至 2500 万美元。很大一部分用于基础设施维护,包括维护、监控、安全和审计。
如果使用得当,利用云方法可以节省大量资金。这是因为基于云的流程和应用程序具有适应性、可扩展性和成本效益。随着大数据应用程序和任务被转移到云端,企业可以以非常快的速度创建、测试和部署产品和服务。在少数情况下,迁移到云的企业设法将节省的资金增加了十倍。

云计算有效地促进了当今企业从 CapEx(资本支出)支出模式向 Opex(运营支出)模式的转变。传统上,IT 基础设施的资本支出很大,主要来自购买和维护资本资产,例如建筑物、硬件和软件许可等。另一方面,Opex 是帮助公司生产和向客户提供产品和服务的经常性支出。这些包括公用事业、工资和计算资源。

迁移到云基础架构可帮助企业消除许多资本支出成本。通过切换到运营支出模型,组织可以创造大量内部机会,因为它释放了宝贵的资金和资源,否则这些资金和资源将用于获取、管理和维护资本资产。

到 2026 年,全球云计算市场有望从 2021 年的 4455 亿美元增长到令人印象深刻的 9473 亿美元。云服务供应商之间的激烈竞争凸显了这一增长。亚马逊、微软和谷歌等家喻户晓的名字在这个领域占据主导地位。

Amazon Web Services (AWS) 提供了大量的大数据云服务,包括 Amazon Elastic MapReduce(处理大量大数据)、Amazon DynamoDB(NoSQL 数据存储服务)和 Amazon S3(网络规模数据存储服务)。
Microsoft Azure 提供了一套大数据服务解决方案和工具。他们最受欢迎的产品包括 Azure Purview(统一数据治理)和 Azure Data Lake Storage(大型、可扩展且安全的数据湖)。

谷歌有大量的大数据云服务可以提供给他们的客户。他们的顶级解决方案包括 Google Big Query(用于大型数据集的快速 SQL 查询引擎)和 Google Prediction API(基于 ML 的大数据分析和学习)。

虽然我们了解将大数据迁移到云端的吸引力,但管理其性能的意义何在?好吧,在云中操作时有很多移动部分,并且有很多利益相关者参与这个过程:

这些只是利益相关者以及他们给方程式带来的复杂性。一旦添加了工具、APM 解决方案、遗留数据中心工具和自主开发的解决方案,它就会变得混乱。在云端,还有更多需要注意的地方。

那么,您如何理解一切并最终确保您的大数据以最佳方式运行呢?不是简单地收集更多数据。一个在提供可观察性和自动化的同时为您分析性能数据的工具就是解决方案。

没有良好的分析,数据是无用的。面对现实:您需要答案和解决方案,而不仅仅是更多数据。这就是提供可观察性和自动化的工具的用武之地。

可观察性让您了解事情发生的原因——而不是仅仅向您提供发生了什么。如果无法观察到您的集群,您就是在盲目飞行。解决应用程序问题需要更长的时间,由于缺乏洞察力而更有可能错过 SLA,并且几乎不可能调整工作负载的大小。因此,当您在寻找云性能管理解决方案时,请寻找能够提供可观察性的解决方案,而不仅仅是监控。在寻找可观察性解决方案时要问的关键问题是:

如果以上任何问题的答案是否定的,您将需要继续搜索。

从自动缩放到自主调优,自动化是优化大数据性能的最后一块拼图。手动调整今天不能削减它。即使是最有能力的团队也无法以所需的精度和速度手动调整每个应用程序和工作流,以跟上云中的规模。事实上,由于硬件资源、时间和精力的浪费,手动调整可能会降低您的投资回报率。

从云中的自动化中获益的另一个机会是自动缩放。虽然云因其可扩展性和灵活性而非常出色,但这可能是一把双刃剑,会导致毫无准备的人成本失控。为了解决这个问题,许多云提供商提供了减少浪费的自动缩放功能。然而,他们并不总能抓住一切。

常规自动缩放通常以较大的增量发生,但工作负载是动态的。他们可能需要更小的计算增量,或者需要比云提供商的自动缩放更快地扩展和缩减。这会导致可避免的浪费和额外成本。

下图清楚地显示了这一点。第一张图表显示了传统的自动缩放如何在整个运行时期间将集群增加到 100 个节点。但是,第二个图表显示了集群在运行时期间实际运行的内容。有时它只是一个任务,有时没有任务在运行。没有必要在整个持续时间内提供 100 个节点的自动缩放。

通过将可观察性与自动化相结合,您可以更好地跟上规模、缩短 MTTR 并提高投资回报率。自动警报会在问题发生时通知您,并且它们会提供可操作的见解,以便您可以快速解决问题。适当的自动缩放可以让您减少云中的浪费和失控的成本。自动计费机制使您能够更好地跟踪成本,自动调整确保部署的资源得到有效利用。这些都使您能够在不超出云预算的情况下跟上云中预期的规模。

当您在云端运行大数据并希望优化其性能时,可观察性和自动化是关键。如果不了解您的大数据性能,您基本上是盲目的。

Pepperdata 解决方案以自主调整、托管自动缩放​​等形式提供全栈可观察性和自动化,因此您可以确信您的大数据堆栈正在以最佳状态运行。

具有托管自动缩放​​功能的 Pepperdata Capacity Optimizer 提供云中所需的动态缩放大数据工作负载。与云服务提供商的自动缩放功能配合使用时,您可以进一步降低成本并获得高投资回报率。事实上,我们最近将 Capacity Optimizer 与 AWS Custom Auto Scaling 进行了基准测试,以了解我们提供了多少改进。我们发现,与 AWS Custom Auto Scaling Policy 搭配使用时,Capacity Optimizer 将云 CPU 利用率提高了 157%。

查看我们的白皮书可观察性和大规模持续调整,以了解有关可观察性和自动化如何影响大数据云性能管理的更多信息。

作者 east
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

上一 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

近期文章

  • 如何在Chrome中设置启动时自动打开多个默认网页
  • 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中的“域控制器”以支持未来扩展?

文章归档

  • 2025年8月
  • 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)
  • 前端 (5)
  • 大数据开发 (493)
    • CDH (6)
    • datax (4)
    • doris (31)
    • Elasticsearch (15)
    • Flink (79)
    • 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)
    • 运维 (35)
      • 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删除.