建構新創公司的資料處理框架
Build the data infrastructure for your own startup
新創公司是否能成功就是要看能否以最快的速度成長，資料的判讀尤其重要，所以在 Cubo，我們希望建立成一個 Data driven 的公司，讓資料作為我們作決策的基礎。
過去傳統上來說，多數公司會直接用 Google Analytics 作為產品的資訊中心，透過 GA 分析來作產品優化的依據。但是只透過單一 GA 會開始面臨一些挑戰：
- 不同成員有各自習慣的 BI 工具，GA 無法滿足所有人，也無法滿足所有的 Use case
- GA 僅能用在產品優化上或網頁優化上，無法滿足不同部門的需求
- GA 是非常單一面向的，難以對不同資料作關聯查詢
- Google 這幾年將 App 的 GA 獨立到 Firebase 產品線上，GA for Firebase 說實在的很不好用，少了不少功能，用起來也很不習慣
但是在新創公司，資源相當匱乏，人手不足，可以怎麼作能最快最省資源的方式建構出自己的資料框架？ 以我們自己的經驗來說，就是善用 Google BigQuery 作為整個資料框架的核心。
下圖是 Cubo 的資料框架設計
BigQuery 是我們的資料倉儲 (Data Warehouse)，也是整個框架的核心。BigQuery 的優點是，你可以把它想像成一個無限大的 SQL 資料庫，你可以無限制的往裡頭塞資料，資料的 Insert 跟查詢效能都在可接受的程度內，當然效能沒有辦法像傳統的 SQL 資料庫那麼好，所以它不適合拿來做 Production 上的資料庫，但是優異的巨量資料查詢能力，讓他非常適合拿來做資料倉儲; 另外，BigQuery 是 managed service ，你無須花費人力作管理，只要會用就好，更棒的是，BigQuery 的介面就是 SQL，只要會 SQL 就會用 BigQuery ，目前市面上的 BI 工具都有直接支援 BigQuery，所以不管你們公司用什麼工具來分析都適用。
資料的收集
一當確立好 BigQuery 作為整體框架的核心後，接下來問題是怎麼將資料開始往 BigQuery 倒。
在我們公司，有 App、裝置、API server、AI inference server 跟客服系統，甚至未來也希望將 Marketing 的廣告資料匯入。
不同來源的資料導入 BigQuery 的方式也有所不同。以 App 來說，我們透過 segment.io 作為資料的 hub，App 所有 tracking 資料都先進到 segment 中，再透過 segment 轉發到 Mixpanel、Google Analytics、Facebook Events 等，當然最重要的是同步備份到 BigQuery。我們的 App 在上線前就已經設定好 Segment，所以目前在 BigQuery 中保有所有 App 的 tracking 資料。
不過 Segment 轉存 BigQuery 有個小缺點，它不是即時的。Segment 的作法是固定時間作同步，付費使用者可以設定一天兩次的同步時間點。也因為這個缺點，我們還是保有使用 Mixpanel; Mixpanel 我們最常拿來追蹤使用者遇到的問題，如果 Segment 可以幫我即時儲存到 BigQuery 的話，理論上我們是可以自行開發一個簡單的 Portal 做到類似 Mixpanel 的功能。但是目前為了客服人員能夠即時協助用戶排除問題，我們還是保留使用 Mixpanel。
Segment 更棒的是，不只可以幫我轉發 App 的 tracking 資料，也可以轉發其他 Source，像是 Zendesk。我們公司產品相當重視客服，目前客服的 portal 使用 zendesk，累積幾個月下來，有相當多的客服資料，這些資料都是可以作分析的，包含哪些類別的 Issue 最多，Issue 的頻率，用戶發 Issue 的時間點等。將資料彙整進 BigQuery ，變可以透過各種 BI 工具輕鬆做到這些分析。
AI Data Feedback Loop
AI 需要持續的資料來演進，訓練完的 Model 上線作 inference，持續採集新的資料，回到自身的資料庫中，然後標記，重新訓練，佈署新版本 Model ，持續改善準確率。
所以我們公司在做 inference 時，新的資料會安全的存放在 GCP Storage 上，嚴格限定控管，至於 meta data 則是存放在 BigQuery 中，並透過內部的工具從 BigQuery 與 Storage 上的資料提供介面讓內部的人作進一步的標記工作。
標記完的資料重新訓練，在驗證準確性後，重新佈署上線。
不過由於 BigQuery 的寫入速度並不是特別快，為了避免影響 inference 的反應速度，我們在寫入 BigQuery 前有另外架設一套 Fluentd，讓 inference server 可以快速的將 log flush 出去，而 Fluentd 再以 batch 的形式寫入到 BigQuery，減少因寫入 BigQuery 帶給前端 response time 的影響。
Service Log / Device log
我們公司整體雲端架構有點小複雜，因為跨了兩個不同的雲端平台 AWS 與 GCP ，這是有一些原因而這麼設計的。
我們對 App 與裝置的 API 是架設在 AWS Lambda 上，但是 AWS 的 CloudWatch 不太好用，所以目前所有的 Log 都是直接打到 GCP 的 StackDriver 上。StackDriver 是套很優秀的 Log 查詢分析工具，有很方便的介面提供查詢，可以快速找到問題，也提供 monitoring 與報表工具讓你對 Log 進行監控與分析。StackDriver 也可以將 Log 倒到 BigQuery 中，不過目前我們還沒有需要用到這功能，光 StackDrive 已經可以解決我們許多在 trouble shooting 上令人頭痛的問題了。
至於裝置的 debug log，我們在裝置中定期彙整壓縮加密上傳 S3 ，然後再寫個 scheduler 轉存到 BigQuery 中。然後再透過 BigQuery 去作分析，了解所有裝置的運作情形，以及協助找 bug。在轉存時也是仰賴 Fluentd 來作 Batch。
BigQuery 的優化
使用 BigQuery 時也有些眉角要注意的。其中之一是注意 BigQuery 的收費方式。BigQuery 是依據儲存資料的多寡與查詢的資料量來收費，儲存的資料的量費用一般來說都不高，但是查詢資料的量會因為你 table 設計有很大的影響。BigQuery 的建議是：
- 盡量減少用 SELECT * 這類的查詢。查詢你想要的欄位就好
- 使用 Partition table 。Partition Table 是根據時間來儲存切割資料庫，透過 Partition table 的查詢可以減少查詢的資料量，也可以加快查詢的效率。
另外我也會對常用的資料作 aggregation，我自己有寫一些 Firebase functions，每日將一些常用的分析資料 aggregate 到另外一個 Table 中，如此一來也可以減少查詢的用量，並加快查詢的時間。不過這部份因為要寫程式，所以還蠻花時間跟人力成本的，建議可以先手動用 SQL 查詢確認資料的準確性後，再將該 SQL 寫成 batch job 去每日執行。
不過這也是希望 BigQuery 未來能夠加入的功能:
- Schedule query
- Parameterized query
如果有這兩項功能會讓資料整理變得更容易。
分析工具的整合
支援 BigQuery 的工具很多，可以善用這些工具去建構出內部的 Dashboard。我們公司常用 Tableau，我自己用 Mode analytics，其實也可以用 Google Data Studio ，各有各的好處，不過這個框架的用意是要去建構出一個有彈性的系統，讓不同的軟體都能夠串上來使用。
但是我自己想特別提的是 Jupyter Notebook，這其實是受 Netflix 這篇文章影響。
Netflix 談到他們怎麼在公司內部如何透過 Jupyter Notebook，去架構出一個很有彈性的框架，讓不管是 Analytics engineer, Data scientist, 或者 Data engineer 各自用他們習慣的語言去作分析。
Jupyter Notebook 是一套非常強大的工具，他的好處是將程式的執行、文件，與結果放在同一個地方，所以一份 notebook 可以自行解釋資料是如何被處理的，並且作圖形化的呈現。而且它支援許多不同的語言，不過最多人用的還是 Python 與 R ，畢竟這兩者非常適合用來作資料分析。
在 Cubo，我們在自己的伺服器上架設 JupyerHub，它是一套給多人使用的 Jupyter Notebook 系統，每個人可以有自己的登入帳號，也可以整合其他 oAuth 服務。只要安裝好 BigQuery Python module 便可以讓所有成員直接在 notebook 中查詢 BigQuery 中的資料。
總結
我自己很喜歡 Netflix 內部的工程師文化，Netflix 是一間重視數據分析的公司，每天要處理超過一百萬兆的事件紀錄，這是海量的資料，光儲存跟分析資料就是一件非常有挑戰的工程。Netflix 可以把這件事情做的很好，是因為他內部有很好的文化，每個員工有對資料分析的渴求，迫使他們不斷精進自己的資料處理能力，並建構出一個有彈性的架構，讓不同的使用者可以在這樣的架構上得到他想要的資訊。
這樣的文化也是我想要建構的，不過新創公司資源相當侷限，不可能在一朝一夕便建構好一套完整功能的框架運行，如何運用現有的工具，以最小的支出達到最大的效益才是重要的考量，然後慢慢地朝向一個 Data driven 的公司前進。
我們公司目前的產品是 「Cubo 寶寶攝影機」，AppWorks 第16屆團隊，我們試圖透過產品來改善人類的行為，透過 AI 來協助人類將事情做的更好。
我們一直都有在持續招募好手，像是 Backend engineer、Deep Learning engineer，如果你對我們的職缺有興趣，可以直接跟我們聯繫 jobs@getcubo.com
覺得我寫的還可以
請幫我拍手三下 👏👏👏如果想要給我更多鼓勵
可以給我更多的拍手 👏👏👏👏👏👏👏👏
