Serverless design for IoT - An example leverage AWS and GrovePi

AWS announced IOT service in about 2015 and gradually release other relative service (for example: IoT Button) for those who need to tackle with the problem on huge amount of increasing response of "The Things". And it is of course the area which cloud provider what to provide a optional solution.

To demonstrate the benefits of leveraging the serverless design and also utilize the power of AWS cloud. I build an example project combines Serverless design, AWS IoT, Respberry Pi, Grove Sensor system and GrovePI. It will provide in door air quality (office) for me if I want to know that before entering office. So that I can have an excuse to work from somewhere else? :)

In this example, a GrovePi mounts in Raspberry Pi (B+) to control Grove's Air Quality Sensor, HCHO sensor and dust sensor. As a software engineer, I assembled all these inside a paper box. See picture below.

RPi and GrovePi are inside the box. 3 sensors are out there.

Reminder: to use AWS service, the most important things is to read official document. AWS has many different services and there are too many out-of-date articles in somebody's blog. It doesn't mean that authors were wrong, it is just out-of-date. Of course, it is the same in Raspberry Pi and all other 3rd party open source library, try to read official document (or official wiki/blog) to have overall view.

The full implementation and design concerns 

(please check all the project detail in github)

(1) Grove's 3 sensors + GrovePi + Raspberry Pi

   The hardware parts. Check GrovePi's official web site to know how to put them together.

    GrovePi might be the easiest way to program Grove's system from Raspberry Pi, if you have more then 2 device in a machine. However, if you have only one sensor, then just use RPi's GPIO.

(2) AWS IoT service

   Although we didn't program anything in side the hardware, we still need to setup things in AWS IoT service. And of course, it will be better to read at least the tutorial.

Screenshot of AWS IoT Tutorial

   AWS IoT pricing model is counting by message (512bytes). At this moment, about $5 per million message. Which means about $5 per 500MB! This is much more expensive than own a EC2 service to serve device message. However, if you don't need to keep all monitoring data transit in AWS every few seconds and you need only monitoring state changes (maybe a few times per day) then a "Device Shadows" is the best for you.

   In this example, we register a "Thing" named: InDoorSensor1 and the most important thing is to have default Shadow Object as below:

{
  "desired": {
    "welcome": "aws-iot",
    "air quality": 43,
    "action": "wait"
  },
  "reported": {
    "welcome": "aws-iot",
    "action": "wait",
    "air quality": 43
  }
}

   The device will keep sync the Shadow in AWS and if the desired state change to "do", it will (a) do a one time air sensor data collection and then (b) update air quality in Shadow object (c) change to "wait" state. In sort, the Shadow and Device will sync the state (wait or do) and the state's sync is the major function provide from AWS.

(3) AWS IoT Python SDK + GrovePi Python library

AWS provides a few SDK for device, in this project, we use Python to do AWS Cloud access (no matter notification or change Shadow state)

In the Raspberry PI B+, you need to:

    (a) install AWSIoTPythonSDK
    # pip install AWSIoTPythonSDK  (also see here)

    (b) consider the protocol (MQTT vs Websocket). In some environment, the MQTT port might be block. AWS SDK provides MQTT via WebSocket which of course allow broker use port 443.

    (c) certificates: please do read AWS IoT Certificate document if you didn't have experience before

If you use Raspberry PI version B+ 2 or 3, then it will be easy to install nodejs/npm and all other fancy stuff.

(4) IoT Shadow

    The Shadow means an identify object of IoT device. This allows client to change the state of a object and then sync to IoT device. In certain scenario, it allows programmer no need to take care of network error handling or any off line case. However, you still need to fully understand what means exactly the "desired" and "reported" state.
   It is possible to edit Shadow state from AWS admin console direct for testing purpose. (you won't want to do so if you have thousands IoT device).

(5) Lambda, API Gateway

    Supposedly, an application will NOT access specific IoT device, it normally access a service and that service provides information or allow meaningful user actions.
    In this case, a lambda service is simple a python program which can (1) retrieve current state and also current air quality value (2) update state to "do". And as always, the Lambda is behind an API Gateway and which means, potentially, all other application could use this API to access necessary (filtered) information.

see the activity hand draw:

Next Project

Hopefully, I can have more budget to purchase Raspberry PI 3 and also CO2 sensor and then also gather data to draw graphic in D3. Also, I am thinking to use LINE to send air quality information to my colleague or neighborhood. 

企業巫醫 - 統計與謠言

In god we trust all others bring data 
  -  W. Edwards Deming (全面品質管理TQM之父)


網路讓資訊傳播成本降到極端的低，同時也讓資訊品質降的極端的低。

謠言的成因有非常多。有些僅只是美麗的誤會，例如：十幾年前開始流傳的泰戈爾的詩。有些則是恐嚇類型的無風起浪，例如：誠品可怕迷魂盜，泰國罐頭。有些只是試圖吸引人目光的搞笑惡作劇，例如：裝翅膀飛起來

。

最糟糕的類型，莫過於以「統計數字」造出看似符合邏輯的謠言。並且，從這樣的謠言中獲得利益。


許多時候，數據本身難以查詢正確性。而且由數字導引出的邏輯，更容易因人而異，因地制宜。從數字所引導的偏誤，有時候甚至比單純的謠言還可怕，因為它可能會在網路上留存多年，難以辯證。如果只是單純搞笑也就罷了，如果個人或者組織，以這類型的資料來作為決策的判斷依據，那下場可能非常慘。錯誤的資料，比沒有資料更糟。


不過，只要稍微留意，加上合理的好奇心，統計謠言是有機會判斷其可能性：

(1) 不解釋的數字

在各類文章或研究報告中，為求精簡，只會根據重要數字做衍生推論。然而，數字背後通常還有「未解釋」的數字，而這個數字可能更為重要。

以企業僅21%的需要大學以上學歷為例。這篇文章，簡單說明勞動部的調查，僅有21%的企業需要大學以上的學歷。然而，這個數字有很大的問題。

也許，該調查隨機抽了100個企業主，其中只有21個企業主宣稱需要大學以上學歷的員工。

也許，該調查抽樣了企業主的「100個正在招募工作職缺總數」，這100個職缺中，只有21個是需要大學學歷。

這兩者有極大的差距。前者，可能這21個企業主，所需要員工數量高達2萬人，而另外79個企業主，所需員工只要79個人也說不定。而後者，正在招募的職缺，和「已經在職」的學歷也並未顯示。而單就此推論，僅21%企業需要大學學歷基本上過於簡化。

所有經過簡化，而沒有附上數據的真實來源的推測，其解釋很容易被扭曲。然而，被扭曲的解釋，當然比較有戲劇性，比較容易被注意。

勞動部網站根本也找不到這份調查。

此外，很多政治性民調也是屬於此類，涵蓋許多不解釋的數字。

(2) 接近完美的不可能

網路上流傳一份超過十幾年的Dr Ephrem Cheng研究顯示，越早退休壽命越長。(參考這裡，這裡，這裡)  

這份數據流傳非常之廣，被引用次數非常多，每隔數年也會在通訊軟體上流來流去。最近當然就是LINE上流傳的長輩文。

上面提供了一份數字，是退休年齡跟「壽命」的對照表如下。

retire	life
49.9	86
51.2	85.3
52.5	84.6
53.8	83.9
55.1	83.2
56.4	82.5
57.2	81.4
58.3	80
59.2	78.5
60.1	76.8
61	74.5
62.1	71.8
63.1	69.3
64.1	67.9
65.2	66.8

不會統計的人也可以看出，在這個表中，越早退休，壽命越長。如果49.9歲就退休，那麼可以活到86歲。65.2歲才退休，就只能活到66.8歲。

以相關係數簡單計算，他的相關程度高達-0.96，換言之，這是一份極為完美的負相關數字。

這種過度完美個數字，應該要看研究論文的細節加以瞭解。例如他的樣本有多大？是什麼時候做的研究。就可取得的事實來看，他的樣本很小，並且研究的時間幾乎可以肯定在1990年以前。由於上述的年紀追蹤到80歲，所以研究對象大概是1930-1950嬰兒潮時代的人。

最重要的是，這些數字並非真實研究論文，卻在很多人的轉貼中，莫名其妙的被冠名「美國權威學者」。


這份研究數字會流傳很久的原因，是他剛好契合 (1) 這看起來是個學術研究 (2) 可以被直銷，財務規劃，人生規劃等等產業拿來利用 (3) 可以有趣的解釋它

除此之外，別無他因。雖然已經有些人發現不對勁，例如這裡。但是許多第一次看到此研究的人，仍然不明究理的轉貼。

如果想知道實際的退休年齡和生存年齡的相關性研究：請參考這篇研究。該篇的結論就交由各位判斷，但至少它的研究方式，數字細節，都解釋得十分清晰。

我已經透過管道寫信給該研究者Dr Cheng，懇請取得確實的研究資料以及統計方式等細節(說不定他也是受害者？)。至今2017/Jan/11尚未收到回覆。

(3) 邏輯上的不可能

邏輯上不可能，或者簡單的說「數字兜不攏」。

中國的2010的地方GDP就是邏輯上的懷疑問題。因為 中國31個省份的GDP加總起來，竟然遠超過全國GDP，而且高過很多。這在邏輯上是不可能的事情，因此自然就有合理的統計造假懷疑。

類似的事情也容易發生在沒檢查，而且其實也不打算認真做統計的相關文章上，例如這裡。因為在許多時候，謠言只是想要造成吸引人的目的，其真實性不重要，當然就也不特別檢查數據。所以自己造成自己數據兜不攏，邏輯上不可能的情況並不少見。

這和前兩者不同，邏輯上的不可能，可以單就資訊本身的內容加以探索，或者是再加上一些事實根據來檢視。因此，比較容易看出謠言的真實性。




最後，稍微提醒一下：廣告的統計宣稱，其實難以查證。例如高露潔的「大部分牙醫師推薦」如果不是公平會主動進行查證，一般市井小民根本無法查證屬實與否。

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

最近有個真實故事：

---

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

台灣人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，這本書用詞遣字相當簡單，而書的本身就是「增加閱讀能力」的方式。因為是本很老的書，應該很便宜，或許早已經沒有版權？