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

月度归档5月 2023

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

  • 首页   /  2023   /  
  • 5月
  • ( 页面4 )
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
Hive 5月 7,2023

Hive 查询优化的 Hive 性能调优方法

您确定您的 Hive 查询正在以最佳状态执行吗?你可能会感到惊讶。 Apache Hive 是当今许多大型企业环境中使用最普遍的查询引擎,但这并不意味着它可以自动优化工作。为了充分利用引擎并实现 Hive 查询优化,调整其性能非常重要。但在深入探讨之前,让我们介绍一下 Hive 性能调优的基础知识。

什么是 Hive 性能调优? Hive 性能调优是指旨在改进和加速 Hive 环境性能的集体流程和步骤。当查询未优化时,简单语句的执行时间会更长,从而导致性能滞后和停机。

如何优化 Hive 查询?性能调优是优化 Hive 查询的关键。首先,通过分区、分桶、压缩等调整数据。改进 Hive 查询的执行是另一种 Hive 查询优化技术。您可以通过使用 Tez、避免偏斜和增加并行执行来做到这一点。最后,抽样和单元测试可以帮助您首先查看(并解决)较小规模的问题,从而帮助优化查询。

虽然我们现在了解它的重要性,但调整 Hive 环境以获得最佳性能可能会很棘手。知道如何分析 Hive 查询性能是成功的必要条件。但是 Hive 性能调优最佳实践是什么?开发人员和运维团队可以做些什么来确保最佳的 Hive 查询性能?

如果您有这些问题,这篇文章适合您。继续阅读以了解三个关键类别的有效性能调整最佳实践。无论您是调整时间还是有效利用资源,这些技巧都适用。

想要更多关于提高 Hive 查询性能的技巧?获取我们的电子书:通过真正了解查询的执行方式来提高性能。

如何提高我的 Hive 性能?大多数用户和开发人员都是从调整他们的数据开始的。使用分区、分桶、压缩、避免小文件等都是很棒的 Hive 查询优化技术。

在 Pepperdata,我们处理有关 Hive 查询的各种问题,其中主要是提高 Hive 性能。在本节中,我们将深入探讨如何尽可能少地操纵数据以获得成功。

分区

分区是一种常见的 Hive 查询调优策略,它根据键将表数据放置在表位置的单独子目录中。分区键提供了一个机会来定位表数据的一个子集,而不是扫描您的操作不需要的数据。

无论存在多少数据,当你有分区时,Hive 只读取特定数量的数据来生成结果。这极大地提高了性能,即使您执行复杂的分析查询也是如此。这是因为 Hive 只需从子句中指定的几个分区读取数据。它已经在启动查询执行之前过滤掉所需的数据。

分桶

Bucketing 类似于分区,是一种 Hive 查询调优策略,允许您以数据子集为目标。在这种情况下,专门通过扫描更少的数据来提高连接性能。由于需要输入、输出或存储在内存中的数据更少,因此这改进了跨时间和效率向量的查询。

Hive 中的分桶需要将表数据集分解为更小的部分。因此,数据更容易处理。使用分桶,您可以连接相似的数据类型并将它们写入单个文件。此处的此步骤大大提高了连接表或读取数据时的性能。这就是带分区的分桶在 Hive 用户中如此受欢迎的原因。

压缩

压缩被列为最好的 Hive 查询优化技术之一。大数据压缩减少了处理大型数据集所需的带宽和存储量。此外,压缩从您的系统中消除了冗余和不重要的部分。

查询操作的每一位数据都有与从磁盘获取数据、进入内存、内存不足以及返回磁盘或另一个最终目标相关的 I/O。压缩最大限度地减少了遍历每个步骤的数据量,并减少了在查询状态中移动所花费的时间。

避免小文件

从查询中消除小文件操作是一种有效的 Hive 性能调优策略。这样做可以促进健康的 Hive 生态系统。每个文件都由 Hive Metastore 跟踪并存储在 HDFS 中,每个文件都经过性能优化以处理较大的文件而不是许多较小的文件。查询性能受限于整个系统和平台的健康状况。

反规范化数据

如果您想消除在运行时从多个表连接数据的需要,Hive 专家建议将数据反规范化作为一种​​首选的 Hive 性能调整方法。通过向一个或多个表添加冗余数据来执行反规范化。这可以帮助我们避免在关系数据库中进行代价高昂的连接。

虽然规范化很有用,但除了从操作中完全消除不需要的数据之外,避免连接是您可以对给定查询做出的最有影响力的更改之一。

表设计

Hive 表不同于大多数数据专业人员所习惯的传统数据库表。它们本质上是子目录。增加分区数量以促进高效读取和并行性是针对这种情况的最有效的 Hive 优化技术之一。然而,这个解决方案并不过分。分区过多会降低 Metastore 和 Hive 服务器的性能。跟踪和基线性能是了解分区数量何时从有益变为有害的最佳方式。

简单连接通常更好

有很多策略旨在提高连接的效率。 SMB 连接、映射连接、流表——每一个都旨在消除连接的复杂性或阶段。嵌套连接的执行成本也很高。由于连接的成本很高,因此正在做很多工作来提高连接性能。

输入文件格式选择

输入格式选择在 Hive 查询调优中很重要。例如,在处理生成大量数据的大规模生产系统时,JSON 不是理想的格式选择。这是因为 JSON 和类似的格式类型实际上占用了大量空间以及一些解析开销。

Apache Hive 利用 RCFile 和 ORC 等列式输入格式来解决此类问题。列格式使您能够单独访问每一列,从而减少分析查询中的读取操作。这导致更快的查询性能。

一开始就正确编写 Hive 查询至关重要。 Hive 查询的执行主要取决于其用户编写的代码。但并不是所有的代码都写得完美。事实上,他们需要不断调整和改变。 Hive 查询调优不仅仅与数据有关;提高执行力对于 Hive 的成功也至关重要。

使用 Tez(或更好的东西)

Apache Tez 是一个构建在 Apache Hadoop 2.0 (Yarn) 之上的框架,旨在加速 Hive 的查询执行。 Tez 帮助用户启动和持有一个或多个容器,这些容器可以重复使用以执行多个查询。它还可以帮助用户避免多次磁盘 IO 并减少启动 JVM 的开销。

执行引擎显然是开发人员关注的焦点,因为我们看到 Tez、LLAP 和 Hive on Spark 等框架希望以无需低级调优即可提高性能的方式添加到核心 Hive。理解和利用手头任务的最佳执行引擎应该是 Hive 性能调整的强制性考虑因素。

避免歪斜

Hive 查询部署一组分布式任务。整体查询仅与最慢的任务一样快。确保在任务之间均匀分配工作是一种有效的 Hive 性能调整方法。这是因为在某些任务中,它通过处理比必要的更多数据来防止查询本身变慢。

增加并行执行

默认情况下,Hive 只会在给定时间执行一个阶段。然而,一个特定的工作可能包含多个阶段,这些阶段可能并不完全相互依赖。并行执行这些非相互依赖的阶段,而不是在一个实例中运行单个阶段,可以大大减少整个作业的运行时间。

并行执行是最好的 Hive 优化技术之一,但只有在不需要顺序操作时才应利用它。并行度的数量取决于资源的可用性和数据的结构。这是另一个领域,如果没有良好的性能解决方案,“正确”的数字可能很难得出。

抽样/单元测试是一个很大的帮助

抽样和单元测试就是在你去操作一百万行之前获取你的数据的一个子集并运行一千行。这种特定的 Hive 查询调优最佳实践可帮助您了解您的代码如何工作,以便在您将大数据集投入其中之前获得所需的结果。这并非万无一失,但在小范围内解决失败或奇怪的结果比在规模上这样做更快、更有效。

将错误的查询拒之门外

仔细检查查询性能并防止低效查询进入生产环境听起来很简单,但是这个 Hive 性能调整步骤经常被跳过,直到出现问题并且为时已晚。在提升到更高级别的环境之前,应自动测量每个查询的性能和效率以满足最低可接受水平。

根据我们的 2021 年大数据调查报告,29% 的企业表示 Hive 应用程序和工作负载消耗了他们的大部分资源。 Hive 是当今企业运营的重要组成部分。这就是为什么在保持资源消耗和相关成本可控的同时微调 Hive 查询以实现最佳性能至关重要的原因。

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

使用 Query Spotlight 提升 Apache Impala 查询性能

“查询是我们客户大数据工作负载的重要组成部分,因此我们知道这些工作负载的性能至关重要。 IT 和应用程序团队现在可以在一个地方了解他们的 Hive 和 Impala 查询,比较他们的查询运行并利用 Query Spotlight 提供的建议,”Pepperdata 首席执行官 Ash Munshi 说。 “我们相信 Query Spotlight 可以提高 Impala 查询的性能,同时帮助他们降低总体成本。”

您的 Apache Impala 查询是否运行缓慢且未达到最佳性能?鉴于 Impala 的复杂性,故障排除可能非常困难。如果没有合适的工具,优化查询性能几乎是不可能的。好消息:Pepperdata Query Spotlight 现在支持 Apache Impala。

Query Spotlight 使操作员和开发人员可以轻松了解其查询和工作负载的详细 Hive 查询性能特征,以及影响这些工作负载的基础架构范围内的问题。通过添加 Impala 支持,现在可以调整、调试和优化这一重要类别的查询工作负载,以提高性能并降低成本。

大数据中的 Apache Impala 是什么?为什么它会成为热门的大数据处理平台?

Apache Impala 是一种开源 MPP(大规模并行处理)SQL 查询引擎,用于处理大量数据。 Impala 提供极高的性能和低延迟,这与其他流行的 Hadoop SQL 引擎不同。

Apache Impala 在大数据处理中的作用是通过消除在分析前将大数据集迁移到指定的处理系统或转换数据格式的需要来增强和增强性能参数。 Apache Impala 的基本功能包括:

Apache Impala 在短短两年内的快速增长和扩张源于 Amazon Web Services 和 MapR 现在都支持它。

Impala Apache 使用标准组件,包括 HBase、HDFS、YARN、Sentry 和 Metastore。除了 Apache Hadoop 的灵活性和可扩展性之外,此功能还允许 Impala 用户享受组合 SQL 支持的好处。借助 Impala,您可以使用传统的 SQL 知识以光速处理存储在 HDFS 中的数据。您还可以访问存储在 Amazon S3、HBase 和 HDFS 中的数据——即使没有 Java 知识。

Apache Impala 的 Query Spotlight 为开发人员和运营商提供了平台性能的全景图,并帮助他们削减运营成本。从详细的统计信息、查询计划、每个查询持续时间的分解等等,可见性是无与伦比的。 Query Spotlight 还提供了对 Impala 数据库和表的可见性。推荐引擎包括系统级推荐和查询级推荐——包括连接。该工具还可以生成更有效、更理想的 Apache 调优配置。

除了可视化有关资源利用率和数据库视图的详细查询信息外,Query Spotlight 还使 Impala 用户能够创建和接收有关 Apache Impala 查询的警报、修复问题并优化查询性能。 Query Spotlight 使开发人员能够:

操作员可以在多用户环境中快速缩小有问题的查询,并使用查询性能洞察来优化集群资源并提高生产力。总而言之,Query Spotlight 现在支持 Apache Impala 带来了以下好处:

超过三分之一的 IT 支出用于故障排除、性能和可用性。最重要的是,80% 的组织正在超出其大数据预算。低效的查询是其中很大一部分,造成错过 SLA 和缓慢的数据库资源。 Query Spotlight for Apache Impala 让这一切变得更好。

作者 east

上一 1 … 3 4 5 下一个

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

标签

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

官方QQ群

小程序开发群:74052405

大数据开发群: 952493060

近期文章

  • 详解Python当中的pip常用命令
  • AUTOSAR如何在多个供应商交付的配置中避免ARXML不兼容?
  • C++thread pool(线程池)设计应关注哪些扩展性问题?
  • 各类MCAL(Microcontroller Abstraction Layer)如何与AUTOSAR工具链解耦?
  • 如何设计AUTOSAR中的“域控制器”以支持未来扩展?
  • C++ 中避免悬挂引用的企业策略有哪些?
  • 嵌入式电机:如何在低速和高负载状态下保持FOC(Field-Oriented Control)算法的电流控制稳定?
  • C++如何在插件式架构中使用反射实现模块隔离?
  • C++如何追踪内存泄漏(valgrind/ASan等)并定位到业务代码?
  • C++大型系统中如何组织头文件和依赖树?

文章归档

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

功能

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

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