亚马逊AWS官方博客

Tag: Amazon EMR

从 Kudu 迁移到 Hudi

在构建本地数据中心的时候,出于Kudu良好的性能和兼备OLTP和OLAP的特性,以及对Impala SQL和Spark的支持,很多用户会选择Impala/Spark + Kudu的技术栈。但是由于Kudu对本地存储的依赖,导致无法支持的数据高可用和弹性扩缩容,以及社区的逐渐不活跃,越来越多的用户,开始迁移到云上的Trino/Spark + Hudi 技术栈,本文通过一个实际的例子,来看一下迁移过程中发生的代码的重构和数据的迁移。

使用 Amazon Athena、Amazon EMR 和 AWS Glue 构建 Apache Iceberg 数据湖

大多数企业将其关键数据存储在数据湖中,您可以将来自各种来源的数据存储到集中存储中。数据由专门的大数据计算引擎处理,例如用于交互式查询的 Amazon Athena、用于 Apache Spark 应用程序的 Amazon EMR、用于机器学习的 Amazon SageMaker 和用于数据可视化的 Amazon QuickSight。

在Amazon EMR上构建实时数据湖

在 Amazon EMR 集群上,通过使用Flink, Spark 等服务与Hudi 集成,配合 Airflow, Amazon MSK 等服务可以轻松实现流式数据湖的构建,从而有效的减少了数据从产生到消费的数据延迟。同时借助 Amazon EMR 和 Amazon MSK, 消除了 Flink /Spark/Kafka 等基础服务运营开销,让这些服务开箱即用,从而使我们只要关心数据湖的构建以及湖上的数据处理

Amazon EMR Hudi 性能调优——Clustering

Hudi作为Amazon EMR提供的智能湖仓的重要组件,已经得到越来越广泛的应用,Hudi在考虑到多种业务场景的同时,也对查询性能提供了很多的优化的方法,例如Index,Metadata Table, Clustering。本篇Blog介绍Hudi在查询方面做的性能优化的方法之一 —- Clustering, 通过介绍 Clustering的原理,操作,以及查询性能的对比,有助于读者理解Hudi Clustering, 并在实际开发中找到适合的场景。