前言 這一篇筆記主要是針對EDX上面的課程: BerkeleyX: CS100.1x Introduction to Big Data with Apache Spark第三個禮拜的部分．剩下兩個禮拜而已… 加油!! 相關文章 edx 課程網址在這裡 https://www.edx.org/course/introduction-big-data-apache-spark-uc-berkeleyx-cs100-1x [MOOCS:edx]BerkeleyX CS100.1x- Introduction to Big Data with Apache Spark (一) [MOOCS:edx]BerkeleyX CS100.1x- Introduction to Big Data with Apache Spark (二) [MOOCS:edx]BerkeleyX CS100.1x- Introduction to Big Data with Apache Spark (三) [MOOCS:edx]BerkeleyX CS100.1x- Introduction to Big Data with Apache Spark (四) Lecture 5 這一個章節主要是講解關於semi-structure資料結構與使用的方式． semi-structured資料主要講解就是一些類似XML或是Tag的資料結構．他有以下的缺點: 各個欄位間可能存在不一致 各個資料格式可能不盡相同(有的用英鎊有的用歐元) 各個欄位內容可能不一致 (walmart <-> wal-mart) 針對這樣的缺點，semi-structured資料使用起來雖然簡單，但是存在者某些程度上的挑戰與風險． 此外這一章節也討論了，資料讀取的速度與效能． 幾個重點紀錄一下: 對於壓縮格式的檔案讀取，讀取會比寫入快， 而Binary IO會比 Text file 快，但是Text file 壓縮後比較小(壓縮比大) LZ4壓縮比跟讀取速度都相當優秀． Lecture 6 這一張主要講解的是Structured Data，也就是主要講解關於RDBMS相關的部分．這裏主要提到就是join與各種join的計算方式． 主要要注意的就是要如何的應用 spark join． Lab2 比起Lab1來說，Lab2的份量實在是多了很多． 案例是分析一個月的Apache Log 透過Spark的一些操作可以分析一些有用的數據． 由於資料量也變大，這次的每個小案例，需要花上比較多的時間來執行． 關於regular expression的grouping 這邊有提到regular expression 的grouping，方法就可以幫你把一行字只要符合的狀況下就會切成一個Array來處理． 這裏用一個簡單的案例: test_string = "[aa bbb ccc]" match = re.search('^[(\S*) (\S*) (\S*))]', test_string) #match[1] = aa, match[2] = bb, match[3] = ccc 常用到的幾個計算方式 這裏有一些常用到的計算流程很適合做筆記： 紀錄某個資料出現個數 假設要計算某個錯誤資料每天出現幾次，計算方式可以如下： #將錯誤資料變成tuple (2015-06-15, 1), (2015-06-16, 1).... errDateCountPairTuple = errRecords.map(lambda data: (data.datetime, 1) ) #將錯誤資料透過reduceByKey之後，然後將每一個加總． errDateSum = errDateCountPairTuple.reduceByKey(lambda a,b: a+b) #排序 errDateSort = errDateSum.sortByKey() 如果要畫圖得時候 #X軸 errDateSort.map(lambda (key, value): key).collect() #Y軸...

前言 之前學習MIT關於分散式系統的部分，其實對於MapReduce與BigData的部分還是一知半解．這一堂課似乎是大家所期盼的課程，所以來學習．其實課程的節奏算是合適，我想整個Loading也不會太重． 相關文章 edx 課程網址在這裡 https://www.edx.org/course/introduction-big-data-apache-spark-uc-berkeleyx-cs100-1x [MOOCS:edx]BerkeleyX CS100.1x- Introduction to Big Data with Apache Spark (一) [MOOCS:edx]BerkeleyX CS100.1x- Introduction to Big Data with Apache Spark (二) [MOOCS:edx]BerkeleyX CS100.1x- Introduction to Big Data with Apache Spark (三) [MOOCS:edx]BerkeleyX CS100.1x- Introduction to Big Data with Apache Spark (四) 課程筆記 本堂課的目標 edx給的官方目標: 學習關於 Data Science的定義與本質 如何使用 Data Science 學習 Apache Spark 我自己的目標: 瞭解 Data Science 瞭解 Big Data相關應用 學習並且了解 Apache Spark WEEK1 (Lecture 1/2) 主要是設定環境跟一些 Big Daa的簡介，內容其實相當的淺顯易懂． 環境設定方面: 主要使用VirtualBox + Vagrant． 透過Vagrant設定好Spark之後，可以透過IPython Notebook來操作． Tranditional Machine Learning(以下簡稱: Machine Learning) 與 Data Science的差異: Machine Learning為了建立有效的Model而Data Science使用建立好的models來分析資料 Data Science的產出會是一個BI (Business Intellegence)而Machine Learning 產生是一個數據良好的模型． Data Science 流程: 取得資料 整理資料 (ETL: Extract-Transform-Load) 分析資料 Data Science實際上可能由於突變因子造成數據不可信任 ex: 新聞與事件造成Google Search string 分析失誤 解決方式： 移除該因子所造成的髒資料(Dirty Data)，重新跑運算 WEEK2 (Lecture 3/4) (Spark: 組成圖來源Spark 官網) 本週進度主要是介紹關於Apache Spark的優點(相較於 Hadoop MapReduce) 關於Map Reduce的原理與方法 Cluster Computer最困難的莫過於處理： (1) 把工作分散給各個機器 (2) 處理某些機器的fail或是過於緩慢的速度 緩慢回應(slow)與失效節點(fail)處理方式: 重啟另外的節點，把運算轉移到新節點 Apache Spark 與 Hadoop MapReduce的差異： 使用In-Memory Data Shading: (最大差異) 將儲存到Hard disk的資料，全部放到記憶體上 (由於記憶體的成本逐漸降低) 新的資料結構RDDs(Relient Distributed Datasets)...

（圖片： FDS的優化示意圖，由這裡來的) ##前言: 到了第二個禮拜，其實卡了很久在Lab2b裡面．主要不是因為要判斷的case太多，而是希望把每次的test case找到在論文中的理由或是整個學術上的依據． MIT 6.824 分散式系統 系列文章 6.824: Distributed Systems [MOOCS][Golang]MIT6_824 Distributed Systems Week2(Lec2/Lab2A) [MOOCS][Golang]MIT6_824 Distributed Systems Week2(Lec2/Lab2A) [MOOCS][Golang]MIT6_824 Distributed Systems Week2(Lec2/Lab2B) [MOOCS][Golang]MIT6_824 Distributed Systems Week3- About Paxos Algorithm [MOOCS][Golang]MIT6_824 Distributed Systems Week4- 關於Consensus協定 Raft 學習(一): 簡介，資料格式與領導者選舉 ##論文-Flat Datacenter Storage 這是微軟在2012發表的新的分散式計算系統FDS，號稱可以在60秒處理141GB的資料，打敗了當初Yahoo所創下的紀錄． FDS組成 FDS為了要達到速度快，把繁瑣的檔案系統移除．整個組成相當的簡單 (Blob 與 Tract) Blob: Blob 是FDS系統裡面的構成元件．每一個Blob由數個Tract所組成的． 一個Blob 可以包含若干個Tract 一個Blob 擁有一個唯一的GUID 其中Blob 提供以下的API: CreateBlob OpenBlob DeleteBlob CloeBlob Tract: FDS裡面最基本的元素． Tract的檔案大小是固定的(預設是8MB) 所有的Tracts 是透過 TractServer來管理，以下為Tract 相關的API: GetBlobSize ExtendBlobSize WriteTract ReadTract WriteTract GetSimultaneousLimit 實際運作上: Blob 並不需要放在同一台電腦上 為了達到速度快，可以把tract放在不同的儲存媒體上．達到類似Raid-0的效果． 用來索引各個tract位置的是TLT(Tract Locator Table)而Metadata Server就是管理TLT的伺服器． 這一篇對於組成的部分有更詳細的解釋 FDS的備份 ##第二週下半課程: ##關於Lab2 Part B:he primary/backup key/value service 這一次的作業相當的有趣，由於上一次要識做一個Server與Client間的分派者或是說控制者的角色(稱為Viewserver)． 而這次要做的就是另外兩個角色 PBServer 與 Client． ###幾個注意地方: 以下列出幾個比較基礎的地方: PBServer 與 Client 與 ViewServer三方的溝通都必須透過RPC call RPC call rpcname必須注意是要Class.Api． 舉例而言: ViewServer.Ping Client 每個動作都需要先去問ViewServer目前的primary ###開始流程: 完成Server的Get()，Put()與Ping() (Ping必須在Tick裡面) 每個transaction 必須要透過 primary 把結果傳給 backup ~ primary/backup要有傳遞備份資料與互相溝通的RPC 要新增不少個 Server需要判別自己的角色是primary或是backup (可以使用 ViewServer.Get與 me來判別) Server與Client溝通原則: 每一個Client的command，在得到reply == OK 前，必須要不斷地送． 相反的，Server必須要遵循at-most-once原則，要過濾掉重複的request client 不能在每次Get/Put去跟ViewServer詢問目前誰是primary，除非你認為primary 已經死了． 時間內沒回覆? 角色的準則裡面: Primary: Backup: 不能直接回覆client需求，而要回復錯誤 Lab2A 的Client (也就是身為 PBServer的角色) 需要知道自己的所扮演的角色 (Primary/Backup) Get Arg 增加欄位判別需求是來自 server/client...

前言: 架設好主機後，接下來開始就是要優化效能．其實有很多人建議了不少的優化與調整工具，不過這裡還是使用兩個視覺化可以很快調整的工具． gcvis: 由Dave Cheney所開發的工具，可以很清楚的觀察GC(Garbage Collection)發生的時間點與Heap的大小，讓你可以了解系統由於GC消耗的多少的系統資源． pprof:這個系統build-in的工具，可以讓你產生每個function所產生的方塊圖可以讓你清楚找出系統裡面的bottleneck． 這裏只是簡單的使用流程與心得，不過應該會有更多的資料補充． 關於gcvis 安裝與使用 go get github.com/davecheney/gcvis 使用相當簡單 gcvis YOUR_APP -index -http=:6060 就會打開一個網頁顯示目前的heap與GC狀態 關於pprof 必須要先安裝好Graphviz 執行go tool pprof http://localhost:YOUR_WEB_PORT/debug/pprof/profile (pprof) top10 (pprof) web 會出現一個圖類似以下: ###問題: Go-martini會將handler預設是沒有開放的，所以會得到404 page not found: 這邊有個討論串，我覺得Patrick這個解法挺好的． import "net/http/pprof" //Some martini init here. m.Group("/debug/pprof", func(r martini.Router) { r.Any("/", pprof.Index) r.Any("/cmdline", pprof.Cmdline) r.Any("/profile", pprof.Profile) r.Any("/symbol", pprof.Symbol) r.Any("/block", pprof.Handler("block").ServeHTTP) r.Any("/heap", pprof.Handler("heap").ServeHTTP) r.Any("/goroutine", pprof.Handler("goroutine").ServeHTTP) r.Any("/threadcreate", pprof.Handler("threadcreate").ServeHTTP) }) 心得: 使用gcvis可以幫助你瞭解目前Heap的數量，記憶體使用數量與GC發生的次數．記住，越多的GC代表著系統資源消耗在回收與釋放記憶體． pprof可以完成一個樹狀圖．不過，目前在Web Application這裏可能還需要有更多的技巧找出真正卡住系統資源的地方． Go 1.5 有出新的tracer, 等 1.5出來可以試著用用看…. 相關文件: pprof: Go的pprof使用 Debugging performance issues in Go programs Intel出的研究文章，相當詳細的解釋． bee Godoc:pprof gcvis: dfc: Visualising the Go garbage collector

##前言: 本週進入第二個禮拜，開始有一些分散式系統的備份與替換的問題還有論文． 加油吧!! MIT 6.824 分散式系統 系列文章 6.824: Distributed Systems [MOOCS][Golang]MIT6_824 Distributed Systems Week2(Lec2/Lab2A) [MOOCS][Golang]MIT6_824 Distributed Systems Week2(Lec2/Lab2A) [MOOCS][Golang]MIT6_824 Distributed Systems Week2(Lec2/Lab2B) [MOOCS][Golang]MIT6_824 Distributed Systems Week3- About Paxos Algorithm [MOOCS][Golang]MIT6_824 Distributed Systems Week4- 關於Consensus協定 Raft 學習(一): 簡介，資料格式與領導者選舉 ##第二週課程: ##關於筆記 Primary/Backup Replication (Remus) 盡量用理解後的中文紀錄，原始筆記在這裡: 關於容錯(Fault Tolerance): 希望能繼續服務儘管有問題發生． 特性如下: 可見性: 即使有問題發生，也希望服務能夠繼續． 正確性: 希望發生問題的時候，服務也跟單機一樣（無錯誤時)正確． 核心想法: 備份，透過兩個或是以上的備份伺服器來預防任何的問題產生． 重要問題: 備份機的狀態? 工作機的狀態如何轉移? 何時要切開與備份機的連接? 異常發生在切開之後？ 如何修復與重新連接備份機? 兩個關於備份機的重要動作: State Transfer (狀態轉移) Replicated State Machine: (備份狀態機) ##論文 Remus: High Availability via Asynchronous Virtual Machine Replication 這裏有網頁版本 Remus 的系統特色: 整個系統備份 對於Application與Client而言是透明的． 當運行成功的時候，備份與切換機器就運作順暢 圖片元素解釋: Primary: 具有資料，會執行OS與App，並且負責跟Client溝通． Backup: 只有資料，但是不執行OS與App．只有跑一些Remus的code 流程簡介： (1) Primary 跑完 Completed Execution (E1)，並且先不回傳E1結果回client． (2) Primary把結果備份到Backup (背景執行) (3) Backup同步所有目前資料跟Primary一樣． (4) Primary 執行Speculative Exection (E2)，並且先不回傳給client (5) Backup 複製所有結果 (6) Primary放出E1結果 (7) Backup 把結果存入RAM/Disk. Remus 特性與檢討: Remus系統的估計 速度為單機系統的1/2~1/4 Check point時間過久 為了要能夠與client溝通，保留結果的時間不能太久 缺點 速度不快: 由於每個Exection都必須等待Backup 複製好相關資料。 Check point 至少等花上100ms 如何改善: 減少主機儲存資料 減少狀態的資料量，或是優化資料格式 試著傳送指令而非狀態 ##關於Lab2 Part A:ViewService 這一篇有點困難，所以稍微做點筆記: ###題目解釋: 主要要implement 一個具有faul-toerant的key/values services- Viewservice．這個Service有以下的幾個功能: 監控 Primary (指的是原始service) 與 Backup(備份用的Service)是否是正常工作． 正常而言，如果Primary壞了，會自動地把Backup promoted成 primary．此時如果有空的server就會拉近來變成新的Backup． 當新的Primary與Backup上線後，Primary還有一個工作： 備份所有資料庫給Backup 所有的command...

##前言: 主要是Golang.Tw上面有人在問，加上這門課程的作業本身是使用Golang來開發．就還蠻有興趣玩玩看． 課程鏈結在這裡．6.824: Distributed Systems MIT 6.824 分散式系統 系列文章 6.824: Distributed Systems [MOOCS][Golang]MIT6_824 Distributed Systems Week2(Lec2/Lab2A) [MOOCS][Golang]MIT6_824 Distributed Systems Week2(Lec2/Lab2A) [MOOCS][Golang]MIT6_824 Distributed Systems Week2(Lec2/Lab2B) [MOOCS][Golang]MIT6_824 Distributed Systems Week3- About Paxos Algorithm [MOOCS][Golang]MIT6_824 Distributed Systems Week4- 關於Consensus協定 Raft 學習(一): 簡介，資料格式與領導者選舉 ##第一週課程: ###Paper1: 鼎鼎大名的Google Mapreduce 論文: 課程內容主要是要讀鼎鼎大名的mapreduce系統論文． ###Lab1: 寫一個簡單的Map跟Reduce 然後來寫一個Lab1 Word Count的小程式．裡面主要要完成兩個functions： Map: 把文章裡面的字拆出來後，放入一個List． List 裡面的內容是文字與出現的次數． Reduce: 就每個檔案裡面的所以出現單字找出來，並且回傳它的加總． 課程算很簡單，主要是要對於mapreduce有基本的了解．我一開始不是很了解，比對了參考文章內的內容跟論文演算法就看懂了． 其實還挺有趣的． 寫完裡面還有go test 可以去驗證你的想法有沒有問題． ###簡單介紹RPC 第一週後半段其實還有一部分是RPC的部分，還好最近有點研究．所以也很快地讀完筆記． 主要講解內容如下: 什麼是RPC Server． RPC 架構下會有什麼問題？ (斷線，命令未收到，命令未完成) 如何解決: “最少一次”: 優點： 可以確認server有執行到． 使用範圍: 可以用: 重複性質的讀取 不能使用: 存款 “最多一次” (Go RPC就是這種) 會把重複的需求挑出來，直接回答上一次的結果而不是再跑一次． 怎麼分辨是不是重複： 透過unique ID． Lab2 要玩這部分． “剛好一次”: 也就是最多一次的系統加上unbounded retries跟容錯設計．Lab3要玩這個． Go thread: 何時使用Go channel 何時使用 shared memory + lock: Channels: 確定要兩個thread互相溝通，一個等待另一個回傳． Shared memory + locks: 需要共用資料，但是不需要等待另一個結果． ##參考文章: 關於MapReduce的Invert Index