聊天機器人 - 快速製作在LINE上的人臉辨識應用

名人以及圖片分析 在和LINE聊天機器人之對話中

 聊天機器人(chatbot)作為人機介面，提供人類各種整合性服務是最容易產生的應用。而人臉辨識，一直都是人工智慧與數據分析的整合課題。因此，把LINE聊天機器人加上照片或人臉辨識的功能，似乎也很有趣。

用LINE QR 加小姍為好友 可以測試人臉辨識

以前，在做關於影像的實驗性質的程式時，通常會先考慮opencv。雖然opencv確實是個好工具，但是如果你的目標不是改善演算法，或甚至做出更先進的人臉辨識方式，那麼opencv會過於複雜。

在2016年底，AWS發表另一個雲端服務：Rekognition。這個服務提供了API用以辨識影像，並順便提供了幾個在應用上的api：「比較人臉」「辨別名人」「識別限制級圖案」。(文件請參考這裡)

這些api要運用的最簡單方式之一，就是使用AWS Lambda來驅動AWS內自己的API，再透過API Gateway跟外界 - 也就是chatbot整合。換言之，這仍然符合公有雲廠商(無論是AWS, google還是azure)的所謂serverless的未來方向。雖然這些公有雲廠商，其實只是為了讓客戶更難離開公有雲環境，但不可否認的是，這些api的確有用而且在初期成本也不高。

快速製作在LINE上的人臉辨識，需要幾個步驟：

(1) 對serverless的設計概念有些瞭解

請參考這裡及這裡。

(2) 對Line聊天機器人申請和製作，以及對AWS Lambda先有基本的瞭解。

可參考這裡和這裡。

(3) 在LINE webhook的event中處理image id。

在webhook的lambda程式中，特別挑出image的id。LINE的訊息傳遞給chatbot時，有分不同的type，要處理的是image type。LINE並不會真的傳圖片檔案到webhook中，他傳遞的是圖片id，透過這個id，可以用一個URL拿到圖片：

https://api.line.me/v2/bot/message/<id>/content

要取得這個圖片，當然要有Line token

(4) 讀取圖片URL並且以取得bytes

以python為例，首先以requests讀取URL，記得stream必須設為True，因為接下來需要將資料(影像的byte)直接讀取成bytearray。參考程式如下

    imageUrl = 'https://api.line.me/v2/bot/message/{}/content'.format(imageId)

    r = requests.get(imageUrl, headers=headers, stream=True)

    bArray = None

    with r.raw as data:

        f = data.read()

        bArray = bytearray(f)

(5) 使用各種AWS的Rekognition服務。

取得bytearray之後，剩下的事情就很簡單了。

以python為例，可以使用boto3 (最好是1.4.4版本)。先取得rekognition的client物件，直接使用裡面的方法(例如以下範例)。將Image參數都設定成{ 'Bytes': your_byte_array} 就可以取得分析的結果。

    rclient = boto3.client('rekognition')

    response = rclient.recognize_celebrities(

        Image = { 'Bytes':bArray }

    )

要注意的是，分析結果response是一個含有各種標籤與技術數值(例如信心程度)的dictionary物件，所有的標籤都還是英文，必須得自己轉換成中文才行。

範例中的「名人辨識」(celebrities)所查到的名字都是英文。可以利用wiki 英文api搜尋這個英文字，找到對應的中文網頁，在取得中文字。

wiki的英文api可參考這裡。

(6) 存取S3之考量

如果看過AWS document應該會發現，使用recognize都可以設定image來源是S3。那麼範例為何不存取S3？ 

事實上，的確可以將LINE的影像，先存在S3，然後再進行分析。然而，這樣會多了「存入」S3和取出S3的時間。並且，S3也是要收費的！影像如果只「分析一次」，那麼存在S3其實很不划算，存在Rekognition裡面更是貴。如果會反覆利用，那麼恐怕還是得存在S3中。

目前結果分享

用LINE將小姍加入好友，就可以試用一下目前LINE與AWS人臉辨識整合。

加小姍為好友 ID-> @opn2514f

加小姍為好友

下圖是辨識川普不同的表情，會被辨識出不同的年紀，和不同的心情。

數據分析 - 獵人頭如何從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採用重複的基礎建設，因此選用兩個截然不同的廠商，可以降低風險。

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