緒論：資料不科學？

我在跟許多合作的企業主洽談的時候常常都會這麼說：「資料科學本質上跟算命差不多，很多時候在真實世界的預測能力上面也許比去廟裡抽籤還差，其效果可能也比不上燒紙錢，但一旦開始決定要走這條道路，基本上你就是開始入邪教了，因為這個體系跟開發網站前後端或是app不一樣，是一個沒有終點的旅程。」

在開始探討為什麼要出這個專題以前，我想先來寫一點故事。我最早開始跟資料有接觸是在高中的時候，那時候為了經營社團開始研究光的一個特殊性質：偏光性，這是一種可以透過操作磁場改變光的行進方式的特性，在一些自然界的物質例如維他命C，都可以呈現這類的效應，但其訊號非常微弱，要捕捉出這樣的特性需要設計精巧的光學儀器與感測系統。事實上這並不是什麼前緣的科學研究，在法拉第的年代就已經知道有這樣的現象存在，只是在磁儲存尚未實現以前，這樣的概念並沒有實用價值，因此被冷落了一百多年。然而在我念高中的時代，巨磁阻效應的發現以及光學儲存媒介的進步都是讓我對這個領域充滿興趣的催化劑，雖然後來靠這個實驗贏得了2005年世界物理年的獎項，但後來進入台大電機系之後我就開始對程式與認知科學產生更濃厚的興趣，因而沒有繼續下去。即使如此，這樣的過程是非常完整的資料素養訓練，從感測器設計、實驗架構規劃、訊號處理、計算邏輯、假設驗證以及論文的撰寫這些能力大概都在我17歲的時候就已經具備，這事實上也就是許多資料科學家都是物理學或是化學、生物學博士出身的原因：科學訓練。

如果你對這個領域稍微有了解，可能會聽過一句名言：

In data science, 80 percent of time spent is preparing data, 20 percent of time is spent complaining about the need to prepare data.

資料科學日常中，80%的時間是在準備資料，20%的時間是在抱怨需要準備資料

我覺得事實上是挺真確的描述了這個工作的情況，但這還只是資料科學的範疇，實際上還有資料工程的範圍需要考慮。下圖為網路上流傳對於資料人與其技能關聯的分佈圖，原始出處我就不清楚了，應該是在pinterest上面找到的，當初是為了幫一個日本公司規劃資料科學家的訓練課程所收集的：

我覺得這張圖描述的挺符合，在學校的訓練裡面非常偏重於右下角，其他領域的訓練就相對薄弱很多，然而我在2013到矽谷的第一課就是學習軟體工程，就如同做研究需要先學習「研究方法」一樣，如果你是要做資料驅動的軟體服務，不懂軟體工程就如同不懂研究方法一樣。在過去兩年多的時間裡面，我也靠著自學補足了前後端的開發能力，以及對於雲端架構與虛擬化技術的掌握，在我目前日常的工作裡面，是依賴下圖的架構去進行的：

在過去數年的學習裡面，最重要的突破點應該要算是在2014年認識了前Amazon的首席科學家Andreas Weigend，因為跟他有許多深入的接觸讓我得以一窺Uber、Airbnb、IBM、Google與Facebook等頂尖科技公司的資料科學家實際工作的場景與解決的問題，當然更多的是Amazon的觀點與經驗，對我來說都是非常豐厚的啟發，加上我約五年在新創公司打滾的經驗，結合成這樣子的架構觀念。

我大約在一年半以前開始嘗試自己一個人打造從一開始就融入這樣觀念的產品，以我家中藥行獨特的非結構化資料為起點，從零到一建構一個從第一天就以可擴充的資料架構與演算法為核心的產品與商業模式，在過程中因為需要處理古文與中醫專業術語而發展的中文處理技術也成為我目前協助一些台灣的新創公司發產核心演算法的主要競爭力門檻。

這個專題的目的在於透過一系列的文章，幫助對這個領域有興趣的人更了解資料處理技術在實際商業運用上所需要具備的架構觀與技術能力，同時也是我過去半年多乃至於未來一年專題寫作期間經驗、技術與智慧的累積與鎔鑄，然而因為我所具備的經驗幾乎都是在startup，因此處理的資料量級最多只到百萬筆左右，如果您的目的是想要了解tb或是pb等級的資料處理技術，建議您去了解Google Cloud所提供的解決方案或是AWS代理商所提供的專業諮詢，這個專題可能就不是您所適合的題材；若您對於專題的後續內容或是付費訂閱內容有興趣，歡迎您進一步參考專題的說明。

在這個專題裡面，付費限定的文章會用到比較多技術名詞，建議您可以先嘗試了解python、flask、docker、swagger、RESTful API、pandas、numpy、d3.js等技術名詞，因為專題文章篇幅有限，不會一一介紹這些技術的細節，大體而言在付費文章裡面會需要用到的程式語言會包含但不限於以下三種：python3、javascript、yaml，若您對於以上技術名詞都感到相當陌生，建議您看公開文章即可，無須付費訂閱。