筛选本质还是在线场景，具有一定的并发能力，并发压力主要在于压榨系统IO上，通过合理的中间件使用、严谨的服务调度、针对性场景的差异化设计降低单次筛选的执行时间，提高并发。
2. 实时海量数据分析和传输能力筛选提供了多种分析维度（图2.2.2），支持灵活的语法组合。筛选服务不仅要满足对海量数据的实时查询分析，还要支持对单次可能破亿的结果集做低成本传输。
图2.2.2 筛选支持的字段类型
3. 成本可控一切问题都是成本问题，从行业看全民上云后服务架构的成本问题更是备受关注，尤其在友盟+庞大的业务量下成本问题更加重要。
4. 为下游任务并行发送创造条件友盟+U-Push的发送层集群用于大量的发送节点，最理想的设计就是在任务筛选阶段即完成数据切片、分发、调度，下游直接并行发送以达到最高效率。
U-Push筛选在持续的技术迭代中，和多领域专业团队深度合作，充分利用不同组件的特性，通过整合Tair、AnalyticDB for MySQL(ADS)、OSS、MaxCompute(ODPS)、Lindorm、HBase、SchedulerX等产出了一套兼顾稳定、性能、和成本的均衡解决方案。
筛选分为离线和实时两部分，离线通过ODPS生成设备主库快照，导入ADS。实时通过消费数据上行服务的设备信息更新事件，实时更新ADS或者RDB库。在执行筛选时候，对于较大结果集通过upload或者dump到OSS的方式输出多个小文件，传输给发送链路下游执行并行发送。
图2.2.4 筛选服务数据流向
上述业务链路和数据结构介绍了筛选目前的整体设计，但是要应付复杂的客情和多变的业务场景还需要做更多细节设计。
3. 设计细节 3.1 筛选库的场景设计从上面的概览可以看出，筛选架构中的主要矛盾就是消息下行链路中海量数据的读和上行链路中设备属性更新的高频写的矛盾，解决这个矛盾需要大量的资源来保证数据一致性和性能，在常规的设计思路中在目前的成本资源下几乎是不可行。大数据三大宝，冷热分离分库分表，通过业务分析调研，U-Push将业务分成若干场景，基于客户的不同生命周期的业务诉求和服务能力将客户指向不同场景，尽量优化客户体验。
图3.1.1 筛选库的场景设计