AWS上的文本分析：使用OpenSearch实施数据湖架构 架构博客
在AWS上进行文本分析：使用OpenSearch实现数据湖架构
作者：Francisco Losada，发布于2023年1月20日 在这篇文章中，我们将探讨如何在AWS上有效处理文本数据，并展示如何使用OpenSearch作为中心搜索和分析服务来提取有价值的洞察。这种架构使数据团队能够独立地从文本文档中提取见解，并随著自动化的推进，不断进化其架构。
重要要点
文本数据是常见的非结构化数据，经常储存且缺乏预定格式，可能难以获取和处理。本文介绍如何在AWS上实现数据湖架构以处理文本数据，并用OpenSearch进行分析。几个AWS服务如AWS Lambda、AWS Glue等协同工作，以完成数据的提取、预处理和更新。数据湖架构可支持独立的数据团队在不同阶段处理文本数据。架构概述
这种架构概述了使用AWS服务创建一个端到端的文本分析解决方案，从数据收集和引入到在OpenSearch中消费数据，如下图所示：
从多个来源收集数据，例如SaaS应用、边缘设备、日志、流媒体和社交网络。根据数据源类型，使用像AWS数据库迁移服务、AWS DataSync、Amazon Kinesis等工具来将数据引入AWS数据湖。将引入的数据存储在Amazon S3的原始区域，保留数据的原始形式。通过AWD Glue或Amazon EMR进行数据的验证、清理、标准化和转换。将准备好索引的数据放置到索引区。使用AWS Lambda将文档索引到OpenSearch中，并将它们以唯一标识符储存在数据湖中。使用清理区作为数据的真实来源，供团队消费并计算新指标。利用Amazon SageMaker或像Amazon Comprehend的AI服务来开发和训练机器学习模型并生成新指标。在丰富区储存新指标及其对应的OpenSearch文档标识符。利用初始索引阶段中的标识符列识别正确文档，使用AWS Lambda在OpenSearch中更新这些文档。使用OpenSearch对文档进行搜索，并用OpenSearch仪表板进行可视化。考量因素
数据湖团队间的协作
该架构允许数据团队在文本文档的不同生命周期阶段独立工作。数据工程团队管理原始和索引区域，负责数据的引入和预处理，以便在OpenSearch中进行索引。
清理后的数据将存储在清理区，数据分析师和数据科学家在此生成洞察并计算新指标。这些指标存储在丰富区内，并由数据工程团队将其索引为OpenSearch文档的新字段。
熊猫vpv加速梯子
例如，一家公司定期检索博客评论并使用Amazon Comprehend进行情感分析。具体流程如下：
评论数据被引入数据湖的原始区域。数据工程团队处理这些评论并将其存储在索引区。Lambda函数将评论索引到OpenSearch中，并使用OpenSearch文档ID丰富评论，最终将其保存在清理区。数据科学团队消费这些评论并使用Amazon Comprehend进行情感分析。情感分析的指标被存储在数据湖的指标区域，第二个Lambda函数将新的指标更新到OpenSearch中的评论中。如果原始数据不需要预处理，则索引区和清理区可以合并。您可以在AWS示例库中探索此特定示例及其代码实现。
结构演变
数据在数据湖的各个阶段中，结构随之变化并得以丰富。参考上述示例，下面是结构演变的展示。
在原始区域，接收来自引入阶段的原始文本字段。建议保留数据的原始版本，以备将来需要重复处理。在索引区，经过处理后的干净文本字段取代原始文本字段。在清理区，我们添加了在索引期间生成的新ID字段，以识别文本字段的OpenSearch文档。在丰富区，ID字段是必需的，其他字段则是可选的，代表其他团队计算的新指标，将会被添加到OpenSearch中。使用OpenSearch的消费层
在OpenSearch中，数据被组织为索引，这可以视为关联数据库中的表。每个索引包含文档类似于表的行和多个字段类似于表的列。可以通过不同的客户端API来索引和更新文档。
接下来，我们来探讨架构如何在索引和更新阶段与OpenSearch集成。
使用Python索引和更新文档
索引文档API操作允许您使用自定义ID索引文档，或在未提供ID的情况下自动分配ID。为了加快索引速度，我们可以使用批量索引API在一次调用中索引多个文档。
我们需要将ID从索引操作存回以便于后续更新文档的指标。可以采用两种方法：
使用requests库调用REST批量索引API推荐： 返回的响应将返回我们需要的自动生成ID。使用Python低级客户端 ID不会返回，需要预先分配以便稍后存储。可以使用AWS DynamoDB中的原子计数器来进行这一操作，这允许多个Lambda函数并行索引文档而不会发生ID碰撞。如图所示，Lambda函数的流程如下：
根据将要索引的文档数量增加原子计数器。从API调用获取计数器的回应值。使用在[当前计数器值、当前计数器值 文档数量]之间的范围，索引文档。数据流自动化
随著架构向自动化演进，数据湖各阶段的数据流变为事件驱动。参考之前的示例，我们可以自动化从原始区域到索引区域的数据处理步骤。
借助Amazon EventBridge和AWS Step Functions，我们可以自动触发预处理AWS Glue作业，以无需人工干预地预处理数据。
相同的方法也可应用于数据湖的其他阶段，以实现全面自动化的架构。可以探索此自动化语言用例的实现。
总结
在这篇文章中，我们讨论了如何设计一种在AWS上有效处理文本数据的架构。我们解释了不同的数据团队如何在使用OpenSearch作为搜索和分析服务的不同生命周期阶段独立工作，以提取文本文档中的洞察。
标签：Architecture、aws solutions、data lakes
Francisco Losada
Francisco Losada是一位分析专家解决方案架构师，工作于西班牙马德里，与EMEA地区的客户共同设计、实施和发展AWS的分析解决方案。他倡导OpenSearch一个开源的搜索和分析套件，并通过分享代码范例、撰写内容和参加会议来支持社区。在业余时间，Francisco喜欢打网球和跑步。
Passkeys 提升了安全性和可用性，因为 AWS 扩大了 MFA 的要求 安全博客
AWS加强MFA要求，Passkeys提升安全性和可用性关键要点AWS推出对FIDO2 passkeys的支持，以增强客户的多因素认证MFA选项和安全性。从2024年7月起，独立账户的根用户在登录AW...