[Golang]關於MacOSX Desktop Notification(桌面提醒)

image

##前言:

想要寫一個小工具,可以把一些http link傳給下指令的人.卻又苦於一般CLI無法直接顯示Hyperlink.想說參考了一下gomon,不過卻發現原來MacOSX的桌面通知有不少方式可以顯示.

##可以發送MacOSX Desktop Notification的方式:

[免費的] 透過Apple Script來發送

Apple Script 提供一個簡單的方式,可以在任何Application 或是 CLI的來發送通知.

不過他有一些缺點:

  • 不支援HTTP LINK
  • 不支援自訂圖片
  • 無法自訂標題或是ICON

這裏有一個Golang 的小工具,有將Apple Script 整理過https://github.com/everdev/mack

[免費的] 透過terminal-notifier

terminal-notifier是一個由ObjectiveC與Ruby構成的小App,可以透過Homebrew來安裝.

雖然可以開啟URL,但是還是有以下的缺點:

  • 無法自訂圖片
  • 不支援ICON

[付費] Growl

Growl算是相當知名的Notification App,提供相當多的API給使用者使用.

這裏列出幾個Go的相關工具:

  • go-gntp
    • 透過Golang來呼叫Growl 的APIs
  • Gomon
    • 會幫你檢查source code並且回報給你.不過也是透過Growl來做的.

[MOOCS][Golang]MIT6_824 Distributed Systems Week3- About Paxos Algorithm

前言:

由於之前無論文有點久遠,先把論文瞭解的部分先寫成文章.之後再來把Lab3寫出來…. 這一篇主要是講Paxos算法的部分

MIT 6.824 分散式系統 系列文章

6.824: Distributed Systems

##論文-Paxos

先拿出一張各種的consensus的解決方式比較圖.

image

論文的原文,Leslie Lamport,(就是 LaTeX 中的”La”)在1990提出該演算法後,由於太難懂沒有受到重視.於是他又寫了一篇來解釋自己的演算法其實很簡單. 很有趣….

共識問題

Paxose主要是要解決共識(consensus)的問題,這一個Quora舉了一個很有趣的案例討論什麼叫做共識(consensus),就像是婚禮的誓詞一樣.

  神父: 新娘你願意嫁給新郎? 
  新娘: 願意
  神父: 新郎你願意娶新娘嗎?
  新郎: 願意
  神父: 那..我宣佈你們成為夫妻

2PC (Two Phase Commit)

類似這樣就叫做共識問題,而一開始提出的解法就是2PC(Two Phase Commit)

  • Vote-Phase: 由協調者(也可以稱為提案者,原本也是其中一個節點)提案所有節點(node),是否同意某個數值(或是交易).其中協調者需要詢問所有的節點,確認大家都是同意的.
  • Commit-Phase: 當協調者確認全部人同意後,他會執行這個動作.並且也告訴所有的節點,要執行這個部分(數值或是交易)

缺點:

  • 指令相當繁瑣,需要一共三次的溝通.如果有n個節點,就需要有3n的資訊往來.
    • 協調者 -> 節點 (是否同意?)
    • 節點 -> 協調者 (我同意)
    • 協調者宣布提案成立
  • 任何一個節點的失敗不會造成該提案失敗,但是如果在詢問的過程中協調者忽然離線了.其他的人就無法知道狀況與結果.

為了避免協調者離線的問題,於是乎有了3PC的方式 (Three Phase Commit)

3PC (Three Phase Commit)

  • Phase 1: 跟Vote-Phase一樣,協調者會問所有的節點.
  • Phase 2(新步驟): 協調者取得所有人的共識後,會發送一個”Prepare to Commit”的訊息給所有的節點.這個動作的重點是,告訴所有的節點我們已經取得所有人的共識.要開始執行提案.(表示該提案已經成立,不會退回).此時所有節點也會回傳給協調者告知是否有收到.
  • Phase 3: 跟Commit-Phase一樣,協調者會執行提案後也告訴所有節點要執行該提案.

解決的問題

  • 如果在3PC的狀況下,如果在Phase 2發生了協調者離線(crash),新的協調者只要重跑一次Phase2 即可,不需要重新詢問Phase 1.
  • 如果是在Phase 3發生crash,由於已經收到回應確認全部人都已經有收到Prepare to Commit.所以新的協調者繼續執行最後步驟即可.

缺點

雖然3PC解決了重大問題,但是還是存在一些問題如下:

  • 步驟變得更繁瑣,需要訊息量也從3n變成5n (2 + 2 + 1)
  • 無法解決如果網路發生問題造成某些節點以為還在第二步驟,某一些節點卻又到了第三步驟.

Paxos Algorithm

image

(Image comes from here)

為何我們需要Paxos Algorithm?
  • 雖然解決了協調者crash問題,但是無法結果Partition Failure.也就是由於某些網路問題造成數個節點離開.(或是中間節點鍛造成兩個子網路)這也是所謂的 Partition tolerant algorithm.(尤其現今網路的狀況,這種情況更容易發生)
  • 原來不論是在2PC或是3PC討論的都是協調者失效後,由其他人來替代的方案.但是現在要討論的是,節點失效後採取的復原方式與相關的處理.這樣會更有效用.根據原文也就是說 3PC是 fail-stop resilient但是比較需要的應該是fail-recover resilient.
關於Paxos的起源與假設

Paxos主要是根據Lamport所提出的一個寓言故事,也就說個古希臘愛琴海上的被稱為Paxos的小島的故事.根據該小島議會制度所提出的演算法,裡面有幾個主要的假設:

  • 小島上的人忙著經商,所以不會一直在議會裡面.也就是共識可能是在大家不一定全部都在的狀況下產生.所以他只需要大多數的人同意即可.
  • 不會有拜占庭將軍問題(也就是一個訊息被傳遞兩次的問題).而且訊息不管要經過多久,都會被傳到.
  • Paxos小島上的人性本善,基本上提出的提案都會被同意.
主要運作原理:

某些層面跟2PC很類似,但是主要精神不同:

  • 選舉出一個leader(或是提案者)
  • 提案者提出一個提案(acceptor)傳給大家(這個訊息稱為acceptor-request)在一個限定的時間內(a given time).
  • 不同於2PC,Paxos只需要大多數的人回覆同意即可繼續發送commit message給所有節點
如果leader(提案者)failure?

由於原本2PC方式沒有辦法處理leader錯誤的狀況.在這裏Paxos提供以下兩個機制來處理:

  • Assign an order to leaders: Paxos不像是 2PC ,他可以存在多個Leader.在他們發現leader failure的時候,其他節點就會推選出新的leader.並且給予每個leader一個順序.預防原本的leade又從failure recover回來.
  • Restricting leader’s choice in selecting value: 要如何能讓consensus的過程在新的leader上面繼續? 就是要限制在這個時候被推選的leader的提案.必須是之前的acceptor (也就是說正在進行中的consensus的數值).
Protocol Step:

以下的敘述,主要以議會的方式來解釋各個狀態:

  • 準備階段(Prepare Stage):
    • 被選為提案者提出了一個提案,其中Proposal 1的數學表示為 P1(x, y) (x: 提案的流水號, y: 提案的內容)
    • 如果是第一個提案,所有議員都會同意.而且同意該提案後.並且議員回覆自己上次同意的號碼給提案者.並且承諾之後所有提案流水號小於x的提案都會被拒絕
    • 議員大多數狀況下只會同意,但是在以下狀況會拒絕:
      • 該提案內容(v)與前一次的提案內容相同.
      • 該提案號碼小於之前同意的提案流水號.
  • 核准階段(Commit stage):
    • 提案者會在收到大多數的人回覆同意之後,將告知所有節點要把提案交付.並且把上一次的提案數據附上.如果沒有前一次數據,提案者可以自行加入任何數值.
    • 議員再收到交付的訊息後,為了不違背之前的承諾.都會把提案內容交付.

參考資料:

[MOOCS:edx]BerkeleyX CS100.1x- Introduction to Big Data with Apache Spark (四)

image

前言:

最後一週,只有Lab.而最後一個Lab其實也接著之後的進階課程Scalable Machine Learning. 所以最後一次的Lab開始介紹Spark關於Machine Learning的部分.喜好電影預測是個很有趣,很實用的課題.

相關文章

edx 課程網址在這裡 https://www.edx.org/course/introduction-big-data-apache-spark-uc-berkeleyx-cs100-1x

Lab4 - Predicting Movie Ratings

image

這一次的Lab主要是要做透過使用者對於喜愛電影的評分,加上從MovieLen上面超過10M資料抽出50萬筆一般大眾的評分資料.來預測你可能會喜歡的電影.運用的技術是所謂的“協同過濾”(Collaborative filtering)的方式來達成.

簡單的概念就是: 如果一般人喜歡A電影的同時,大多也喜歡B電影.當你輸入你喜歡A電影的時候,系統就會預測出你可能也喜歡B電影.

上面的圖片可以有一個簡單的概述,也就是透過以下流程達成:

  • 建立參考數值(也就是我們所認知的一般人喜好)
    • 計算每部電影的平均評分跟評分個數
    • 找出500個評分以上的資料.這些資料要來當作預測數值衡量基準.
  • 訓練模型
    • 找出訓練的資料群組
    • 針對Matrix Factorization Model的資料類型,Spark提供ALS.train的方式來train
    • 計算出預測出的RMSE(Root Mean Square Error),也就是與大眾偏好的偏差值
      • 當預測數值越精確,RMSE會越趨近於零.反之,越趨近於一.
    • 透過rank的變化,挑選出最好的模型(RMSE最低的)來進行下一個階段
  • 預測你可能會喜歡的電影
    • 輸入你對於電影的評分
    • 透過ALS.train預測結果

心得

關於最後的Lab,一開始還稍微卡住.不過跟一些人請教之後.一下子就把最後的Lab寫完.

我才發現其實Spark的使用上並不會困擾我,我反而是困擾在Python的Lambda運用.

因為題目裡面很多都只給一個. 但是當你不熟悉Lambda的時候,你就只會用很多行的方式來解決.

如果可以熟練使用Lambda的方式,更可以搭配著Spark的一些transform (map, filter, flatMap 或是 reduceByKey…) 來解決更多的問題.

有人推薦這本Data Science from Scratch principles Python似乎也蠻適合我這種對於Data Science完全沒有概念的人. 關於這本書的範例程式在這裡可以找到.

相關鏈結:

[MOOCS:edx]BerkeleyX CS100.1x- Introduction to Big Data with Apache Spark (三)

image

前言

剩下兩週了,不過家中寶貝誕生.必須要把時間做更好的調配,才能完成這個課程.

相關文章

edx 課程網址在這裡 https://www.edx.org/course/introduction-big-data-apache-spark-uc-berkeleyx-cs100-1x

Lecture 7 Data Management

  • Data Clean: Deal with:
    • Missing Data
    • Entity Resolution
    • Unit mismatch
  • 對於現實世界中數值可能出現的Dirty Data分為以下各種:
    • 失真(distortion): 當發現在連續作業中的某段資料不見的時候.
    • 選擇性偏差(Selection Bias):由於樣本的選擇不同,所以得到差異相當大的數值.比如說訪問政黨傾向不同得民眾.這裡有更詳細資料
    • Left and Right Censorship: 由於樣本不斷地來來去去,不能知道樣本是否有跑完所有採樣流程.
    • 相依的(Denpendence): 每個樣本應該是比次獨立,但是有一些沒有而造成資料的偏差.
  • Data Gathering的重要性:
    • 資料在取得的時候存在許多發生錯誤的可能性,比如說硬體或軟體的問題或是欄位的問題..等等 若是能在取得資料的時候做一定程度的驗證,可以讓資料精確度更高.
  • 其他名詞解釋:
    • Big rot: 資料超過一定時間的沒有數值跟精準度.
  • Data Delivery可能發生的問題與解決方式:
    • 資料遺失或是毀損:
      • 透過可信賴的傳輸方式或是透過Relay,也可以增加checksum來增加資料傳遞的可信任程度.
    • 資料來源的相依性與可信任程度:
      • 必須跟資料提供者有相當程度協調與協議.

Lecture 8 Exploratory Data Analysis and Machine Learning

  • 敘述性統計(Descriptice Statistics): 透過統計數量來對事件作敘述,比如說,本班的成績平均.
  • 推論性統計(Inferencial Statistics): 透過收集到的統計數字,對事件作一定的推論.比如說,選前問卷調查.

  • 探索性數據分析(Explortory Data Analysis): 透過先行的探索來進行數據的分析,進行的活動可能有以下數種:
    • Visualizing the data distributions
    • Calculating summary statistics for the data
    • Examining the distributions of the data
  • Rhine Paradox: 找了一千個人來猜連續十張為藍色或紅色的卡片.進而判斷出不能告訴超能力的人他有超能力的心理分析結果.
    • Rhine’s Error: 但是真正的錯誤是,由於要猜測10張完全顏色一樣的機率為1 / 2^10 =>(1/1024) 也就是說一千個人要猜對一次也不到1個.其實要講解的是對於數據的不清楚造成錯誤的結論.
  • Spark Machine Learning Toolkit(mllib): 提供許多功能比如說分類與回歸分析或是一些數值分析的工具.

Lab3

這次的Lab3更加深難度的要讓我們學習Text Analysis 跟 Entity Resolution並且有提到“詞袋模型”(Bag-of-words model),裡面有幾個比較需要注意的地方:

關於 python dictionary 的 lambda:

這次比較困擾我的,其實是Python 的dict lambda

//建立一個新的map,其結果是 key in MapA value 是 MapA[key]+ MapB[key]
newDict = dict()
for k in MapA:
    newDict[k] = MapA[k] + MapB[k]

//可以用Lambda表示
newDict = {k: MapA[k]+MapB[k] for k in MapA}

很多題目都只有給一個 但是要做的事情太多,只得用lambda來思考.這個部分需要相當大量的腦力,蠻希望能有機會找找到更漂亮的解答.

關於一些Apache Spark查詢的優化方式:

由於不少人的查詢方式有點慢,造成auto-grader 發生錯誤,於是學校方面發了一些聲明來指導大家正確的使用他:

  • 關於找出最大的幾個數值的部分:

      #不要使用python的方式來排序,
      for i in vendorRDD.collect():
          measure len() to find biggest X
    
      #使用spark的action來找,放在記憶體跑會比較快.,
      vendorRDD.takeOrdered(helper function)
    
  • 關於聯集合的部分:

      #不要使用python的集合合併
      unionRDD = sc.parallelize(A.collect()+B.collect())
      #直接使用 union
      A.union(B)
    
  • 關於加總的部分

      #使用python的list家總是比較慢的.
      sum = sum(RDD.collect())
      #直接使用spark action裡面的加總
      RDD.sum() 
    

心得

關於“詞袋模型”(Bag-of-words model),一開始真的完全搞不懂這是在幹嘛.不過透過一步步地完成每一個小函式,最後組成完整的功能.也慢慢了解這個的原理.

這次由於中間卡著家中小寶貝的誕生,所以整個作業無法順利的全部做完.只能先把3/4的作業先弄完了. 不過這次的作業題目有夠難懂,主要時間都花在了解題目與思考提到到底要我們完成什麼.

最後,其實這週的lab3課程相當有趣,每個練習的排練方式也有提到一些些的原理.整個課程安排方式讓我回想到學習Scala的時候的學習脈絡,這大概也是學習FP的好處吧.

參考鏈結:

[MOOCS:edx]BerkeleyX CS100.1x- Introduction to Big Data with Apache Spark (二)

image

前言

這一篇筆記主要是針對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

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軸
errDateSort.map(lambda (key, value): value).collect()

想要取得top5

#想要數字多的在前面,使用-1 如果要少的在前面 就使用+1
errDateSort.takeOrdered(5, lambda s: -1 * s[1])

這大概是比較常用的幾個,此外也有幾個function 需要注意. 不外乎是 distinct()cache(), 如果出現任何問疑的時候,也建議趕快把資料印出五個來debug

#檢查如果有誤
errDateSort.take(5)    

心得整理:

這一次作業的資料量已經有點大,而且裡面的題目也有點多. (大約有20~30題) 每一個運算都要跑好久才有結果.

以下是我的心得:

  1. 跑很久…
  2. 錯了再一次. 又要很久…
  3. 沒想好… 就跑… 真的要很久…..
  4. 不小心搞掛系統… 全部重跑.. 會更久……

此外,由於使用ipynb來單步執行作業,繳交作業前也要確認你的ipynb沒有任何的warning跟error.就算是之前不小心跑出來也要讓他都成功才能繳交作業.

參考鏈結:

  • TBD

[MOOCS:edx]BerkeleyX CS100.1x- Introduction to Big Data with Apache Spark (一)

image

前言

之前學習MIT關於分散式系統的部分,其實對於MapReduce與BigData的部分還是一知半解.這一堂課似乎是大家所期盼的課程,所以來學習.其實課程的節奏算是合適,我想整個Loading也不會太重.

相關文章

edx 課程網址在這裡 https://www.edx.org/course/introduction-big-data-apache-spark-uc-berkeleyx-cs100-1x

課程筆記

本堂課的目標

edx給的官方目標:

  • 學習關於 Data Science的定義與本質
  • 如何使用 Data Science
  • 學習 Apache Spark

我自己的目標:

  • 瞭解 Data Science
  • 瞭解 Big Data相關應用
  • 學習並且了解 Apache Spark

WEEK1 (Lecture 1/2)

主要是設定環境跟一些 Big Daa的簡介,內容其實相當的淺顯易懂.

  • 環境設定方面:
  • 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)

image

(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)
      • 具有track lineage information 可以發現並且修復某些資料
      • 建立後不能更改,但是可以根據已經存在的RDDs修改並建立新的
      • 支援Parallel處理下的資料集合
    • Generalized pattern, Lazy Evaluation, lower overhead and less expensive shuffles

關於RDD的相關程式碼

RDD 宣告
    data = [1, 2, 3, 4, 5]
    rdd = sc.parallelize(data, 4)

這段程式碼有以下特點:

  • 建立RDD,並且具有4 個 partition
  • 根據 Lazy Evaluation 他不會執行任何動作.只是建立RDD

     distFile = sc.textFile("...", 4)
    
  • 由檔案讀入並且,建立四個partition的RDD
  • 每一行事當成一個Element
Transformation

Spark 支援至少以下數種tranformations

  • map
  • filter
  • distinct
  • flatMap

而以上的tranformation並且也支援lambda,也就是說可以有以下數種處理:

    data = [1, 2, 3, 4]
    rdd = sc.parallelize(data, 4)

以下語法都使用同樣的rdd:

    rdd.map(lambda x: x*2)
    # 轉成一個map [1, 2, 3, 4] -> [2, 4, 6, 8]

若是改成filter

    rdd.filter(lambda x: x%2 = 1)
    # 轉成 [1, 3]

flatMap是一個會把所有set 切成平面

    rdd.flatMap(lambda x:[x, x+3])
    # 轉成 [ [0, 3], [1. 4], [2. 5], [3, 6], [4, 7]] => [0, 1, 2, 3, 3, 4, 4, 5, 6, 7]

切記: transformation 並不會馬上執行

Action

透過Action,Spark才會去執行transformation 並且把結果傳回給driver. 這是唯一能拿到結果的方式.

Spark 支援以下幾種的 Action:

  • reduce: 可以傳回所有的集合總和
  • take(n): 只拿前面n個結果
  • collect(): 把整個集合傳回
  • takeOrdered(n, func): 拿回符合func的前面n個結果,相當有用的action
Caching

想要避免action跑完後,需要原始的資料,可以透過 cache來把資料先暫存起來.記住,他一樣是屬於lazy evaluation所以是不會執行.

data = [1, 2, 3, 4, 5]
rdd = sc.parallelize(data, 4)
#create cache並且儲存 x*2 的結果
c1 = rdd.map(lambda x: x*2).cache()
#將rdd修改成 x= x*3
ret1 =rdd.map(lambda x: x*3).take(3)
print ret1
#此時cache依舊是舊的資料,可以直接開始其他action.
print c1.collect()
RDD Lifecycle
  • RDD create
    • sc.parallelize() or sc.textFile
    • transform 會將RDD製造新的副本出來… (Lazy create)
  • Action 之後,RDD就會結束.. 除非你有用cache 把RDD複製一份起來…
Shared Variables

rdd的function closure稱為worker,worker彼此間是無法溝通的.唯一能夠讓worker與driver溝通的方式就是透過以下兩種shared variables. (其實跟OpenCL很類似)

根據方向上而言,可以分為以下兩種:

  • Driver -> Worker (Broadcast)
    • Driver將read-only資料,傳送給各個worker
  • Worker -> Driver (Accumulator)
    • Worker將各個計算結果傳回給Driver這裏的資料是Write-only
    • Accumulator 只能在worker存取,並且每次worker只能寫一次

LAB1 Word Count###

透過iPython Notebook的Lab作業,因為是一步一步地執行.其實是相當的簡單.而且,就算真的看不懂要幹嘛~其實看下一個檢查的地方,就能了解你需要做什麼事情.幾個需要注意的地方:

  • 需要了解mapreduceByKey真正的差異在哪裡. 尤其是面對 key-value資料的處理上, map會一個個的iterate 但是reduceByKey 會已經透過key把重複的抓過來這個function比對.
  • 要注意到,每一個transform 與 action的關係,由於action 是一個closure所以不要把action 結果帶去另外一個transform
  • 對於我而言,一開始常犯的錯誤是: 把 map當作是filter來使用. 要注意的是:
    • map 會 iterator 每一個元素並且輸出結果.
    • filter 才會把符合function的放入你的結果中.
  • Lab1 整體很簡單,依照教學與只是可以做簡單的word count概念的功能.不過卡住我最久的竟然是regular expression,我是用regulex來幫助我了解與分析結果.

image

一個regular expression 的圖示,去除掉頭尾的空白與所有字串中的非字元與空白的字.

參考鏈結