适用于 SQL 应用程序的 Amazon Kinesis Data Analytics 故障排除 - SQL适用于应用程序的 Amazon Kinesis Data Analytics 开发者指南
已关停的应用程序无法运行 SQL 代码无法检测到或发现我的架构引用数据已过时应用程序不写入到目标要监控的重要应用程序运行状况参数在运行应用程序时出现无效代码错误应用程序正在将错误写入到错误流吞吐量不足或 MillisBehindLatest 较高

经过仔细考虑，我们决定分两个步骤停止使用亚马逊 Kinesis Data Analytics SQL 的应用程序：

1. 从 2025 年 10 月 15 日起，您将无法为应用程序创建新的 Kinesis Data Analytic SQL s。

2. 我们将从 2026 年 1 月 27 日起删除您的申请。您将无法启动或操作适用于应用程序的 Amazon Kinesis Data Analytic SQL s。从那时起，亚马逊 Kinesis Data Analytics SQL 将不再提供支持。有关更多信息，请参阅 适用于应用程序的 Amazon Kinesis Data Analytic SQL s 停产。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

适用于 SQL 应用程序的 Amazon Kinesis Data Analytics 故障排除

以下内容可以帮助您解决在适用于 SQL 应用程序的 Amazon Kinesis Data Analytics 中可能遇到的问题。

已关停的应用程序

  • 什么是已关停的适用于 SQL 的 Kinesis Data Analytics 应用程序？

    已关停的应用程序是至少三个月未处理任何记录的应用程序。即使客户没有使用适用于 SQL 的 Kinesis Data Analytics 资源，但仍在为其支付费用。

  • AWS 什么时候开始关停空闲的应用程序？

    AWS 将在 2023 年 11 月 14 日至 2023 年 11 月 21 日期间关停空闲的应用程序。我们将在所在区域的工作时间段关停空闲的应用程序。

  • 是否可以重新启动已关停的适用于 SQL 的 Kinesis Data Analytics 应用程序？

    是。您可以在需要时照常重新启动应用程序。无需创建支持票证。

  • AWS 停用空闲应用程序后，我的查询结果是否会随之删除？

    不会。首先，由于您的应用程序处于空闲状态，因此无法对查询进行处理。其次，您的查询结果不会存储在适用于 SQL 的 Kinesis Data Analytics 中。您可以为适用于 SQL 的 Kinesis Data Analytics 应用程序配置接收器 (目的地)，例如，在 Amazon S3 或其他数据流中。因此，您保留对数据的完整所有权，并且根据该存储服务的条款，这些数据仍可被检索。

  • 我不希望应用程序被停用，我该怎么做？

    在 2023 年 11 月 10 日之前任何时候，你可以发送电子邮件给服务团队 (kda-sql-questions@amazon.com)，要求不停用您的应用程序。电子邮件中应包含您的账户 ID 和应用程序 ARN。

无法运行 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 对象时，不会将引用数据加载到应用程序中。

如果应用程序中的引用数据不是最新的，可以通过以下步骤重新加载这些数据：

  1. 在 Kinesis Data Analytics 控制台上，在列表中选择应用程序名称，然后选择应用程序详细信息。

  2. 选择 Go to SQL editor (转到 SQL 编辑器) 打开应用程序的 Real-time analytics (实时分析) 页面。

  3. 在 Source Data (源数据) 视图中，选择引用数据表名称。

  4. 依次选择 Actions (操作)、Synchronize reference data table (同步引用数据表)。

应用程序不写入到目标

如果数据未被写入到目标，请检查以下各项：

如果该角色和目标配置看起来正确，请尝试重启应用程序，同时为 LAST_STOPPED_POINT 指定 InputStartingPositionConfiguration。

要监控的重要应用程序运行状况参数

要确保您的应用程序正常运行，我们建议您监控某些重要参数。

要监控的最重要的参数是 Amazon CloudWatch 指标 MillisBehindLatest。此指标表示落后于您从流中读取的当前时间多久。此指标可帮助确定您是否足够快速地处理源流中的记录。

一般来说，应将 CloudWatch 警报设置为在滞后超过 1 小时时触发。但是，时间量取决于您的使用案例。您可以按需进行调整。

有关更多信息，请参阅最佳实践。

在运行应用程序时出现无效代码错误

如果无法保存和运行 Amazon Kinesis Data Analytics 应用程序的 SQL 代码，常见原因如下：

  • 在 SQL 代码中重新定义了流 – 在创建流和与流关联的数据泵后，不能在代码中重新定义相同的流。有关创建流的更多信息，请参阅 Amazon Kinesis Data Analytics SQL 参考中的 CREATE STREAM。有关创建数据泵的更多信息，请参阅 CREATE PUMP。

  • GROUP BY 子句使用多个 ROWTIME 列 - 您只能在 GROUP BY 子句中指定一个 ROWTIME 列。有关更多信息，请参阅 Amazon Kinesis Data Analytics SQL 参考 中的 GROUP BY 和 ROWTIME。

  • 一个或多个数据类型有无效转换 - 在这种情况下，您的代码有无效的隐式转换。例如，您可能在代码中将 timestamp 转换成 bigint。

  • 流的名称与服务预留流名称相同 - 流的名称不能与服务预留流 error_stream 的名称相同。

应用程序正在将错误写入到错误流

如果您的应用程序正在将错误写入到应用程序内部错误流，则可以使用标准库解码 DATA_ROW 字段中的值。有关错误流的更多信息，请参阅错误处理。

吞吐量不足或 MillisBehindLatest 较高

如果应用程序的 MillisBehindLatest 指标稳步增加或始终高于 1000 (1 秒)，这可能是以下原因造成的：

  • 检查应用程序的 InputBytes CloudWatch 指标。如果提取速度超过 4 MB/秒，这可能会导致 MillisBehindLatest 增加。要提高应用程序的吞吐量，请增加 InputParallelism 参数值。有关更多信息，请参阅并行处理输入流以增加吞吐量。

  • 检查应用程序的输出传输 Success 指标以确定传输到目标是否失败。确认您已正确配置输出，并且您的输出流具有足够的容量。

  • 如果您的应用程序使用 AWS Lambda 函数进行预处理或作为输出，请检查应用程序的 InputProcessing.Duration 或 LambdaDelivery.Duration CloudWatch 指标。如果 Lambda 函数调用持续时间超过 5 秒，请考虑执行以下操作：

    • 提高 Lambda 函数的内存分配。您可以在 AWS Lambda 控制台的 Configuration (配置) 页面上的 Basic settings (基本设置) 中执行此操作。有关更多信息，请参阅 https://docs.aws.amazon.com/lambda/latest/dg/resource-model.html 开发人员指南 中的AWS Lambda配置 Lambda 函数。

    • 在应用程序的输入流中提高分片数。这会提高应用程序将调用的并行函数的数量，从而可能提高吞吐量。

    • 确认函数没有进行影响性能的阻止性调用，如同步的外部资源请求。

    • 检查 AWS Lambda 函数以确定是否具有可提高性能的其他方面。查看应用程序 Lambda 函数的 CloudWatch 日志。有关更多信息，请参阅《AWS Lambda 开发人员指南》中的访问适用于 的 Amazon CloudWatch 指标。

  • 确认您的应用程序未达到 Kinesis 处理单元 (KPU) 的默认限制。如果您的应用程序达到该限制，您可以请求提高限制。有关更多信息，请参阅自动扩展应用程序以提高吞吐量。

  • 增加 KPU 限制后，如果您的应用程序仍然存在问题，请检查应用程序的输入吞吐量，确认其是否超过 100 MB/秒。如果超过 100 MB/秒，建议进行更改，降低整体吞吐量，从而稳定应用程序，例如通过减少发送至数据源 (Kinesis Data Analytics SQL 应用程序的读取来源) 的数据量。此外，还可以使用其他方法，包括增加应用程序的并行性、缩短计算时间、将列式数据类型从 VARCHAR 更改为更小的数据类型 (例如 INTEGER、LONG 等)，以及减少通过采样或过滤处理的数据。

    注意

    建议您定期检查应用程序的 InputProcessing.OkBytes 指标，以便您可以规划使用多个 SQL 应用程序，或者如果应用程序的预计输入吞吐量将超过 100 MB/秒，则可以迁移到 managed-flink/latest/java/。