[書摘] 大數據 - 第二章- 更多的資料

圖片來源：博客來

前一陣子寫了一篇關於BigData的基本問題 - 到底要多大?要多快? 原本嘗試著要用物理性質的角度來思考到底多大才算是大數據，何時才需要使用不同於傳統的技術?

但是看了這本書才看了第二章馬上就給我不同的思考角度，首先他先說明巨量資料是關於三種思維的改變：

1. 是要針對特定主題分析龐大資歷料整理的能力，而不是退而求其次分析較小的資料集
2. 願意接受真實資料會雜亂不清的事實，而不是一味追求精確
3. 要更看重相關性，而不是追求難以捉摸的因果關係

針對第一點， 他不是用一般傳統的4V去解釋Big Data，他是用如何處理資料的角度來解釋何謂Big Data。

在這章節給Big Data (巨量資料) 下了一個定義：

巨量資料的"巨量"不是絕對、而是相對的概念，指的是要有完整的資料集。 

在過去因為受到收集與計算技術的限制，難以全面性的收集資料，所以統計學才因此誕生，而其中最核心的方法就是在抽樣，不過統計學家也證實要提高抽樣的準確度，最好的方式並非增加樣本術，而是要做到隨機抽樣 (不過要如何設計一個好的隨機抽樣永遠都是一個難題，而且會有局限性)

因此真正得巨量資料判斷標準，在於是否使用隨機抽樣*， 也就是說就算全部的資料(樣本=母體)資料量不一定很龐大，但是不再使用抽樣的方法去操作資料就是所謂的巨量資料。


不過第三點就很值得玩味，作者舉了Google 流感，與Jobs DNA定序的例子，指出很多時候我們只要能透過全面資料運算，看到有這樣的模式/現象，其實就足夠了，不一定要去追求為什麼會有這樣的現象/模式或是嘗試去了解它們交互關係原理是什麼。

(謎之音：找到能賺錢的價值就夠了，至於原因上帝知道就夠了~)

圖片來源：Only God knows

(謎之音：看樣子這大數據這本書比雲端時代的殺手級應用：Big Data海量資料分析 有內容多了，也多了一份哲理在~:P  就讓我們繼續看下去....)

延伸閱讀：
[1] 抽樣方法
[2] 抽樣與代表性 (Sampling and representativeness)

[筆記] Spring Annotation 的意義

在很多網路上的範例程式，常常都會看許多相同的場景卻用到到各種不同的寫法，最常見的就是Spring的Annotation，到底什麼時候該用什麼樣的annotation呢？

參考stackoverflow這篇文章 What is the most appropriate way of injecting daos in services, services in controllers in Spring? 的解釋：

@Service and @Repository are just "sub-annotations" for @Component to specify the bean a bit more (to separete Services from Repositories for more sophisticated stuff). From the point of injection this three are equal.
For injection, there are 3:

• @Resource (JSR-250)
• @Inject (JSR-330  --> Google-guice)
• @Autowired (Spring only)

也就是說@Autowire是spring原本在使用的Annotaion，而@Resource和@Inject 是後來定的業界標準，新版的Spring也都可以相容，如果沒有打算使用其他Ioc的framework如Google-guice，那還是仍然可以使用Spring原生的annotation。

詳細的比較可以參考Spring 3.1 - beans-standard-annotations-limitations

Table 4.6. Spring annotations vs. standard annotations

Spring	javax.inject.*	javax.inject restrictions / comments
@Autowired	@Inject	@Inject has no 'required' attribute
@Component	@Named	—
@Scope("singleton")	@Singleton	The JSR-330 default scope is like Spring's prototype. However, in order to keep it consistent with Spring's general defaults, a JSR-330 bean declared in the Spring container is a singleton by default. In order to use a scope other than singleton, you should use Spring's @Scope annotation. javax.inject also provides a @Scope annotation. Nevertheless, this one is only intended to be used for creating your own annotations.
@Qualifier	@Named	—
@Value	—	no equivalent
@Required	—	no equivalent
@Lazy	—	no equivalent

Reference:
[1] Spring 3 and JSR-330 @Inject and @Named example

關於BigData的基本問題 - 到底要多大?要多快?

圖片來源：technode

關於BigData的基本問題 - 到底要多大?要多快? 才需要從RDB 換到Hadoop?我們常常可以看到下面這種再說明全世界一直再快速的產生資料：

How BIG is Big Data? infographic

但是這些東西都離我們太遠了，畢竟我們不是Facebook，我們也不是youtube，那對於一般企業來說怎樣的資料算是大？怎樣的資料量需要轉移使用Hadoop的技術呢？

首先要思考的問題是傳統資料庫在怎樣的資料量下，擁有怎樣的效能是合理的？當資料量超過多少以後，則效能才會有顯著的差異，此時才比較適合換成NoSQL Solution? 不過這個問題可能還是得分成兩種狀況來討論：

• 資源足夠的大企業(大多以Oracle為首選標準配備)
• 一般網路公司中小企業 (可能就是用MySQL / PostgreSQL...等選擇)

那先來看看Oracle，剛好我Google到一篇文章-What is The Maximum Datafile Size Limit In Oracle Database 10gR2 ，這篇文章參考Oracle 11g 提供的文件 Physical Database Limits，主要是再描述Oracle可以儲存多少的資料，一般來說Oracle有兩種 Database Block Size：

• Small File Tablespace (Normal Tablespace)       : 4194303    (2^22 -1) 
• Big File Tablespace   (New in 10gR2)                : 4294967295 (2^32 -1) 

Database Block Size	Maximum Datafile File Size
2k	4194303 * 2k    = 8 GB
4k	4194303 * 4k    = 16 GB
8k	4194303 * 8k    = 32 GB
16k	4194303 * 16k  = 64 GB
32k	4194303 * 32k  = 128 GB

Max datafile size for BIG FILE TABLESPACE would be:

Database Block Size	Maximum Datafile Size
2k	4294967295 * 2k   = 8 TB
4k	4294967295 * 4k   = 16 TB
8k	4294967295 * 8k   = 32 TB
16k	4294967295 * 16k = 64 TB
32k	4294967295 * 32k = 128 TB

如果block size 是32KB，則單表空間(DataFile Size)最大可以長到128TB，而一個數據庫最多有64K表空間，則可以計算出理論上的極限值是128TB *64 K= 8192 PB= 8EB 這是能儲存的理論極限值，但是實務上不可能會這樣使用，更何況還要考慮其他因素，比如說做系統的的FileSystem，實際硬體的儲存媒介...等。

不過知道可以存多少有意義嘛？資料庫之所以有意義，重點不是在於能儲存多少，而是這麼多資料能在多少時間內Query出來，因為資料越多Performance 一定會越糟，而傳統DB又只能用Scale Up的方式去擴增，不像Hadoop是用Scale Out的方式，關於這點我們可以參考Oracle的這篇文章，Sizing for data volume or performance or both?，近幾年來Oracle也提出不少與Hadoop借接混搭的Solution & Architecture，以及Big Data Appliance ，那他怎麼看待這個基準線呢？直接節錄結論：

You will need to worry about the processing requirements and you will need to understand the characteristics of the machine and the data. You should not size a system, or discard something as too big right away by just thinking about your raw data size. You should really, really consider Hadoop to be a system that scales processing and data storage together and use the benefits of the scale-out to balance data size with runtimes.

雖然Hadoop的硬碟花費可能會是傳統DB的 三倍以上，但是他可以透過增加機器來維持甚至增加運算的效能，所以我好奇的是Break Even point 在哪裡？怎樣的資料才需要使用這些技術？ 不然這些"為了未來Scale out 做準備 "的 slogan 就只是一般商業行銷用的話術， 很多網站和企業說實在資料根本不會成長到那麼大....)


基於這個問題我開始上網找一些資料，首先先來看看業界的實際案例，到底在怎樣的資料大小下，傳統的RDB會出現無法接受的效能呢？

案例一：Hadoop World 2011: Replacing RDB/DW with Hadoop and Hive for Telco Big Data

這是國外一家電信商在做CDR分析的案例，每個月將近15TB的資料， 一年可以達到254TB

案例二：Case Study - How Rackspace Query Terabytes Of Data

• Rackspace has more than 50K device
• System store 800 million object (an object=email or log) within Solr
• 9.6 billion records within Hadoop = 6.3TB compressed
• Several hundred gigabytes of email log data

案例三：Hadoop Use Cases and Case Studies

在這裡面有列出各個產業的案例以及資料量，最低標準至少是 1TB of data / month


其實沒有一個定論，只能引用Agile與Lean的名言：No Big Design Up Front (BDUF)，不要預先想太多太早最佳化，可能我們應該就像這家遊戲廠商一樣，真的遇到大量資料的問題了在想辦法轉移就好~:P

Big Data at Riot Games from Hadoop_Summit