Serverless 架构下的高并发分析查询最佳实践与解决方案

业务背景与技术需求

在现今互联网行业中，很多最终用户对数据的访问需求不断增加，比如游戏玩家通常需要联系客户服务以获取详细的游戏信息，包括战斗记录、充值历史和礼包领取状况。这些查询不仅涉及玩家的个人游戏体验，也关系到账户安全，这类客户服务查询的场景包括：

战斗记录查询：玩家可能需要回顾特定比赛的细节，用于分析策略或解决争议。客户服务需要快速访问并提供准确的战斗数据，包括参与者、时间、比分和关键事件。
充值记录验证：为确保交易的透明度和准确性，玩家经常需要验证自己的充值历史。客户服务必须能够快速调取完整的充值记录，包括金额、时间和支付方式，以解决可能出现的账单问题。
礼包获得记录查看：玩家可能会询问过去获得的礼包内容或领取时间。客户服务需要访问详细的礼包发放记录，以帮助玩家了解其账户的奖励历史。
账户异常处理：当玩家遇到账户异常，如物品丢失或账号被盗时，客户服务需要全面查看玩家的游戏数据，包括登录记录和物品变动历史等，以快速定位和解决问题。

这些查询既可以通过联系客户服务完成，玩家也可以在游戏内直接进行，而游戏内的直接查询功能也必须高效可靠。无论是通过客户服务还是游戏内查询，系统都面临着大量并发请求的挑战。在高峰时段，可能有成千上万的玩家同时查询自己的游戏数据。因此，数据查询平台必须具备强大的并发处理能力和快速的数据返回速度。

另外，比如在广告行业中，需要对广告的点击情况进行归因分析，了解客户的广告点击情况，统计投放效果，并对广告过程中涉及的媒体进行费用结算。在营销行业中，需要对应用的客户点击情况进行追踪，分析客户行为，提高留存率和转化率，为营销活动提供洞察数据。其它类似业务场景还包括：

电商平台
- 高并发点查：用户查询商品详情、库存等
- OLAP 分析：分析用户购买行为、销售数据,以优化商品推荐、定价策略等
在线旅游预订
- 高并发点查：查询机票、酒店房间的实时库存和价格
- OLAP 分析：分析用户预订习惯、航班载客率等，用于产品优化和营销策略
金融证券
- 高并发点查：查询实时行情、交易记录等
- OLAP 分析：分析市场趋势、投资组合表现等，支持投资决策
社交网络
- 高并发点查：查看用户个人主页、好友动态等
- OLAP 分析：分析用户行为习惯、内容传播路径等，用于广告投放、内容推荐
物联网监控
- 高并发点查：查询设备实时状态
- OLAP 分析：分析设备运行数据，预测故障、优化能耗等

要实现上述业务需求，设计系统架构时需要考虑：

实时数据加载与数据摄入能力
高并发读写系统和 OLAP 分析系统有机结合
实时统计数据，以及批处理报表查询
动态自动伸缩扩展，每天不同时段的请求量变化明显，需要跟上请求量变化速度，同时尽可能降低成本
简单易用、易于运维、快速部署

基于 Serverless 的技术方案与架构

方案一：SDK → S3 + auto copy + 多 Serverless Workgroup 架构

Amazon Redshift 推出自动复制，用于简化将数据从 Amazon S3 加载到 Amazon Redshift Serverless 的过程。你可以设置连续文件提取规则，以跟踪 Amazon S3 路径并自动加载文件，而无需其他工具或自定义解决方案。

Amazon Redshift Serverless 客户运行 COPY 语句，从各种数据来源（包括 Amazon S3）将数据加载到其本地表中。你可以将 COPY 语句存储到 COPY 作业中，这将自动加载在指定的 Amazon S3 路径中检测到的新文件。COPY 作业跟踪以前加载的文件并将其从摄取过程中排队。可使用系统表对它们的活动进行监控。还可以手动执行 COPY 作业，以便在不需要自动加载时，重用 COPY 语句并防止数据重复。

架构图

主要步骤

创建一个预览版的 Amazon Redshift Serverless 端点。
在新创建的 Amazon Redshift Serverless 中创建相关的表。
自动摄取指定 Amazon S3 路径的下的文件。

COPY XXX
FROM 's3://..../'
IAM_ROLE 'arn:aws:iam::...'
gzip delimiter '|' EMPTYASNULL
region 'us-east-1'
JOB CREATE xxx AUTO ON;

优势：将高吞吐数据摄入的 COPY 命令扩展为事件驱动，适合大吞吐量数据按时间驱动来摄入，降低了批量数据摄入的时延，同时还简化了数据管道。

方案二：MSK/KDS + Streaming Ingestion（可选）+ NLB + 多 Serverless Workgroup 架构

为了满足高并发性、使用量激增和快速查询响应时间等苛刻的性能需求，同时优化成本，本文建议使用 Redshift Serverless。建议的解决方案旨在满足三个关键性能要求：

通过在网络负载均衡后面使用多个 Redshift Serverless 端点来支持数千个高可用性的并发连接
能过可扩展和分布式工作组，以低延迟服务级别协议容纳数百个并发查询
使用 Amazon Redshift 的快速查询处理功能，实现针对大型数据集的短查询的亚秒级响应时间

建议的架构使用通过单个网络负载均衡器客户端点访问的多个 Redshift Serverless 端点。网络负载均衡器在工作组之间均匀分配传入请求。通过扩展资源来满足高吞吐量和低延迟需求，这可以提高性能并减少延迟。

架构图

下图概述了 Redshift Serverless 架构，该架构在网络负载均衡器后面有多个 Amazon Redshift 管理的 VPC 终端节点。

主要步骤

创建 Amazon Kinesis Data Streams 到 Amazon Redshift Serverless 的流式摄取。
创建 Amazon Redshift data sharing，将 Producer Amazon Redshift Serverless 中的数据分享给其它一个或者多个 Consumer Amazon Redshift Serverless。
创建 Amazon Redshift 托管 VPC 终端节点。

完成以下步骤以创建 Amazon Redshift 托管 VPC 终端节点：

在 Redshift Serverless 控制台，导航栏选择工作组配置。
从列表中选择一个工作组。
在数据访问标签，在Redshift 托管的 VPC 端点，选择创建端点。
输入端点名称。创建一个对你组织有意义的名称。
填写 AWS 账户 ID。这是你的一个12位的账户ID。
选择将在其中创建终端节点的VPC。
选择子网 ID。在最常见的用例中，这是一个子网，你希望在其中连接到 Redshift Serverless 实例的客户端。
选择要添加的 VPC 安全组。每个安全组充当虚拟防火墙，控制受安全组保护的资源（例如特定虚拟桌面实例）的入站和出站流量。

以下屏幕截图显示了该工作组的示例。记下创建目标组期间要使用的 IP 地址。

重复这些步骤以创建所有 Redshift Serverless 工作组。

为网络负载均衡的目标组添加 VPC 终端节点

要使用 Amazon Elastic Compute Cloud (Amazon EC2)将这些 VPC 终端节点添加到网络负载均衡器的目标组，请完成以下步骤：

在 Amazon EC2 控制台上，选择导航栏中负载均衡下的目标组。
选择创建目标组。
对于选择目标类型，选择实例以按实例 ID 注册目标，或选择 IP 地址以按 IP 地址注册目标。
对于目标组名称，输入目标组名称。
对于协议，选择 TCP 或 TCP_UDP。
对于端口，请使用 5439 （Amazon Redshift 端口）。
对于 IP 地址类型，选择 IPv4 或 IPv6。仅当目标类型为实例或 IP 地址并且协议为 TCP 或 TLS 时，此选项才可用。
你必须将 IPv6 目标组与双栈负载均衡器关联。目标组中的所有目标必须具有相同的 IP 地址类型。创建目标组后，你无法更改其 IP 地址类型。
对于 VPC，选择具有要注册目标的 VPC。
保留运行状况检查部分、属性部分和标签部分的默认选择。

以下屏幕截图显示了该目标组的示例。

创建负载均衡器

创建目标组后，你可以创建负载均衡器。我们建议使用端口 5439 (Amazon Redshift 默认端口）。

网络负载均衡器充当单访问终端节点，将用于到达 Amazon Redshift 的连接。这允许你添加更多 Redshift Serverless 工作组并透明地增加并发性。

性能测试 （baseRPU=8, 单表1000亿条 / 40TB)

RPU / TPS	100并发	200并发	300并发	400并发	500并发
1个workgroup(MaxRPU=24)	113	83	99	99	119
NLB+3个workgroup(MaxRPU=8)	174	177	166	180	168

如上图性能测试结果，在 NLB on 3 个Redshift Serverless Workgroup（baseRPU=8）情况下，面向单表 1000亿条数据（40T）的聚合查询，TPS 有显著的提升，延迟有显著的下降。

优势：适合高并发数据分析的场景，跟 Redshift 自带的并发扩展相比，消除了集群扩缩的时间，提升了用户体验。

方案三：Flink + DDB (streaming) + KDS + Streaming Ingestion + Redshift Serverless架构

此架构中，点击流数据，包括 SDK 发送的广告点击和应用行为数据，发送到云上。服务器接收并处理请求，日志信息发送至批处理，实时数据通过Flink计算，数据落到 DynamoDB 数据库。此时除了数据快速写入之外，还可提供快速数据点查能力，参考架构和类似 SQL 如下：

    SELECT
      *
    FROM
      adtable
    WHERE
      (app_id = 'apple')
      and ((oaid = '123456789))
      and (
        receive_ts >= '2024-06-12 18:33:35’
        and receive_ts <= '2024-06-19 18:33:35’
      )

DynamoDB 适合此类快速点查和范围查询。对于复杂的 JOIN 查询，或者聚合查询，可以在专门的数据仓库 Redshift 进行。DynamoDB 提供了实时处理的管道，写入的变化数据打入 Kinesis 消息管道，通过 Kinesis Ingestion 写入 Redshift 物化视图，并可以自动更新，提供复杂查询的能力。

根据业务设计表结构，主键作为业务的核心构成，包含分区键和排序键。分区键要求尽量分散，避免热点数据。如果用户很多，并且大多分布均匀，可以用 account_id 作为分区键。排序键按照顺序存储和读取数据，特别适合时间这类有序数据。指定分区键和排序键某个范围，就可以对数据点查或者指定数据的范围查询。

以下是使用示例：

Dynamodb: on-demand 按需模式

Partition key: account_id(Number), Sort Key: click_time(Number)

写入测试数据，230 亿行，约 11.2TB。写入数据期间，最高一直保持 1300 左右 WCU，写入延迟稳定在 3ms。初始表写入压力打上去时，触发自动扩容，此期间有部分请求限流，分区完成后此现象消失。

部分数据示例如下：

根据业务需求查询数据。例如，查询某个用户在某个时间段的点击行为，并且是特定 IP，客户端包含 Android。此查询中，按照分区键 account_id 和排序键 click_time 时间范围，在此结果中进一步过滤，以 IP 和客户端 ua 作为过滤条件，即可获得所需的数据。

再发起一些并发查询测试，查看 Dynamodb 性能指标，10000 并发请求下，RCU 读取容量消耗 620，Query 查询延迟为 5ms。

以上测试可以看出，Dynamodb 在几十 TB 的大容量数据情况下，无论请求量多大，仍然能保持一致的高性能。写延迟 10ms 以内，查询延迟也在几十 ms 左右。可以满足海量数据的点查需求。

接着测试 DynamoDB 写入变化写到 Kinesis 消息队列，并且写入 Redshift 数据仓库。

DynamoDB 打开 Kinesis Data Stream，写入数据。

Kinesis console：可显示解码后的数据

在 Redshift 创建外部 schema，指向 Kinesis Data Stream。这里需要事先创建 IAM Role，授权可以访问 Kinesis。

CREATE EXTERNAL SCHEMA kds
FROM KINESIS
IAM_ROLE 'arn:aws:iam::XXXXX:role/service-role/AmazonRedshift-CommandsAccessRole-20230702T123228';

创建 Redshift 物化视图，从 Kinesis Data Stream 获取数据并自动更新。请注意：使用 SELECT *的默认查询，不能直接显示数据。应该使用分析 JSON_PARSE 函数，以转换 Kinesis JSON 数据到 Redshift 可读数据。

CREATE MATERIALIZED VIEW my_view1 AUTO REFRESH YES AS
SELECT approximate_arrival_timestamp,
partition_key,
shard_id,
sequence_number,
refresh_time,
JSON_PARSE(kinesis_data) as kinesis_data
FROM kds.dynamodb
WHERE CAN_JSON_PARSE(kinesis_data);

查询物化视图

select * from my_view1;

2024-08-07 05:52:11.449 61EF4BAXXXXXXX532258583 shardId-0XXXXXXXXXXXXX02 49653XXXXXXXXXXXXX459997598479852468837496605135339554 2024-08-07 08:24:42 {“awsRegion”:”us-east-1″,”eventID”:”ae3XXXXXXXXXX2-8b96c7aXXXff”,”eventName”:”INSERT”,”userIdentity”:null,”recordFormat”:”application/json”,”tableName”:”adXXXo”,”dynamodb”:{“ApproximateCreationDateTime”:17XXXXXX28,”Keys”:{“account_id”:{“S”:”5XXXXXXXXX6″},”click_time”:{“N”:”1XXXXXXX538″}},”NewImage”:{“creative_name”:{“S”:”m9rWXXXXXXXXXXXXXXz5MSrXTmRW”},”noredirect”:{“S”:”true”},”ad_type”:{“S”:”3″},”caid”:{“S”:”[{\”qaid\”:\”rLLOXXXXXXXXXXXXXHSbIsT2w5w\”,\”hash_qaid\”:\”V7IXXXXXXXXXXXXXXXB2ZQ9lG99u\”,\”version\”:1743},{\”qaid\”:\”OpzZqil9DkXXXXXXXXXXX2kvx\”,\”hash_qaid\”:\”U0qwXXXXXXXXXXXXXuIRlYlAC5fr\”,\”version\”:1242}]”},”callback”:{“S”:”http://tracking.example.com/conv?cb=KI9yfjXXXXXXXXXXXXXXXUNECK7yZURJbnyE&conv_id=461XXXX1″},”creative_components_info”:{“S”:”[{\”id\”:92XXXX679,\”type\”:\”DESCRIPTION\”},{\”id\”:30XXXXX314,\”type\”:\”VIDEO\”},{\”id\”:9XXXXX3292,\”type\”:\”ACTION_BUTTON\”},{\”id\”:57XXXXXXXX3,\”type\”:\”BRAND\”},{\”id\”:7XXXXXXX96,\”type\”:\”BRAND\”},{\”id\”:77XXXXX75,\”type\”:\”BRAND\”}]”},”marketing_asset_id”:{“S”:”5XXXX37″},”ua”:{“S”:”Mozilla/5.0 (Android; CPU Android 13_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 MicroMessenger/8.0.84(0xXXXXQxqw) NetType/3G Language/en_US”},”channel”:{“S”:”tXXXXXXMQ8pfsw”},”csite”:{“S”:”SXXXX_SET_cXXXop”},”csite_id”:{“S”:”26″},”subpublisher_name”:{“S”:”jMXXXXXXXX7ZZNyxregTbd88cZVWNiB0DZuVXY1f”},”creative_id”:{“S”:”AXXXXX5mZ”},”encrypted_position_id”:{“S”:”8kAsXXXXXVW02qDEQG”},”promoted_object_type”:{“S”:”28″},”os”:{“S”:”ios”},”ip”:{“S”:”1XXXX.XX.184″},”account_id”:{“S”:”594XXXX6″},”ad_platform_type”:{“S”:”5″},”bi_os”:{“S”:”Android”},”app_id”:{“S”:”dd.XXXXod”},”material_package_id”:{“S”:”631XXXX39″},”agency_id”:{“S”:”961XXXX8″},”click_time”:{“N”:”168XXXX38″},”idfa_md5″:{“S”:”GGjDsXXXXXXCQoTDTUmQnwkuoU4IQe”},”click_id”:{“S”:”wxXXXXXXW2oqNtIzWGCC”},”promoted_object_id”:{“S”:”118XXXX20″},”subpublisher_id”:{“S”:”377XXXX62″}},”SizeBytes”:1317,”ApproximateCreationDateTimePrecision”:”MICROSECOND”},”eventSource”:”aws:dynamodb”}

当 DynamoDB 有更新写入时，变化会写入 Kinesis，并通过 ingestion 更新到 Redshift 物化视图。此过程是自动的，并且时间很短。

以下信息可以看到，approximate_arrival_timestamp 表示写入 Kinesis 的时间，refresh_time 表示 Redshift 刷新时间，此测试中可以达到秒级。实际时间受数据库写入速率，Kinesis 生产和消费等因素影响。

方案四（preview）：DDB + Zero ETL + RS Serverless- 架构

Amazon DynamoDB 与 Amazon Redshift Serverless 的 zero-ETL 集成使客户能够对其 DynamoDB 数据运行高性能分析，并且不会影响 DynamoDB 上运行的生产工作负载。数据写入 Amazon DynamoDB 表后，即可在 Amazon Redshift Serverless 中无缝使用，从而让客户无需构建和维护复杂的数据管道即可执行提取、转换、加载（ETL）操作。Amazon DynamoDB 与 Amazon Redshift 的 zero-ETL 集成可以帮助你全面了解许多应用程序的情况、打破组织中的数据孤岛、大幅降低成本并提高运营效率。现在，你可以利用 Amazon Redshift Serverless 丰富的功能来增强 DynamoDB 数据分析，例如高性能 SQL、内置机器学习和 Spark 集成、物化视图、数据共享以及合并多个数据存储和数据湖中的数据的能力。

架构图

主要步骤

创建 Amazon DynamoDB 并引入示例数据集。详情请见
创建 Amazon Redshift Serverless（Preview 版本）。详情请见
创建 Amazon DynamoDB 到 Amazon Redshift Serverless 的 zero-ETL 集成。
- 在 Amazon DynamoDB 中创建一张表，并启用 Point-in-time 恢复。
- 在 Amazon Dynamodb 控制台，导航栏选择集成，并选择创建 zero-ETL 集成。
- 对于输入集成 id，输入集成 id。对于目标，从列表中选择一个工作组，以创建 zero-ETL 集成。
- 在 Amazon Redshift 控制台，在导航栏 Zero-ETL 集成，选择从集成创建数据库，并输入数据库名称。

优势：极大地降低了数据摄入的时延，同时还简化了数据管道。

方案五：MSK + Streaming ingestion + Redshift + Glue + DDB or MySQL

架构图

下图是一个经典的 Lambda 架构，该架构同时满足了客户对于实时与离线双重计算需求。该 Lambda 架构中与众不同的一点就是大量的使用了 Serverless 服务，大大降低了客户运维的难度从而降低了 TCO，同时提升了服务随着业务量变化而扩缩的能力从而提高了性价比。

部署步骤

创建 Amazon Managed Streaming for Apache Kafka 和 Amazon Kinesis Data Streams 到 Amazon Redshift Serverless 的流式摄入，将数据实时写入 Amazon Redshift Serverless 中。联合从 Amazon Database Migration Service 从源头关系型数据库中摄入的数据，为后续基于 dbt 的 ELT 提供数据源。
创建 Amazon Manage Service for Apache Flink 消费 Amazon Kinesis Data Streams 数据，完成 Lambda 架构中实时部分。详情请见
以 Amazon Redshift Serverless 提供的数据存储与计算能力，构建基于 dbt 的 DataOps 环境。详情请见
基于 Amazon Glue 的可视化 ETL能力，在可视化控制台上进行拖拽，将 Amazon Redshift Serverless 中的集市层数据按需要输出到前端运营数据库。详情请见

总结

本文主要介绍了在基于亚马逊云科技的一系列 Serverless 托管服务下快速构建的最佳实践和多套解决方案，可以满足不同业务场景下的高并发、低延迟的分析查询需求，同时易于运维与构建。

方案	适用场景	数据同步/摄入延迟	查询并发支持	复杂数据转换
方案一： SDK → S3 + auto copy + 多Serverless Workgroup架构	埋点数据分析，IoT数据分析	分钟级别	较高	数据入仓后通过SQL完成转换
方案二： MSK/KDS + Streaming Ingestion(可选) + NLB + 多Serverless Workgroup架构	风控、欺诈、IoT等需要实时分析的数据	秒级别	较高	数据入仓后通过SQL完成转换
方案三： Flink + DDB (streaming) + KDS + Streaming Ingestion + Redshift Serverless架构	实时监控、用户查询	秒级别	高（点查可在DDB完成）	轻量级数据清洗可在Flink中完成
方案四(preview)： DDB + Zero ETL + RS Serverless架构	交易数据、订单数据实时分析	秒级别	高（点查可在DDB完成）	数据入仓后通过SQL完成转换
方案五： MSK + Streaming ingestion + Redshift + Glue + DDB or MySQL	埋点、业务日志与最终用户查询	分钟级别	高（点查可在DDB or MySQL完成）	聚合转换可在Glue(Spark)中完成

亚马逊AWS官方博客

Serverless 架构下的高并发分析查询最佳实践与解决方案

业务背景与技术需求

相关服务与技术说明

基于 Serverless 的技术方案与架构

方案一：SDK → S3 + auto copy + 多 Serverless Workgroup 架构

方案二：MSK/KDS + Streaming Ingestion（可选）+ NLB + 多 Serverless Workgroup 架构

方案三：Flink + DDB (streaming) + KDS + Streaming Ingestion + Redshift Serverless架构

方案四（preview）：DDB + Zero ETL + RS Serverless- 架构

方案五：MSK + Streaming ingestion + Redshift + Glue + DDB or MySQL

总结

本篇作者