使用k3s减少k8s成本

爱飞狗后台的数据爬虫以及数据服务器资源都部署在k8s上,使用rancher搭建。在不影响太多性能的情况下尽量选择最低配置的机器。对于内存不足的情况适当的使用交换文件代替(swap)。整个集群大致结构如下:

用途 机器类型 价格
爬虫1 1G 1CPU 5美元
爬虫2 1G 1CPU 5美元
爬虫3 1G 1CPU 5美元
监控 1G 1CPU 5美元
etcd 2G 1CPU 10美元
rancher主机 2G 1CPU 10美元
aiflygo服务器 4G 2CPU 20美元

一个月的开销大概在60美元左右。分析上面的集群可以发现,rancher和etcd两个节点是浪费了钱,每个月有20美元的开销。DigitalOcean提供了k8s的托管集群,可以将这部分开销节省。但托管集群的droplet无法定制化,无法使用交换分区和bbr,造成性能瓶颈。另外托管的droplet的最低要求也是2G的内存,造成不必要的开支。

k8s有一个非常不好的地方就是最低的机器要求比较高,1G内存的worker node已经完全低于推荐配置,如果在上面部署worker node直接的内存占用就要300M左右,剩余的内存空间并不多,必须要使用交换分区。etcd节点之前也用过1G的内存,但经常会由于大量使用交换分区导致性能问题,最后集群崩溃,所以无论如何也需要使用2G的内存才行。

最近rancher公司推出了k3s,其主打就是简易的部署和极地的机器消耗。这点对于节约成本来讲非常的重要。我试了下k3s的server大概只占用200M左右的内存,agent只占用几十兆内存,非常的节约。k3s也可以完全使用kubectl来进行管理,配置文件和k8s保持一致,非常方便。

我将etcd节点和rancher主机删除,替换成了1G 1CPU的机器(5美元),节约了15美元,然后将aiflygo的服务器进行降配置到2G 2CPU (15美元),总共节约20美元。得益于更多的可用内存,目前爬虫的性能比以前更好,整体集群的性能也非常的高。

至于HA,既然都穷到了用k3s来减少开销,对于我这样的小型的集群和不是关键系统来讲都不是需要考虑的了。

心路历程:爬虫实战——从数据到产品

京东链接:https://item.jd.com/12575102.html

经过近一年的辛苦创作、编辑、等待,本书终于出版了。这种感觉有点像是十月怀胎,但没有生育时候的痛苦,只有最后得到的欣喜。现在回忆起去年接到写书的邀请,然后到纠结,再到刚开始痛苦的写作,以及最后成稿后的释然,一切都觉得是一场人生的经历。我倒是认为写书的目的不是为了赚钱,写一本书给自己,总结自己的过往,将经验传播给他人,就可以了。

故事——还得从2017年说起

2017年1月左右,摩拜单车终于进入到成都。不像重庆那样的上山下坡,成都平原地势较平,成都原本就有非常多骑自行车的人,街头巷尾都有自行车的踪影。作为短途的必要交通工具,摩拜单车的进入算是给出行带来了非常大的方便。

有一天在查看摩拜单车的APP的时候,突发奇想是否可以将这些车的位置数据拿到,然后尝试分析一下运营状况,看看成都到底有多少车。打开电脑,轻车熟路的进行API分析,搞明白了API的接口,然后就写了一个简单的爬虫,获取了一个月左右的数据并进行了分析。然后在简书上发了几篇文章,并将源代码放在了https://github.com/derekhe/mobike-crawler这个repo中。

image.png

出乎意料的是,这些分析居然得到了非常大的流量,两三天时间就到了1万多的阅读量,甚至这个数据分析还“成功”的引起了对方的注意:被问到你怎么得到数据?

2018年

2018年,顺着这个思路,后来我又继续分析并爬取了共享汽车、自由职业者网站,并继续坚持将2016年6月开始做的机票的数据爬虫做得更快更稳定。

image.png

2017年末,爱飞狗旅行小程序上线,将我收集到的机票的数据公开,并集成了一个预测系统。知晓小程序对此特意写了一篇文章进行报道。随后,在2018年下半年ThougtWorks对外的YottaBytes分享中,我将爱飞狗的整个产品的规划、开发以及背后的技术实践都分享出来,并写成文章。

写书?

2018年3月底,电子工业出版社的安娜编辑联系我,看我能不能约一本书稿。当时我还没放在心上,想想写个书算是一个大工程吧,费时费力的,当时就想想要不还是算了?后来和编辑的更多沟通中发现,爬虫方面的书最近还比较热,也能热一段时间,我做的这些工作也恰好和爬虫非常有关。

我随后看了一些目前的爬虫相关的书籍, 发现很多爬虫的书籍都写得很初级,讲讲Python的语法、讲讲几个库的用法,弄两个例子就完了,甚至有些书居然用了76页讲各种东西的安装!!初级的爬虫往往很简单,爬几个网站即可,但更复杂的如何去拿到app的数据,如何破解一些sign的思路,却全然没有。或许是太复杂了吧。即便有些数据拿到手了,怎么分析,怎么可视化,也很少有讲解。

如果我要写的话,我一定不会写这样的书,我不会写初级的书。我要写的话,一定是从一个想法开始,到如何实现这个想法,到如何解决各种困难。案例的话,一定是end to end的,将数据达到实用的阶段。

还好之前做过的各种数据分析案例,都是有一定的业务背景的,有一些数据提供给了一些爱好者进行了更深入的分析,有一些数据甚至帮助一些公司进行一些新业务的拓展尝试。我和编辑沟通了这些想法,那就开始动手吧!(其实内心是有点纠结的,因为想到要写很长的时间,非常的难受)

那就开始吧

这是最原始的选题单,可以看到其实当时想写的例子其实比现在书中呈现的更多。但后来由于目标网站改动太大,以及有些网站的例子不太合适,所以进行了删减。

最后,只有半年的时间啊……

万事开头难,先写个提纲吧:

开始

工欲善其事必先利其器,2009年写过研究生的论文,倒是对Word玩的很溜。但如今都2018年了哟,好歹用点Markdown对吧!

好吧,就用Markdown。但是用Markdown的话,我需要把每个章节分开么?后来尝试了一下发现,单一Markdown文件就非常利于管理,不用有洁癖一样把东西拆来拆去:

  • 方便预览整书情况
  • 方便章节之间相互引用
  • 避免调整章节时候的麻烦事

然后,在Visual Studio中安装了Markdown Preview Enhanced插件,这个工具很好:

  • 自动预览
  • 自动生成目录
  • 自动内嵌图片、内嵌代码
  • 能够导出成多种格式(Word格式、PDF格式等)

最后,整个项目当然会用git进行管理,这是最基本的啦。

其中我觉得需要拿出来讲的是,Markdown中可以直接引用代码。这意味着我一边写书一边写的代码,可以无缝的集成到文章中,这样我更改了代码以后,书中的代码也更新了,避免了不同步的问题。

一年

现在回顾一下整个出书的历程。

我这个人是喜欢一鼓作气做完一件事情。为了保证及时交付,每天都分配了至少两个小时的时间,再加上之前已经有一些素材的积累,所以整个书的书写都相对比较快。基本上在4个月时间内集中写完了书籍。初稿完成后,我的事情就比较少了,主要是一些校对的工作。

  • 4月底:建立Repo
  • 5月初:书写第一章
  • 6月初:完成单车部分书写
  • 6月底:完成共享汽车部分书写
  • 7月底:完成Freelancer部分书写
  • 8月初:增加爱飞狗产品
  • 9月底:完成所有书写,并转换成docx供编辑修改
  • 10月初——12月底 一排
  • 12月底到1月初: 二排,拿到书号
  • 2月底:终审
  • 3月中:封面、查重、定价
  • 3月底:样书到

经验

  • 持续和编辑联系,写完一章就给编辑大致看看得到反馈
    这一点避免了很多走弯路。第一次写书,对写书需要做的事情了解的比较少,加之平时在敏捷项目中都强调快速反馈,在写书过程中也是,能够及时避免一些坑。
  • 一鼓作气,坚持每天花些时间写,避免拖拉
  • 长期写博客,积累素材

在写书的过程中也有一些不可避免的“坑”。一来是写书不像是写博客那么随意,对于语言以及内容的提供都要有一个监管在里面。运气不好的是初稿交了以后,编辑告诉我2018年国家对地图相关的图片管理很严。我了解到相关的书籍都必须要进行审核,虽然说是免费,但是为了避免审核的时间消耗和一些潜在的风险,我们对书中的一些地图相关的图片、内容进行了一些修改和删减。

爬虫这种技术有一定的法律风险,再三考虑之下对书中也有提到一些特定APP名字的地方,我们将名字进行了打码,并强调了这些思路以及代码都仅供参考。

初稿的反馈说书写的很直白,全是干货,审核后说是要语言柔和一些。由于这个书的架构和其他类似书籍先将一大堆基础知识不一样,出版社的领导提议说将书的结构进行调整,变成介绍工具在前,案例在后。但这就是我想尽力避免的,不想让读者的钱花到了原本网上可以很快查到的地方,所以拒绝了。

由于互联网时代变化很快,网站和APP都在改版,所以爬虫相关的代码,目前有些已经无法使用了。这是预料之中的事情,但书中所传递的方法,是通用的。

总结

不管如何,第一本书也算是出来了,放在书架上也是对我的极大地鼓舞。写书不容易,一旦开始就要一鼓作气。平时的积累非常重要,所以多多写博客吧。

从数据到产品——爱飞狗背后的故事

这篇文章基于最近整理的一份演讲的Slide,由于报名太晚错过了截止日期,所以只好写成文章,一起来看看爱飞狗背后的一些故事。

几年前我和家人会经常往返于成都和广州两个城市,从平时的观察中可以看到机票价格从400人民币到全价接近1500人民币,机票产生的波动有时候会高达100元以上,如果没有看好时间,一家人出行就会增加几百元的成本。

买机票的时候,我应该和大家差不多,会在买机票前进行一番观察。主要是观察未来几天起飞的机票价格,用来选择哪天出行。然后手工记录一下近期的价格变化,看看是不是在涨价还是跌价中。当然这个纯属体力活也容易错过最佳购票时期。我当时在想,如果我能知道去年的机票的价格和变化趋势,或许可以用来预测今年的价格的波动和判断是否需要购买机票。

我提出了两个问题,近期的价格的趋势是什么?决定好起飞时间后,我应该提前多少天购票?

我查了一下目前我们有的一些服务和APP,看是不是有人已经做过了类似的事情。

  • Farecast是最早做机票预测服务的一家公司,后来被微软收购后并入了Bing,此后Google收购了Farecast所依赖的数据源后,Bing的这项业务也停止了,所以现在Farecast已经关闭,无法使用。
  • Kaya这家网站提供了机票的近期价格曲线以及购票建议,十分切合我的需要,但遗憾的是中国的数据源非常少,几乎没有可参考性。
  • Hopper也是最近两三年比较好的一款App,提供了出行的建议以及是否购票的提示。但Hopper不会提供去年的曲线图,也没有近期的票价情况,一切看你是否相信它的AI预测了。和Kaya类似,这个App也没有中国区域足够的数据,没有什么参考价值。

面对这样的情况,作为一个程序员,我觉得是时候出手了。

由于我没有运营机票代理业务,所以无法获得机票信息的一手资源。对于我来讲唯一能够获取到数据的方式就是采用爬虫,通过模拟人工的搜索来获得票价信息,存储到数据库中。

为了分析一整年的数据,我在给自己定了一些目标:

  • 至少要连续采集1年的数据
  • 更新频率大概在1小时左右
  • 低成本
  • 容忍爬虫或者数据源的失败

根据这些目标结合当时的情况,我将这个任务分解成了以下几个部分:

  • 机票采集的范围:中国范围内2800个航线的直飞的价格数据
  • 采集的数据:每条航线起飞前45天的票价信息
  • 数据源:4个数据源做互补,一来是为了检查数据的准确性,二来是为了防止数据源失效
  • 全年无休连续爬取

在数据爬虫的架构上,我需要一个低成本的方案,毕竟要干上一年以上的时间(其实到现在已经2年多了)。我并没有使用各种爬虫的框架,而是自己写了一个轻量级的爬虫来处理代理的筛选逻辑和爬取数据的验证。这些爬虫将会运行在DigitalOcean或者Linode的$5的服务器上,这些服务器上只有1个CPU和1G的内存。自定义的爬虫能够尽可能的根据性能进行针对性的调优,从而增加性能。每个爬虫之间互相独立,部署在单独的机器上,也是为了减少爬虫之间的相互干扰。

在存储上我是用了tar.xz的文件将所有的爬取到的原始文件按照每一轮爬取进行打包压缩,然后在本地里面的一台PC机负责将所有的数据拉回来,放到一个4T的硬盘上。同时这些数据也会存储到百度云上面进行备份。目前这些压缩包已经达到2T左右了,解压下来大约有20T的数据量,大约有380亿条数据。

在数据处理上,首先是实时数据流的处理。使用了kafka来进行队列管理,一个Parser来进行实时的处理原始数据,将处理好的结果放到redis缓存中,供小程序的后端使用。

在数据的分析上,我使用Java手写了一个高性能的ETL,直接读取压缩包然后进行数据解析。在这里也是使用了轻量的原则,没有使用更多框架,从而达到非常高的性能。

在PC机上也使用了Postgres中进行数据存储,每一天的数据存储到一个表中。

在近两年的时间中我积累了以下一些经验:

  • 在长时间的爬取中证明了简单的爬虫的可变性非常好,在针对特殊场景调优的时候非常有针对性。
  • 存储原始文本也为了应对数据结构的变化,当数据结构变化后,本地的Parser失败以后,可以重复的调用之前的数据,从而保证数据不丢失。
  • 多个数据源进行备份的设计非常好。目前依然有两个数据源在持续爬取。针对两个数据源我也可以进行数据的对比,发现数据对比后数据较为相似,说明没有爬取到脏数据。

拿到这些数据后,就要开始数据分析了。

分析的结论在我的简书的前几篇文章中都有提到。这里不再赘述,请参看:
https://www.jianshu.com/p/3b22fb101189
https://www.jianshu.com/p/366e839af3ea

在分析完这些数据后,我们再回头看一下最初问题的定义:针对某一条航线,给定历史价格和近期的价格,现在看到当前的价格是P和距离起飞还有N天,我们应该是买还是等待?

我使用了以下一些算法来分析,包括决策树、支持向量机、Q-learning和神经网络。

在准备数据时,提取了以下一些基本特征,当然针对不同的算法还是用不同的特征。

在数据的分割上,考虑到这个是时间序列相关的数据,将数据集分为1年的训练数据,2个月的测试数据和2个月的验证数据集。当然实际数据比这个多,可以尝试更多的组合。

但这些算法算出来的结果还并不令人特别满意,达到的准确率也只能超过人工根据一些简单的规则推导出来的准确率,可能和我所用的数据训练方式有关。所以在线上计算的时候,我目前还是采用专家系统的做法,将数据分析的结果整理成规则,根据这些规则还是能够得到较高的预测准确率,其他的指标例如Recall等可能会比较差。

那么为什么专家系统能够行得通呢?我从一些内部人士了解到,原因在于这些机票都是来源于中航信,而这个系统比较老旧,针对价格的调整也不够灵活,大多数都是给予一些人工的规则来进行。收益管理员基本上都是从这里学到一些规则然后进行调价,所以学到的规则其实比较相近,所以会产生大家都有差不多一样的规则。

有了数据之后,想到可以来造福大众,便产生了做一个小产品的想法。

这时候正直小程序比较火的年代,小程序比较简单,而且受益于微信的用户群可以很方便的进行推广。所以设计了几个简单的功能,能够选择出发、到达和起飞日期,然后会显示出实时的价格和历史最低的价格,点进去后可以看到预测、近期的价格波动和去年的价格波动。这能够更好的指导大家进行机票的选择。

下面来看看产品背后的架构:

  • 前端当然是用微信提供的一套进行开发,这个和其他的小程序没有什么两样。
  • 后端使用Flask进行开发,简单快捷。
  • 数据提供方面有之前提到的实时数据的显示,来自Redis缓存,当然还有离线历史数据数据。这些数据每天从离线的PC机上同步到云端,然后由API进行展示。
  • 还有用户行为数据的存储及分析。这些数据都存在ElasticSearch服务器中以便进行快速的搜索,借助Kibana可以对用户行为进行在线的分析,非常的方便。当然还有一些和用户相关的需要实时更新的数据(例如session值和飞币的信息)也放在EleasticSearch中,主要是利用了NoSQL数据库没有Schema的特点,增加数据使用的灵活性。
  • 基础设施方面小程序相关的部分全部在阿里云的服务器上。所有的服务都使用Kubernetes进行管理,Rancher进行可视化管理,爬虫等服务放在DigitalOcean一遍节约成本。

小程序也发布了9个多月了,目前积累了大约4.3万的用户,数量还相对较少,这个小程序的未来如何考虑呢?

首先是继续将机器学习应用到价格的预测,毕竟积累了2年的多的数据是一笔不小的财富。
然后是提供更好用的界面提升用户的使用满意度。
最后就是找到一套可行的商业模式进行变现。目前小程序还只能依靠广告有一点收益,完全是入不敷出的情况。

如果您对这个小程序感兴趣,请试试微信搜索“爱飞狗旅行”和关注微信公众号“爱飞狗”,或者扫一扫下面的二维码。您的支持将是我进步的最大的动力。

小心!我正在偷窥你的运营

首先,问一个很简单的问题考考你——在上海,摩拜单车出行的高峰时段是什么?这个问题相对比较容易回答,根据普通人上下班的时段应该是早上七八点左右,下午六七点左右。恭喜,你答对了。

现在问一个稍微更难一点的问题:在上海,摩拜单车使用次数的分布是什么情况?对于我而言,基本上每天就从地铁站骑到公司,然后下班从地铁站骑回公司,就算做是两次吧,通常这部分人应该不少。而这道题问的是分布,那么得知道0次骑行的车的数量,骑行一次、两次、n次的车的数量。我们可以做个小范围的采样,在单车密集的区域架设几个摄像机,然后分析一下哪些车没有被骑走即可。但是,骑行两次、三次以及更多次数的车的数量如何得知呢?我们很难知道,或许我们可以通过发放调查问卷来得知,但如果样本太少会得到打的偏差。同样的道理,回答“摩拜单车的骑行距离的分布式什么情况”,也相对较难。

要知道共享单车的运营情况,我们通常只能通过官方或者研究机构的各种报告来获取到。然而这些报告可能缺少一些时效性,对某些研究来讲并不能产生任何作用:例如在城市规划时研究OD线、叠加图层分析更多因素的结合时,就显得无能为力。最后的渠道也是最正规的渠道是通过和共享单车企业合作,然而由于涉及到商业机密,通常很难获得。

OD线(Origin-Destination Line),是指连接“起点”(origin)和“终点”(destination)的线,通常用于在地图上直观表示某两个地理位置之间的联系,如车辆的行驶轨迹、飞机的航线和人口的迁徙等。

回到单车的APP上来,既然能够帮我们显示出车辆的信息,那么我们能不能把一个区域的范围的车的信息都抓取下来,然后进行分析呢?这个思路非常的有趣,在我之前写的摩拜单车爬虫解析——找到API 中已经有所涉及。在这里我们不谈技术细节,通过对爬取的上海市2018年5月29日星期二(晴天)的数据进行分析我们迅速地得出上面问题的答案:

  • 单车的分布图和部分热力图。可以明显的看到上海城市的发展规模以及人口密集区域的分布。

单车分布图

单车热力图

  • 单车使用次数类似一个正则分布,2次的次数最多,符合人们的直觉。
    使用次数直方图

  • 骑行的直线距离分布在2千米之类,以1千米范围为最多,这通常也是单车解决“最后一公里”问题的证据。
    骑行距离分布

  • 出行的时段的分布在早上7点左右达到高峰,然后晚上7点左右达到高峰,这和人们的出行习惯是密切相符的。有趣的是夜间22点以后到第二天凌晨5点左右,也有单车在移动,但这时候骑行的人相对很少,所以这些单车的移动很有可能是摩拜单车的运营人员在批量的挪单车。如果将这些数据加以分析应该可以知道这些车从哪里挪到哪里,进而更深层的分析单车企业的运营策略。

骑行时段分布

同样的道理,让我们来看看共享汽车的运营情况。我们抓取了去年GoFun从10月到1月的数据,得出了以下一些运营状况的分析:

  • GoFun绝大多数车型都是奇瑞的车。两座和四座的车是主流,车身小巧一方面比较节能,另一方面比较容易操作。这主要是因为奇瑞投资了GoFun。

车辆信息

  • 截止2018年1月26日,GoFun目前在全国总共有10327辆车。下图是车辆增长的情况。可见运营一直在持续,并且缓慢增长。

增长

  • 三个月内车的使用次数的分布。横坐标是使用的次数,纵坐标是次数对应的车的数量。近似一个正态分布,大约70%的车都在24到72的区间。平均起来每天0.3次到1次左右,这对于共享汽车企业来讲并不是一个好事,太低的使用率可能会导致入不敷出。

image

  • 使用时长的分布。横坐标代表停车的时长(小时)最长统计到70小时,纵坐标代表有多少车次。对比停车时长的分布,使用时长的分布比较明显的集中在0到6小时之间,这也是共享出行的特点。由于GoFun有包天的租车服务,所以长期的出行的费用也是可以接受,长达70小时以上的使用时间也有1700多车次。

image

由于篇幅所限,更多的分析结果可以参见大数据看共享汽车一文。

保护我们的数据

以共享单车为例,当我们手工的小范围的采集数据时,并不能产生很大的作用,当我们收集到的数据越来越多时,甚至通过自动化爬虫这种手段获取到足够多的数据以后,大数据就开始展现量变到质变的过程。共享单车、共享汽车的案例中,虽然我们没有得到订单的数据、没有用户信息,但通过对海量数据分析、结合多种维度,我们依然可以窥探企业的运营。我在2017自由职业大数据分析一文中爬取到Freelancer网站的所有公开信息并进行了自由职业的分析;在机票大数据分析,揭示购票的秘密 中,通过一年多的机票价格数据采集得到多个机票购票的建议。所有的数据都来自于公开的API,而主要的获取方式则是爬虫。

网络爬虫(又被称为网页蜘蛛,网络机器人,在FOAF社区中间,更经常的称为网页追逐者),是一种按照一定的规则,自动地抓取万维网信息的程序或者脚本。另外一些不常使用的名字还有蚂蚁、自动索引、模拟程序或者蠕虫。

爬虫获取信息的方式可以通过爬取页面,也可以通过分析APP的请求来得到API。所以一切返回数据的地方都是可以通过一些手段获取到,而主要的区别在于获取数据的难度的大小,这也通常是爬虫和反爬虫的较量之一。当爬虫的成本高到一定水平以后,反爬虫就胜利了。

通常来讲,反爬虫的手段无外乎对IP限制、验证码、要求登录等,可以参考关于反爬虫,看这一篇就够了一文。固然这些方式都可以较好的保护应用,但会给适用方带来不便,除此之前我们可以考虑一些建议来减小数据被大规模爬取的可能,增加爬虫的成本:

从业务上进行考虑,不需要客户感知的数据不提供或者少提供

以单车应用来看,ofo单车并没有提供摩拜单车的预定的功能,所以在界面上也没有必要展示出单车的编号信息。在去年9月份左右,ofo单车对API进行了调整,将所有的单车编号进行随机化处理,导致ofo单车的数据目前无法爬取。哈罗单车在未登陆的情况下只提供几台单车的数据,登陆后能够展示附近所有的单车。由于需要登录,爬虫的成本会变得很高也非常的脆弱。
反观某大型旅游OTA网站的API,调用后返回了相当数量的额外信息,甚至在价格方面包含了两种价格,而其中一种价格并不会在界面上进行显示,这种信息非常值得怀疑是不是内部的价格。

盘点所有的API的使用方,谨慎一切以JavsScript开发的客户端

目前手机APP层面的保护措施已经相对较多,而且大多数应用受到加密外壳的保护很难破解,想得到URL里面的签名信息的生成方式变得非常困难。然而仔细盘点一款产品的各种渠道,会发现有些产品可能会提供HTML5、公众号、小程序等入口,而这些以JavsScript生态圈的应用并未收到很好的保护。
以某款快递软件为例,该查询软件中提供了sign信息,基本无法知道如何生成,但在小程序中调用了类似的API并带上了sign信息,通过一个Root的安卓手机可以将小程序解包,分析JavaScript很容易的发现了sign的生成方式。另外某单车软件登陆的签名信息eption也是经过了加密处理,在小程序中也能够发现其生成的方式,马奇诺防线就这样轻松的被越过了。
当然小程序端的防止爬取的方式比较简单,小程序的后端可以通过微信的接口生成动态的token的方式进行用户验证,防止数据泄露。

做好后台的监控

道高一尺魔高一丈,后台API调用的日志和监控手段要重视。对于异常数量的API调用要及时分析出原因减少被利用的可能。

大数据看共享汽车——GoFun篇

去年2月份我做过共享单车的数据分析,也分析出一些有意思的点。从2017年10月1日开始,历时3个多月,我收集了GoFun和EVCard共享汽车的公开数据。下面整理成一个互动的报告(文后有链接及代码),一起看一下共享汽车的现状。

声明:该数据分析及报告仅代表个人意见,仅供参考,数据来自于API请求的结果,只包含公开的信息,不涉及用户信息。
引用、使用该报告引起的任何后果(包括但不限于版权、侵犯法律法规)等,由使用方承担。
未经许可禁止转载

基本信息

GoFun出行是首汽集团针对移动出行推出的一款新能源共享汽车产品,秉承首汽集团作为全国最大出行服务运营企业的多年经验和优势资源,响应政府号召,把握“新能源+车联网”的全趋势,致力于整合用户碎片化的用车需求,提供便捷、绿色、快速、经济的出行服务。 GoFun出行是共享行业新兴的一种租车模式,车辆无人值守,用车全程App操作,以“分钟+公里”计算并提供汽车的即取即用、分时租赁服务,消费者可按个人用车需求预订车辆。GoFun出行已相继完成全国20余个城市的布局,其中不乏北京、上海、武汉、成都、南京等一、二线城市,更有西安、青岛、昆明、桂林、三亚等重要旅游地。

我们先来看一些关于车的基本的信息。

从上面几幅图可以知道,GoFun绝大多数车型都是奇瑞的车。两座和四座的车是主流,车身小巧一方面比较节能,另一方面比较容易操作。


为什么是奇瑞的车占据绝大部分份额呢?从网络搜索到两条新闻可以知道奇瑞是GoFun的合作伙伴,这也不足为奇了:

#业务概况

根据采集的数据,截止2018年1月26日,GoFun目前在全国总共有10327辆车。下图是车辆增长的情况。注意,车辆数量有时候会变少,这是因为数据采集时只能采集到没在使用的汽车,所以会少一些。整体趋势来讲呈平稳上升趋势,说明目前发展状况稳定。

我们再来看看车辆的数量分布。可以看出来在四川、广东、陕西、福建等省有很多的车辆,属于比较正常的情况。比较奇怪的是上海的车辆数量很少,我猜测在上海早已有竞争对手占据了市场,还不如避而求其次。

由于GoFun必须在指定地点借还,停车场的数量多少就直接影响到用户体验。随着车的增长,停车场的数量也应该有相应的增长才对,从图里面也看出停车场的增长较为平稳。截止2018年1月26日,全国总共有2887个停车场。

在停车场各省的分布情况中,几乎是和车辆的分布接近。

我们再来看一下多少汽车共用一个停车场的情况。从图上看出,平均来看大致一个停车场目前有3辆车的规模。如果一个停车场容纳的车越多,那么用户能够拿到车的几率越大,从这方面看也是一个好事。如果停车场的数量较少,网点不密集,就会影响用户的到达性。从这张图可以看到出湖北省的比例最高,从之前的车辆数量排名看湖北省排名第5,但停车场数量排名第10,停车场数量偏少。你可以在”停车场分布”图中,具体看看武汉市的网站分布。

停车场分布

下图是停车场的分布图,图上标记了全国的停车场的位置,可以自由浏览。以成都市为例,作为西部重点城市,共享汽车的发展和共享单车一样的迅猛。目前GoFun的覆盖面还是比较广,主要集中在人口密集的三环境内、南边的高新区。在西边的郫都区和东边的工业区龙泉也有所分布。但从图中可以看出显然北边和东北方向都没有太多的分布,这也和城市的发展密切相关。在西边的旅游城市都江堰,GoFun也有大量的网点,这也给出行的人带来了丰富的选择。

车辆流转情况

下图是三个月内车的使用次数的分布。横坐标是使用的次数,纵坐标是次数对应的车的数量。近似一个正态分布,大约70%的车都在24到72的区间。平均起来每天0.3次到1次左右。

但使用次数只是运营情况的一种体现。如果每次使用时间比较短,停车时间比较长,对GoFun也不是一个好事。下图展示了停车时长的分布。横坐标代表停车的时长(小时)最长统计到70小时,纵坐标代表有多少车次。从图上峰值是在0到2小时之间。也有连续70小时,也有1000多车次有过这样长的停车时间。

下图展示了使用时长的分布。横坐标代表停车的时长(小时)最长统计到70小时,纵坐标代表有多少车次。对比停车时长的分布,使用时长的分布比较明显的集中在0到6小时之间,这也是共享出行的特点。由于GoFun有包天的租车服务,所以长期的出行的费用也是可以接受,长达70小时以上的使用时间也有1700多车次。

车的轨迹

下面这个动画展示了一辆车的直线运动的轨迹。由于我们仅能得到出发、到达地无法获得中间的轨迹,所以只能这样按照直线标注。图上展示最近几个点,以及位置迁移情况。

#电池电量

下面这张图展示某一辆车的电池变化情况,其中深色区域代表该车在停车场内没有被使用。

#总结

根据以上的分析,GoFun目前的发展势头还是稳步增长。在路上我们也越来越多的看到共享汽车的身影。以成都为例,当停车场数量、车的数量越来越多以后,出行的局限性会变的更少,相信会俘获更多的用户。

#附件
互动报告:http://www.april1985.com/sharecar_report/report/index.html
报告源代码:https://github.com/derekhe/sharecar_report