Data Pipeline 從零開始建置

如同前文所述,我在電商產業工作,近年來隨著公司的發展,開始將研發的重點強調在數據與 AI 的應用上,因此資料的蒐集儲存的彈性就需要不段的擴增,來滿足斷續分析與應用的需求。

近一年的工作有一半是在做資料的處理/整合,記錄一下工作上 data pipeline 的需求與演進,概念上就是如何從基本的 rds 進化成可以擴展到適合大數據分析的資料庫架構。

契子

幾乎所有的系統都是從 RDS 開始的,我們也不例外,但是當我們開始要處理使用者行為這種規模大的大量資料,事情就開始改變了,一開始我們是使用 mongodb 實驗性質的開始儲存每個商品的 pageview,因為其資料量可以達到數億筆之多,而我們的經驗是,當你把像是 log 一樣的資料存到 mysql,最後都會有一點悲劇,mysql 的查詢會隨著資料量增大,變得有點難以查詢與維護,且不小心錯誤的查詢還會影響其他更重要的效能。

轉念

像是 mongodb 或者 elasticsearch 在實務上就很常拿來存放 log,但是我們的比較希望能用 fully managed 的雲端服務,只是前幾年沒有找到對應的 solution,單純透過 mongodb 還是滿足了決大部分的使用情境,只是需要花不少時間管理與調教,並且限制了很多實務的應用,遇到的問題不外乎是機器的記憶體與 io 的瓶頸,加上因為人力與需求的考量上沒有將其 cluster 化。

在這個架構之下就開始逐漸建立基本的資料觀念,不要把重要跟不重要的資料放在一起,像是交易與商品等關鍵應用的資料,就很適合放到 RDS 裡面維護,但是 log 化的資料需要更適合的資料庫來處理,這個觀念會被應用在後續的每一個調整之中。

轉型

美好的時光總是匆匆,當我們開始要大量的分析使用者行為的資料的時候,我們開始不停的對 mongodb 進行大量的查詢,大範圍的掃描對其進行基本的統計,在此之前我都是透過 aggregate 來解決,雖然其查詢彈性很大,但是終究沒辦法滿足資料分析上的需求,終究你當然沒辦法讓每個分析師都學會 mongodb 那極為不實用的 aggregate 語法,且對大量資料的掃描上的效能上也有個瓶頸。

所以最終我們開始思考,要重新將 mongodb 定位在短期資料的緩衝上,他可以即時的資料塞進去讀出來,做為一個應用的後端其極服有彈性,但是當我們要大量掃描的時候,就會遇到很多難以解決的困難。

後來我們評估了 AWS 與 GCP 上所有的服務以後,我們決定採納 BigQuery 來作為資料倉儲的解法,我們將 mongodb 的資料即時同步進 BigQuery,在這個決定之後,我們的所有資料分析突然變得如魚得水,你可以想像 BigQuery 查詢起來的快感,像是沒有效能瓶頸的 RDS,你不需要考慮索引、IO 的限制,可以隨意自在的透過 SQL 來取得資料,唯一的考量是每次查詢所掃瞄的資料都是要計費的,只是其費用極其低廉,在我們這種小規模的數據分析上,甚至可以比一台高階 RDS 開一個月的費用還低。

最完美的是 BigQuery 可以跟 DataStudio 無縫整合,讓我們快速的探索這些資料,並做出對商業價值有意義的報表,進一步提供給不同業務單位使用。什麼?data studio 竟然是免費的:O

合金進化

接著半年我們就過著開心快樂的日子了,只是後續的問題變成 mongodb 的定位需要更明確的被切割出來,否則其資料不斷的增長,造成硬碟擴充維護與查詢效能會不斷的拖垮他作為短中期資料緩衝區的定位。

所以後續就開始評估將 mongodb 的資料都設計為帶有 TTL index 的 collection,來限制其增長,但是就要將其資料都封存到一個更適當的地方,因為 BigQuery 的資料有經過轉換,也不是透過即時的方式同步,反而使 mongodb 作為短期資料庫定位的實作不夠完整。

所以在最近決定開始採用 AWS 的 kinesis stream 與 kinesis firehose 作為資料串流的入口,在資料進入後可以即時的同步到 mongodb、封存到 s3,同步到 bigQuery 上作為資料倉儲,來完整的滿足區分短、中、長期的資料分析、應用、備份需求。

大致的情境如下圖

結論

在這個 Data Pipeline 成形以後,決大部分的資料分析與應用的情境都不會被侷限住了,在處理大量資料統計就到 BigQuery 查詢,要做前台應用就把結果塞到 mongodb,在做後台就判定掃描的性質來決定要到 BigQuery 或 Mongodb。

在這裡有一個新的問題產生,目前的 Data Pipeline 真的是否需要重複的儲存到不同的資料倉儲服務中呢?mongodb 適合應用、除錯、彈性的查詢,BigQuery 適合資料分析、s3 適合封存備份,但其每一個環節都有重疊的部分,是否能在收斂成使用更少的服務就完成所有需求呢?有可能拔掉自建的 mongodb 且在成本合理情況下,達到整個資料流都 fully managed 嗎?

我們最近剛好在徵資料分析師/科學家,對我們的資料與應用有興趣嗎😮? 可以跟我聯絡喔!

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *