871
使用ODPS进行拼车分析
前言
最近几年以来出现的共享的士（Uber，Lyft，滴滴）给人们的出行带来了极大的便利。随着烧钱大战的结束，中美市场大局已定，为了维持高估值（Uber 80 Billion $, 滴滴30 Billion $），缩减亏损，增长净利润，继而进入上市流程，几大公司都开始发掘盈利的规则。带来的影响是，共享出行的用户们发现：1）车越来越难打，价钱越来越高；2）使用拼车会大幅度增长时间损耗，而带来的金钱节约却并不明显；3）司机发现盈利有限，真正愿意开车的司机越来越少，滴滴公司正在慢慢的转变成为一个的士信息服务平台。这与其做成让用户通过手机便捷，实惠出行的愿景大相径庭。我认为滴滴将Uber踢出局极其类似于当年谷歌离开的场景，当没有竞争以后，其创新能力也大幅减退，最终会导致其自食其果。
我想说一个故事，作为这篇文章所要解决的的一个问题的引子。那天天气炎热，我正在公交等去高铁站的公共汽车，由于太热，我决定打一辆车，当我拦下来一辆车后跟司机说15块钱到车站，司机答应了。而此时跟我同时等公交的另外一个陌生人也过来问我们要到哪里去，当他得知目的地是火车站以后，表示也想搭车，这时候司机坐地起价要他加10块钱。这位陌生人想想觉得可以，就加了10块钱给他。设想一下，如果我在拦的士之前就知道这个陌生人也想去火车站，两人决定一起打车最后的价钱是怎样的结果？也许15-20块钱就可以搞定问题，而不是最终的25块。而事实上，如果大家都具有这样的能力，我想对的士司机来说也可以增长盈利，因为更多的打车需求会让他们的单数变多从而增加总的流水。
回到滴滴的话题，目前假设从阿里巴巴西溪总部出发到杭州东站（路径A），一个人打车的费用是100，那么第二个人拼车也是到杭州东站附近(路径B)，这时候他可能需要付的价钱是90块钱，也就是说总价190块钱。大家是否认为司机会拿到这部分的差额呢？事实上，的士司机只拿到了他们共享路程的费用(（A /union B）* 20%)，而不是（(A + B) * 20%），如果A和B完全相等的话，那么司机基本上不会拿到更多的钱，这部分多出来的利润就被滴滴公司完全拿去了。 为什么滴滴公司会这么做而且敢这么做呢？因为他们不但垄断了共享车的平台，也垄断了信息分享的平台，一个人在上车之前他是不知道另外一个人跟在类似的时间段去类似的地方的。如若这两个人在上车前就已经知道了对方的目的地，并联合起来打一辆车的话，那么这个博弈的格局就完全不同了。我们写此文的目的就是要分析真实世界中这样的需求是否真实存在，值不值得我们投入精力去开发或者利用一个已有的信息平台让有类似出行需求的人在按下滴滴打车”的按钮前就找到对方，从而增加议价的权利。
本文使用的数据来自于Todd Scheider维护的纽约的士数据[1]，在此文中只分析Yellow Cab的数据，因为其时间跨度较长（2009-2016），同时覆盖纽约市区的范围也更广（所有纽约5个大区）。使用的阿里云大数据的技术有：Tunnel，Sql，UDF，MapReduce，Graph和Quick BI。实验机为阿里云的ECS最低配的机器。所有开发实验工作均在公有云上进行。本文的结构如下：第二节将介绍数据分析的技术细节，第三节为实验结果分析，第四节为工作方向讨论。
数据导入
首先我们将csv格式的数据使用Tunnel导入到ODPS表中，使用的表的schema如下：
使用的Tunnel导入的script如下：
这样我们得到的数据一共有：698,211,833条数据。
数据清洗和图生成
引用
[1] https://github.com/toddwschneider/nyc-taxi-data
最后更新：2017-07-16 19:02:33