45、构建亚马逊销量前十产品仪表盘及架构对比分析

构建亚马逊销量前十产品仪表盘及架构对比分析

1. 数据处理架构相关

在处理大规模数据时，Kappa 架构和 Lambda 架构是两种常见的选择。Kappa 架构在事件流平台（如 Kafka）存储大量数据成本高昂，且扩展性在达到数 PB 后受限，而 HDFS 专为大规模数据设计。Kafka 通过日志压缩实现无限保留，每个消息键只存储最新值，删除早期值以节省存储。对于很少访问的数据，可使用 S3 等对象存储进行长期存储。

架构	描述
Lambda	有单独的批处理和流处理管道，需要不同的集群、代码库和处理框架，各自需要独立的基础设施、监控、日志和支持。批处理管道在处理大量数据时性能更快。但批处理作业中的错误可能需要从头重新处理所有数据。
Kappa	使用单一管道、集群、代码库和处理框架。处理大量数据比 Lambda 架构慢且成本高，但数据一旦摄入就会立即处理，相比按计划运行的批处理作业，可能更快提供数据。流处理作业中的错误只需重新处理受影响的数据点。

对于销量前十产品仪表盘的 Kappa 架构，可按产品 ID 和时间范围聚合每个销售事件，不将销售事件存储在 HDFS 中再进行批处理。由于单台主机无法每天处理 10 亿个事件，需要进行多层聚合。同时，要对错误进行日志记录和监控，当错误率超过临界值时，停止管道（停止 Kafka 消费者消费和处理事件）。

其高层架构如下图所示：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    Sales(销售后端):::process --> Streaming(流处理管道):::process
    Streaming --> Dashboard(仪表盘):::process
    SQL --> Streaming
    SharedLogging(共享日志服务<br/>(如 ELK 或 Kafka)):::process --> Streaming

2. 日志、监控和警报

共享批处理 ETL 平台应与日志、监控和警报系统集成，以便在汇总作业中出现异常长时间运行或任务失败时发出警报。汇总任务写入 HDFS 表，可使用数据质量监控工具检测无效数据点并发出警报。

3. 其他可能的讨论话题

• 数据分区 ：按国家或城市等其他特征对列表进行分区。
• 指标变更 ：若要返回按收入排名的前十产品，需要进行哪些设计更改。
• 趋势跟踪 ：如何跟踪销量和/或收入变化的前十产品。
• 搜索系统 ：设计一个搜索系统，用于查找名称或描述符合特定模式的产品的排名和统计信息。
• 程序化用户 ：考虑程序化用户（如机器学习和实验服务）对前十列表的使用，他们可能会引入新的非功能需求。
• 近似显示 ：仪表盘能否在事件完全统计之前，甚至在事件发生之前显示前十列表的近似值。
• 销售争议 ：销售计数是否应包括正在进行的争议，如退款或换货请求。若退款被批准或拒绝，或发生换货，如何重新统计销售事件。
• 长期保修 ：由于可能提供多年保修，争议可能在销售多年后发生，数据库查询可能需要搜索多年前的销售事件，这可能导致内存不足。
• 产品召回 ：如产品召回等突发事件发生时，是否应调整销售事件的计数。

4. 仪表盘功能扩展

浏览器应用目前仅显示前十列表，可扩展功能需求，如显示销售趋势或预测当前或新产品的未来销售情况。

5. 架构选择总结

当准确的大规模聚合操作耗时过长时，可运行并行流处理管道，使用近似技术以牺牲准确性换取速度，这种并行运行快速但不准确和慢速但准确的管道的方式称为 Lambda 架构。大规模聚合的一个步骤是按后续要聚合的键进行分区，与聚合无关的数据应存储在不同的服务中，以便其他服务使用。检查点是涉及廉价读取操作（如 Redis）和昂贵读取操作（如 HDFS）的分布式事务的一种可能技术。可结合堆和多层水平扩展进行近似大规模聚合操作，Count - min sketch 是一种用于计数的近似技术。在处理大数据流时，可以考虑 Kappa 或 Lambda 架构。

6. 单体架构与微服务架构对比

在软件系统开发中，单体架构和微服务架构是两种不同的选择。微服务架构将软件系统构建为一组松散耦合、独立开发、部署和扩展的服务，而单体架构则作为一个单一单元进行设计、开发和部署。

6.1 单体架构的优势

单体架构	微服务架构
开发初期更快更容易，因为是单一应用。	开发者需要在每个服务中处理序列化和反序列化，处理服务之间的请求和响应。开发前需确定服务边界，且所选边界可能不合适，重新开发服务更改边界通常不切实际。
单个数据库使用较少存储，但有一定权衡。	每个服务应有自己的数据库，可能导致数据重复和更高的存储需求。
单个数据库和较少的数据存储位置，可能更容易遵守数据隐私法规。	数据分散在多个位置，更难确保整个组织遵守数据隐私法规。
调试可能更容易，开发者可使用断点查看任何代码行的函数调用栈，理解该行发生的所有逻辑。	使用 Jaeger 或 Zipkin 等分布式跟踪工具理解请求扇出，但无法提供很多细节，如请求中涉及的服务的函数调用栈。跨服务调试通常比单体架构或单个服务更难。
能轻松在单个位置查看所有代码并跟踪函数调用，使应用/系统整体比微服务架构更易理解。	服务的 API 像黑盒，虽使用时无需了解细节，但可能难以理解系统的许多细节。
运营成本更低，性能更好。所有处理都在单个主机的内存中进行，没有主机之间的数据传输，数据传输速度慢且成本高。	服务系统之间大量的数据传输会产生很高的成本。例如，亚马逊 Prime Video 通过将分布式微服务架构中的大部分（但不是全部）服务合并为单体架构，将系统的基础设施成本降低了 90%。

6.2 单体架构的劣势

• 大多数功能无法有自己的生命周期，难以实践敏捷方法。
• 任何更改都需要重新部署整个应用。
• 包体积大，资源需求高，启动时间长。
• 必须作为单个应用进行扩展。
• 单体架构中任何部分的错误或不稳定都可能导致生产故障。
• 必须使用单一语言开发，无法利用其他语言及其框架的能力来满足各种用例的需求。

6.3 微服务架构的优势

• 敏捷快速开发和扩展 ：满足产品需求的软件设计、实现和部署速度比单体架构快，因为单体架构代码库更大，依赖关系更紧密。开发服务时可专注于一组相关功能和服务接口，通过 HTTP、gRPC 和 GraphQL 等行业标准协议进行通信。基于云的容器原生基础设施使服务开发和部署更快，可根据服务需求选择最佳硬件进行成本高效的扩展。单个服务的更改可独立部署，包体积小，资源需求低，启动时间快。
• 模块化和可替换性 ：服务的独立性使其模块化且易于替换，可实现具有相同接口的新服务替换现有服务。而在单体架构中，开发者协调开发更困难。可根据服务需求选择最合适的技术。
• 故障隔离和容错 ：微服务架构没有单点故障，每个服务可单独监控，能快速定位故障。采用良好容错实践的服务可适应高延迟和依赖服务的不可用性，如缓存其他服务的响应、指数退避和重试等，还可返回合理的错误响应而不是崩溃。可根据服务重要性分配开发和运营资源。
• 明确的所有权和组织结构 ：服务边界明确，将服务所有权映射到团队更直接，有助于集中专业知识和领域知识。但开发者可能不太了解其他服务和整个系统。服务的明确边界允许各种服务架构风格提供 API 定义技术，如 REST 的 OpenAPI、gRPC 的协议缓冲区和 GraphQL 的 Schema 定义语言（SDL）。

6.4 微服务架构的劣势

• 组件重复 ：每个服务都要实现服务间通信和安全，存在大量重复工作。不同团队开发重复组件可能重复犯错，增加开发和维护成本。服务不共享数据库会导致数据重复和更高的存储成本，也使遵守数据隐私法规更复杂和昂贵。
• 组件开发和维护成本 ：需要服务注册表和可能的额外服务进行服务发现。微服务应用有多个部署需要管理，CI/CD 是必需的，涉及容器、容器注册表、容器编排、CI 工具和 CD 工具等。服务请求可能会引发对下游服务的请求，增加网络延迟。可使用缓存缓解，但会引入复杂性，如考虑缓存过期和刷新策略。服务可能需要实现指数退避和重试来处理依赖服务的中断。微服务架构还需要分布式跟踪工具进行监控和故障排除。安装/更新库时，微服务需要在多个服务中进行，若更新有重大更改，开发者需手动更新并处理兼容性问题，增加开发人员的工作量和存储需求。
• 分布式事务 ：服务有单独的数据库，可能需要分布式事务来确保数据库之间的一致性，这会增加成本、复杂性、延迟以及可能的错误和失败。
• 引用完整性 ：引用完整性指关系中数据的准确性和一致性。单体架构的单个数据库可使用外键轻松实现引用完整性，而数据库分布在多个服务中时，引用完整性的实现更复杂。

构建亚马逊销量前十产品仪表盘及架构对比分析

7. 架构对比总结

为了更清晰地对比单体架构和微服务架构，我们将它们的优势和劣势进行总结，如下表所示：
|架构类型|优势|劣势|
| ---- | ---- | ---- |
|单体架构|开发初期快且易；单数据库省存储；易遵守数据隐私法规；调试和理解系统较方便；运营成本低、性能好|功能生命周期受限；更改需全量部署；包大、资源需求高、启动慢；扩展单一；部分故障影响整体；语言选择受限|
|微服务架构|敏捷快速开发和扩展；模块化和可替换；故障隔离和容错；所有权和组织结构明确|组件重复；开发和维护成本高；需处理分布式事务；引用完整性实现复杂|

从这个表格可以看出，两种架构各有优劣，在选择架构时需要根据具体的业务需求、团队能力、项目规模等因素进行综合考虑。

8. 架构选择决策流程

在实际应用中，我们可以通过以下决策流程来选择合适的架构：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(项目启动):::process --> B{项目规模大吗?}:::process
    B -- 是 --> C{业务变化频繁吗?}:::process
    B -- 否 --> D(选择单体架构):::process
    C -- 是 --> E(选择微服务架构):::process
    C -- 否 --> F{对性能和成本要求高吗?}:::process
    F -- 是 --> D
    F -- 否 --> E

这个流程图展示了一个简单的架构选择决策过程：
1. 首先判断项目规模是否大。如果规模小，单体架构通常更合适，因为其开发简单、成本低。
2. 若项目规模大，则进一步判断业务变化是否频繁。业务变化频繁时，微服务架构的敏捷性和可扩展性更能满足需求。
3. 若业务变化不频繁，则考虑对性能和成本的要求。对性能和成本要求高时，单体架构可能更优；否则，微服务架构是更好的选择。

9. 数据处理架构的应用场景

Kappa 架构和 Lambda 架构在不同的数据处理场景中有各自的优势：
- Kappa 架构 ：适用于对数据实时性要求较高的场景，数据一旦摄入就立即处理。例如，实时监控系统、实时数据分析等。在构建销量前十产品仪表盘时，如果需要及时反映销售数据的变化，Kappa 架构是一个不错的选择。但它在处理大量数据时速度较慢且成本较高，需要注意多层聚合和错误监控。
- Lambda 架构 ：当需要准确的大规模聚合操作，但又希望在等待准确结果的同时能有近似结果可用时，Lambda 架构比较合适。它通过并行运行快速但不准确和慢速但准确的管道，平衡了速度和准确性。例如，财务报表生成、长期数据分析等场景。

10. 架构优化建议

无论是选择单体架构还是微服务架构，都可以通过一些优化措施来提高系统的性能和可维护性：
- 单体架构优化 ：
- 代码分层 ：将代码按照功能模块进行分层，如表现层、业务逻辑层、数据访问层等，提高代码的可维护性和可测试性。
- 数据库优化 ：合理设计数据库表结构，使用索引提高查询效率，定期清理无用数据。
- 缓存机制 ：使用缓存（如 Redis）减少数据库访问，提高系统响应速度。
- 微服务架构优化 ：
- 服务拆分 ：根据业务功能合理拆分服务，避免服务过大或过小。
- 负载均衡 ：使用负载均衡器（如 Nginx）将请求均匀分配到多个服务实例上，提高系统的并发处理能力。
- 异步通信 ：采用异步通信方式（如消息队列）减少服务之间的耦合度，提高系统的可靠性和性能。

11. 仪表盘功能扩展实现思路

若要扩展仪表盘的功能，如显示销售趋势或预测未来销售情况，可以采用以下实现思路：
- 数据收集 ：收集更多相关数据，如历史销售数据、市场趋势数据、季节因素等。
- 数据分析 ：使用数据分析算法（如时间序列分析、机器学习算法）对收集到的数据进行分析，提取有价值的信息。
- 可视化展示 ：将分析结果以直观的图表（如折线图、柱状图、预测曲线等）展示在仪表盘上，方便用户查看。

12. 总结

在构建亚马逊销量前十产品仪表盘的过程中，涉及到数据处理架构的选择、日志监控、功能扩展等多个方面。Kappa 架构和 Lambda 架构在数据处理上各有特点，需要根据实际需求进行选择。单体架构和微服务架构也有各自的优势和劣势，决策时要综合考虑项目规模、业务变化频率、性能和成本要求等因素。通过合理的架构选择和优化措施，可以提高系统的性能、可维护性和用户体验。同时，仪表盘功能的扩展可以为用户提供更丰富的信息，满足不同的业务需求。在实际应用中，要不断根据业务发展和技术进步进行调整和优化，以适应不断变化的市场环境。