请说明在 Apache Storm 中通过自定义任务调度器（Custom Scheduler）来优化 Topology 执行效率的具体做法和关键考虑因素。
考察说明
考查对 Storm 调度机制的理解及自定义调度器的落地能力
回答思路
- 【回答框架 1】Storm 默认使用 DefaultScheduler，基于轮询或资源感知将 Executor 分配到 Worker 进程，不考虑数据局部性和通信开销。自定义任务调度器通过实现 IScheduler 接口，重写 schedule 方法，根据 Topology 结构、集群资源、通信模式等自定义分配逻辑，可优化执行效率。
- 【回答框架 2】优化目标通常包括：减少跨 Worker 的网络传输，将与数据流关系密切的 Executor 分配到同一 Worker 或同一主机；平衡各 Worker 负载，避免热点；考虑资源约束如 CPU、内存，合理利用多机资源。
- 【回答框架 3】实现时需通过设置 topology.scheduler 配置指定自定义调度器类，类需继承 IScheduler 并实现 prepare 和 schedule 方法。schedule 方法接收集群状态和待分配 Topology，返回分配映射，可结合集群拓扑、历史监控数据进行决策。
- 【回答框架 4】关键考虑因素包括：调度器的高效性，避免频繁全量重算；容错性，节点故障后的重新调度；与 Storm 其他机制如 rebalance、resource-aware 的兼容性。
- 【回答框架 5】实际效果可通过测试和线上对比评估，关注吞吐、延迟、资源利用率等指标，必要时结合数据本地性对调度算法持续迭代。
- 【关键点 1】自定义调度器需实现 IScheduler 接口，并通过 topology.scheduler 配置生效。
- 【关键点 2】优化重点是减少跨节点通信和均衡负载，核心是合理聚集相关 Executor。
- 【关键点 3】调度决策应考虑资源可用性，并兼容 rebalance、故障转移等机制。
- 【易错点 1】忽略跨 Worker 通信成本，导致局部优化但整体性能下降。
- 【易错点 2】调度器实现过于复杂，本身成为性能瓶颈，应控制计算开销。
- 【易错点 3】未考虑动态负载变化，Static 分配无法适应数据倾斜，需结合监控调整。