目的和意義

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

題目分析(含數據源)

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

構建一個模型，根據天氣，交通，區域里面的各種設施，以往歷史數據，預測未來的某個時間點，某個區域里，打車需求的缺口。整個算法其實就是一個有監督的機器學習的過程。

數據整理

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

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

關于訂單的目標區域HashCode，這里發現一部分數據是無法找到的，可能是跨區域的。
（全部訂單：498789 ，目的地可以找到：406138，跨區域：92651）

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

訂單數據整理

訂單數據整理，主要是整理出各個時段，各個地域的訂單數據。

• 時間段
• 地域編號
• 需求數
• 缺口
• 缺口比例

數據整理盡量使用LINQ進行處理，MONGODB查詢是消耗時間的！！！，這里數據庫只是用作數據的存儲不做計算

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.                    //暫時只分析一天數據

36.                    ;break;

37.                }

38.            }

39.        }

利用Excel，可視化數據

2016-01-01 分時圖

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

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

整體上看，所有區域的分時圖 2016-01-01的數據圖：

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

2016-01-02 分時圖

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

各項指標分析

起始區域差距

以下數據為2016-01-01的數據統計

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

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

起始區域POI整體數目和訂單數關系

我們將POI總數/30 和訂單數一起放到柱狀圖中發現，POI總數和訂單數應該有一些聯系。
一個區域POI數越多說明這個地區越是繁華，從這里打車的需求就越多。

POI子項目和訂單關系

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

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

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

2. Q: 關于POI數據的分類一共分多少1級類目，多少2級類目，且是否有類目示意的對照表?
   A: 這個問題的答案都在數據中，參賽者可以自行統計。類目對應信息其實不是很重要，重要的是分析其和目標的關聯程度。

天氣和訂單的關系

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

當天全時段的PM2.5和溫度分時圖

天氣類型編號和天氣描述，請參見 滴滴算法大賽算法解決過程 - 機器學習

當天的全區域的訂單情況分時圖

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

關于WeekDay

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

第05區域也是這樣的。

交通和訂單的關系

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

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

看一下Level4 #51區域的情況

詳情請咨詢！

客服熱線：023-66090381