作者：方块K

每天坐地铁上下班通勤的K哥，经常为过安检而苦恼。每次都要经过“排队 – 卸下背包 – 把背包送进安检台 – 在安检台出口等待– 再次背上背包”这一极其耗时的流程。尤其是在某些站点，居然是分批过安检，比如一批10个人，前面一批通过后，安检人员竟然莫名其妙地强制要求后面排队的乘客等待。当然，这免不了后面赶时间的乘客一片骂声。

现代社会，生活节奏偏快，尤其是在大城市，对于经常赶时间的通勤族来说，安检确实是个不大不小的麻烦。当然，安检的必要性和重要性不言而喻，为大家的乘车安全提供了可靠的保障。但是，能不能在满足安检的基本属性前提下，为大家提供更多的便利呢？

长期通勤的上班族，多为在大城市打拼、奋斗的年轻人，这些人有理想、有抱负，心思都放在工作和事业上。对于这一群体来说，在大城市的生存和发展尤为重要，基本不可能在地铁里寻衅滋事，更不会在背包内存放“刀具、硫酸、炸药”等危险物品，更多时候存放的可能是电脑、文件、记事本等等。那么，地铁运营者能不能为这些群体提供“豁免权”，为他们提供“免安检通道”呢？

从技术角度讲，K哥认为完全可以！地铁的闸机终端记录着所有旅客的刷卡信息，这些信息包括一卡通ID、进站/出站、站点编号、刷卡日期、刷卡时间、优惠幅度、消费金额、卡余额等。我们只需定义什么是“通勤旅客”（如最近三个月，每周不少于4次通勤的乘客），就可以利用大数据技术从这些刷卡信息中统计出哪些一卡通属于“通勤旅客”。然后，根据统计结果对一卡通打标签，也即，是否为通勤旅客。有了这个标签之后，就可以根据标签对旅客区别对待。

图-1是旅客进站区分对待示意图。旅客安检前，首先通过“常旅客检测机”刷卡判断自己是否为“通勤旅客”。若是，则无需安检，直接通过“免安检通道”刷卡进站；否则，像往常一样，先安检，再刷卡进站。这样一来，既保证了安检的安全保障属性，又为特殊人群提供了便利。

那么问题来了，这一方案在技术上怎么实施呢？列位看官，您抬眼：

图-2是技术解决方案示意图。以北京地铁为例，旅客刷卡信息都保存在进出站闸机Windows平台的SQL Server数据库中。因此，我们首先需要通过Sqoop把这些刷卡信息统一保存至Hadoop平台的分布式文件系统中，也即HDFS。然后，利用性能强劲的分布式计算引擎（如Apache Spark），对刷卡信息进行统计、汇总，并根据计算结果对一卡通打标签。打标签完成后，将所有[一卡通ID，常旅客标签] 记录插入/更新到分布式内存数据库（如Cassandra），提供实时数据访问。进站口的“常旅客检测机”通过访问Cassandra内存数据库，可以为旅客提供准实时的反应和交互。

有小伙伴问了：“上下班高峰时段，那么多人同时刷卡，常旅客检测机能扛得住吗？”这是个好问题！兄弟们拿好小板凳，K哥给你算笔账。根据北京地铁官方提供的数据，截至到2016年3月，全市共有17条地铁线路，共有站点327个。我们假设每个站点有5个出/入口，那么全市共有327 * 5= 1635 个地铁出/入口；我们再假设，为了提高效率，每个出/入口放置3台“常旅客检测机”，这么一来，全市共有 1635 * 3 = 4905 台“常旅客检测机”。也就是说，高峰时段，有多达5000人同时刷卡、同时访问后台的Cassandra数据库。Cassandra大神说：“呵呵”！5000并发对于大多数内存数据库来说，只能用一句话来形容：“那都不叫事儿”！

又有小伙伴反对：“K哥，你这方案肯定落实不了， 万一卡丢了咋办？”这确实是个问题。毕竟现在的一卡通，不是实名制。不过随着社会的进步和发展，也许未来能够用身份证、指纹、掌纹这些能够唯一标识身份的方式来乘坐地铁，到时候K哥的这个提案就有用武之地啦！

内位小伙伴又说了：“K哥，这里面还有个成本问题啊，人家地铁官方凭啥自己掏腰包，免费给你提供便利？”嗯，没错。不过，在“移动互联网+”时代，传统公共服务部门也应该吸纳“互联网思维”，不遗余力地把提升最终用户体验放到最高的位置，从而吸引越来越多的优秀人才流入，进而促进城市的经济社会发展，您说是不是？

本文来自微信订阅号《小生活与大数据》