這篇文章基于最近整理的一份演講的Slide，由于報名太晚錯過了截止日期，所以只好寫成文章，一起來看看愛飛狗背后的一些故事。

幾年前我和家人會經(jīng)常往返于成都和廣州兩個城市，從平時的觀察中可以看到機票價格從400人民幣到全價接近1500人民幣，機票產(chǎn)生的波動有時候會高達100元以上，如果沒有看好時間，一家人出行就會增加幾百元的成本。

買機票的時候，我應(yīng)該和大家差不多，會在買機票前進行一番觀察。主要是觀察未來幾天起飛的機票價格，用來選擇哪天出行。然后手工記錄一下近期的價格變化，看看是不是在漲價還是跌價中。當然這個純屬體力活也容易錯過最佳購票時期。我當時在想，如果我能知道去年的機票的價格和變化趨勢，或許可以用來預(yù)測今年的價格的波動和判斷是否需要購買機票。

我提出了兩個問題，近期的價格的趨勢是什么？決定好起飛時間后，我應(yīng)該提前多少天購票？

我查了一下目前我們有的一些服務(wù)和APP，看是不是有人已經(jīng)做過了類似的事情。

• Farecast是最早做機票預(yù)測服務(wù)的一家公司，后來被微軟收購后并入了Bing，此后Google收購了Farecast所依賴的數(shù)據(jù)源后，Bing的這項業(yè)務(wù)也停止了，所以現(xiàn)在Farecast已經(jīng)關(guān)閉，無法使用。

• Kaya這家網(wǎng)站提供了機票的近期價格曲線以及購票建議，十分切合我的需要，但遺憾的是中國的數(shù)據(jù)源非常少，幾乎沒有可參考性。

• Hopper也是最近兩三年比較好的一款A(yù)pp，提供了出行的建議以及是否購票的提示。但Hopper不會提供去年的曲線圖，也沒有近期的票價情況，一切看你是否相信它的AI預(yù)測了。和Kaya類似，這個App也沒有中國區(qū)域足夠的數(shù)據(jù)，沒有什么參考價值。

面對這樣的情況，作為一個程序員，我覺得是時候出手了。

由于我沒有運營機票代理業(yè)務(wù)，所以無法獲得機票信息的一手資源。對于我來講唯一能夠獲取到數(shù)據(jù)的方式就是采用爬蟲，通過模擬人工的搜索來獲得票價信息，存儲到數(shù)據(jù)庫中。

為了分析一整年的數(shù)據(jù)，我在給自己定了一些目標：

• 至少要連續(xù)采集1年的數(shù)據(jù)

• 更新頻率大概在1小時左右

• 低成本

• 容忍爬蟲或者數(shù)據(jù)源的失敗

根據(jù)這些目標結(jié)合當時的情況，我將這個任務(wù)分解成了以下幾個部分：

• 機票采集的范圍：中國范圍內(nèi)2800個航線的直飛的價格數(shù)據(jù)

• 采集的數(shù)據(jù)：每條航線起飛前45天的票價信息

• 數(shù)據(jù)源：4個數(shù)據(jù)源做互補，一來是為了檢查數(shù)據(jù)的準確性，二來是為了防止數(shù)據(jù)源失效

• 全年無休連續(xù)爬取

在數(shù)據(jù)爬蟲的架構(gòu)上，我需要一個低成本的方案，畢竟要干上一年以上的時間（其實到現(xiàn)在已經(jīng)2年多了）。我并沒有使用各種爬蟲的框架，而是自己寫了一個輕量級的爬蟲來處理代理的篩選邏輯和爬取數(shù)據(jù)的驗證。這些爬蟲將會運行在DigitalOcean或者Linode的$5的服務(wù)器上，這些服務(wù)器上只有1個CPU和1G的內(nèi)存。自定義的爬蟲能夠盡可能的根據(jù)性能進行針對性的調(diào)優(yōu)，從而增加性能。每個爬蟲之間互相獨立，部署在單獨的機器上，也是為了減少爬蟲之間的相互干擾。

在存儲上我是用了tar.xz的文件將所有的爬取到的原始文件按照每一輪爬取進行打包壓縮，然后在本地里面的一臺PC機負責將所有的數(shù)據(jù)拉回來，放到一個4T的硬盤上。同時這些數(shù)據(jù)也會存儲到百度云上面進行備份。目前這些壓縮包已經(jīng)達到2T左右了，解壓下來大約有20T的數(shù)據(jù)量，大約有380億條數(shù)據(jù)。

在數(shù)據(jù)處理上，首先是實時數(shù)據(jù)流的處理。使用了kafka來進行隊列管理，一個Parser來進行實時的處理原始數(shù)據(jù)，將處理好的結(jié)果放到redis緩存中，供小程序的后端使用。

在數(shù)據(jù)的分析上，我使用Java手寫了一個高性能的ETL，直接讀取壓縮包然后進行數(shù)據(jù)解析。在這里也是使用了輕量的原則，沒有使用更多框架，從而達到非常高的性能。

在PC機上也使用了Postgres中進行數(shù)據(jù)存儲，每一天的數(shù)據(jù)存儲到一個表中。

在近兩年的時間中我積累了以下一些經(jīng)驗：

• 在長時間的爬取中證明了簡單的爬蟲的可變性非常好，在針對特殊場景調(diào)優(yōu)的時候非常有針對性。

• 存儲原始文本也為了應(yīng)對數(shù)據(jù)結(jié)構(gòu)的變化，當數(shù)據(jù)結(jié)構(gòu)變化后，本地的Parser失敗以后，可以重復(fù)的調(diào)用之前的數(shù)據(jù)，從而保證數(shù)據(jù)不丟失。

• 多個數(shù)據(jù)源進行備份的設(shè)計非常好。目前依然有兩個數(shù)據(jù)源在持續(xù)爬取。針對兩個數(shù)據(jù)源我也可以進行數(shù)據(jù)的對比，發(fā)現(xiàn)數(shù)據(jù)對比后數(shù)據(jù)較為相似，說明沒有爬取到臟數(shù)據(jù)。

拿到這些數(shù)據(jù)后，就要開始數(shù)據(jù)分析了。

分析的結(jié)論在我的簡書的前幾篇文章中都有提到。這里不再贅述，請參看：

https://www.jianshu.com/p/3b22fb101189

https://www.jianshu.com/p/366e839af3ea

在分析完這些數(shù)據(jù)后，我們再回頭看一下最初問題的定義：針對某一條航線，給定歷史價格和近期的價格，現(xiàn)在看到當前的價格是P和距離起飛還有N天，我們應(yīng)該是買還是等待？

我使用了以下一些算法來分析，包括決策樹、支持向量機、Q-learning和神經(jīng)網(wǎng)絡(luò)。

在準備數(shù)據(jù)時，提取了以下一些基本特征，當然針對不同的算法還是用不同的特征。

在數(shù)據(jù)的分割上，考慮到這個是時間序列相關(guān)的數(shù)據(jù)，將數(shù)據(jù)集分為1年的訓(xùn)練數(shù)據(jù)，2個月的測試數(shù)據(jù)和2個月的驗證數(shù)據(jù)集。當然實際數(shù)據(jù)比這個多，可以嘗試更多的組合。

但這些算法算出來的結(jié)果還并不令人特別滿意，達到的準確率也只能超過人工根據(jù)一些簡單的規(guī)則推導(dǎo)出來的準確率，可能和我所用的數(shù)據(jù)訓(xùn)練方式有關(guān)。所以在線上計算的時候，我目前還是采用專家系統(tǒng)的做法，將數(shù)據(jù)分析的結(jié)果整理成規(guī)則，根據(jù)這些規(guī)則還是能夠得到較高的預(yù)測準確率，其他的指標例如Recall等可能會比較差。

那么為什么專家系統(tǒng)能夠行得通呢？我從一些內(nèi)部人士了解到，原因在于這些機票都是來源于中航信，而這個系統(tǒng)比較老舊，針對價格的調(diào)整也不夠靈活，大多數(shù)都是給予一些人工的規(guī)則來進行。收益管理員基本上都是從這里學(xué)到一些規(guī)則然后進行調(diào)價，所以學(xué)到的規(guī)則其實比較相近，所以會產(chǎn)生大家都有差不多一樣的規(guī)則。

有了數(shù)據(jù)之后，想到可以來造福大眾，便產(chǎn)生了做一個小產(chǎn)品的想法。

這時候正直小程序比較火的年代，小程序比較簡單，而且受益于微信的用戶群可以很方便的進行推廣。所以設(shè)計了幾個簡單的功能，能夠選擇出發(fā)、到達和起飛日期，然后會顯示出實時的價格和歷史最低的價格，點進去后可以看到預(yù)測、近期的價格波動和去年的價格波動。這能夠更好的指導(dǎo)大家進行機票的選擇。

下面來看看產(chǎn)品背后的架構(gòu)：

• 前端當然是用微信提供的一套進行開發(fā)，這個和其他的小程序沒有什么兩樣。

• 后端使用Flask進行開發(fā)，簡單快捷。

• 數(shù)據(jù)提供方面有之前提到的實時數(shù)據(jù)的顯示，來自Redis緩存，當然還有離線歷史數(shù)據(jù)數(shù)據(jù)。這些數(shù)據(jù)每天從離線的PC機上同步到云端，然后由API進行展示。

• 還有用戶行為數(shù)據(jù)的存儲及分析。這些數(shù)據(jù)都存在ElasticSearch服務(wù)器中以便進行快速的搜索，借助Kibana可以對用戶行為進行在線的分析，非常的方便。當然還有一些和用戶相關(guān)的需要實時更新的數(shù)據(jù)（例如session值和飛幣的信息）也放在EleasticSearch中，主要是利用了NoSQL數(shù)據(jù)庫沒有Schema的特點，增加數(shù)據(jù)使用的靈活性。

• 基礎(chǔ)設(shè)施方面小程序相關(guān)的部分全部在阿里云的服務(wù)器上。所有的服務(wù)都使用Kubernetes進行管理，Rancher進行可視化管理，爬蟲等服務(wù)放在DigitalOcean一遍節(jié)約成本。

小程序也發(fā)布了9個多月了，目前積累了大約4.3萬的用戶，數(shù)量還相對較少，這個小程序的未來如何考慮呢？

首先是繼續(xù)將機器學(xué)習(xí)應(yīng)用到價格的預(yù)測，畢竟積累了2年的多的數(shù)據(jù)是一筆不小的財富。

然后是提供更好用的界面提升用戶的使用滿意度。

最后就是找到一套可行的商業(yè)模式進行變現(xiàn)。目前小程序還只能依靠廣告有一點收益，完全是入不敷出的情況。

作者：我是思聰

鏈接：https://www.jianshu.com/p/b6c59316d980

在不久的將來，云計算一定會徹底走入我們的生活，有興趣入行未來前沿產(chǎn)業(yè)的朋友，可以收藏云計算，及時獲取人工智能、大數(shù)據(jù)、云計算和物聯(lián)網(wǎng)的前沿資訊和基礎(chǔ)知識，讓我們一起攜手，引領(lǐng)人工智能的未來！

標簽： Google 大數(shù)據(jù) 服務(wù)器 數(shù)據(jù)分析 數(shù)據(jù)庫 搜索 推廣 網(wǎng)絡(luò) 云計算

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。