亚马逊AWS官方博客
Category: AWS Big Data
使用 AWS Step Functions 为 Amazon Redshift 编排 ELT 流程
现代数据湖依靠提取、转换和加载 (ETL) 操作将大量信息转换为可用数据。本文将指导您实施 ETL 编排流程,该流程使用 AWS Step Functions、AWS Lambda 和 AWS Batch 实现松散耦合,以便创建 Amazon Redshift 集群。
使用 AWS DMS 和 AWS Glue 持续加载数据湖更改
在 Amazon S3 上构建数据湖可让组织受益无穷。它允许您访问各种数据源,确定独特的关系,构建 AI/ML 模型来提供定制的客户体验,并加速新数据集的管理以供消费。但是,无论是在本地还是在 AWS 上,从运营数据存储中捕获不断变化的更新并将其加载到数据湖,都可能会非常耗时且难以管理。
下文演示了如何部署一个解决方案,将来自热门数据库源(如 Oracle、SQL Server、PostgreSQL 和 MySQL)的持续更改加载到您的数据湖中。该解决方案会将新数据和发生更改的数据流式传输到 Amazon S3。它还会创建和更新相应的数据湖对象,根据您配置的计划提供与数据源类似的数据视图。然后,AWS Glue Data Catalog 公开新更新和经过重复数据删除的数据,以供分析服务使用。
在 Amazon Elasticsearch Service 中设置警报
4 月 8 日,Amazon ES 推出了事件监控和警报支持。要使用此功能,您可以使用带有触发器(即您设置的特定触发条件,指示监视器何时发送警报)的监控 Monitor(即事先安排的作业)。警报是发生触发条件的通知。触发器触发时,监控 Monitor 将执行特定操作(向目标发送消息)。
本文使用模拟的物联网 Device Farm 生成数据并将数据发送到 Amazon ES。
如何使用 AWS Step Functions 和 AWS Glue 将 Amazon DynamoDB 表导出至 Amazon S3
不愧是 AWS 的做派,我在 AWS 大数据博客上发表 How Goodreads offloads Amazon DynamoDB tables to Amazon S3 and queries them using Amazon Athena 之后不到一周,AWS Glue 团队就发布了 通过 AWS Glue 爬网程序和 AWS Glue ETL 作业原生读取 DynamoDB 表中数据的功能。我对此兴奋不已。写得代码越少意味着缺陷越少。最初的架构已经存在了至少 18 个月,只需稍加改进即可实现大幅简化。
利用 AWS Glue 自动触发数据目录和 ETL job 构建自动化无服务器数据湖
如今,海量数据从四面八方纷涌而来,比如来自 IoT 传感器、应用程序日志和点击流等资源的非结构化数据,以及来自事务处理应用程序、关系数据库和电子表格的结构化数据。数据已成为每家企业的重要组成部分。为了快速获取数据中的价值,保持单一事实来源(single source of truth),并且自动执行从数据提取到转换和分析的整个pipeline的需求应运而生。
Amazon EMR 5.24 中的 Apache Spark 性能升级 — 性能比 Amazon EMR 5.16 最高提升 13 倍 | AWS 大数据博客
Amazon EMR 发行版 5.24.0 包含了多项 Spark 优化,提升了查询性能。为了评估性能的提升,我们使用了 3TB 级的 TPC-DS 基准查询,在一个 6 节点 c4.8xlarge EMR 集群上运行,数据存储在 Amazon S3 中。我们观察到,在以类似的配置运行时,EMR 5.24 上的查询性能要比 EMR 5.16 高 13 倍。
利用 Amazon S3 inventory, Amazon EMR, 和 Amazon Athena 来触发针对预先存在的对象的跨区域复制
在本文中,我们展示了如何用Amazon S3 inventory, Amazon Athena, AWS Glue Data Catalog和Amazon EMR来对预先存在的和之前复制失败的对象进行规模化的copy-in-place。
通过 Amazon EMR 重新配置动态修改集群
这篇文章讲解了如何使用新的 EMR 集群重新配置功能在运行的集群上配置实例组的基础知识。并详细介绍了提交重新配置请求的额外语义、重要的配置级别概念以及重新配置跟踪方法的方式。
使用 Amazon Kinesis Data Firehose 和 Amazon EMR 中的 Apache Spark 优化流式数据处理
对于大多数公司而言,处理不断增加的数据量并整合新数据源充满挑战。 通常,AWS 客户会收到来自各种连接设备和传感器的海量消息,这些消息必须先经过有效注入和处理,之后才能执行进一步分析。 通常 Amazon S3 是适合保存所有类型数据的地点。 但是,数据在 Amazon S3 中的存储方式会对后续数据处理的效率和成本产生重大影响。 具体而言,如果 Apache Spark 处理的是大量小文件而不是较少的大文件,则可能会因文件操作量大而承受巨大负担。 在这些文件中,用于打开每个文件、读取元数据信息和关闭文件都会占用几毫秒时间。大量文件操作占用的总时间较多,这会导致处理缓慢。这篇博文将介绍如何使用 Amazon Kinesis Data Firehose 将传送到 Amazon S3 的大量小消息合并为较大消息。 这样可以加快运行 EMR 服务 中运行的 Spark 的的处理速度
通过 Amazon EMR 重新配置动态修改集群
如果您是使用长期运行的 Amazon EMR 集群的开发人员或数据科学家,您将面临快速变化的工作负载。这些变化通常需要不同的应用程序配置才能在集群上以最佳方式运行。
通过重新配置功能,现在可以更改正在运行的 EMR 集群上的配置。从 EMR 版本 emr-5.21.0 开始,该功能允许您在不创建新集群或通过 SSH 手动连接到每个节点的情况下修改配置。







