二氧化碳監測與Raspberry PI

Raspberry PI 或稱樹莓派，是最近幾年蠻有名的微型單版機電腦。最新版本(RPi 3)仍然是約略名片大小，但擁有1G RAM 加上 64bit ARMv8使它能做的事情已經和一般的PC沒有太大的不同。

這對純軟體工程師來說，是一個很容易介入IOT硬體的開始。早期，需要嵌入式系統（Embedded System）或者對各類硬體輸出入有一定了解，才能做一些有趣的應用，而現在由於RPi的關係，讓這些應用的門檻降的非常低。

因為RPi已經可以運行各類Linux Distribution，FreeBSD 甚至Windows10。讓軟體工程師可以直接撰寫有趣的應用程式，降低考慮硬體的問題。

不過，「降低」並不代表完全不需要考慮硬體問題。實際上很多市面上的硬體零件，其規格和輸出入方式各有不同，還是得有基本了解或者「取得範例」，才能達到想要的效果。

以市面上容易買到的「攀藤CO2模組」為例，它的文件相當的「精簡」，也沒有任何範例程式，因此需要自己想像一下官方文件到底在說什麼。

想跳過以下冗長說明的，可以直接看這個python範例。

官方文件提及這個模組式需要用標準序列埠Serial Port連結。因此可以想像就是把Raspberry TX/RX 和這個硬體的 RX/TX對接，並且硬體需要5v的電，也要接到Raspberry的5V輸出以及接地，因此就是4, 6, 8, 10這四個pin腳。

接上之後，需要送出指令，這個模組才會運作。根據中文官方文件，你需要知道指令，以及把指令組合成7個bytes然後送出。

但是其實，這個裝置也只有一個指令，也就是0xe3，上面述的DATAH, DATAL其實是填0，而不是如同文件上「打X」。由於只有一個指令，所以校正數字當然就一定也只有一個可能。簡單的說，其實只要（而且也只能）送出以下資料到serial port即可：

[ 0x42, 0x4d, 0xe3, 0x00, 0x00, 1, 114]
#python 範例程式節錄 送出serial port
ser = serial.Serial("/dev/ttyAMA0", 9600)
init_cmd =[ 0x42, 0x4d, 0xe3, 0x00, 0x00, 1, 114]
for c in init_cmd:
     ser.write(chr(c))



上述程式在RPi中會預設serial port已經不作為TTY (終端機)使用，因此才能直接對/dev/ttyAMA0執行輸出入。由於RPi預設serial port(8,10)式作為終端機使用，因此請記得disable它，並且重開機。

接下來，根據文件的內容，需要接收(讀取)一個12個bytes的資料，資料內容也都是固定，真正有意義的是第五和第六個byte，這兩個byte應該組合成一個數字。這個裝置最好的地方在於，它的數字已經是CO2的PPM值，這比某些其他公司的裝置還需要用各種方式換算方便許多。

兩個bytes組成一個數字的方式很多，例如可以把第一個位數利用 << 位移8，然後加上第二的位數。當然也可以把第一個位數*256加上第二個位數。

#python 範例程式部分節錄
 while True:
     count = ser.inWaiting()
     if count >= 12:
         recv = ser.read(count)
         h8 = recv[4]
         l8 = recv[5]
         print(str(ord(h8)*256 + ord(l8))+" PPM,")


最終結果就是，會有個Raspberry PI可以監視並且告知附近環境的CO2含量。
在辦公室監視一整天的結果非常明顯，上班前的CO2含量比較低，人越多的時候CO2含量會快速增加。連續兩日，都是在每日下午5點到達最高峰，接下來逐漸下降至隔天開始上班為止。

數據分析 - 獵人頭如何從Github尋找人才？

前陣子遇到某特殊的獵人頭hunter公司(參考:這裡)，竟然是透過分析統計在github, gitbucket的程式庫，來找到軟體人才。

目前，github使用者數量仍屬商業機密，但估計約在2千萬左右(參考:這裡)。當然，使用者大部分從事軟體相關的行業。

資訊科技，特別是軟體的實際成果，容易在網路上展示。因此，如果要找到「軟體開發人才」，github是一個很好切入的地方。一般獵人頭可能會人工搜尋，但身為工程師，當然是寫程式找到大量資料。

從github找人，這做法有一些顯而意見的好處：

1. 有可能看到此人實際上寫的程式碼
2. 有可能了解最近此人的工作範圍
3. 很快找到此人的聯絡方式(email)部落格或其他技術相關資訊
4. 有可能找到此人合作對象
5. 有可能看出此人的英文語言能力

當然也有些顯而易見的缺點：

1. 當然找不到那些不在把專案程式擺道github的人
2. 此人可能只是擺放玩樂性質的程式
3. 只能有機會看得出技術能力，非技術能力仍然需要其他佐證
4. 資料範圍過大，很難逐一肉眼看完

雖然我不是獵人頭，但基於工程師的精神，就嘗試一下解決「資料範圍過大，很難逐一肉眼看完」的問題。看是否能透過程式取得並處理gitbub資料，找到潛在挖角對象清單。

實際上做的步驟如下：

1. 了解gitbub資料如何取得：

github提供api可供程式使用。和許多Web Service一樣，也有完整的文件，請參考這裡。

2. 以程式取得少量測試資料

github的web api測試起來很簡單。舉例來說，如果你已經登入github，用以下這個URL request就可以找到，以javascript與nodejs為關鍵字的所有程式庫：

https://api.github.com/search/repositories?q=topic:javascript+topic:nodejs

當然，他的回應是json格式，需要簡單地用程式轉換。例如下圖，乃是搜尋和javascript相關，並且其位置在台灣的使用者：

測試資料回傳乃是json，調整格式成為csv，以便於日後在excel做簡單分析。

3. 了解測試資料內容

如果已經有在使用github，那麼對於回傳的資料應該很清楚其內容意義。

如果不太了解github，就需要找對軟體版本控制系統有些認識的人幫助瞭解其含意。

這上述的範例：「搜尋和javascript相關，並且其位置在台灣的使用者」來說，程式會刻意收集following(有多少人在跟隨這個人的更新)，follower(這個人跟隨了多少其他人)。此外，程式會額外計算push和javascript相關的程式庫的次數，取名為work，表示和javascript的相關工作在過去一段時間的次數。

4. 撰寫簡單統計程式，大量取得資料

當然，這個程式就放在github上。請參考這裡。

程式本身是python撰寫，需要有github帳號密碼才能使用。

5. 結果

以上述範例：「搜尋和javascript相關，並且其位置在台灣的使用者」大量取得資料並且「過濾可取得公開email」的人數一共是661筆。並且取最前面的199筆，給熟識的headhunter (獵人頭) 鑑定看看是否有效果。

目前的回應都是此資料非常有用。

數據分析從零開始 - (4) 檔案儲存

數據分析的各階段，都有可能需要儲存檔案。而資料的來源，也有可能是已經存在某處的檔案。

(非檔案儲存？參考註1)

越重要的資料，就得更重視儲存的方式。而越是大量複雜的資料，就勢必要對資料存儲做好預先的規劃。

雲端儲存 - 巨量資料

近年來流行的Cloud Storage，通常是將資料以網路上傳(註2)至某個雲端服務公司。最典型的例子是Amazon提供的S3服務。AWS S3因為使用者眾，以至於其的S3 rest http介面，甚至演變成某種標準。許多類似的服務，或者儲存廠商，會以「相符S3 rest api標準」當作重要的功能或賣點！(註3)

顯而易見，雲端儲存具有管理上的優點。理論上，不用擔心備份，擴充，網路，電力，硬體更換...等等營運上的問題。

然而，巨量資料雲端儲存也有幾個顯而易見的缺點

1. 錢：雲端儲存的費用並不便宜。單以S3為例，2016年的每1T資料光是「存著」的費用，一年就高達276美金，相當於8832台幣。這還未計算上傳下載等操作費用。倘若要進行「長期保存」其費用相當驚人。也因此雲端儲存商針對長期保存的檔案也提供比較便宜的方案。然而，仍然是某種成本。然而，自行巨量儲存也要考慮費用，特別是

2. 營運：單純僅只使用雲端儲存，對整體營運的好處有限。並且，企業還是需要自行考慮檔案的有效使用問題。

3. 移轉：儲存到雲端之後，一旦量變大，很難轉換營運商。

雲端儲存 - 少量資料

至於極少量資料，例如10G之內。無論是企業或者是個人，都可以取得幾乎免費的儲存空間。

但也因為是免費空間，不太可能保證資料不會遺失。可是非常適用於新創公司，或者SOHO族。

最好是利用兩個以上的雲端儲存服務，儲存重要的檔案。

例如：利用googledrive + yandex.disk 儲存重要的檔案。這樣幾乎可以確保檔案不會因為單一基礎建設有問題，而導致重要檔案遺失。(註4)

實際作法：

(1) 尋找適當的工具或API，用以一次性整合這兩個雲端儲存

(2) 設定自動化方式，或者撰寫自動化程式

(3) 定時執行自動化備份，同時備份兩份到不同的雲端服務

Yandex disk的範例程式(參考這裡)

自行儲存 - 巨量資料

企業組織非常有可能需要自行處理檔案儲存。無論是因為技術因素或者法律因素。

傳統上儲存會用硬體商的解決方案，近年來多了分散式檔案系統可以考慮。

自行儲存，一樣要考慮錢(費用)，營運。

1. 錢(費用)

    - 硬體費用：必須考慮長期硬體維護的費用
    - 軟體費用：授權或者購買維護
    - 人的費用：必須使用假設的最大值！

2. 營運

    - 如何讓其他系統使用
    - 有問題的時候怎麼辦
    - 備份與災難復原 


傳統巨量檔案資料，是購買netapp之類的硬體解決方案，配合網路架構，讓企業的巨量資料有集中管理的地方。2000年之後，分散式檔案系統因為效率和成本的關係，慢慢變成另一個可行的選項。

早期使用分散式檔案系統管理者，要跨越比較高的技術門檻，這幾年分散式檔案系統日漸成熟，管理也越趨方便。常見的有：(在這頁wiki上有詳盡的清單。)

(1) glusterfs
(2) ceph
(3) HDFS
(4) mooseFs
(5) mogilefs
(6) GridFS
(7) Lustrefs


這些分散式檔案系統各具特色，大部分都可以無償取得使用權。然而，有些需要額外的知識或技能才有辦法長期維護。

因此，如果可預期的資料量，以及資料存取技術與成本，小於硬碟技術的成長。使用分散式檔案系統不見得有利。

硬碟的技術符合約略的摩爾定律。在1996年，每1G的硬碟約127美金，2006年，每1G的硬碟價格為0.3美金，但是在2016年，每1G的硬碟價格已經小於0.03美金。（參考這裡）

除了價格逐年降低之外，存取速度也是逐年增長。如果預期資料成長量並不高，其實單就更換更換同價格的硬體設備搞不好也就夠了。

然而，巨量資料的增長往往遠超過預期，尤其近年來大資料分析蔚為風潮的情況下，盡可能保留資料便於未來使用成為企業組織對資訊科技的期待。也因此，使用分散式檔案儲存的組織越來越多。

選用分散式檔案系統，必須考慮：

(1) 使用目的和環境條件
(2) 營運計畫
(3) 實際測試


考慮雖然需要詳盡，但是這些「考慮」都是為了配合實際運作。因此，按照上述的考量，擬定可以「每日」有進展的「逐步」前進的計畫，是讓分散式系統成功運作的最好作法。

舉個例子：

(1) 使用目的和環境條件：要能夠簡單擴增(scale-out)，並且能利用現有已經存在的NAS/SAN，而且非常容易營運與維護。檔案不需要striping，存取效能一般即可。

(2) 營運計劃摘要：一開始預計使用12台機器，共48顆硬碟。未來一年可能擴增到20台機器，80顆以上硬碟。總資料量可能成長為120TB。僅有一位開發維運人員(devops)。

(3)實際測試：實際分別以4台VM測試過glusterfs, mogilefs, ceph, Lustrefs。其中以mogilefs最為簡單使用。

自行儲存 - 少量資料

少量檔案的儲存，仍然附著在其他系統上。例如email上的附件，版本控制系統，wiki上的附件等等。

大部分的組織，很少著重於少量資料的整體計畫。大多數僅只為「安全性」的規範。例如客戶資料不得外洩之類。實務上，完全依賴個人行為。

現在，大部分的作業系統，都已經可以對其下的檔案做全文檢索(例如mac finder)，而也都支援某種程度的備份功能。

摘要

	巨量資料	少量資料
雲端儲存	錢, 營運, 移轉	考慮  (1) 自動化
自行儲存	(1) 傳統NAS  (2)分散式檔案系統	考慮  (1) 傳統備份  (2) 全文檢索

---

註1：非檔案儲存有傳統的RDB(例如Mysql, Oracle), Document DB(例如Lotus Notes), 有比較新潮的nosql (HDFS, mongodb, couchbase)。 這目前不在本文的討論範圍

註2：通常是指http。不過由於ftp在2000年之前應用範圍真的太廣，所以還是有不少雲端公司會額外提供ftp介面。

註3：參考這裡 -> http://www.s3-client.com/s3-compatible-storage-solutions.html

註4：為何選擇這兩者？google當然是不用說，因為它的基礎建設相當完整。而yandex則號稱為俄羅斯的google，很明顯由於是俄羅斯最大search engine，大概不會和google採用重複的基礎建設，因此選用兩個截然不同的廠商，可以降低風險。

台灣博士生與大數據分析：如何評估對大數據分析的本職學能？

最近有個真實故事：

---

(為保護當事人，內容與細節均有所改變) 

台灣人F，目前就讀於某知名國立大學，已經是博士候選人。

最近為要爭取某一私立學校E的教職。在其履歷表上是以雲端計算大數據專家自稱。而E校的某系評會要求他面試15分鐘，用以評估他的能力。試教主題不限。

然而，F其實對大數據除了看過一些商管叢書之外，其實根本一竅不通。因此，他找了以前大學時候已經在業界工作的好友J，問了一些「技術問題」如下：

F：我聽說過spark，是不是大數據分析都用它啊？spark是不是個作業系統？

J：如果這是你的問題，那你壓根離spark太遠。後面就不要再談了。

F：哎喔，我覺得教學只是個演出啦，看表面而已。以你在業界打滾多年，就幫我個忙。couchbase是什麼？有什麼如果講出來會讓大家知道我很厲害的地方？

J：如果這真的是你的問題，你真的什麼都不懂啊，就算你去E校當教授，也是害了別人。

F：....

---

這個真實故事乍看之下太過駭人！但或許反映了學術與實務之間的鴻溝。

其實，台灣有許多學術界的人才，不但學術淵博，技術根底也厚。從數十年前的硬體產業蓬勃發展就可見一般。近幾年的軟體也是，許多教授幫業界「產出」能產生價值的知識性員工，並且也讓業界的知識持續推進。

然而，M型社會反映的層面，不指是一般在職場工作的人，在學術界中也越趨嚴重。

也有不少學術蟑螂。他們靠著極致的生存能力和夠厚的臉皮，穿梭在三流研討會，大企業策略部門，顧問性質演講，以及不在乎學生品質的大學院校中。

這些學術蟑螂做的事情，大概也不會真正傷害到誰，只是，也不會對任何人有好處。只要不是在「自己家裡」，一般人在路上看到蟑螂只會視而不見，也不太會去追打。

但是，如果是在自己家裡呢？

評估對大數據的本職學能，才能判斷來者是學術淵博的長者，還是費力在夾縫生存的蟑螂。如果是像E校一樣，原本的教授群並沒有這方面的背景，要如何在沒有足夠的知識情況下，判斷對方有沒有知識？這雖然有點難，但是，透過一些方式還是可以把誤判機會降低。

(1) 實際經歷探詢（情境實例面試法）

情境實例面試法很基本，但是事先有所準備。做法很簡單，只詢問「過去實際上」發生的事情，用以判斷被面試者現在的情況。而且絕對不詢問開放性問題！！

對於couchbase而言，就不會問「你對couchbase瞭解程度如何」或者「分散式資料庫你有哪方面研究」。因為這類型開放性問題，會浪費大家的時間。也會讓學術蟑螂有機會以混淆視聽的長篇大論，大打模糊仗來損耗面試者的判斷精力。

簡單問題像是：

* 請用1分鐘定義何謂nosql

* nosql的實作有很多，請舉一個你最熟悉的nosql平台工具，一個你實際最常用，最熟悉的就好(在此假設他回答couchbase)。

* 請問你實際接觸couchbase多久了？  (用判斷他最熟悉的工具有可能有多熟，如果少於6個月大概也等於是不太熟）

* 你利用couchbase為平台，撰寫並發表過哪篇論文？(學術界而言，沒有發表相關論文等於是沒有相關方面的研究）

稍微麻煩的問題像是：

* 你有沒有加入couchbase的任何相關的mail-list? (沒有加入mail list也沒關係，但表示其實只是單純的使用者，不會有太多深入的了解)

* 你利用couchbase為平台，撰寫並發表過哪篇論文中，所使用的研究資料量有多大？100G？10T？（資料量極小的nosql，並不代表不正確，只是代表不是大數據而已）

* 你用過哪些版本的couchbase（起碼要記得大版本編號吧）

* 你最近讀了哪一篇論文是以couchbase實作其研究？是大概什麼時候讀的，內容是什麼？


總之，事先準備好不能模稜兩可的問題，並且也定義好不能模稜兩可的期望回答。事先準備的問題也不需要太多，只要7-10提及可。這樣，比較不容易被蟑螂溜進來。並且，在準備的過程中，其實也會讓團隊（無論是學術還是技術團隊）對這方面的知識有基本的增長。

(2) 真實展示

簡單的說，就是請他拿一台電腦，展示一下他對大數據分析中最會「做」的事情。無論是撰寫程式碼，還是建立模型都可以。

真實展示其實很容易騙得過沒有相關知識的人。但是，如果事先已經提醒會有真實展示，可以簡單篩選掉連打開電腦都不敢的小蟑螂。

E校要求試教15分鐘，其實是真實展示的好方法。然而，盡可能展示「動手」而不僅只是「動口」。雖然君子動口不動手，但是蟑螂恐怕也是。

(3) 自我反省

當在一個地方看到蟑螂的時候，通常表示附近還有另外10隻蟑螂(也有人說是數百隻)，只是沒看到而已。會有蟑螂來面試 - 無論是工作還是教職 - 是不是這組織已經有很多蟑螂。更重要的是，自己是不是其中一部分。

自我反省是極端困難的工作，對生活優越的自己，在心理上也不見得好過。但是，在陰暗狹小的地方求生存，總是比不上光明正大的貢獻自己的能力。

請謹記，「自信心」和「自我感覺良好」只有一線之隔。或許，透過實際經驗探詢，先自我檢查自己，才是去評估別人之前，真正自己應該做的事。

數據分析從零開始 - (3)外部取得資料

...續<上篇>...

外部取得資料

最常見的就屬於在網站上資料取得。最近由於透明化政府政策越受到重視，可供老百姓取得的資料就越多，當然可供作為資料分析的運用就多得不得了。

直接取得可程式化資料

資料本來就提供給外部取得用以計算，例如：政府開放資料。資料好不好用，是另外一回事，但起碼大部分的情況下，這類型的資料只要能下載就足夠應用。

有些資料可以api的方式取得，通常需要申請權限，典型的像是facebook graphic api，musicbrainz api，wiki api等等。

假設需要的資料都可直接程式化取得，那真要感謝上帝。資料數據分析就少了一大堆痛苦的事情要處理。

有個重要的技巧：利用Shell以及試算表對資料做基本驗證。這和前篇雷同。不過在此以試算表為例。

外部資料取得如果已經是整理過的，必然可以用很簡單的方式驗證。即便你沒有Excel，也可以先利用google的googledrive產生樞紐分析表。

作法很簡單。以前陣子最有名的資料：不動產時價登錄為例，

(1) 首先，到內政部網站下載公開資料

http://plvr.land.moi.gov.tw/DownloadOpenData。
它提供了很多資料格式，不過請下載csv格式。

內政部雖然是一番好意，提供各種格式資料。但坦白說，只csv格式是真正正確容易處理。其他格式根本是多餘而且難以直接利用，它的xml並沒有定義namespace，會讓需要合併處理xml時，要重新定義所有的node。

(2) 選擇其中一個csv上傳到googledrive，上傳之後是預覽狀況，請參見下圖：

(3) 按下右上角的：使用『google試算表』開啟

這時候會把csv格式自動轉換成google試算表內部格式。請注意這個格式，並非excel。

(4) 在試算表上選擇「資料」，並選取出現的「資料透視表」。要注意的是，這裡雖然是資料透視表，但是其實下一個畫面名稱就變成樞紐分析表了。

(5) 樞紐分析表出現後，是空的。在右邊選擇想要的欄列。之後就可以自動展示簡單分析的結果。

下圖的例子是以桃園的區作為列，建物型態作為欄。並且在「值」的位選擇平方公尺的單價的平均值(Average)。這個基本的分析可以很快的看出來資料的特性。舉例來說，在這段期間，屬於廠辦的交易就只有龍潭區。

間接取得資料

許多有用的資料，都要自己寫程式來取得。特別是，這類型的資料雖然公開，但不期望也不希望被程式大量取得，例如統一編號查詢。這種資料通常會用captcha來阻擋，不過現在破解captcha的工具和機率越來越高，現在比較重要的網站都改成以「請點選以下哪幾張照片裡面有老虎」這種方式處理。

在1996年之前，間接取得資料的通訊協定有很多種。但是，現在http幾乎已經統一可公開間接程式化取得「資料」的所有方式。而也因此，所有間接的，可程式化的取得資料大概都只需要專注在http。

簡單的說，只要 

(a)熟知http crawler (爬蟲)技巧 

(b)程式化處理html 或其他格式文字

就大概可以解決75%以上的問題。

建議的步驟為：

步驟一：找到正確而適當的目標。

不是所有外部資料都是好資料。倘若你想要蒐集在台灣關於醫療方面的問答資訊。或許你會先透過google隨意查詢一下，接下來，你可能會看到 verywed.com 有很多有趣的訊息和網友經驗。如果你就真的覺得上面的資料有用，那麼你等同是蒐集了眾多無法證實的資訊，造成資料嚴重的可信度問題。

雖然google也並未對所有資料的可信度加以查證，但它的演算法可以利用交互連結，以巨大的資料排比最可能的結果，而巨量資料在很多時候，可以彌補質的問題。

個人的爬蟲和資料蒐集，當然不可能做的和google一樣。至少從零開始的時候是不可能。因此，有意義，可信的資料來源變得很重要。

以前述的醫療資訊而言，台灣衛服部的台灣e院網站所提供的問答資料更具可信度。因為，回答問題必然是「具名」的醫生，當然其專業和可信度比「不具名的網友」高很多。

台灣e院看似複雜，但簡單來說所有的Q&A檔案歷史，都可以由一個ShowDetail.php加上簡單的參數以GET方法取得細節。每個網站的作法都不一樣，仔細觀察每個查詢按鈕，加上一些經驗與知識，絕大部分的網站都可以找到某種規則。比較複雜的網站，請善用瀏覽器的「開發人員工具」。

步驟二：以curl或其他工具，先行測試

在mac或linux上都有的curl指令，是在撰寫爬蟲程式之前，最方便先測試的小工具。

在很多時候，甚至可以利用curl配合wget，可以連程式都不用寫就抓取一整個靜態網站的資料。

例如，以下指令可以取得q_no=111521的網頁資料。（參見下圖)

#curl http://sp1.hso.mohw.gov.tw/doctor/All/ShowDetail.php?q_no=111521 -o onepage.html

步驟三：以script撰寫能處理與轉換儲存資料的程式

以台灣e院為例，要取得所有Q&A的歷史檔，只要知道「大概」最後的q_no編號，再寫個簡單的python程式即可。

要特別處理的地方只有：

(a) 不存在的編號：每個網站處理不存在的resource方式各有不同，以台灣醫院為例，仍然會在http reponse中回應200，但是內容改變

(b) 編碼：這個網站使用big5，但為了未來處理方便，最好先轉換成UTF-8。範例中使用requests取得網頁之後，理解編碼並且轉碼。注意!大部分的big5會被誤以為是ISO-8859-1因此要先強行指定為big5之後再轉換

(c) 轉換格式：當然不會想要整個網頁存檔，只想要問答內容。範例中使用lxml的xpath的方式直接取得所需要的element內容。

程式碼參考如下：

#!/usr/bin/env python3 # -*- coding: utf-8 -*- import requests import time import sys from io import StringIO from lxml import etree from datetime import datetime for i in range(34500,34520):         time.sleep(3)         print('working on'+str(i))         url='http://sp1.hso.mohw.gov.tw/doctor/All/ShowDetail.php?q_no='         r = requests.get(url+str(i))         r.encoding = 'big5'         htmlstr = r.text         if htmlstr.count(u'不存在</h1>') > 0:             print('ignore '+str(i))             continue         parser = etree.HTMLParser()         sio = StringIO(htmlstr)         tree = etree.parse(StringIO(htmlstr), parser)         question = tree.find(".//li[@class='ask']")         allq =""         for t in question.itertext():             allq = allq + t         dr = tree.find(".//li[@class='doctor']").text         ans = tree.find(".//li[@class='ans']")         alla = ""         for t in ans.itertext():             t.replace("\n","")             alla = alla+t         oneResult = {'a':alla,'q':allq,'dr':dr}         print(oneResult)

步驟四：考慮儲存地點

網頁可以儲存為靜態檔案，也可以分析欄位後，儲存在傳統資料庫，但近年來更流行存在nosql中。

可選用的nosql非常多，mongodb, AWS的dynamodb, elasticsearch, couchbase...都可以。

前述的範例，倒數第二行：

oneResult = {'a':alla,'q':allq,'dr':dr}

其目的就是在於轉換為python dict之後，很容易處理為json或者直接利用各nosql的sdk，存入到儲存地點。

步驟五：慢速進行

大部分的網站其資料當然是公開讓廣大網友使用。然而，程式化使用，例如利用爬蟲大量下載，通常是網站管理員不會特別注意到，然而爬蟲程式的確有可能讓網站變慢。

作為一個自治網路世界的好公民，首先應該先了解該網站是否有robots.txt，也就是定義爬蟲程式的規範。如果有，那就應當遵循。如果沒有，應該要在爬蟲程式中，適度的停一段時間。

例如，以前述範例來說，在for迴圈中使用time.sleep(3)，讓每一個http request都等3秒鐘之後才進行。這樣雖然有可能讓爬蟲程式本來需要1小時就完成，變成足足3小時以上，但可以確保該網站不會受到你的爬蟲程式太多影響。

數據分析從零開始 - (2)資料取得和前處理

既然要分析資料數據，自然要有資料數據才能分析。資料取得是必要的事情。

資料來源有很多種，取得並且事後處理的難易度各有不同。

但可以確定的是基本情況是：

1. 資料的時間，會遠超過自己的想像

2. 在開始進行分析之前，資料整理的所花的時間精力，也會遠超過自己的想像

3. 資料整理，幾乎不可避免

4. 資料整理，沒有捷徑也沒有神奇的密技，只能靠不懈怠的努力耐心以及經驗

5. 實際上有創意，有價值的數據分析，都不能免除資料取得和整理。 

第一手資料：

在「嚴格的一手資料」定義下，做資料分析的人真的拿到一手資料的機會極端的少。不過如果你是購物網站的大老闆，則購物網站上產生的營運資料，web server的log等等，對你而言就是第一手資料。

實務上最常看到的第一手資料，應該就是網頁存取日誌(web log)。在2016年網頁伺服器市場上，apache加上nginx仍然佔了半數以上，其他的網頁伺服器種類雖然也不罕見，但網頁的log格式反倒似乎都很統一，因此，以網頁存取來說，資料取得跟分析都已經存在既有的工具。剩下就看規模和個人技巧。

其他類型第一手資料就包山包海，以業務來說，發票檔案(invioce)當然是貨真價值的第一手資料。以軟體開發來說，git上所有的commit log也是第一手資料。

以現在軟硬體的成本之低，第一手資料原則上都可以盡量保持「原來的樣子」，頂多保存的時候壓縮而已，不太需要進行破壞性過濾處理。

要點一：使用shell 做基本的確認以及雜訊處理。

mac或linux可以用的基本文字處理的技術太多。伺服器的log最基本的處理方式，應該先用shell快速瞭解一下現況。

舉例來說：

以下指令可以把access.log中的第11欄，http response code列出來，並且簡單統計一下各return code的次數。

#cat access.log | awk '{print $11}' | sort | uniq -c

以上圖來說，結果就是有3個http return 400，有134個return 200，沒有任何500的回傳值。至於什麼是http return code，請參考w3規範。

要點二：用excel做最基本統計檢視

過去許多excel版本都有筆數的限制（最多六萬五千多筆），2013之後就放寬很多（大約一百萬筆），請參考官方網站。

即便有數量的上限，也非常值得資料中，先擷取樣本來試著分析。使用樞紐分析表，可以很快看到資料欄位彼此可能的關係，在未來進行分析時候是很有用的參考。

如果到現在你還不知道什麼是pivot-table(樞紐分析表)，那表示你根本不懂excel。  怎麼使用樞紐分析，請參考官方網站的說明。下一篇，我們會用政府公開資料簡單做個樞紐分析表。

要點三：以自動化的方式產生濃縮的摘要（二手資料）

只要能取得第一手資料，盡量使用自動化方式，自動產生有意義的濃縮摘要，這個摘要就算是二手資料。

當然，這要配合要點一的shell文字處理，例如以下指令：

#cat access.log | grep "GET /login" | awk '{print $6}' | cut -d ":" -f 1 | sort | uniq -c

這可以產生簡要報告，說明登入(login)頁面每天有多少人次來使用，執行結果如下圖：

這圖上的執行結果顯示，9/12有15個人次，而9/13有2個人次。

現存二手資料的資料

所謂二手資料當然就是不是直接產生資料的來源的資料。資料分析採用二手資料的機會非常高。

所有組織外部取得的資料，絕大部分都算是二手資料。因此在下一節中會特別說明外部資料的取得處理。

要點一：取得過程的紀錄，以及基本分析

無論資料是自己拿或者這別人給，都需要紀錄取得的過程。

舉例來說，如果IT「自動」會給你一份，wifi的使用者登入時間，以及最後封包產生時間，你就需要有方式「自動」記錄這個過程。

如果是外部網站，也應該要記錄當時取得的方式，假設是curl取得，則用了哪些參數，執行多少時間等等。

基本分析則和前一節相同，先用shell和excel對資料有基本理解。

要點二：正確性判斷

二手資料很可能不正確，或者，對資料的解釋不正確，會大幅影響資料的使用方式。

資料解釋不正確：舉例來說，只要有用過就知道，政府公開資料很多都宣稱編碼是utf-8，但實際根本就是Big5（例如 房地產實價登陸）。

資料不正確：二手資料取得的資料本身判斷正不正確很困難，特別是在大規模的資料收集下，很難簡單判斷正確與否。而且有些資料的正確性，可能連第一手資料來源都不能保證（例如天氣觀測）

但是可以透過「多面向」的方式來探究單一資料的正確性。簡單的說就是多找幾種資料來交叉比對。舉例來說，如果你的天氣資料來自不同的網站，如下兩個圖：

雖然這兩個圖在同一個時間點的氣溫還是差了兩度，不過起碼是一個合理的範圍，因此大致還能知道資料是合理。

要點三：自動化進行轉換格式以及二次儲存

二手資料無論是什麼格式，幾乎都會被轉移格式，或者合併，或者改換儲存媒介。例如csv檔案，常常就被改為json格式並且存進nosql中。

但重點是要「自動化」進行。雖然格式轉換或者改變儲存的形式，幾乎都有現成的工具可供匯入匯出，但是只要太多「人為手動操作」，都會讓資料處理越來越花時間，越來越難保證整個流程的品質。

外部取得資料

<<TBD>> ...請見下一篇

數據分析從零開始 - (1)事前準備

當你打算從零開始，變成一個有足夠能力的資料工程師，一開始會需要準備基本工具。而隨著時間過去，自然而然你會瞭解並且學習到更多工具。

在此提供簡單的確認清單(Check List)，讓在打算開始學習並應用數據分析時的準備參考。

1. 電腦

既然是資料分析，電腦自然是必備工具。

最推薦的是Mac的notebook，如果沒有太大的經濟壓力，最好買記憶體越大的越好。13吋MacBookPro，RAM 16G價格大概四萬八。其他可以考慮dell的linux desktop。


選用Mac或者OS為Linux的電腦有許多原因，內建的終端機(terminal)可在bash等環境快速執行各類型資料處理的前期工作。現在windows也有powershell，並且至今技術工程師在對比unix/linux的shell時，常常會有各種爭論。

不過，就打算從零開始的數據工程師，別想太多，就選unix/linux吧！

2. 作業系統

無論你的電腦是桌上型還是筆記型，無論他原本是什麼作業系統。你都需要一個Linux作業系統。在MacOS上可以安裝VirutalBox或者VMware來執行Linux虛擬機器(VM)

3. 基本知識技能與其標準

雖然說是基本，但真要搞定以下知識與技能需要很長的一段時間，就從零開始的情況而言，「盡你所能」的了解以及練習是不二法門。

(1) Linux基本操作：在終端機(或者Shell)中，完全了解以下幾圖中的指令的意義：
（圖一）

   (圖二)

   (圖三)

(2) 網路工具自我學習與操作：能有耐心的看完這篇AWS CLI，並且能用AWS CLI上傳檔案到S3。在整個過程，僅使用官方文件，不在google上搜尋非官方說法。

AWS有提供許多免費工具，用在資料分析上非常適合。但是如果你有PB等級的資料，在AWS上做大數據分析是非常花錢的。

(3) 程式設計基本能力：利用python或任何程式語言，將台北市的住宅竊盜公開資料處理分析加總之後，列出各區的竊盜案件次數表。這裡要注意編碼(encoding)的問題。
如下圖：

(4) 英文閱讀能力：

其實英文閱讀能力對數據分析，甚至其他技術學習是非常重要的基礎。如果不習慣閱讀英文，而老是只查中文網頁，那麼就等於少了60%的網路知識存取。

如果對自己的英文閱讀能力有疑慮，可以先試著不查字典看完這本書：How To Read A Book，這本書用詞遣字相當簡單，而書的本身就是「增加閱讀能力」的方式。因為是本很老的書，應該很便宜，或許早已經沒有版權？