经过仔细考虑，我们决定停用适用于 SQL 应用程序的 Amazon Kinesis Data Analytics：

1. 从 **2025年9月1日起，**我们将不再为适用于SQL应用程序的Amazon Kinesis Data Analytics Data Analytics提供任何错误修复，因为鉴于即将停产，我们对其的支持将有限。

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

3. 从 **2026 年 1 月 27 日**起，我们将删除您的应用程序。您将无法启动或操作 Amazon Kinesis Data Analytics for SQL 应用程序。从那时起，将不再提供对 Amazon Kinesis Data Analytics for SQL 的支持。有关更多信息，请参阅 [Amazon Kinesis Data Analytics for SQL 应用程序停用](discontinuation.md)。

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

# Amazon Kinesis Data Analytics·for·SQL 应用程序故障排除
<a name="troubleshooting"></a>

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

**Topics**
+ [已关停的应用程序](#idle-applications)
+ [无法运行 SQL 代码](#sql-statement)
+ [无法检测到或发现我的架构](#detect-schema)
+ [引用数据已过时](#reference-reload)
+ [应用程序不写入到目标](#output)
+ [要监控的重要应用程序运行状况参数](#parameters)
+ [在运行应用程序时出现无效代码错误](#invalid-code)
+ [应用程序正在将错误写入到错误流](#error-stream)
+ [吞吐量不足或过高 MillisBehindLatest](#insufficient-throughput)

## 已关停的应用程序
<a name="idle-applications"></a>
+ **什么是已关停的 Kinesis Data Analytics for SQL 应用程序？**

  已关停的应用程序是至少三个月未处理任何记录的应用程序。这意味着，即使客户没有使用 Kinesis Data Analytics for SQL 资源，但仍在为其支付费用。
+ **何时 Amazon 开始停止闲置的应用程序？**

  Amazon 将于 2023 年 11 月 14 日开始停止闲置的应用程序，并于 2023 年 11 月 21 日之前完成。我们将在所在区域的工作时间段关停空闲的应用程序。
+ **是否可以重新启动已停止的 Kinesis Data Analytics for SQL 应用程序？**

  是。您可以在需要时照常重新启动应用程序。无需创建支持票证。
+ **当空闲应用程序 Amazon 停止时，我的任何查询结果也会被删除吗？**

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

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

## 无法运行 SQL 代码
<a name="sql-statement"></a>

如果需要了解如何使特定 SQL 语句正常工作，可以在使用 Kinesis Data Analytics 时利用几个不同的资源：
+ 有关 SQL 语句的更多信息，请参阅[Kinesis Data Analytics for SQL 示例](examples.md)。此部分提供了一些可使用的 SQL 示例。
+ *[Amazon Kinesis Data Analytics SQL 参考](https://docs.amazonaws.cn/kinesisanalytics/latest/sqlref/sqlrf_Preface.html)*提供了编写流式 SQL 语句的详细指南。
+ 如果仍遇到问题，我们建议您在 [Kinesis Data Analytics 论坛](https://forums.aws.csdn.net/ann.jspa?annID=4153)上提问。

## 无法检测到或发现我的架构
<a name="detect-schema"></a>

在某些情况下，Kinesis Data Analytics 无法检测或发现架构。在很多此类情况下，您仍然可以使用 Kinesis Data Analytics。

假设您具有不使用分隔符的 UTF-8 编码数据，或具有使用非逗号分隔值 (CSV) 格式的数据，或发现 API 未发现您的架构。在这些情况下，可以手动定义架构或使用字符串操作函数来构建数据。

为了发现您的数据流的架构，Kinesis Data Analytics 会随机对流中的最新数据进行采样。如果您无法始终如一地向您的流发送数据，Kinesis Data Analytics 可能无法检索样本和检测架构。有关更多信息，请参阅 [针对流数据使用架构发现功能](sch-dis.md)。

## 引用数据已过时
<a name="reference-reload"></a>

在启动或更新应用程序时或在服务问题导致的应用程序中断期间，引用数据将从 Amazon Simple Storage Service (Amazon S3) 对象加载到应用程序中。

在更新基础 Amazon S3 对象时，不会将引用数据加载到应用程序中。

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

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

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

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

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

## 应用程序不写入到目标
<a name="output"></a>

如果数据未被写入到目标，请检查以下各项：
+ 验证应用程序的角色具有足够权限来访问目标。有关更多信息，请参阅 [写入到 Kinesis 流的权限策略](iam-role.md#iam-role-permissions-policy-ak-stream)或 [写入到 Firehose 传输流的权限策略](iam-role.md#iam-role-permissions-policy-af-delivery-stream)。
+ 验证是否已正确配置应用程序目标，并且应用程序正在使用正确的输出流名称。
+ 检查输出流的 Amazon CloudWatch 指标，看看是否正在写入数据。有关使用 CloudWatch 指标的信息，请参阅[使用 Amazon 进行监控 CloudWatch](monitoring-cloudwatch.md)。
+ 使用添加 CloudWatch 日志流[AddApplicationCloudWatchLoggingOption](API_AddApplicationCloudWatchLoggingOption.md)。您的应用程序将配置错误写入日志流。

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

## 要监控的重要应用程序运行状况参数
<a name="parameters"></a>

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

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

通常，您应该设置一个 CloudWatch 警报，以便在您落后超过一小时时触发。但是，时间量取决于您的使用案例。您可以按需进行调整。

有关更多信息，请参阅 [最佳实践](best-practices.md)。

## 在运行应用程序时出现无效代码错误
<a name="invalid-code"></a>

如果无法保存和运行 Amazon Kinesis Data Analytics 应用程序的 SQL 代码，常见原因如下：
+ **在 SQL 代码中重新定义了流** – 在创建流和与流关联的数据泵后，不能在代码中重新定义相同的流。有关创建流的更多信息，请参阅 *Amazon Kinesis Data Analytics SQL 参考*中的 [CREATE STREAM](https://docs.amazonaws.cn/kinesisanalytics/latest/sqlref/sql-reference-create-stream.html)。有关创建数据泵的更多信息，请参阅 [CREATE PUMP](https://docs.amazonaws.cn/kinesisanalytics/latest/sqlref/sql-reference-create-pump.html)。
+ **GROUP BY 子句使用多个 ROWTIME 列** - 您只能在 GROUP BY 子句中指定一个 ROWTIME 列。有关更多信息，请参阅 *Amazon Kinesis Data Analytics SQL 参考* 中的 [GROUP BY](https://docs.amazonaws.cn/kinesisanalytics/latest/sqlref/sql-reference-group-by-clause.html) 和 [ROWTIME](https://docs.amazonaws.cn/kinesisanalytics/latest/sqlref/sql-reference-rowtime.html)。
+ **一个或多个数据类型有无效转换** - 在这种情况下，您的代码有无效的隐式转换。例如，您可能在代码中将 `timestamp` 转换成 `bigint`。
+ **流的名称与服务预留流名称相同** - 流的名称不能与服务预留流 `error_stream` 的名称相同。

## 应用程序正在将错误写入到错误流
<a name="error-stream"></a>

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

## 吞吐量不足或过高 MillisBehindLatest
<a name="insufficient-throughput"></a>

如果您的应用程序的[MillisBehindLatest](https://docs.amazonaws.cn/AmazonCloudWatch/latest/monitoring/aka-metricscollected.html)指标稳步增长或持续高于 1000（一秒），则可能是由于以下原因造成的：
+ 检查您的应用程序的[InputBytes](https://docs.amazonaws.cn/AmazonCloudWatch/latest/monitoring/aka-metricscollected.html) CloudWatch 指标。如果提取速度超过 4 MB/秒，这可能会导致 `MillisBehindLatest` 增加。要提高应用程序的吞吐量，请增加 `InputParallelism` 参数值。有关更多信息，请参阅 [并行处理输入流以增加吞吐量](input-parallelism.md)。
+ 检查应用程序的输出传输 [Success](https://docs.amazonaws.cn/AmazonCloudWatch/latest/monitoring/aka-metricscollected.html) 指标以确定传输到目标是否失败。确认您已正确配置输出，并且您的输出流具有足够的容量。
+ 如果您的应用程序使用 Amazon Lambda 函数进行预处理或作为输出，请检查应用程序的 .Duration 或 [InputProcessingLambdaDelivery.Durati](https://docs.amazonaws.cn/AmazonCloudWatch/latest/monitoring/aka-metricscollected.html) [on 指标。](https://docs.amazonaws.cn/AmazonCloudWatch/latest/monitoring/aka-metricscollected.html) CloudWatch 如果 Lambda 函数调用持续时间超过 5 秒，请考虑执行以下操作：
  + 提高 Lambda 函数的**内存**分配。您可以在 Amazon Lambda 控制台的 **Configuration (配置)** 页面上的 **Basic settings (基本设置)** 中执行此操作。有关更多信息，请参阅 [https://docs.amazonaws.cn/lambda/latest/dg/resource-model.html](https://docs.amazonaws.cn/lambda/latest/dg/resource-model.html) 开发人员指南* 中的Amazon Lambda 配置 Lambda 函数*。
  + 在应用程序的输入流中提高分片数。这会提高应用程序将调用的并行函数的数量，从而可能提高吞吐量。
  + 确认函数没有进行影响性能的阻止性调用，如同步的外部资源请求。
  + 检查您的 Amazon Lambda 函数，看看是否还有其他方面可以提高性能。检查应用程序 Lambda 函数的 CloudWatch 日志。有关更多信息，请参阅《*Amazon Lambda 开发者指南》*中的 “[访问亚马逊 CloudWatch 指标](https://docs.amazonaws.cn/lambda/latest/dg/monitoring-functions-access-metrics.html)”。
+ 确认您的应用程序未达到 Kinesis 处理单元 (KPU) 的默认限制。如果您的应用程序达到该限制，您可以请求提高限制。有关更多信息，请参阅 [自动扩展应用程序以提高吞吐量](how-it-works-autoscaling.md)。
+ 如果您的应用程序在 KPU 限制提高后仍然存在问题，请检查您的应用程序的输入吞吐量是否不超过 100MB/sec. If it exceeds 100MB/sec，我们建议您进行更改以降低总体吞吐量以稳定应用程序，例如通过减少发送到 Kinesis Data Analytics Sql 应用程序读取的数据源的数据量。此外，还可以使用其他方法，包括增加应用程序的并行性、缩短计算时间、将列式数据类型从 VARCHAR 更改为更小的数据类型 (例如 INTEGER、LONG 等)，以及减少通过采样或过滤处理的数据。
**注意**  
我们建议您定期查看应用程序的`InputProcessing.OkBytes`指标，以便您可以提前计划使用多个 SQL 应用程序或迁移到托管-flink/latest/java/ if your application’s projected input throughput will exceed 100 MB/sec。