- Java锁的逻辑(结合对象头和ObjectMonitor)
- 还在用饼状图?来瞧瞧这些炫酷的百分比可视化新图形(附代码实现)⛵
- 自动注册实体类到EntityFrameworkCore上下文,并适配ABP及ABPVNext
- 基于Sklearn机器学习代码实战
Apache Hudi 社区一直在快速发展,各公司正在寻找方法来利用其强大的功能来有效地摄取和管理大规模数据集。 每周社区都会收到一些常见问题,最常见的问题与 Hudi 如何执行更新插入有关,以确保以低延迟访问最新数据.
快速更新插入的主要考虑因素之一是选择正确的存储表类型。 Hudi 支持两种不同的存储表类型——Copy-On-Write (COW) 和 Merge-On-Read (MOR)。 由于处理数据更新的方法不同,每种表类型都会对 upsert 性能产生不同的影响.
与 MOR 表相比,COW 表的操作更简单,因为所有更新都写入 Apache Parquet 格式的基础文件。不需要运行像压缩这样的单独服务来管理任何日志文件以提高读取或存储效率。COW通过完全重写文件以生成新版本的基本文件来处理更新。 因此 COW 表表现出更高的写放大,因为创建新的基本文件版本会进行同步合并。 然而 COW 表的一个关键优势是它们的零读取放大,因为所有数据都在基础文件中可用,随时可以读取。 查询所需的磁盘读取很少,因为它们不需要读取多个位置或合并数据.
与 COW 表相比,MOR 表具有更高的操作复杂性。 MOR 不会重写整个文件,而是将更新写入单独的日志文件,然后这些日志文件稍后与基本文件合并为一个新的文件版本,这是通过压缩服务完成的。 需要压缩来限制日志文件的增长,这样查询性能就不会下降并优化存储.
直接写入日志文件避免了多次重写整个基本文件,从而降低了写入放大——如果正在处理流数据,这种差异就会变得很明显,也就是说 MOR 表进行了写入优化。 但是由于需要读取基本文件和日志文件并动态合并数据,MOR 表在压缩之间对快照查询有更高的读取放大.
如果更新插入比率很高并且对摄取延迟很敏感,那么更适合使用 MOR 表。 如流数据源——通常会希望更快地根据洞察采取行动,以便为用户提供相关和及时的信息。 但是如果工作负载更多地基于插入,并且可以容忍合理的摄取延迟,那么更适合使用 COW 表.
通过利用索引,Hudi 在更新插入期间查找记录时避免全表扫描,这比较耗费时间和资源。 Hudi 的索引层将记录键映射到相应的文件位置,索引层是可插拔的,有多种索引类型可供选择。 需要考虑的是索引延迟取决于多种因素,例如正在摄取多少数据、表中有多少数据、是否有分区表或非分区表、选择的索引类型、工作负载的更新程度和记录键的时间特性。 根据所需的性能和唯一性保证,Hudi 提供了不同的开箱即用的索引策略,可以分为 全局或非全局索引 .
非全局索引: Hudi 确保一对分区路径和记录键在整个表中是唯一的。 索引查找性能与正在摄取的传入记录之间的匹配分区的大小成正比。 。
全局索引: 该索引策略在表的所有分区中强制执行键的唯一性,即保证对于给定的记录键,表中恰好存在一条记录。 全局索引提供了更强的保证,但是更新/删除成本随着表的大小而增长.
由于唯一性保证的差异,全局与非全局之间的主要考虑因素之一与索引查找延迟有关: 非全局索引仅查找匹配的分区: 例如如果有 100 个分区并且传入的批处理仅包含最后 2 个分区的记录,则只会查找属于这 2 个分区的文件组。 对于大规模的更新插入工作负载可能需要考虑非全局索引,例如非全局布隆、非全局简单索引和桶索引。 全局索引查看所有分区中的所有文件组: 例如如果有 100 个分区并且传入的记录批次中有最后 2 个分区的记录,则将查找所有 100 个分区中的所有文件组(因为 Hudi 必须保证整个表中只有一个版本的记录键)。 这会增加大规模更新插入工作负载的延迟.
布隆索引: 这是一种索引策略,可以有效地管理文件组中的更新插入和记录查找。 该索引利用布隆过滤器,这是一种概率数据结构,有助于确定给定记录键是否存在于特定文件组中。适用于全局和非全局索引.
简单索引: 这是一种索引策略,它提供了一种将记录键映射到其相应文件组的直接方法。它针对从存储表中提取的键执行传入更新/删除记录的连接。适用于全局和非全局索引.
HBase索引: 该索引策略使用HBase存储索引来映射记录键及其在文件组中对应的文件位置。 适用于全局索引.
桶索引: 这是一种索引策略,它使用散列将记录路由到静态分配的文件组。 适用于非全局索引.
一致性哈希桶索引: 这是一种索引策略,是桶索引的高级版本。 虽然桶索引需要为每个分区预先分配文件组,但使用一致的哈希索引可以根据负载动态地增加或收缩每个分区的文件组。 适用于非全局索引.
分区是一种技术,用于根据数据集中的某些属性或列将大型数据集拆分为较小的、易于管理的部分。 这可以大大提高查询性能,因为在查询期间只需要扫描数据的一个子集。 然而分区的有效性在很大程度上取决于分区的粒度.
一个常见的误区是将分区设置得过于精细,例如按 <city>/<day>/<hour> 划分分区。 根据工作负载每小时粒度的数据可能不足,从而导致许多只有几千字节的小文件。 如果小文件越多,磁盘寻道成本就越高,查询性能就会下降。 其次在摄取方面,小文件也会影响索引查找,因为修剪不相关文件需要更长的时间。 根据正在使用的索引策略,这可能会影响写入性能。因此建议用户始终从较粗糙的分区方案开始,如 / 以避免小文件的问题,如果仍然觉得需要粒度分区,可以根据查询模式重新评估分区方案和/或可以潜在地利用Clustering服务来平衡摄取和查询性能.
最后此篇关于提升ApacheHudiUpsert性能的三个建议的文章就讲到这里了,如果你想了解更多关于提升ApacheHudiUpsert性能的三个建议的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
在这段令人惊叹的视频 ( https://www.youtube.com/watch?v=udix3GZouik ) 中,Alex Blom 谈到了 Ember 在移动世界中的“黑客攻击”。 在 22
我们希望通过我们的应用收集使用情况统计信息。因此,我们希望在服务器端的某个地方跟踪用户操作。 就性能而言,哪个选项更合适: 在 App Engine 请求日志中跟踪用户操作。即为每个用户操作写入一个日
在针对对象集合的 LINQ 查询的幕后究竟发生了什么?它只是语法糖还是发生了其他事情使其更有效的查询? 最佳答案 您是指查询表达式,还是查询在幕后的作用? 查询表达式首先扩展为“普通”C#。例如: v
我正在构建一个简单的照片库应用程序,它在列表框中显示图像。 xaml 是:
对于基于 Web 的企业应用程序,使用“静态 Hashmap 存储对象” 和 apache java 缓存系统有何优缺点?哪一个最有利于性能并减少堆内存问题 例如: Map store=Applica
我想知道在性能方面存储类变量的最佳方式是什么。我的意思是,由于 Children() 函数,存储一个 div id 比查找所有其他类名更好。还是把类名写在变量里比较好? 例如这样: var $inne
我已经阅读了所有这些关于 cassandra 有多快的文章,例如单行读取可能需要大约 5 毫秒。 到目前为止,我不太关心我的网站速度,但是随着网站变得越来越大,一些页面开始需要相当多的查询,例如一个页
最近,我在缓存到内存缓存之前的查询一直需要很长时间才能处理!在这个例子中,它花费了 10 秒。在这种情况下,我要做的就是获得 10 个最近的点击。 我感觉它加载了所有 125,592 行然后只返回 1
我找了几篇文章(包括SA中的一些问题),试图找到基本操作的成本。 但是,我尝试制作自己的小程序,以便自己进行测试。在尝试测试加法和减法时,我遇到了一些问题,我用简单的代码向您展示了这一点
这个问题在这里已经有了答案: Will Java app slow down by presence of -Xdebug or only when stepping through code? (
我记得很久以前读过 with() 对 JavaScript 有一些严重的性能影响,因为它可能对范围堆栈进行非确定性更改。我很难找到最近对此的讨论。这仍然是真的吗? 最佳答案 与其说 with 对性能有
我们有一个数据仓库,其中包含非规范化表,行数从 50 万行到 6 多万行不等。我正在开发一个报告解决方案,因此出于性能原因我们正在使用数据库分页。我们的报告有搜索条件,并且我们已经创建了必要的索引,但
我有一条有效的 SQL 语句,但需要很长时间才能处理 我有一个 a_log 表和一个 people 表。我需要在 people 表中找到给定人员的每个 ID 的最后一个事件和关联的用户。 SELECT
很难说出这里问的是什么。这个问题是含糊的、模糊的、不完整的、过于宽泛的或修辞性的,无法以目前的形式得到合理的回答。如需帮助澄清此问题以便重新打开它,visit the help center 。 已关
通常当我建立一个站点时,我将所有的 CSS 放在一个文件中,并且一次性定义与一组元素相关的所有属性。像这样: #myElement { color: #fff; background-
两者之间是否存在任何性能差异: p { margin:0px; padding:0px; } 并省略最后的分号: p { margin:0px; padding:0px } 提前致谢!
我的应用程序 (PHP) 需要执行大量高精度数学运算(甚至可能出现一共100个数字) 通过这个论坛的最后几篇帖子,我发现我必须使用任何高精度库,如 BC Math 或 GMP,因为 float 类型不
我一直在使用 javamail 从 IMAP 服务器(目前是 GMail)检索邮件。 Javamail 非常快速地从服务器检索特定文件夹中的消息列表(仅 id),但是当我实际获取消息(仅包含甚至不包含
我非常渴望开发我的第一个 Ruby 应用程序,因为我的公司终于在内部批准了它的使用。 在我读到的关于 Ruby v1.8 之前的所有内容中,从来没有任何关于性能的正面评价,但我没有发现关于 1.9 版
我是 Redis 的新手,我有一个包含数百万个成员(member) ID、电子邮件和用户名的数据集,并且正在考虑将它们存储在例如列表结构中。我认为 list 和 sorted set 可能最适合我的情
我是一名优秀的程序员,十分优秀!