我其實是成為資料工程師之後才開始學習成為一個資料工程師的。
這段話可以說是這篇文章唯一的重點，也可以說是我這兩年半以來從事這項工作最重要的心得，雖然聽起來像幹話。可能有些人會覺得困惑，學校裡面有很多像是機器學習、自然語言處理或是人工智慧等等課程，也有台灣人工智慧學校之類的培訓機構，現在連巨匠都開始教AI了，難道這樣不能夠讓人成為一個最性感的資料科學家嗎？
在這個領域有四個容易混淆的名詞，我想在開始深入之前可以先來探討一下這四者之間的差別：
- 資料分析師（Data Analyst）：著重於透過資料的詮釋找出可運用的商業價值。
- 資料科學家（Data Scientist）：著重於運用資料解析技術開發具有突破性與差異性的核心技術。
- 資料工程師（Data Engineer）：建構以資料為核心的服務所需要的一切基礎建設。
- 軟體工程師（Software Engineer）：產出可交付終端使用者使用的軟體，包含前後端、軟體工程與感測器的設計等等，屬於一個比較廣泛的集合。
回到本文主題，基本上挑選跟成為資料人才是一個一體兩面的問題，其本質命題其實是「什麼是好的資料人才？」若要解決這個問題，就必須更深入的探討：
你想要找，或是成為的人，是為了解決什麼問題而存在？
這個問題，跟實際的商業需求，也跟個人的特質、個性、興趣、志業有關，以我自身為例，我天生的性格就是喜歡做沒有人做過的事情，因此真正能夠吸引我的只有Data Scientist的工作，但很可惜在台灣這個方面的需求很少，是因為欠缺完整的環境，徒有Data Scientist的環境注定會發揮不了作用。以美國某家投資銀行的工作流程為例，他們的作法是Data Scientist只要負責設計數學模型，甚至用紙筆寫出來也可以，會有專門的工程師去把數學模型寫成程式，也會有專門的工程師負責測試、佈署與後續的維護，因此資料科學家可以只要專注於數學，這樣的團隊一年可以產生三千多個數學模型做投資市場的預測，每季作一次大幅的檢視決定是否要續用模型或是要重新設計，然而這在台灣要實踐相對困難非常多，很多公司連實際操作AB Testing的經驗都很貧乏，加上公司往往是依據領導者的感覺制定策略，很難形成數據驅動的文化，因此目前大多數的工作還是集中在能夠產生商業智慧(Business Intelligence)的Data Analyst上面，有少部分Data Engineer的工作，但根據我目前面試幾次的結果，大部分公司其實並沒有搞清楚Data Engineer應該要做什麼，更別說搞清楚跟Data Scientist之間的差異了，而且大部分公司其實都請不起真正有能力的人。
在這種環境條件的限制之下，跟矽谷比起來，要磨練出真正可以做出可規模化資料科學產品的人才其實是相對困難很多的，可以討論的對象也非常少，因此我非常建議有心想要在台灣的產業環境成為這領域的專才者，必須要有先成為通才的覺悟，這也是這個專題之所以存在的目的，我希望能夠透過我自身的經驗，把這條途徑當中所需要經過的步驟用最小可執行的單元讓閱讀此文的你可以依循，期待透過這個完整的系列，可以讓你具備獨立發佈一個資料科學MVP(Minimum Viable Product)的能力。
在本專題當中，我將用嵌入gist的方式來呈現相關的程式碼，我本人不喜歡用jupyter notebook，是因為對我來說其啟動與執行都太過肥大，且在產品整合流程裡面是相對複雜的。在這個專題裡面會用到的工具都盡可能是最基礎的原子型工具或是最簡單的框架，以下是一個非常簡單的範例，但這個份程式碼會是未來所有應用開展的基礎，這是一個應用了Flask與Flask Restplus框架的最基礎程式，將之執行之後就可以在http://localhost:5000/看到執行的樣貌，如下面圖所顯示。
因此，本專題主旨並不在於讓你成為一個可以每個月發論文的資料科學大師，但可以讓你掌握如何將資料科學技術整合到網頁前後端並進行持續整合的敏捷開發流程，我將之稱作為DDD(Data Driven Developemt，資料驅動開發)，從我們第一步是建立符合Swagger標準的html文件就可以證明這點不是在虎爛的，所以可能這點會跟你想像的不太一樣，我沒有打算要取代台大或是人工智慧學校的角色，如果你深愛數學模型，請去跟這些教授學習。
為什麼我們強調工程能力？
在品質與把事情搞定之間取得平衡
資料技術的應用與學術研究最大的差別在於走出高度控制的實驗室環境之後，許多參數與回饋數值不可控性大增，因此非常難追求完美，我大部分的工作重點在於減少資料技術實際落地的障礙，然後建立可以驗證假設可否認性的機制，進而能夠開始實際根據應用的情境調整模型與參數，如果欠缺工程能力的整合概念，在執行的速度上落差會非常大，這也是目前學用落差主要的斷層之一，期許未來台灣的學校體系能夠更重視軟體工程的教育，如同科學研究應當重視科學哲學與實驗方法論的基礎能力一樣。事實上具備足夠的工程能力對於快速交付成果、取得預算也是相當重要的一項能力。
為什麼我們重視敏捷？
視犯錯為探索手段
敏捷的重點就在於敏捷本身，敏捷的能力是工程能力的一部分，敏捷的意義在於整合團隊，面對市場的變化，快速做出調整，而資料科學在商業上主要的應用領域幾乎都免不了最後需要直接跟真實物理世界的數據對接，進而能夠不斷的改進模型的價值，因此犯錯是不可避免的，重點在你能夠如何快速的以最小成本犯錯並修正模型、參數甚至是假設。
PHAME framework
這個概念是過去在矽谷跟著Andreas學習的時候他所提出來的概念，以下列五個面向開展資料分析的工作，事實上也是一般科學訓練裡面注重的素養，在資料科學領域Andreas稱之為Data Literacy：
- Problem：定義邏輯清晰的問題，並且以商業價值作為權衡優先度的主要考量，例如「如果我能夠增強站內推薦的技術，應該能夠提升公司的估值與使用者的滿意度。」
- Hypothesis：定義可否證的假設，例如「使用最基本的協同過濾技術應該要能提升5%以上的瀏覽量，轉換率應高於基於內容推薦的演算法。」
- Action：執行資料分析的能力，包含資料前處理、對模型與演算法的熟悉度、工程整合能力與面對異質資料的處理經驗等等
- Metrics：建立衡量資料技術應用的成果機制，如何設定正確的Metrics對於資料科學技術能否實際應用在產業成果上面至關重要，我們後面會有專文探討此方面的議題。
- Evaluation：整體評估，根據現有的執行情況與衡量數據，評估假設、實驗設計、系統整合等等面向是否有缺陷以及需要調整的部分。
最後是關於本專題使用的軟體版本的資訊宣告，如果你已經熱血澎湃想要挽起袖子來了，請先仔細看一下以下的說明：
主要軟體版本
- Python: 3.6
- Docker: 18.09.0
- Flask: 1.0.2
- Flask-restplus: 0.11.0
- ipython: 6.5.0
- pandas: 0.23.4
- numpy: 1.14.3
- Keras: 2.2.4
雖然我們使用了Keras，但在本專題文章的範例裡面通常不會用到百萬等級以上的數據，事實上通常一萬筆左右的資料量就足夠我們做出最基本的成果了，以MVP來說有時候幾百筆幾千筆也是可以做的，因此我在這個專題裡面基本上是不太會需要用到GPU跟Scala、Hadoop等技術，你只需要燃燒CPU跟準備夠大的記憶體即可(8~16G，16G為佳，如果本機電腦不夠的話可以到Google Cloud Platform或是AWS上面去開適合的機器)，但我們會稍微提到平行化相關的技術以講解程式優化的方式。
使用範例程式
本專題主旨在幫助你完成你需要進行的工作，一般來說，讀者可以隨意的在自己的程式或是文件當中使用本系列專題的程式碼，但若需要重製程式碼的重要部分，請來信聯絡我以取得授權，或是在github上面發送修改的需求，如果對於程式碼、圖片或是文章內容的引用有任何授權上的疑慮，請您來信與我討論。
專題宣告
本篇文章為本專題付費文章系列第一篇，由於付費訂閱設定修改尚未完成，本篇文章會開放公開閱讀到2018年12月31日，若您對於專題寫作風格或是內容有任何想法歡迎您隨時來信指教。
下一篇公開文章「工欲善其事，必先利其器」預計會在12月中到12月底之間刊出，會簡單的介紹相關的工具應如何使用，但不會探討太多程式碼的部分。其後的付費文章會探討「建立第一個資料科學專案架構」如何用最小化的成本建立一個可規模化的資料科學專案工程架構，會包含較多的專案規劃概念與程式碼範例。
有任何的意見請您賜教 ofafa.hsueh.app+dnsc[at]gmail.com
