2023年 – 第10页

云计算 5月 18,2023

云迁移挑战：迁移后

每个人要么已经迁移到云，要么正在迁移到云。云提供了节省成本以及可扩展性、可靠性和敏捷性的承诺。云迁移的一些挑战在迁移工作之前就已经出现了。但其他云迁移挑战出现在第二天，即成功完成迁移后的关键阶段。

组织希望在促进业务增长的同时降低成本。当成本降低时，资金和其他资源就会被释放出来，使组织能够将它们用于其他优先事项，这些优先事项可以增加利润并在满足时推动进一步增长。迁移到云为企业提供了同时享受成本节约和业务增长的机会。

但组织也希望在迁移到云完成后做出数据驱动的决策。他们希望在企业的每个部分创建数据驱动的环境。几项调查一次又一次地揭示了这种情况。成为真正的数据驱动意味着采用新技术、新方法、新分析和新工具。这就是 IT 团队利用基于云的数据库、数据湖环境等的原因。

事情是这样的：数据驱动的工具对于云迁移挑战和任何其他类型的业务挑战一样有用。

云迁移之旅不是一个单一的事件。它实际上更像是一个迭代和增量过程。企业有时会像迁移一次一样处理云迁移。但从某种意义上说，它一直在发生。迁移完成后出现的云迁移挑战需要继续消除。

通常，在成功迁移之后，企业会对管理云基础设施和云流程所付出的努力感到震惊。更不用说，他们不切实际的投资回报率预期没有得到满足。当被问及他们期望何时获得云迁移投资回报时，几乎三分之二的人在几个月内回答，如果不是几周或几天的话。

但是，它通常需要比这更长的时间。云迁移的投资回报率可能较慢，并且需要持续努力。设定企业级期望可能很棘手，但企业需要保持期望切合实际。他们需要接受，在几个周期之后，你才能真正掌握在云中的窍门。只有这样，您才能真正开始收获收益。

这是第 2 天云迁移的另一个重大挑战。成本通常是企业希望首先进入云的主要原因。然而，一旦企业进入云计算，他们就会发现管理云支出是一个主要问题。从 IT 的角度来看，这是一个挑战。他们如何在不限制业务需求的情况下限制使用？

许多企业最终都遭遇了账单冲击，因为他们没有预料到云成本会如此之高。他们发现自己超出了云预算。

在不妨碍对云资源的访问的情况下控制云支出的一项有效措施（尽管存在争议）是实施扣款政策。这是对部门在特定时间段内消耗的技术和资源收费的时间。

这是非常有效的，因为部门要对他们使用云服务负责。此举还让 IT 管理员了解如何利用云资源。然而，这是有争议的，因为大多数业务部门不为使用公司资源和公用事业计费。

当人们第一次听说云的优势时，他们认为整合数据和逐步淘汰硬件在支出方面都是有利的。但实际上，迁移之后，成本通常会攀升。你可能有效率，但享受这些效率需要资源。资源就是金钱。因此，您组织中的人们陷入了战争与和平的局面，争论如何管理成本。谁得到它？谁没有？谁可以消费它？哪些产品、工作和项目可以优先使用其中的一些资源？

组织需要做的是在环境中使用不同的工具、优化工作和产品，以通过可见性和洞察力匹配并帮助降低这些成本。

一旦进入云端，组织就可以采用数百种工具、服务数据库和其他东西。数据平台内的产品前景广阔。第二天，企业需要立即分配资源和专业知识，以确定如何在新技术环境中最好地装备自己。他们需要弄清楚如何控制浪费。

在云中运行业务流程的另一个复杂方面是云支出的浪费。闲置或未使用的资源、超大的基础设施和资源集中等因素会导致云浪费。

仅在 2019 年，云浪费造成的损失就达 141 亿美元。为了防止这些损失，组织必须准确估计他们的资源需求并增加额外的容量，而不是批量购买资源。主动监控或关闭未使用的云环境也有助于减少浪费。利用 AI 支持的云优化工具非常适合维护多个环境的用户。随着工作负载的波动，这些工具将自动扩展其云基础设施。

转移到云端需要大量的改变。事实上，抵制这种变化的组织将经历一系列不同的新的和意想不到的挑战。您可以将这些更改强加于您，也可以接受它们。无论哪种方式，在云中操作都意味着您无论如何都必须进行更改。云计算空间正在不断发展。你越是意识到这一点并接受这些变化，从长远来看，你的组织就会越好。

Rackspace Hosting 2013 年的一项研究反映了这一思路。在 1,300 名企业受访者中，有 88% 的人表示迁移到云为他们节省了资金，而 56% 的人确认这增加了他们的利润。有了正确的战略和正确的工具，迁移到云可能是任何企业都经历过的最好的事情。他们需要做的就是在第 2 天的云迁移挑战中生存下来，并弄清楚如何从“迁移”过渡到“运营”，同时应对两者之间的颠簸和阶段。

作者 east

Hive 5月 18,2023

通过可观察性优化 Spark 中的性能

Apache Spark 为大数据行业的企业提供了许多好处。然而，与任何技术解决方案一样，它也伴随着挑战和障碍。通过优先考虑强调可观察性的工具，您可以优化 Spark 作业的性能，并开始深入了解性能问题的原因，而不仅仅是问题的本质。

Apache Spark 架构为大数据行业提供非常有用的工具有几个原因：

无论 Spark 多么强大，它仍然面临着一系列挑战。因此：根据我们的 2020 年大数据性能报告，观察到 Spark 作业的失败频率是其他作业的四到七倍。

此外，该报告进一步揭示了在没有 Spark 性能调整和优化的情况下：

这就是为什么公司需要优化 Spark 的性能。如果不应用 Spark 优化技术，集群将继续过度配置和利用资源。据一位分析师称，在全球范围内，仅闲置资源一项就产生了约 88 亿美元的年增长率。

在优化 Spark 工作负载和作业时，关键是可观察性。

以内存利用率为例。也许用户需要分配更多内存以避免垃圾回收。或者，在多租户环境中，用户可能分配了过多的内存，导致租户之间出现排队等问题。如果没有正确的优化解决方案，Spark 用户对如何为他们的集群正确分配内存一无所知。

Spark 性能调优的另一个机会是减少（如果不能避免的话）数据倾斜。 Spark 对数据倾斜很敏感，对于高度分布式和瘫痪的应用程序来说，它可能是非常具有破坏性的。数据倾斜导致某些应用程序元素的工作时间超过它们应有的时间，而其他计算资源则闲置，未得到充分利用。有助于优化 Spark 性能的工具应该跟踪数据倾斜并提出有效的建议来纠正它。

那么如何优化 Spark 的性能并衡量成功呢？再次，通过可观察性。

Spark 用户最终需要说，“嘿，我的应用程序现在运行无故障，而且我始终如一地满足我的 SLA。”为此，他们需要合适的可观察性工具来帮助他们确定内存利用率、数据倾斜以及大多数公司工作的多租户环境中可能出现的其他问题。

作者 east

Spark 5月 17,2023

银行业大数据分析：如何减少超支

在银行业有效利用大数据分析现在是一项竞争要求。大数据在银行业中的作用是多方面的。最常见的用例是访问各种类型的第一方数据，以更好地了解客户并根据他们的需求定制产品和解决方案。其他大数据银行业务示例和用例包括利用命令式数据协助银行处理 Customer 360，以及通过高级财务数据分析进行风险管理。总体而言，银行业通过大数据分析实现的自动化也最大限度地减少了人类情感和偏见对金融交易的影响。

然而，许多银行每年花费超过 1 亿美元来继续获得银行业大数据分析的好处。其中一些是不必要的超支。公司需要采用新的技术工具来帮助他们优化性能并减少超支。

多租户数据湖的挑战

所有主要银行都在随时存储和访问大量数据。这些数据位于每年都在扩展的数据湖中。通常，它们的大小会增加一倍以上。

曾几何时，大数据银行示例和用例是分开的。将有一个商业银行数据湖，一个零售数据湖，一个投资数据湖，一个家庭保险数据湖，等等。但今天，越来越多的数据涌入，形成了一个巨大的数据湖。银行的各个部分充当租户，访问同一个数据湖。这种多租户数据湖安排给系统和服务器带来了巨大压力。通常，在银行业有效使用大数据分析的能力会逐渐停止。

多租户数据湖还带来了另一个问题：数据隐私。关于银行和金融机构如何处理大量不同的、非结构化的私人数据，存在很多紧张的讨论。并且有充分的理由；当谈到银行业的数据分析时，个人信息是从消费者行为分析中收集的，他们的决策是使用大量杂乱无章的信息做出的。当然，安全协议已经到位，可以保护如此庞大的数据集合。但是，当每个人都浸入同一个湖中时，数据泄露的风险就会增加。

银行如何最终超支以跟上

金融服务公司通常如何应对多租户数据湖的挑战？通过增加基础设施。根据 ResearchandMarkets 的一份报告，在大数据和人工智能上投资至少 5000 万美元的公司去年增长了 7%。在全球范围内，每年约有 1800 亿美元用于大数据分析投资。

简而言之，在银行业有效利用大数据分析的压力促使银行迅速投资额外的本地和云基础设施，以跟上不断增长的数据量。这会导致 Dell 或 IBM 的巨额硬件账单，和/或 AWS 的巨额云账单。

此外，运营基础设施本身也需要花钱。指挥基础设施和不断扩大的数据湖的管理和维护需要具有专业知识的专业人员的服务。成本迅速增加，许多银行每年花费超过 1 亿美元来继续获得银行业大数据分析的好处。

作者 east

Spark 5月 17,2023

为什么 Spark 这么慢？今天优化 Spark 的 5 种方法

在竞争日益激烈的世界中寻找优势？通过 Kubernetes 2023 状态揭示 Kubernetes 可以为您的业务做些什么。现在阅读以探索如何利用 Kubernetes 的优势、解锁潜在解决方案并克服挑战。

当 Apache Spark 运行良好时，它确实运行良好。但有时，用户会发现自己在问这个令人沮丧的问题。

Spark之所以如此受欢迎，是因为它比传统的数据处理解决方案能够执行更多的计算和更多的流处理。与 MapReduce 等流行的传统系统相比，Spark 的速度要快 10-100 倍。但是，虽然 Spark 能够处理范围广泛的工作负载和大数据集，但有时也会遇到困难。这就是原因，这就是您可以采取的措施。

所以：您已经尝试了一些 Apache Spark 性能调优技术，但您的应用程序仍然很慢。此时，是时候深入了解您的 Spark 架构，并确定导致您的实例运行缓慢的原因。

驱动故障

在 Spark 架构中，驱动程序充当编排器。因此，它配备的内存少于执行程序。当驱动程序遇到 OutOfMemory (OOM) 错误时，可能是以下原因造成的：

简而言之，当驱动程序执行需要更多内存的服务或尝试使用比分配的内存更多的内存时，就会发生 OOM 错误。解决这种情况的两个有效的 Spark 调优技巧是：

高并发

有时，Spark 运行缓慢是因为运行的并发任务太多。

高并发能力是一个有益的特性，因为它提供了 Spark 原生的细粒度共享。这会导致最大的资源利用率，同时减少查询延迟。 Spark 将作业和查询划分为多个阶段，并将每个阶段分解为多个任务。 Spark 会根据多种因素并发执行这些任务。

但是，并行执行的任务数基于 spark.executor.cores 属性。虽然高并发意味着要执行多个任务，但如果该值设置得太高而没有适当考虑内存，执行程序将失败。

低效查询

为什么 Spark 这么慢？也许你有一个写得不好的查询潜伏在某处。

按照设计，Spark 的 Catalyst 引擎会自动尝试最大程度地优化查询。但是，如果查询本身写得不好，任何优化工作都注定会失败。例如，一个查询被编程为选择 Parquet/ORC 表的所有列。每列都需要某种程度的内存中列批处理状态。如果查询选择所有列，则会导致更高的开销。

一个好的查询读取尽可能少的列。一个好的 Spark 性能调优实践是尽可能使用过滤器。这有助于限制获取到执行程序的数据。

另一个好技巧是使用分区修剪。将查询转换为使用分区列是优化查询的一种方法，因为它可以极大地限制数据移动。

配置不正确

获得正确的内存配置对于 Spark 应用程序的整体性能至关重要。

每个 Spark 应用程序都有一组不同的内存和缓存要求。如果配置不正确，Spark 应用程序会变慢或崩溃。深入查看 spark.executor.memory 或 spark.driver.memory 值将有助于确定工作负载是否需要更多或更少的内存。

YARN 容器内存开销也会导致 Spark 应用程序变慢，因为 YARN 需要更长的时间来分配更大的内存池。实际情况是 YARN 在容器中运行每个 Spark 组件，例如驱动程序和执行程序。它产生的开销内存实际上是用于JVM（驱动程序）开销、interned字符串和JVM的其他元数据的堆外内存。

当由于 YARN 内存开销导致 Spark 性能下降时，您需要将 spark.yarn.executor.memoryOverhead 设置为正确的值。通常，为开销分配的理想内存量是执行程序内存的 10%。

您需要采取某些步骤来确保 Spark 运行不慢。以下是使您的 Spark 架构、节点和应用程序以最佳水平运行的一些有效方法。

数据序列化

这种特殊的 Spark 优化技术将内存中的数据结构转换为可以存储在文件中或通过网络传输的不同格式。使用这种策略，您可以显着提高分布式应用程序的性能。两种流行的数据序列化方法是：

Java 序列化——您使用 ObjectOutputStream 框架序列化数据，并利用 java.io.Externalizable 来完全控制序列化的性能。 Java 序列化提供轻量级持久性。

Kyro 序列化——Spark 利用 Kryo 序列化库 (v4) 比 Java 序列化更快地序列化对象。这是一种更紧凑的方法。要通过使用 Kyro 序列化真正提高 Spark 应用程序的性能，必须通过 registerKryoClasses 方法注册这些类。

缓存

缓存是一种高效的优化技术，在处理重复需要和查询的数据时使用。 Cache() 和 persist() 非常适合存储数据集、RDD 和 DataFrame 的计算。

需要记住的是，cache() 将数据放入内存中，而 persist() 将数据存储在用户指定或定义的存储级别中。缓存有助于降低成本并在处理重复计算时节省时间，因为从内存读取数据比从磁盘读取数据快得多。

数据结构调整

数据结构调整减少了 Spark 内存消耗。数据结构调优通常包括：

垃圾收集优化

垃圾回收是一种内存管理工具。每个应用程序都将数据存储在内存中，内存中的数据有一个生命周期。垃圾收集标记哪些数据不再需要，标记为删除，然后删除。删除发生在应用程序暂停期间。这些暂停是要避免的。当垃圾收集成为瓶颈时，使用带有 -XX:+UseG1GC 的 G1GC 垃圾收集器已被证明效率更高。

Spark 并不总是完美运行。这是一个很棒的数据处理平台，但不能让它完全自动运行。一致的 Spark 性能调优将帮助您的 Spark 基础设施以最佳水平运行

下次您发现自己问“为什么 Spark 这么慢？”时，请深入了解 Spark 架构并仔细研究。前面提到的 Spark 性能缓慢的原因可能只是罪魁祸首之一，而提到的提高性能的技巧可能是您需要改进的地方。

作者 east

Kafka 5月 16,2023

Kafka Streams 最佳实践：今天要尝试的 3 个

Kafka Streams 最好定义为专门为构建应用程序和微服务而设计的客户端库。考虑 Kafka 流的一种简洁方法是将其视为一种消息服务，其中数据（以消息的形式）在 Kafka 集群中从一个应用程序传输到另一个应用程序，从一个位置传输到另一个仓库。所有输入和输出数据都存放在 Apache Kafka 集群中。

为了形象化，这是 Kafka 环境中数据传输的样子：数据请求（消费者，用 Kafka 术语来说）被创建并发送到另一端。在这里，生产者响应请求生成内容，并通过 Kafka 架构将其直接传送回消费者，消费者随后消费信息。

Kafka Streams 是开发人员非常流行的工具，主要是因为它可以处理从消费者到生产者的数百万个请求，并将它们分布在数十台服务器上，以确保快速和连续传输，同时保持准确性。相反，该平台可以将大量数据从生产者转移到消费者，同时保证消费者实际上能够以他们需要的速度和他们需要的顺序消费数据。

但人们真正喜欢 Kafka Streams 的地方在于数据流没有停顿。大规模实时数据处理对于许多应用程序来说至关重要。（没有它，Facebook 或 Uber 就会有大麻烦。）Kafka 不间断地传输数据，这与使用过时遗留应用程序的传统环境不同。 Kafka Streams 可在其集群内实现无阻碍的数据流，确保数据在来回循环中从一个应用程序传输到另一个应用程序，从消费者传输到生产者，中间没有任何停顿。其内置冗余可确保数据在传输过程中不会丢失，并完好无损地到达预定目的地。

所以：Kafka Streams 很棒。 Kafka Streams 为任何应用程序开发项目带来的优势直接证明了该平台越来越受欢迎和无处不在。但要真正从 Kafka Streams 中获得最大价值，您需要将一些最佳实践应用于底层 Kafka 平台：

如果你想优化 Kafka Streams 环境中的数据流，你需要跟踪很多事情。其中之一是速度，因为它涉及：

速度是一个关键组成部分。 Kafka Streams 可以有效地促进数据在集群内的移动。但是，如果消息移动的速度对您的应用程序来说不够快，则可能意味着麻烦。确保数据和消息以您需要的速度移动。

要完全优化 Kafka Streams，您的架构必须使用适量的资源构建，以便它获得并保持必要的数据流速度以实现其目标。简而言之，您需要解决以下问题：

必须构建消息路由以满足您的应用程序要求并且吞吐量要令您满意。这是关于为工作而建造的。你不会想要一辆半卡车来运送比萨饼。同样的原则适用于比特，而不仅仅是原子。

如果 Kafka 开始表现不佳，问题可能出在 Kafka 指标上。但这也可能是另一个问题，例如硬盘驱动器或某些性能不佳的内存。团队需要能够尽可能快速有效地进行故障排除。

借助正确的大数据分析工具，您可以集中查看堆栈中的所有硬件、应用程序和监控指标，包括来自 Kafka Streams 的指标。您得到的是一个单一的统一界面，其中指标和消息传递相互关联。这使您可以查看哪个应用程序遇到问题以及它如何影响 Kafka 及其功能。

在大多数大数据监控设置中，硬件监控不同于大数据应用程序监控。将 Kafka 监控添加到图片中，您将拥有一个大的脱节监控环境。但是使用像 Pepperdata 这样的统一监控套件，您可以查看和跟踪所有内容。您对大数据堆栈享有绝对且无与伦比的可见性和可观察性。

Kafka 是一个丰富而复杂的平台。还有很多东西要学。但是 Kafka Streams 的这三个最佳实践是让您获得成功的强大基础。

作者 east

Hive 5月 16,2023

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

Kafka 5月 16,2023

从 Kafka 吞吐量指标中获得最大价值

Kafka 支持在系统之间快速、安全、高效地移动大量流数据。出于这个原因，它已成为我们大数据时代的强大工具，在这个时代，数据速度和安全性比以往任何时候都更加重要。

了解和优化您对 Kafka 吞吐量指标的使用是成功支持基于 Kafka 构建的用例（例如实时 Kafka 流和流分析框架）的重要组成部分。吞吐量与在给定时间范围内可以在系统或应用程序之间移动的数据量有关。它广泛用于衡量 RAM、硬盘驱动器、网络连接和互联网的性能。对于 Kafka，吞吐量仅与消息从一个点移动到另一个点的速度有关。

各种组件的性能影响 Kafka 集群内的整体吞吐量：生产者生产内容的速度有多快？代理如何处理消息的移动？消费者消费消息的速度有多快？所有这些因素都会影响吞吐量。衡量这些组件及其性能可帮助您形成一组基线数字。 Kafka JMX 指标是您确定 Kafka 集群是否以最佳方式运行的能力的基础。

一旦捕获了 JMX 指标，集群所有者和/或架构师就可以使用这些指标，从可视化这些指标到创建图表并最终收集洞察力。这种捕获、分析和获得可操作见解的过程几乎不可能手动解决。解决方案需要尽可能多地自动化流程，同时不代表 Kafka 平台所有者自己陡峭的学习曲线和上下文切换。

Kafka 为您提供 JMX 指标，但它们仅代表您评估和维护平台的健康和性能所需的数据的一个子集。要问的大问题是：单独使用 JMX 指标是否足以完成这项工作？（剧透：没有）。您能否将这些指标综合为关键决策的燃料？您能否使用这些 Kafka 吞吐量指标来提高集群的性能并避免因性能问题而感到惊讶？您将如何将基于 JMX 的性能数据与基于 Kafka 构建的平台硬件和应用程序的性能指标相关联？

作者 east

云计算 5月 15,2023

大数据分析调优是 IT 转型的关键

大约 70% 的全球企业已经启动或计划启动某种形式的 IT 转型，这是有充分理由的。进行各种形式的 IT 转型的企业实现其最高业务目标的可能性比同行高 64%。

但 IT 转型不仅仅是实施 DevOps 模型。企业需要一个全面的战略和计划。在制定计划后，他们需要对现有的关键 IT 基础设施进行现代化改造，以提高运营支出和管理开销方面的效率。

大数据分析堆栈的自动调整极大地促进了所有形式的 IT 转型。在我们最近关于 IT 转型的电子书中，我们将自动调整和优化作为正确转型所需的重要原则之一。

无论您仍在本地并计划迁移到云端，还是已经在云端，都有一个令人不安的事实：企业组织使用的计算量通常比他们预期的要多得多。 Gartner 预测，“到 2020 年，由于缺乏成本优化方法，80% 的组织将超出其云 IaaS 预算。”这意味着大多数公司都面临过度配置和超支的风险，尤其是当他们不采用成本优化时。超出预期的支出是任何 IT 转型的糟糕开端。

一个很大的原因是公司没有工具来提供对云应用程序性能和大数据分析堆栈的完整和可操作的可见性（尽管这两者对于任何 IT 转型都至关重要）。 APM 工具可以让您对数据应用程序有一定的了解，但如今，仅进行监控是不够的。公司真正需要的是建议和自动调整，以纠正性能问题并优化现有资源。你需要行动，而不仅仅是观看。

为了促进有效的 IT 转型，用于管理应用程序工作负载、查询、消息流和性能问题的解决方案需要敏捷且果断。这些解决方案必须具有保持所有工作负载以优化速度运行所需的深度可见性。否则，它们会对 SLA 以及应用程序和工作负载性能产生不利影响。

作者 east

云计算 5月 15,2023

大数据趋势推动的 IT 运营新职业

大流行迫使许多组织重新考虑其 IT 运营。企业领导者已经意识到，要实现弹性和业务连续性，他们需要加快数字化转型，从而增加对 IT 和其他新兴技术的依赖。这些技术中的关键是云和大数据工具。

因此，IT 运营领域的新职业正在兴起。这些职业包括致力于帮助公司采用云计算和大数据技术的角色。随着越来越多的组织将重点放在此处，企业拥有在未来几年蓬勃发展所需的技术和工具将变得至关重要。

IT 运营或 IT Ops 是指由组织的 IT 部门执行和管理的一组服务和流程。总体术语通常包括所有 IT 资源的利用和管理，例如硬件（计算机、笔记本电脑、网络设备等）、软件（软件许可证、应用程序、在线服务等）和人员（IT 经理、技术人员、数据科学家等）。

IT 运营人员承担多种角色，从内部 IT 流程（如技术管理、质量保证、网络管理、设备管理和基础设施管理）到外部和面向客户的运营（如为其 IT 产品和服务提供支持和专业知识）。

企业技术的现代化一直是 IT 运营的主要关注点，尤其是当他们的组织面临落后于竞争对手的风险时。 IT Ops 还为其他部门提供指导，特别是传达获取当前和新兴技术以取代旧技术的需求。

就 IT 运营职业而言，最重要的趋势可能是向云的巨大转变。大多数公司已将其关键业务运营和应用程序迁移到云端。 IBM 最近的一项研究表明，95% 的 IT 领导者计划采用多种云战略，以加速其 IT 现代化计划。

这些公司需要大数据堆栈来保持其 IT 基础设施和流程平稳运行，并充分发挥效益以产生可观的回报。随着其对企业的作用和影响呈指数级放大，IT 运营正在经历前所未有的繁荣。

随着该领域变得越来越复杂和细分，IT 运营领域的新职业正在涌现。 IT等相关技术的进步催生了DevOps（开发运营）、DataOps（数据运营）、MLOps（机器学习运营）等多种运营模式。

IT Ops 的现有定义已经变得广泛和过时，因为各个部门现在都有自己的 IT 流程和规则。现代业务的快速发展、不断变化和不断进步的技术以及加快对独特业务需求的反应时间的明显需求需要新的和独立的运营方法。

虽然按定义和目的分开，但这些方法或运营模型仍然通过 IT 相互连接。例如，DevOps 将 IT Ops 与软件应用程序开发 (R&D) 和质量保证 (QA) 的最佳实践和方法相结合。

云计算使企业能够根据需要为 IT 服务付费。大规模云迁移已将 IT 支出从资本支出 (CapEx) 转移到运营支出 (OpEx)。随着企业迁移到云端，他们抛弃了数据中心、物理服务器和其他昂贵的网络设施和设备，转而采用灵活且可扩展的云托管基础架构。

然而，从管理良好的资本支出模型转变为极其流畅的运营支出支出模型存在挑战。一方面，云环境在很大程度上是分布式和分散的。这使得财务团队很难始终保持监督。如果没有可靠的治理和监控，企业很容易对其云支出管理不善并积累不可持续的成本。企业必须想出一个可持续的云支出模型来帮助管理支出并确保成功和安全的过渡。 IT Ops 可以在正确过渡方面发挥重要作用。

随着企业努力提高 IT 支出的透明度，准确的退款将成为未来的常态。组织将实施可持续支出模型，其中包括一个记录系统，该系统允许根据用户消费对 IT 服务进行精细成本核算。通过跟踪用户的资源和服务消耗，IT 部门可以为其他业务部门提供准确和透明的云账单。

IT 运营团队对于准确了解计费框架至关重要。

业务格局发生了变化，IT 需求也发生了变化。

也许最大的变化是 IT 不再单独负责生产和开发。其他运营模式已经出现。他们的职责和职能现在与传统 IT 团队重叠。特别是当业务部门正在创建自己的应用程序并更多地支持自己时。 IT Ops 现在几乎是任何处理数据的工作的一部分。

此外，机器学习 (ML) 和人工智能 (AI) 的日益普及和采用是 IT 世界的主要趋势。商业组织越来越依赖人工智能和机器学习来执行重复性任务。

到 2022 年，20% 的员工将使用 AI 来完成他们的工作。到2025年，人工智能将完成50%的数据科学家任务，有效解决专家严重短缺的问题。

这些巨大的变化为 IT Ops 的职业生涯提供了新的途径。 IT 专家现在享有多种机会来接受新的工作方式以及与其他部门的整合。 IT Ops 仍然可以通过拥抱新技术趋势前沿的新角色为组织增加价值。

数据和分析经理。顾名思义，数据和分析经理负责管理数据和分析卓越中心。该职位需要支持整个企业的数据和分析交付。他们还被要求为数据和分析的战略和愿景做出贡献，制定路线图，与高级利益相关者沟通，并承担资源和预算的责任。除了衡量团队绩效外，数据和分析经理还跟踪和监控数据和分析对其业务目标的影响。

数据工程师。数据工程师的任务是寻找数据集中的趋势和机会。他们构建算法来简化对原始数据的访问。他们还寻找从符合企业或客户目标的原始数据中获取价值的方法。

数据工程师的另一个职责是优化数据检索并为利益相关者提供理解数据的方法，例如仪表板、报告和其他可视化。

较大的企业通常在其花名册中拥有多名数据科学家或分析师，以帮助解释和交流数据。但是在这个小企业现在可以访问数据的新环境中，数据工程师可以同时扮演这两个角色。

数据分析师。数据分析师是那些在统计分析方面拥有丰富经验和知识的人，他们能够找到有助于支持其业务特定方面的见解。通常，他们是领域专家，或者与领域专家密切合作，利用他们发现的见解寻找改进业务流程和功能的方法。

数据架构师。这些是数据远见者，他们根据组织的战略和目标获取业务需求并将其转化为技术需求。他们还负责为其组织的数据管理框架创建数据标准和原则。

数据架构师充分了解各种数据和分析场景如何影响其整体 IT 架构。他们经常与企业架构师合作，为他们的数据和分析架构及其支持平台制定战略。

首席信息管理员。执行由信息治理单元制定的信息治理策略是首席信息管理员的主要职责。他们确保所有信息治理政策得到实施和遵守。实际上，他们根据这些策略监控信息人员和资产。

除了数据和分析的重要性和战略价值日益增加之外，IT 领域的巨大变化给企业及其 IT 和数据和分析领导者带来了新的挑战。

非技术业务用户正在颠覆传统的 IT 角色。 IT 在每个部门和整个企业中的日益普及和利用率催生了混合 IT 角色，其中许多角色融入了 IT Ops 的新一代职业。

作者 east

云计算 5月 15,2023

如何有效地对 Cloud FinOps 进行基准测试

由于 Cloud FinOps 能够帮助更有效地管理财务运营，因此在当今数字时代的组织中迅速流行起来。这是因为它允许组织以更高的可见性跟踪、衡量和优化他们的云支出。它还通过自动化众多财务流程（包括计费、预算、审计和报告）来帮助提高运营效率。

除了更好的可见性之外，FinOps 还能够通过提供对使用模式的洞察力来识别节省成本的机会，并进一步帮助组织保持对财务法规的遵守。 FinOps 正迅速成为任何希望在保持财务运营领先地位的同时最大化盈利能力的组织的必备工具。但是组织如何将这些实践的结果与过去的结果进行比较呢？

本博客将讨论您需要了解的有关 FinOps 的所有信息，以及如何在当今不断发展的数字环境中保持领先地位。

Autonomous FinOps（Cloud FinOps 的细分）是一种在云中进行成本优化和财务运营的现代方法。它利用自动化、分析和机器学习技术来优化资源利用率和控制云支出。这种方法允许团队确定优化领域、设置 SLA 并监控他们的进度以降低成本、提高效率和优化资源利用率。它还允许组织更好地了解云资源使用情况、预测未来支出并制定成本优化策略。

随着围绕 Cloud FinOps 开放的新部门区域，团队与 IT 组织合作，以确保云资源得到高效且经济的使用。这种方法可帮助组织最大限度地提高云投资回报，同时最大限度地降低风险和不必要的支出。专注于此的团队还可以帮助组织掌握最新的行业趋势，确定需要改进的领域并做出更好的云决策——这对任何基于云的组织来说都是宝贵的资产。

这种运营方法使组织能够实现其财务和运营目标，同时避免代价高昂的错误。它正迅速成为任何基于云的组织的关键组成部分，对于组织而言，了解 Cloud FinOps 并开发专门从事它的团队以最大化其云投资非常重要。

FinOps 是一种财务优化策略，可让企业减少支出并更好地管理预算。它通过主动支出优化帮助企业提高效率和降低成本。它还采用多种策略，使云用户能够准确跟踪支出、根据使用数据主动采取行动并预测未来成本。

Cloud FinOps 通过加强财务和工程团队之间的协作，帮助企业在云中最大限度地减少开支、最大限度地节省开支并制定预算优化计划。它还提供了对云使用趋势、成本和资源优化机会的可见性。这有助于云用户确定潜在的成本节约和减少超支。

Cloud FinOps 基准测试

FinOps.org 建议采用以下步骤进行有效的基准测试。

资源利用和效率。 FinOps 团队必须确保消耗的每一种资源都能转化为足够的商业价值。由此产生的性能和其他质量指标必须在经济上值得每一笔费用。

首先，FinOps 团队应该建立和定义他们的业务效率指标集。这些指标应该反映他们的业务并衡量资源的效率。

FinOps 团队必须能够将货币价值与可以通过合理调整低效或未充分利用的资源来避免的成本相对应。

衡量单位成本。团队制定能够展示每项云投资的商业价值的指标至关重要。专门的 FinOps 从业者求助于 Cloud Unit Economics，这是一种建立在客观衡量标准之上的利润最大化模型，可根据您的 FinOps 和业务目标评估您的组织绩效。常用单位包括：

基于承诺的折扣。云服务提供商提供服务折扣以吸引客户并签署消费承诺。著名的例子是 AWS Savings Plans 和 Google CUD。

重要的是要注意，每个云提供商都有不同的产品和关于如何提供折扣的独特规则。 FinOps 团队必须仔细研究每个计划，并确定这些折扣结构如何帮助他们实现运营和财务目标。

异常管理。异常是意外的云支出，与正常发生的成本不同。以云自动缩放器为例，许多 FinOps 团队发现他们的云成本飙升，因为这些自动缩放器提供资源的速度很慢。开发人员倾向于过度配置资源，以便他们的应用程序相应地执行，从而导致资源浪费和组织的云账单异常。将异常需求降至最低的 FinOps 团队是一个自主平台，可以根据利用率与分配情况实时安排资源——消除手动调整的错误并最终控制云成本。

Cloud FinOps 如何影响组织

Cloud FinOps 通过适当的监控、实时洞察力和精细报告来制定统一的支出决策。没有健全战略的企业缺乏推动明智、统一决策所需的洞察力。这通常会导致他们的云资源利用率低下，性能不佳且成本高昂。管理人员更好地了解他们的资源利用及其财务影响，从而使他们能够开发和实施简化的实践，以实现运营和财务目标。

这种现代运营方法可帮助公司转变为云优先文化。现在越来越多的组织正在转向云并投资于云资源。然而，只有少数人足够成熟，能够认识到这是一种文化转变。他们正在摆脱传统的流程和模型。 Cloud FinOps 使组织能够发现、阐明和实施获取和使用云资源的最佳方式。这创造了一种文化，在这种文化中，各方都可以从资源的优化和标准化利用中受益。

预测的准确性对于依赖云的组织也至关重要。对云利用率和支出了解最少的企业将难以控制其云消费。 Cloud FinOps 提供实施主动监控、放置和执行控制以及提供自动预算警报所需的数据和见解。企业将为其所有流程提供充足的云资源，同时消除供应不足和过度供应的风险。

使用容量优化器对 FinOps 性能进行基准测试

为了有效地对您的 Cloud FinOps 性能和支出进行基准测试，您将需要一个超越可观察性和表面指标的自主优化工具。 Pepperdata Capacity Optimizer 利用自动化和机器学习来分析大量实时性能和资源利用率数据，以重新捕获浪费的容量、优化集群资源、运行更多应用程序等。

对于寻求提升其 FinOps 方法的组织，Capacity Optimizer 使 FinOps 团队能够了解其云基础架构、流程、消耗和支出。这使他们能够衡量有价值的关键业务 KPI，并获得高度可行的见解，从而削减云成本并提高工作负载效率。

在 Capacity Optimizer 带来的成本控制和优化中，它可以显示企业基础架构内节省的快速差异。最重要的是，它可以帮助企业实现这些成本节约，同时满足 SLA 并实现其业务目标。

作者 east

Flink 5月 15,2023

flink cdc初始全量速度很慢原因和优化点

link cdc初始全量速度很慢的原因之一是，它需要先读取所有的数据，然后再写入到目标端，这样可以保证数据的一致性和顺序。但是这样也会导致数据的延迟和资源的浪费。
flink cdc初始全量速度很慢的原因之二是，它使用了Debezium作为捕获数据变化的引擎，而Debezium在读取数据时，会使用全局锁或者快照隔离级别，这样会影响源端数据库的性能和并发能力。
flink cdc初始全量速度很慢的优化点之一是，使用并行读取的方式，将源端数据库的表分成多个分区，然后使用多个任务同时读取不同的分区，这样可以提高读取速度和吞吐量。
flink cdc初始全量速度很慢的优化点之二是，使用增量检查点的方式，将读取到的数据在内存中进行增量备份，然后定期写入到目标端，这样可以减少写入次数和延迟，并且在故障恢复时，可以从检查点恢复数据，而不需要重新读取所有的数据。
flink cdc初始全量速度很慢的优化点之三是，调整flink cdc和flink的相关参数和选项，如设置合理的并行度、任务槽、检查点间隔、缓冲区大小、网络超时等，以适应不同的场景和需求。

作者 east

年度归档2023