对于新项目,我们建议您使用适用于 Apache Flink Studio 的新托管服务,而不是使用适用于 SQL 应用程序的 Kinesis Data Analytics。适用于 Apache Flink Studio 的托管服务将易用性与高级分析功能相结合,使您能够在几分钟内构建复杂的流处理应用程序。
本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
针对 SQL 应用程序的 Amazon Kinesis Data Analytics 进行故障排除
以下内容可以帮助您解决在使用 Amazon Kinesis Data Analytics for SQL 应用程序时可能遇到的问题。
主题
已停止的应用程序
什么是已停止的 Kinesis Data Analytics for SQL 应用程序?
已停止的应用程序是指我们观察到至少在三个月内未处理任何记录的应用程序。这意味着客户需要为他们未使用的 SQL 资源付费 Kinesis Data Analytics。
何时Amazon开始停止闲置的应用程序?
Amazon将于 2023 年 11 月 14 日开始停止闲置的应用程序,并于 2023 年 11 月 21 日之前完成。我们将在该地区的办公时间时区停止闲置的应用程序。
是否可以重新启动适用于 SQL 的 Kinesis Data Analytics 应用程序?
可以。如果您需要重新启动应用程序,则可以照常重新启动。没有必要削减支持票。
当空闲应用程序Amazon停止时,我的任何查询结果也会被删除吗?
不是。 首先,由于您的应用程序处于空闲状态,因此它无法处理查询。其次,您的查询结果不会存储在 Kinesis Data Analytics for SQL 中。您可以将 Kinesis Data Analytics for SQL 应用程序配置为发送计算结果的接收目标(例如,在 Amazon S3 或其他数据流中)。因此,您保留对数据的完全所有权,并且根据该存储服务的条款,这些数据仍可被检索。
如果我不想停止我的应用程序该怎么办?
你可以在 2023 年 11 月 10 日之前给服务团队 (kda-sql-questions@amazon .com) 发送电子邮件,要求不要停止应用程序。电子邮件中应包含您的账户 ID 和应用程序 ARN。
无法运行 SQL 代码
如果你需要弄清楚如何让特定的 SQL 语句正常工作,那么在使用 Kinesis Data Analytics 时,你有几种不同的资源:
有关 SQL 语句的更多信息,请参阅适用于 SQL 的 Kinesis Data Analytics 示例。此部分提供了一些可使用的 SQL 示例。
《亚马逊 Kinesis Data Analytics SQL 参考》提供了创作流式 SQL 语句的详细指南。
如果你仍然遇到问题,我们建议你在 Kinesis Data Analytics 论坛
上提问。
无法检测到或发现我的架构
在某些情况下,Kinesis Data Analytics 无法检测或发现架构。在其中许多情况下,您仍然可以使用 Kinesis Data Analytics。
假设您具有不使用分隔符的 UTF-8 编码数据,或具有使用非逗号分隔值 (CSV) 格式的数据,或发现 API 未发现您的架构。在这些情况下,可以手动定义架构或使用字符串操作函数来构建数据。
为了发现直播的架构,Kinesis Data Analytics 会随机采样直播中的最新数据。如果您没有始终如一地向直播发送数据,Kinesis Data Analytics 可能无法检索样本并检测架构。有关更多信息,请参阅针对流数据使用架构发现功能:
引用数据已过时
当应用程序启动或更新时,或者在服务问题导致应用程序中断期间,参考数据将从 Amazon Simple Storage Service (Amazon S3) 对象加载到应用程序中。
更新底层 Amazon S3 对象时,不会将参考数据加载到应用程序中。
如果应用程序中的引用数据不是最新的,可以通过以下步骤重新加载这些数据:
-
在 Kinesis Data Analytics 控制台上,在列表中选择应用程序名称,然后选择应用程序详细信息。
-
选择 Go to SQL editor (转到 SQL 编辑器) 打开应用程序的 Real-time analytics (实时分析) 页面。
-
在 Source Data (源数据) 视图中,选择引用数据表名称。
依次选择 Actions (操作)、Synchronize reference data table (同步引用数据表)。
应用程序不写入到目标
如果数据未被写入到目标,请检查以下各项:
验证应用程序的角色具有足够权限来访问目标。有关更多信息,请参阅 写入 Kinesis 直播的权限策略 或 写入到 Firehose 传输流的权限策略。
验证是否已正确配置应用程序目标,并且应用程序正在使用正确的输出流名称。
检查输出流的亚马逊 CloudWatch 指标,以查看是否正在写入数据。有关使用 CloudWatch 指标的信息,请参阅使用亚马逊进行监控 CloudWatch。
使用添加 CloudWatch 日志流AddApplicationCloudWatchLoggingOption。您的应用程序将配置错误写入日志流。
如果该角色和目标配置看起来正确,请尝试重启应用程序,同时为 LAST_STOPPED_POINT
指定 InputStartingPositionConfiguration。
要监控的重要应用程序运行状况参数
要确保您的应用程序正常运行,我们建议您监控某些重要参数。
要监控的最重要参数是亚马逊 CloudWatch 指标MillisBehindLatest
。此指标表示落后于您从流中读取的当前时间多久。此指标可帮助确定您是否足够快速地处理源流中的记录。
通常,您应该设置一个 CloudWatch 警报,以便在您落后超过一小时时触发。但是,时间量取决于您的使用案例。您可以按需进行调整。
有关更多信息,请参阅最佳实践:
在运行应用程序时出现无效代码错误
当您无法保存和运行 Amazon Kinesis Data Analytics 应用程序的 SQL 代码时,常见原因如下:
-
在您的 SQL 代码中重新定义了流 — 在创建了流和与该流关联的泵之后,您无法在代码中重新定义相同的流。有关创建直播的更多信息,请参阅 Amazon Kinesis Data Analytics SQL 参考中的创建流。有关创建数据泵的更多信息,请参阅 CREATE PUMP。
-
GROUP BY 子句使用多个 ROWTIME 列 — 在 GROUP BY 子句中只能指定一个 ROWTIME 列。有关更多信息,请参阅《亚马逊 Kinesis Data Analytics S QL 参考》中的 G RO UP BY 和 ROWTIME。
-
一种或多种数据类型的转换无效 — 在这种情况下,您的代码具有无效的隐式转换。例如,您可能在代码中将
timestamp
转换成bigint
。 -
流的名称与服务预留流名称相同 - 流的名称不能与服务预留流
error_stream
的名称相同。
应用程序正在将错误写入到错误流
如果您的应用程序正在将错误写入到应用程序内部错误流,则可以使用标准库解码 DATA_ROW
字段中的值。有关错误流的更多信息,请参阅错误处理。
吞吐量不足或过高 MillisBehindLatest
如果您的应用程序的MillisBehindLatest指标稳步增长或持续高于 1000(一秒),则可能是由于以下原因造成的:
检查您的应用程序的InputBytes CloudWatch 指标。如果提取速度超过 4 MB/秒,这可能会导致
MillisBehindLatest
增加。要提高应用程序的吞吐量,请增加InputParallelism
参数值。有关更多信息,请参阅并行处理输入流以增加吞吐量:检查应用程序的输出传输 Success 指标以确定传输到目标是否失败。确认您已正确配置输出,并且您的输出流具有足够的容量。
如果您的应用程序使用Amazon Lambda函数进行预处理或作为输出,请检查应用程序的 .Duration 或 InputProcessingLambdaDelivery.Durati on 指标。 CloudWatch 如果 Lambda 函数调用持续时间超过 5 秒,请考虑执行以下操作:
增加 Lambda 函数的内存分配。您可以在 Amazon Lambda 控制台的 Configuration (配置) 页面上的 Basic settings (基本设置) 中执行此操作。有关更多信息,请参阅 https://docs.amazonaws.cn/lambda/latest/dg/resource-model.html 开发人员指南 中的Amazon Lambda配置 Lambda 函数。
在应用程序的输入流中提高分片数。这会提高应用程序将调用的并行函数的数量,从而可能提高吞吐量。
确认函数没有进行影响性能的阻止性调用,如同步的外部资源请求。
检查 Amazon Lambda 函数以确定是否具有可提高性能的其他方面。检查应用程序 Lambda 函数的 CloudWatch 日志。有关更多信息,请参阅Amazon Lambda开发者指南中的访问亚马逊 CloudWatch 指标。
确认您的应用程序未达到 Kinesis 处理单元 (KPU) 的默认限制。如果您的应用程序达到该限制,您可以请求提高限制。有关更多信息,请参阅自动扩展应用程序以提高吞吐量:
如果您的应用程序在 KPU 限制提高后仍然存在问题,请检查应用程序的输入吞吐量是否不超过 100MB/秒。如果超过 100MB/秒,我们建议实施更改以降低总体吞吐量以稳定应用程序,例如通过减少发送到Kinesis Data Analytics Sql应用程序读取的数据源的数据量。我们还推荐了其他方法,包括增加应用程序的并行性、缩短计算时间、将列式数据类型从 VARCHAR 更改为大小较小的数据类型(例如 INTEGER、LONG 等),以及减少通过采样或过滤处理的数据。
注意
我们建议您定期检查应用程序的
InputProcessing.OkBytes
指标,以便您可以提前计划使用多个 SQL 应用程序,或者如果应用程序的预计输入吞吐量将超过 100 MB/秒,则可以迁移到managed-flink/latest/java/。