目的和意義

很難有機(jī)會接觸這么多的實際真實數(shù)據(jù)。
通過對于這些數(shù)據(jù)的分析，初步了解的處理方式。
進(jìn)一步掌握MongoDB的特性，熟練Excel的高級用法。
這里只是做分析，不提供源代碼，畢竟是一個比賽。
這里只是做分析，不提供源代碼，我也無意開發(fā)一個完整的程序。

題目分析(含數(shù)據(jù)源)

//research.xiaojukeji.com/competition/detail.action?competitionId=DiTech2016

構(gòu)建一個模型，根據(jù)天氣，交通，區(qū)域里面的各種設(shè)施，以往歷史數(shù)據(jù)，預(yù)測未來的某個時間點，某個區(qū)域里，打車需求的缺口。整個算法其實就是一個有監(jiān)督的機(jī)器學(xué)習(xí)的過程。

數(shù)據(jù)整理

（5月20日版本）下載后的整個壓縮數(shù)據(jù)包575M，其中包括的訂單數(shù)據(jù)大約900萬條。（其他Master表數(shù)據(jù)量很小，這里忽略不計）
使用MongoDB存儲的話，大概使用2GB的空間，全部導(dǎo)入之后，工作用計算機(jī)十分卡頓。MongoCola管理軟件失去響應(yīng)。所以，這里的訂單按照日期導(dǎo)入。（訓(xùn)練的時候，按照天來訓(xùn)練）
注意：官方的訂單數(shù)據(jù)的 訂單號 OrderID是主鍵重復(fù)的。這里以第一次出現(xiàn)的訂單號的數(shù)據(jù)為準(zhǔn)。
官方對于重復(fù)訂單的解釋：

1. Q: 在order info 中重復(fù)出現(xiàn)的數(shù)據(jù)應(yīng)如何處理？ A: 數(shù)據(jù)重復(fù)是因為同一個用戶可能在一個10分鐘片同一個地區(qū)發(fā)單被多次應(yīng)答，但是這樣的情況并不多，影響并不大。為了簡化問題，重復(fù)的訂單不需要去重，直接計入到缺口的計算中。

關(guān)于訂單的目標(biāo)區(qū)域HashCode，這里發(fā)現(xiàn)一部分?jǐn)?shù)據(jù)是無法找到的，可能是跨區(qū)域的。
（全部訂單：498789 ，目的地可以找到：406138，跨區(qū)域：92651）

由于數(shù)據(jù)量非常龐大，所以這里建議將中間的計算結(jié)果也放入數(shù)據(jù)庫中備用。

訂單數(shù)據(jù)整理

訂單數(shù)據(jù)整理，主要是整理出各個時段，各個地域的訂單數(shù)據(jù)。

• 時間段
• 地域編號
• 需求數(shù)
• 缺口
• 缺口比例

數(shù)據(jù)整理盡量使用LINQ進(jìn)行處理，MONGODB查詢是消耗時間的?。?！，這里數(shù)據(jù)庫只是用作數(shù)據(jù)的存儲不做計算

1.        private void btnImportDB_Click(object sender, EventArgs e)

2.        {

3.            string rootFolder = txtRootDir.Text;

4.            //Order: Root + "\order_data"

5.            foreach (var filename in Directory.GetFiles(rootFolder + "\\order_data"))

6.            {

7.            ;    if (!filename.Contains("._"))

8.                {

9.                    string strDate = filename.Substring(filename.LastIndexOf("_") + 1);

10.      ;              var colname = "Order_" + strDate;

11.                    Database.Clear(colname);

12.  ;                  var orderlist = new List<Order>();

13.                    var read = new StreamReader(filename);

14.                    while (!read.EndOfStream)

15.                    {

16.        ;                var o = Order.Gernerate(read.ReadLine());

17.      ;                  orderlist.Add(o);

18.                    }

19.        ;            orderlist = orderlist.Distinct(x => x.order_id).ToList();

20.                    Database.InsertRecBatch(orderlist, colname);

21.                    var orderGaplist = new List<OrderGap>();

22.                    Database.Clear("OrderGap_" + strDate);

23.           &nbsp;   &nbsp;    for (int time = 1; time < 144 + 1; time++)

24.                    {

25.               &nbsp;        for (int area = 1; area < 66 + 1; area++)

26.                        {

27.                            var m = new OrderGap() {  DistrictId = area,TimeSlient = time};

28.                          ;  m.Total = orderlist.Count((x) => { return x.DistrictID == area && x.TimeSlient == time; });  

29.                            m.Gap = orderlist.Count((x) => { return x.DistrictID == area && x.TimeSlient == time && x.driver_id == "NULL" ; });

30.                            m.GapPercent = m.Total == 0 ? 0 : Math.Round(((double)m.Gap / m.Total) * 100, 2);

31.      ;                      orderGaplist.Add(m);

32.                        }

33.                    }

34.                    Database.InsertRecBatch(orderGaplist, "OrderGap_" + strDate);

35.                    //暫時只分析一天數(shù)據(jù)

36.                    ;break;

37.                }

38.            }

39.        }

利用Excel，可視化數(shù)據(jù)

2016-01-01 分時圖

以下是2016-01-01的數(shù)據(jù)分析。藍(lán)色的是GAP缺口數(shù)，紅色的是Total數(shù)。
一天24個小時整體需求分布可以看個大概了。
PS 區(qū)域1 ：占整體的5.1%訂單量，有一定的參考價值

區(qū)域51 ：占整體的22.5%訂單量，有一定的參考價值

整體上看，所有區(qū)域的分時圖 2016-01-01的數(shù)據(jù)圖：

這里看到，整個24小時分布極不均衡?？紤]到 01-01 是一個特殊的日子，大家為了跨年而在零點之后選擇打車也是可以理解的。

2016-01-02 分時圖

同樣的51區(qū)域，2016-01-02的情況則比較正常，整體的高峰出現(xiàn)在夜間16：50 - 17：20（評價訂單850） 左右。21：10，22：00也是兩個小高峰（平均訂單720）。

各項指標(biāo)分析

起始區(qū)域差距

以下數(shù)據(jù)為2016-01-01的數(shù)據(jù)統(tǒng)計

整體有效訂單數(shù)：498789（訂單ID去重復(fù)）
66個區(qū)域的訂單分布是極其不均衡的.

排名后33位的，總共只有整體的4.37%的訂單
排名前5位的，總共只有整體的50.87%的訂單

起始區(qū)域POI整體數(shù)目和訂單數(shù)關(guān)系

我們將POI總數(shù)/30 和訂單數(shù)一起放到柱狀圖中發(fā)現(xiàn)，POI總數(shù)和訂單數(shù)應(yīng)該有一些聯(lián)系。
一個區(qū)域POI數(shù)越多說明這個地區(qū)越是繁華，從這里打車的需求就越多。

POI子項目和訂單關(guān)系

滴滴打車的POI分為了25個分類，我們選取了 2016-01-01 對于POI的分類和訂單之間的關(guān)系也作了研究。
按照實際來說，例如有100家KTV，則每家KTV為貢獻(xiàn)一些訂單。同理，如果是飯店，每家飯店也會貢獻(xiàn)一些訂單。
這里的圖表示了各個POI分類的數(shù)量和總體訂單的關(guān)系。

• 如果有0100家N類POI，整體訂單是100，則比率是01。
• 如果有1000家N類POI，整體訂單是100，則比率是10,
• 如果有0010家N類POI，整體訂單是100，則比率是0.1。
  這個比率越小表示該P(yáng)OI分類對于可能對于整體貢獻(xiàn)越大。當(dāng)然，如果該分類表示一些極為特殊的設(shè)施，例如市政府，則不在考慮之內(nèi)。
  所以這里需要過濾掉POI數(shù)量過小的情況。
  （注意：這里為0的意思是沒有該類別的POI。分子為0）Q：為什么在POI信息表中有的類別沒有用#區(qū)分？

1. A：不是所有設(shè)施級關(guān)系都是a#b：xx的格式，有的設(shè)施只有一級，而有的設(shè)施甚至有三級，#號只是表示分割層級的關(guān)系，如果是設(shè)施只有一級則為a:xx，而如果是2級則是a#b：xx，如果是3級則是a#b#c：xx，依次類推。

2. Q: 關(guān)于POI數(shù)據(jù)的分類一共分多少1級類目，多少2級類目，且是否有類目示意的對照表?
   A: 這個問題的答案都在數(shù)據(jù)中，參賽者可以自行統(tǒng)計。類目對應(yīng)信息其實不是很重要，重要的是分析其和目標(biāo)的關(guān)聯(lián)程度。

天氣和訂單的關(guān)系

天氣數(shù)據(jù)庫是里面的數(shù)據(jù)分為PM2.5的值。天氣狀態(tài)編碼（編碼和實際對應(yīng)關(guān)系未知），以及溫度情況。
按照道理來說，如果天氣越差，則打車的需求就越旺盛。
下面我們來分析一下天氣和訂單的關(guān)系。
選擇 2016-01-03作為分析對象。
天氣數(shù)據(jù)每個時間片測試兩次，為了方便觀察，我們選擇第一次測試結(jié)果作為考察對象。

當(dāng)天全時段的PM2.5和溫度分時圖

天氣類型編號和天氣描述，請參見 滴滴算法大賽算法解決過程 - 機(jī)器學(xué)習(xí)

當(dāng)天的全區(qū)域的訂單情況分時圖

從一天的時間看，在不明確天氣類型的時候，PM2.5和溫度對于整體的影響很難看到直接關(guān)聯(lián)的證據(jù)。

關(guān)于WeekDay

我們考察最繁華的51區(qū)域，周一到周日對于訂單量的關(guān)系。
這里觀察到并沒有什么規(guī)律可循

第05區(qū)域也是這樣的。

交通和訂單的關(guān)系

這里的交通數(shù)據(jù)是每個區(qū)域里面，不同擁擠狀況的道路條數(shù)。
2016-01-07 #51 區(qū)域分時擁堵狀態(tài)圖 （0：10 -23：50 143個數(shù)據(jù)）

大部分情況下，Level1的道路條數(shù)占據(jù)了絕大多數(shù)。（LV4最擁堵）

看一下Level4 #51區(qū)域的情況

詳情請咨詢！

客服熱線：023-66090381