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

年度归档2023

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

  • 首页   /  
  • 2023
  • ( 页面12 )
云计算 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
Kafka 5月 7,2023

Kafka 优化:四个最佳实践

Apache Kafka 是一个强大的工具。它允许创建易于扩展的实时、高吞吐量、低延迟数据流。优化后,Kafka 会带来其他好处,例如抵抗集群内发生的机器/节点故障以及集群上数据和消息的持久化。这就是 Kafka 优化如此重要的原因。

优化你的 Kafka 框架应该是一个优先事项。但是,可能很难知道究竟如何优化 Kafka。这就是为什么我们为您带来四个 Kafka 最佳实践,您可以实施这些最佳实践以充分利用该框架。

以下是四个基本的 Kafka 优化技巧:

您的 Kafka 部署可能是一个挑战,因为分布式架构有很多层,并且可以在这些层内调整许多参数。

例如,通常情况下,具有自动数据冗余的高吞吐量发布-订阅 (pub/sub) 模式是一件好事。但是,当您的消费者努力跟上您的数据流,或者如果他们无法阅读消息,因为这些消息在消费者到达它们之前就消失了,那么就需要做一些工作来支持消费应用程序的性能需求。

但是这四种基本的做法应该是你Kafka优化的基础。继续阅读以深入了解这些方法。

实现和维护 Kafka 部署需要持续监控。 Kafka 是一个强大的实时数据流框架。未能优化会导致流式传输缓慢和性能滞后。

Kafka 优化是一个广泛的主题,可以非常深入和精细,但这里有四个高度利用的 Kafka 最佳实践可以帮助您入门:

1.升级到最新版本的Kafka。

这听起来可能非常明显,但您会惊讶于有多少人使用旧版本的 Kafka。一个非常简单的 Kafka 优化举措是升级并使用最新版本的平台。您必须确定您的客户是否使用旧版本的 Kafka(0.10 或更早版本)。如果是,他们应该立即升级。

Kafka 每次更新都会略有变化。最新的 Kafka 版本于 2021 年 4 月发布,提供了 KIP-500 的早期访问版本,使用户即使没有 Apache ZooKeeper 也可以运行 Kafka 代理。这消除了对内部 Raft 实现的需要。其他变化包括支持每个集群更多的分区、更无缝的操作和更严格的安全性。

2. 了解数据吞吐率。

优化 Apache Kafka 部署是优化平台堆栈层的练习。分区是吞吐量性能所基于的存储层。

每个分区的数据速率是消息的平均大小乘以每秒消息数。简而言之,它是数据通过分区的速率。所需的吞吐率决定了分区的目标架构。

这是一个关键的 Kafka 优化技巧:为了提高吞吐量,您可以扩大请求中获取的最小数据量。这导致更少的请求。然后以更大的批次传递消息。这一点至关重要,尤其是在生成的数据量较少时。对 Kafka 吞吐量指标的广泛了解将帮助用户在这种情况下充分优化他们的 Kafka 系统。

3. 在编写主题时坚持随机分区,除非体系结构要求另有要求。

解决方案架构师希望每个分区都支持相似的数据量和吞吐率。实际上,数据速率会随着时间的推移而变化,生产者和消费者的原始数量也会随之变化。

可变性带来的性能挑战是消费者滞后的可能性,也就是消费者读取率落后于生产者写入率。随着 Kafka 环境的扩展,随机分区是一种有效的方法,可确保您不会在不必要地尝试将静态定义应用于移动性能目标时引入人为瓶颈。

分区领导通常是通过由 Zookeeper 维护的元数据进行简单选举的产物。然而,领导选举并没有考虑到各个分区的性能。

根据您的 Kafka 发行版,可以利用专有的平衡器。但由于缺少此类工具,随机分区提供了实现平衡性能的最不干涉途径。

这就是为什么随机分区是我们推荐的关键 Apache Kafka 最佳实践之一。它为消费者平均分配负载。因此,扩展消费者变得更加容易。当您使用默认分区程序而不手动识别特定分区或消息密钥时,这实际上会发生这种情况。随机分区最适合无状态或“令人尴尬的并行”服务。

外卖?在写入主题时坚持随机分区,除非体系结构要求另有要求。

4.调整consumer socket buffer,实现高速摄取。

在较旧的 Kafka 版本中,参数 receive.buffer.bytes 默认设置为 64kB。在较新的 Kafka 版本中,参数为 socket.receive.buffer.bytes,默认为 100kB。

这对 Kafka 优化意味着什么?对于高吞吐量环境,这些默认值太小,因此不够用。当代理和消费者之间的网络带宽延迟乘积大于 LAN(局域网)时,情况就很明显了。

当没有足够的磁盘时,线程会变慢并变得有限。 Apache Kafka 最重要的最佳实践之一是增加网络请求缓冲区的大小。这样做将帮助您提高吞吐量。
如果您的网络以 10 Gbps 或更高的速度运行并且延迟为 1 毫秒或更长,建议您将套接字缓冲区调整为 8 或 16 MB。如果内存有问题,请考虑 1 MB。

优化 Apache Kafka 部署是一项持续的工作,但 Kafka 的这四个最佳实践应该是一个坚实的开始。上面提到的性能优化技巧只是用户可以实施以提高 Kafka 性能的一些优化方法。

Kafka 越来越受到应用程序开发人员、IT 专业人员和数据管理人员的欢迎。并且有充分的理由。有关 Kafka 的更多信息,请查看我们的另一篇博文,其中讨论了将 Kafka 应用于应用程序开发和数据管理的特定领域时的最佳实践。

作者 east
云计算 5月 7,2023

IT 转型的下一步是什么?

查看成功 IT 转型的五项原则电子书,获取有关如何转型 IT 和推动业务成功的深入指导。

IT 转型描述了企业重新检查并可能全面检修其 IT 系统的计划,以系统地努力提高业务效率。在大流行等重大破坏之后,随着行业变得比平时更具竞争力,更新和现代化 IT 系统的需求就变得突出了。

这些计划通常由 CIO(首席信息官)和其他企业领导者牵头。非正式地称为“推倒重来”流程,IT 转型的目标是“推倒”过时的 IT 系统。这些系统可以包括硬件、软件、网络架构、数据访问和存储协议以及 IT 服务管理流程。然后,组织用更新、更复杂的版本“替换”这些过时的 IT 功能。

详细说明这一转型的计划已在各部门和企业中得到越来越多的重视。据 Statista 称,数字化转型计划是 56% 的组织在 2021 年的优先事项。在另一份报告中,超过 77% 的 CIO 表示将推动他们的数字化转型计划作为 2021 年的首要 IT 计划。

大数据量的增加也促使组织进行 IT 转型。最近的统计数据显示,世界在 2020 年创建、捕获和使用了 59 泽字节 (ZB) 的数据。到 2024 年,这个数字将增长到 149 ZB。

大数据为企业提供了对其运营的重要洞察、更快地推动决策制定的能力以及推动创新周期的手段。大数据使企业能够做出正确的选择并有效地实施数据驱动的战略来推动其增长。

然而,面对当今大数据的庞大数量、复杂性和多样性,过时的 IT 基础设施和系统以及传统的数据管理实践变得无效。企业收集的大数据超出了他们的需要。在许多情况下,他们获得了根本不需要的数据类型。

随着越来越多的大数据流入企业,数据分析变得越来越复杂。通过提高他们的 IT 能力,组织将能够有效地筛选、缩小和确定他们需要哪些类型的数据,以便他们的组织以最佳水平充分发挥作用,同时减少他们收集的数据量。

任何 IT 信息计划的最终目标都是增强业务流程和改进服务交付。通过使组织的 IT 现代化以满足当前的服务标准和要求,组织可以对其流程获得深入的、可操作的洞察力;找到更可行的方法来提高效率;优化性能;并降低成本。

结果?更快的上市时间、减少的延迟、愉快的客户旅程和卓越的客户满意度。

不提云计算就不可能讨论 IT 转型。云技术的出现引入了一种新的商业模式,企业将其关键流程和应用程序从现场服务器转移到云托管基础设施。这使他们能够做更多事情,而无需承担本地 IT 中心带来的成本和挑战。

基于云的分析处理的快速发展,以及获取和查询新数据源的能力,使企业能够快速分析信息并根据高质量的洞察力做出战略性业务决策。

这就是制定计划的必要性,尤其是在竞争激烈、消费者比以往任何时候都要求更高的经济环境中。

信息技术转型是一个广泛而持续的过程,包括成本和资源。 IT 专家制定的一项特殊战略是实施 IT 即服务 (ITaaS) 方法,以帮助实现转型并同时降低成本。

ITaaS 是一种变革性的运营模式,无论是来自内部 IT 部门还是来自外部 IT 服务供应商,业务部门或个人用户都可以将 IT 作为托管服务使用。在此模型中,企业只需为他们所需的 IT 服务付费,并从供应商提供的 IT 服务和功能目录中使用这些服务。这包括框架指南、配置设置和各种其他服务。

虽然 ITaaS 不是从内部部署到云的技术转移,但它可以让企业做好准备,并帮助他们在转型 IT 基础架构的过程中实现显着的业务收益。

IT 转型不仅涉及技术转变,还为新角色和职能铺平了道路。 IT 不再是 IT 部门的唯一职责。 IT 几乎存在于整个企业的每个部门或业务单元中。最重要的是,每个单位都有自己的框架来指导其使用 IT。

实施转型战略意味着企业必须将新的 IT 角色作为议程的一部分。 IT 运营中的新兴职业——如数据架构师、数据工程师、数据分析师和首席信息管理员——是对业务领域主导的分析、数据管理自主性等前所未有的增长的集体回应。

IT 格局的重大变化,加上数据和分析的重要性和战略价值不断增加,为企业及其 IT 和数据和分析领导者带来了新的挑战。

传统 IT 角色正在被非技术用户颠覆。 IT 在每个部门和整个企业中的日益普及和利用率创造了混合 IT 角色和新的运营模式。新的 IT 角色承担着与传统 IT 团队重叠的责任和职能。事实上,ITOps 现在几乎是任何处理数据的工作的一部分。因此,这种转变需要寻找“技术运动员”,即灵活、适应性强并愿意承担新的 IT 职能和责任的 IT 专家。搜索本身可能是一项具有挑战性的工作。

云计算彻底改变了企业处理大数据应用程序的方式。这可能是 IT 转型的一大挑战。随着企业转向云端,IT 支出已从资本支出 (CapEx) 转变为运营支出 (OpEx)。这意味着严重的成本管理问题。

虽然放弃数据中心、物理服务器和其他昂贵的网络设施和设备等与资本支出相关的费用有望节省大量资金,但企业必须应对运营支出的高度流动性支出模式。云中的运营费用会迅速增加,特别是如果云团队在没有上限和没有治理的情况下运作。

关键应用程序和操作所需的数据通常量大且访问频繁。为确保在需要时随时可用,此类数据被放入热云存储中。热云存储价格昂贵,因为它们包含更快、更耐用且功能强大的存储介质,如 SSD。

将热数据存储在热云存储中的问题是数据温度会在瞬间发生变化。今天的热点数据明天可能会变冷,而现在的冷数据可能会迅速变得重要。放在冷存储中的数据需要时间来访问和处理。在为冷数据支付热存储的场景中,本可以分配到其他地方的钱很容易丢失。

似乎云计算和信息技术转型还不够复杂,IT 工具和云服务的激增使情况进一步复杂化。企业可以使用大量可用的解决方案和技术。但是,拥有大量选择意味着 IT 领导者必须重新检查他们的 IT 架构和管道,以确保他们针对每个案例和/或目的使用最好的工具。

此外,它不仅限于选择和使用正确的工具和服务。与您的云或多云基础架构一起管理这些工具和服务可能会非常痛苦。您如何才能管理好这一切而又不偏离您的转型目标?

IT 团队必须能够实时无缝地沟通和协作,以便他们有效地管理 IT 基础架构、应用程序及其所有组件。他们需要在出现问题时立即收到通知和警报,以便他们可以快速查明原因并执行有效的解决方案。然而,找到并实施正确的工具并不容易。大多数协作和消息传递软件解决方案都是为企业团队而不是 IT 设计的。

开发人员通常更喜欢容器并选择它们而不是虚拟机,因为前者允许快速简单地创建和分发应用程序代码和依赖项。容器使开发人员能够快速工作并满足业务部门和客户的规范和独特需求。

虽然开发人员称赞容器的使用,但 ITOps 发现它们存在缺陷并且存在多种缺点。一方面,容器不能以裸机速度运行,由于容器和主机系统之间的接口等导致性能开销。其次,图形应用程序在容器内运行时很笨重。第三,一旦容器关闭,您将无法检索容器内的数据。而这些只是众所周知的表面上的划痕。

2021 年 IT 优先事项报告显示,由于与 COVID-19 相关的中断和紧张局势,IT 挑战已经扩大。随着转型和云采用计划的显着加速,新的 IT 问题逐渐浮出水面。

使用过时的 IT 技术是 37% 的 IT 领导者和员工的主要挫败感,其次是获得远程办公支持 (33%)。处理支持票是第三大挫折。然而,尽管最近面临挑战,但超过一半的受访者表达了对 IT 的尊重和同情。

当您的企业踏上 IT 转型之路时,您最好参考以下几点以帮助您走在正确的轨道上:

要了解更多信息,请查看我们的电子书,了解有关如何转变 IT 和推动业务走向成功的深入指导。

作者 east
Hive 5月 6,2023

Hive 查询介绍——它们是什么以及如何有效地编写它们

在大数据领域,Hive 是一个大问题。精心编写和精心设计的 Hive 查询可加速从数据集中检索数据。 Hive 比 SQL 好得多,因为前者可以更有效地处理复杂数据。此外,Hive 查询有助于降低处理成本。这就是为什么为大数据分析用户和开发人员正确编写和优化 Hive 查询至关重要。

与其他可用的数据处理平台相比,完全优化的数据查询以更快的速度为您提供所需的数据。高效有效的 Hive 查询可以减少 50% 的执行时间。当您的数据处理框架运行得更快时,好处就会增加。

回答这个问题首先要准确理解 Hive 到底是什么。 Apache Hive 是一个在 Hadoop 之上开发的开源数据仓库平台,用于执行数据分析和分布式处理。 Facebook 创建了 Apache Hive 以减少编写 Java MapReduce 平台所需的工作。

大数据流程需要快速准确地处理大量不同的数据,以提供高度可行的见解。如果手动完成,这是一项不可能完成的任务。 Hive 的存在是为了简化大数据处理,并通过快速 Hive 查询将原始数据转化为可操作的内容。

使用 Hive 进行查询和数据分析比使用 MapReduce 框架更容易、更快,即使在处理大型数据集时也是如此。为简单起见,我们将重点关注 MapReduce 作为主要执行引擎,了解 Hive 还可以利用 Tez、Tez LLAP 和 Spark。 MapReduce 是一个低级平台,需要多个自定义程序才能运行。开发人员必须熟悉 Java,它已经是一个复杂的平台,才能充分利用 MapReduce。相比之下,您无需成为 Java 专家即可使用 Hive。

通常,Hive 查询只是对信息的请求。当在数据科学和计算机编程的上下文中使用时,Hive 查询是同一回事。不同之处在于信息直接来自数据库。

Hive 查询不仅仅是随机信息请求。您要检索的信息必须具体。因此,您可以使用一组预定义代码和数据库原生的编程语言来编写和优化 Hive 查询。一旦数据库收到并理解该指令,它就会收集查询中指定的所有信息并发布您请求的数据。

要真正从您的查询中获得最大价值,它们必须写得很好并且经过专业调整。但在此之前,让我们深入了解您需要了解的关于它们的其他信息。

用于创建数据库管理任务和流程的标准编程语言称为结构化查询语言 (SQL)。但是,SQL 并不是使用 Hive 执行查询和数据分析的唯一编程语言。 AQL、Datalog 和 DMX 也是流行的选择。

Hive 查询语言或 HiveQL 是一种类似于 SQL 的声明性语言。 HiveQL 所做的是将这些查询转换为 MapReduce 程序。它还使开发人员能够通过将复杂的 MapReduce 程序替换为 Hive 查询来处理和分析结构化和半结构化数据。

任何熟悉 SQL 命令的开发人员都会发现使用 Hive 查询语言创建请求很容易。

分区、表和桶的创建

您可以在 Hive 中创建查询,以将存储在 Hadoop 文件中的大型数据集分类到表、分区和存储桶中。在每个模型中,您根据分区或列键对相同类型的数据进行分组。可以有一个或多个分区键来帮助查明特定分区。分区数据集加速了对数据切片的查询。

ETL 功能

在将数据加载到其目标数据存储之前,您需要使用 ETL(提取、转换和加载)功能清理、准备和转换该数据。 Hive 查询可以做到这一点。数据通常从源中提取,然后存储在通用或兼容的存储中,例如 Azure Data Lake Storage 或 Azure Storage blob。然后一系列查询转换数据。在此之后,数据在 Apache Hive 中进行组织,然后再批量加载到其目标数据仓库中。

创建用于合并不同数据表的连接

Hive 查询可以包括连接,这是一种用于通过使用每个表共享的值来组合来自两个或多个表的特定字段或记录的功能。联接在速度方面以指数方式提高 Hive 查询的效率,具体取决于查询的编写方式。例如,当它们首先对最小表进行流式处理,最后对最大表进行流式传输时,带有连接子句的查询执行得更快,而不是相反。

有四种类型的连接,对每一种类型的深入了解将帮助用户选择正确的连接来使用——并编写正确的查询。这四种类型的连接是:

按查询排序

HiveQL 中的 ORDER BY 语法使用“SELECT”语句来帮助对数据进行排序。此语法遍历 Hive 表上的列,以按照“Order by”子句中的说明查找和筛选特定列值。查询只会选取 Order by 子句中提到的列名,并以升序或降序显示匹配的列值。

按查询分组

当 Hive 查询带有“GROUP BY”时,它会探索 Hive 表上的列并收集 group by 子句中提到的所有列值。查询将仅查看名称定义为“group by”子句的列,并将通过对特定和匹配的列值进行分组来显示结果。

按查询排序

当 Hive 查询带有“排序依据”子句时,它会遍历查询定义的名称下的列。执行后,查询会探索 Hive 表的列以对输出进行排序。如果您使用“DESC”指令按查询排序,您将按降序排序和显示结果。带有“ASC”的查询将执行升序排序并以类似方式显示结果。

按查询聚类

带有 CLUSTER BY 子句或命令的 Hive 查询通常部署在查询中以同时执行 DISTRIBUTE BY 和 SORT BY 的功能。此特定查询可确保对所有输出数据文件进行绝对排序或排序。

分配方式

DISTRIBUTE BY 指令确定输出如何在 MapReduce 作业中的缩减程序之间分配。 DISTRIBUTE BY 的功能类似于 GROUP BY 子句,因为它管理如何将数据行加载到 reducer 中进行处理。

查看另一篇博文,您将在其中了解如何通过 Hive 查询优化来充分利用 Hive 查询。

以下是您在管理 Hive 查询时会遇到的常见命令的简要介绍。

Hive 数据定义语言 (DDL) 命令

Apache Hive 备忘单是一个包含所有 Apache Hive 语法和函数的五部分摘要。为开发人员和大数据工程师提供参考或指导。

Apache Hive 备忘单分为以下部分:

Hive 查询会消耗资源。在大数据的世界里,资源就是金钱,资源的低效利用可能会阻碍任何组织。因此,Hive 查询优化对于将资源消耗保持在最低水平、运营成本可控以及整体性能处于最佳水平至关重要。

以下是优化 Hive 查询的一些有效方法:

针对我们所有的查询优化您的方法至关重要。 Pepperdata 为企业提供大数据优化解决方案,旨在为他们的查询、Query Spotlight 以及他们的所有堆栈、应用程序、流程等提供全面的可见性和可观察性。用户享受实时性能报告和数据驱动的建议,以优化其大数据基础架构及其所有组件的性能,同时显着降低运营成本。

作者 east

上一 1 … 11 12 13 … 19 下一个

关注公众号“大模型全栈程序员”回复“小程序”获取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年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)
  • 大数据开发 (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删除.