作者：張子良
版權所有，轉載請注明出處
引子：什麼才算大資料？
說一下自己的了解吧，大資料是指那些很大的資料集，大到傳統的資料庫軟體工具已經無法采集、存儲、管理和分析。大資料既有存儲規模方面的考慮，同時也涉及到分析計算規模的考慮。之是以選擇雙色球算獎平台作為大資料應用的案例，也正是考慮到這兩個方面的問題。其一，曆史投注明細資訊的存儲，如果采用傳統的關系型資料庫，肯定是不合适，無論是分區還是分表，都無法解決根本問題。其二、目前投注規模的情況下，進行快速算獎，所要進行的計算規模肯定也不是一個傳統方式能輕易解決的問題。
當然關于具體多大規模的資料才算大資料，目前為止尚未有一個官方的界定門檻值的存在，規定超過多少算大資料，低于多少不算大資料的說法。既然沒有标準，也就無所謂是與不是，見仁見智，不一而足。
一、概述 業務規則
雙色球獎項設定和兌獎規則如下所示：
“雙色球”彩票以投注者所選單注投注号碼（複式投注按所覆寫的單注計）與當期開出中獎号碼相符的球色和個數确定中獎等級：
一等獎：7個号碼相符（6個紅色球号碼和1個藍色球号碼）（紅色球号碼順序不限，下同）
二等獎：6個紅色球号碼相符；
三等獎：5個紅色球号碼和1個藍色球号碼相符；
四等獎：5個紅色球号碼或4個紅色球号碼和1個藍色球号碼相符；
五等獎：4個紅色球号碼或3個紅色球号碼和1個藍色球号碼相符；
六等獎：1個藍色球号碼相符（有無紅色球号碼相符均可）。
二、資料對象分析
既然是資料規模的評估，我們要解決的首先就是資料對象的确認。針對雙色球算獎平台，我們需要關注那些資料對象呢？按照沖突論的觀點，事物的沖突分為主要沖突和次要沖突，其中主要沖突起決定性作用。是以在這裡我們隻考慮雙色球算獎平台涉及的最主要的資料對象，而不考慮其他細節問題。
資料對象主要包括以下幾個方面：
（1）銷量統計：包括全國、分省市、銷售網點的銷量彙總統計資料。
（2）中獎統計：包括全國、分省市、銷售網點的各獎項的中獎注數彙總統計資料。
（3）開獎号碼：包括每一期開獎号碼資訊。
（4）獎金資訊：包括每一期次各獎項獎金多少的統計資料。
（5）選注明細：目前期次選注明細資料。
（6）選注曆史明細：曆史期次選注明細資料。
（7）中獎選注明細：目前期中獎選注明細資料。
（8）中獎選注曆史明細：曆史中獎選注明細資料。
如果從存儲規模和計算規模兩個次元分别考慮，針對銷量統計、中獎統計和獎金資訊，我們需要關注的是計算規模；針對選注明細、選注曆史我們要關注的則是存儲規模。
三、存儲規模評估
3.1 資料結構
針對雙色球算獎平台而言，所有需要存儲的資料中，選注曆史明細資訊的存儲是規模最大的，根據目前雙色球每一期次的平均銷量來看，需要存儲的每一期次選注明細資訊約為2億條記錄。每一選注需要存儲的資訊包括：站号、操作員、流水号、銷售期、有效期、銷售時間、金額、投注明細（多條）、開獎時間和附加碼。具體如下圖所示：
為簡化我們的分析，我們将複式投注和膽拖投注明細拆分成單式投注進行存儲，具體資料結構如下：
序号
字段名稱
類型
長度
1
期次
char
7（yyyymmn）
2
站号
8（全國唯一）
3
流水号
6（右側補零）
4
red1
2（左側補零）
5
red2
6
red3
7
red4
8
red5
9
red6
10
blue
按照簡化後的資料存儲，單注明細需要的存儲空間=35位元組，每一期次需要存儲的絕對資料規模=200000000*35/1024/1024=6675.7m。如果單從這個角度來看，資料存儲規模還真的不算大。但是考慮到rdms表的存儲和通路，無論是采用分區，還是分表，能夠實作的其實隻是把資料塞進去，至于，讀出來，如何讀出來則将會是一個悲劇。不要告訴我用索引，用索引需要付出的代價是什麼，我想有更多的人比我清楚。
3.2 測試環境
項
值
備注
作業系統
windows xp
資料庫
sybase15.7
cpu
t5550
雙核1.83
記憶體
2g
硬碟
200g
3.3 測試結果-無索引插入
輪次
插入記錄數
耗時
第一輪
200w
15分03秒
第二輪
18分05秒
第三輪
19分04秒
3.4 資料庫空間-1000w記錄資料庫空間
四、計算規模評估
這部分設計到具體采用的算法，但是無論采用何種算法，2億次規模的資料周遊是必須的，之前園友提到的方法其實很好，根據開獎号碼，設計中獎選注表，利用待兌獎資料進行組合id比較，然後得出目标選注。然後進行獎項層次的細分，思路很好，可是有沒有想到過2億次乘以目标中獎選注表項個數的計算規模有是多少次呢。如果采用sql的方式，時間呢，又需要多少的時間？有資料有真相，正在跑相關的測試案例。至少目前看到的結果，很不理想。
正在跑測試資料，持續更新中，有圖有真相，有資料才有說服力！敬請關注、支援！求推薦！