2012年10月9日 星期二

[筆記] Technical Workshop: AWS DynamoDB and Elastic MapReduce

話說今年六月的時候有寫過一篇"要使用大象,真的得養頭大象嗎?為何不使用AWS EMR",但是我得先自首,寫完這篇以後就根本沒有時間去研究了,科技日新月異,我只覺得大象離我越來越遠了......(不要走~~)。話說這個月剛好有時間,就想說把Hadoop 架起來玩玩看(Cloudera CDH4),結果沒遇到什麼問題就裝好了,而且還附帶精美完整的Cloudera manager Dashboard和監控畫面,只能驚嘆科技日新月異,只要短短幾個月沒跟上就差很多了...(感嘆貌~)

好這都不是重點~XD 重點是這個星期剛好Amazon 有舉辦 AWS DynamoDB and Elastic MapReduce 的 Technical Workshop,當然就二話不說立馬報名~



由於這次講的主題是針對產品的技術Detail 去介紹和探討,如果對NoSQL 不認識或不了解,可能會容易聽不懂吧?我在這邊嘗試著整理我有記錄到的筆記再加一些我的記憶。

DynamoDB


一開始講師Jidesh 先定義怎樣的情境該使用NoSQL (for high throughput),什麼時候還是該用SQL (specific data with structure attribute),然後才開始進入主題介紹DynamonDB,不過講師還是建議大家有時間的話還是先去看 Amazon CTO - Werner Vogels 所寫文章 和介紹paper (PDF)。

DynamoDB 的定位很明確,就是專門處理 High throughput , Small size item (
64k item size limit, 1KB metering for throughput),特色如下:
  • 沒有Schema 的概念,就只有很簡單Key-value pair的table
  • 兩種Hash Key 模式 :Single Key & Composite key (Range key) 
  • No index Query API ,only scan API

此外Jidesh 花了很多時間在解釋Dynamo DB 神奇的 partition (or Sharding?)機制,簡單來說他們是透過ring 的概念去做資料的hash,所以會盡量的把資料分散到各個node,但是如果有某筆資料存取特別頻繁(hot data),Jidesh 會建議可以把Key 再次分散,比如說Key=a,改成Key=a1,a2,a3....等,不過我也有問他那目前有提供任何的機制去監控hot data access嘛?結果目前是還沒有的,所以看樣子只能透過經驗法則,如:
  • 如發現系統效能變慢
  • 發現資料存取throughput 太大
這時再去找是否request 都hit 到同一個partition,這時候就要把某個key切分出來,或是把這些資料移到另一個table.....(感覺很難追蹤..@@)

目前也有提供免費試用方案(Free tier),詳情請見官網:

● 10 reads/sec and 5 writes/Sec
    - Metering is done in 1KB blocks
    - 10, 1KB items equivalent to 1,10KB item
● Scan and Edit Tables in the AWS console

Elastic MapReduce

在介紹EMR之前,Jidesh 先重新介紹了一下Big Data ,其種講到幾個重點:
  • 3Vs (Volume & Velocity & Variety)
  • Big Data  到底要收集什麼,越來越難定義,越來越多東西都要收集,事後再來分析
  • New model is collect as mush as possible. "Data-First " Log everything!
  • Collect & store & analyze & share
此外他們還別強調Amazon的 hadoop 是有特別調教的,在所有Distrubtion裡面是最厲害的~:P




後面就是最刺激的Live Demo 啦,教材都有放在網站上,這次講的題目是:

後記:

所以EMR有兩種用法,一種是開了只做短暫的分析,另一種是開了就拿來做長期使用,真的跑Hadoop的Service 在上面,不過這時候價錢就會是考量了....

Reference:
[1] AWS Elastic MapReduce Document

張貼留言