商家忠诚度平台：AWS OpenSearch、Quicksight与DynamoDB前端分析方案选型

项目背景 #

我负责的商家忠诚度计划平台，核心流程是商家扫描客户二维码完成积分发放/扣除操作。当扫描数据提交至API后，Lambda函数会在DynamoDB中存储三类对象：

• 一条SCAN对象，记录单次扫描的完整信息
• 为执行扫描的员工，累加对应日期对象的scans属性，数据结构示例：

PK                      SK                          QUANTITY
BUSINESS#<business_id>  <who_scanned_id>#DATE#xx/xx/xxxx  123

• 为获得积分的客户，累加对应日期对象的指定属性（如积分总额、累计扫描次数等）

现有三个前端分析展示方案待选，需评估选型或提出更优方案：

1. 商家查看仪表盘时，直接请求AWS OpenSearch
2. 商家查看仪表盘时，展示嵌入的AWS Quicksight图表
3. 商家查看仪表盘时，通过API Gateway + Lambda多次调用DynamoDB，按日期查询并整理数据

方案优劣分析 #

方案1：直接调用AWS OpenSearch #

• 优势：
  • 聚合与搜索能力强，适配多维度分析需求（如按员工、日期、客户群体筛选统计）
  • 查询响应快，OpenSearch针对检索和聚合做了专项优化，性能优于直接查询DynamoDB
  • 可通过DynamoDB Streams + Lambda实现数据实时同步，避免DynamoDB的查询压力
• 劣势：
  • 需额外维护OpenSearch集群，增加运维成本与学习成本
  • 前端需集成OpenSearch SDK并处理认证逻辑，复杂度较高

方案2：嵌入AWS Quicksight图表 #

• 优势：
  • 无需自研分析前端，Quicksight提供现成可视化组件与报表模板，快速搭建仪表盘
  • 支持多数据源（直接对接DynamoDB或OpenSearch），自动处理数据聚合与可视化
  • 内置完善的权限体系，可基于商家ID实现数据隔离
• 劣势：
  • 嵌入自有前端需处理Quicksight的认证流程，有一定复杂度
  • 定制化能力有限，无法满足高度自定义的交互需求
  • 按使用量计费，商家数量或查询频率较高时成本上升明显

方案3：API Gateway + Lambda + DynamoDB直接查询 #

• 优势：
  • 技术栈与现有架构统一，无需引入新服务，上手成本低
  • 数据处理与前端展示逻辑可完全自定义，灵活性最高
• 劣势：
  • 性能瓶颈突出，多次调用DynamoDB会增加延迟，尤其在大时间范围、大数据量场景下
  • 聚合逻辑需在Lambda中实现，代码复杂度高，维护成本大
  • DynamoDB原生查询能力有限，不支持复杂多维度聚合分析

选型建议 #

优先推荐：方案2（AWS Quicksight嵌入） #

如果商家的分析需求以标准报表、可视化图表为主（如每日扫描量统计、客户积分趋势、员工业绩排行），Quicksight是性价比最高的选择：

• 利用其多数据源能力，直接对接DynamoDB或同步至OpenSearch的聚合数据
• 通过嵌入式功能将报表集成到自有平台，同时借助内置权限体系确保商家数据隔离
• 少量定制交互需求可通过Quicksight API配合自有前端逻辑实现

备选方案：方案1 + 后端接口封装 #

若商家需要高度定制的分析交互或复杂全文检索需求，可选择OpenSearch作为分析数据源：

• 通过DynamoDB Streams实时同步数据至OpenSearch，保证数据一致性
• 在后端用API Gateway + Lambda封装OpenSearch查询接口，前端仅调用封装后的接口，避免暴露OpenSearch认证信息
• 前端基于接口返回的聚合数据实现自定义可视化组件

不推荐：方案3 #

除非商家的分析需求极简单（如仅查询单日扫描次数），否则不建议直接多次调用DynamoDB，会带来严重的性能与维护问题

内容的提问来源于stack exchange，提问作者alexareintrebari