本稿件基于對玩物得志CTO張淼及大資料負責人朱朔晗采訪成文
2018 年底，玩物得志從 0 開始，搭建技術團隊，技術架構快速經曆了服務化、平台化等轉變。
為了支撐業務的快速發展，玩物得志極少自己造輪子，會大量采用雲平台提供的 SaaS、PaaS 服務。比如大資料體系是在阿裡雲 DataWorks + MaxCompute 架構體系上建設起來。使用了其核心存儲、計算等元件，上層的可視化以及業務查詢部分，在使用過程中也會有大量的定制化需求，玩物得志在開源方案的基礎上進行了一些二次開發。
之是以直接選擇雲産品搭建研發系統，張淼認為對于快速疊代的初創型企業來說，一切效率為王。如果選擇自己去搭建整個鍊路和基礎設施，很難有現在這麼快的發展速度。
早期，玩物的資料量比較小，所有業務資料都放在一個大的資料DB 的執行個體裡，是以當時讀庫或者用訂閱binlog方式打造一個分析庫，就可以完成日常報表輸出工作。跑SQL就足夠了，這是資料體量小的時候通用的一個方案。當時沒有大資料的概念，都是在Mysql上跑sql腳本，出資料報表，定期給到營運，這就是玩物得志早期的基本的架構。
從玩物得志APP 正式運轉起來大概四五個月的時間，電商業務發展很快。2019年，每個月都是指數性增長，然後就發現Mysql查資料查不動了。我們就開始探索新的解決方案來幫助我們實作大資料平台的建設。之前我們更多是業務資料，比較簡單，放在DB 裡。在我們接入了埋點後，就要去拿日志。而解析日志Mysql是不支援的。我們開始去想到底哪種大資料平台架構可以滿足我們目前的需求。
此時，玩物的人力資源受限，整體的資料規模也不大，雖然Mysql查不動，但也沒有達到那麼大規模，傾向于選擇一站式的資料開發平台。其好處是不但效率高，我們又不需要投入人去做很多底層的事情。因為對創業公司來講，早期做資料底層建設是費力不讨好的事情。其次就是能夠高效的幫助我們把原來基于Mysql的這套體系搬到雲上去。我們發現阿裡雲的DataWorks+MaxCompute 産品是符合我們預期的。因為我們最開始是一個DB ，DataWorks有一鍵整庫同步到MaxCompute功能，對于早期做建設，基本上就是配置一下，等它運作完成之後，初步的入倉就做好了。體量不大，也不需要考慮分流，分層等一系列事情。另外，我們所有的業務應用都依托阿裡雲的平台，業務日志也是放在阿裡雲SLS服務上，SLS可以直接通過DataWorks歸檔到MaxCompute，能夠縮短我們在資料轉化中的鍊路，很便捷的把我們整個前端的日志和後端的業務資料結合起來。是以，我們就開始基于DataWorks + MaxCompute 來建構我們最早期的大資料平台。
早期大資料平台架構
基于這個我們還做了一件事情。最開始大家都是跑Mysql發郵件和Excel，畢竟那時人少，業務也相對聚焦。當業務規模變大，業務方人變多，每個小部門的需求越來越分化時，我們就需要做一個可視化的資料平台。
最開始用redash+RDS+MaxCompute的流程， MaxCompute對資料進行處理，然後通過資料集層回寫到RDS，再通過RDS連接配接前端報表可視化軟體去做展示。但存在的不足之處就是鍊路長，需要先把業務資料同步到MaxCompute，然後MaxCompute再去跑任務，跑完任務再寫RDS，寫到RDS再去給可視化用。整個環節長，中間鍊路多，資料累積多了，對RDS占用大，存儲成本非常高。
于是我們開始推進到第二個階段。使用redash工具，發現阿裡雲MaxCompute有一個Pyodps 的sdk能夠在我們的開源工具二次開發內建Pyodps能力，就可以直接用MaxCompute裡的資料，不需要去回寫，這樣就節省了RDS 存儲空間，并且縮短我們的資料鍊路。當時，把很多需要回寫的任務逐漸往這個方向去改造。這個改造本身解決了鍊路長和存儲問題。但又出現了新問題，就是MaxCompute畢竟是一個檔案系統，讀取資料的速度不太能夠秒級傳回。于是我們又對MaxCompute做了深入的了解，發現 lightning 這個功能是能夠符合我們預期的，它相當于在離線的系統上面又封裝了一層，類似數倉DB的概念。我們所有的結果表都比較小了，都可以通過lightning 傳回到報表系統。我們的報表系統通過這樣的疊代，最終形成了業務資料庫到MaxCompute，再通過lightning 傳回到報表系統這樣一個架構，将近一年的時間裡，一直是這樣的架構來實作資料可視化和自動化報表。
我們在初期遇到的問題，除了由電商業務本身的發展帶來，另外一個原因是電商以外的業務正在逐漸孵化出來。比如我們有内容社群的業務，也有商家端的業務。除了業務本身，技術架構上原來的單庫支援本身存在RDS的瓶頸，不可能無限制擴張。于是，我們就開始對技術架構進行平台化，服務化的建設。回報到資料這邊的話，就是業務開發那邊開始進行整個平台的分庫分表。一個業務應用，就跑隻有這個業務應用的執行個體，然後這個業務應用的執行個體，底層可能會有多個表。同一個業務同一個邏輯表，底下可能還會分到各個不同的事實表裡，到這個階段，我們的大資料建設面臨的問題就變成了有很多的讀庫，并且業務變複雜了，再通過通路源表的方式進行報表加工就很低效。為了解決這兩個問題我們做了兩件事情。
第一，基于DataWorks 和MaxCompute本身的能力對原來的這種一鍵式整庫歸檔資料倉庫的方式做了調整。通過調整多個串行的資料基線，每個基線再通過每個節點運作的耗時和對資源的占用去合理的配置設定基線啟動的時間，減少并發請求業務讀庫的情況。因為數量太大，如果并發去請求，會導緻讀庫 IO打滿，觸發一系列的報警。通過這種方式，首先是減輕了讀庫的壓力，其次還能節省讀庫成本，讓讀庫配置不用做的特别高。
第二，業務分化，我們開始做數倉模組化。在整個分庫分表業務變更的過程中，引入了更多不同的資料庫形式。最早是RDS資料庫，都是單體Mysql。後來有些業務應用的資料規模特别大，Mysql 單機不能支援。我們就引入了DRDS、Hbase等一系列方案來解決業務上的資料存儲、計算和處理的問題。對于我們的數倉來說，因為業務資料分散在不同的媒體裡, 是以我們的訴求是對不同來源的資料進行資料品質監控。這就應用到了DataWorks 和MaxCompute的特性，能夠對資料品質進行定時監控，通過既有的觸發報警的功能，提醒我們某天某個業務的資料流入是有異常的。這樣我們的數倉同學就能夠及時介入并解決問題。
目前大資料架構
當下的情況又會跟中期不太一樣，因為平台的體量又到達了更高量級。現實的問題就是不管什麼樣的業務，單表的資料量是非常大的。單表的資料規模大，就不能再用原來通過DataWorks資料內建方式批量導入。既然批量導入不現實，我們就開始調研其他方式來把業務DB的資料同步過來，我們也看了阿裡雲的産品，包括我們本身的DTS，它有資料內建的功能，也能夠指向到數倉。不過用起來感受沒那麼完善。比如說DRDS的資料，沒有辦法直接打到數倉。因為有很多分庫分表，我們需要DRDS的資料能夠平滑的進入到數倉裡。我們就對資料內建進行了疊代。先引入了一個新的內建元件DTS 加DataHub，然後再到數倉。因為DataHub可以根據我的需求進行資料歸檔，我可以每十五分鐘就把資料歸檔到數倉裡面。整個架構就會變成了來源是業務DB，然後DTS，然後DataHub。然後再通過DataWorks 進入MaxCompute這樣一個雲原生的大資料平台體系。
随着準實時和實時需求越來越多，有兩個問題是亟待解決。一是原來所有資料查詢，甚至準實時資料查詢都依賴于MaxCompute本身的計算能力。因為有準實時需求，我們每1小時、半個小時甚至十五分鐘都有大量的任務運作。但算力其實是受限的。BI同學想要去查一個表的資料，此時計算資源可能在同步其他的表或計算其他的任務，導緻資料查詢效率不高。這時我們發現了MC-Hologres，他能通路MaxCompute底層檔案資料，且不占用MaxCompute 資源，形成一個獨立的計算節點和叢集，解決我們查詢加速和資源隔離的問題。
另外，我們目前有很多榜單類的實時資料名額需要提供給業務方。今年下半年又上線了廣告平台，商家可以在我們平台内部投廣告。榜單，直播這類業務都依賴實時資料來産生業務價值。這時我們就引入了實時數倉。實時數倉建設依賴阿裡雲EMR，采用Flink 加Kafka，對我們的資料進行訂閱消費分層。資料來源也有幾種，一個是DTS 到DataHub。因為DataHub除了能歸檔到MaxCompute，DataHub資料也可以被Flink在這些場景裡去訂閱。我們搭建實時數倉時，也用了Flink on Yarn的方式，基于EMR 的Yarn，最終幫我們把實時數倉的架構搭建起來。實時數倉建好後，還有一個訴求是需要實時資料，我們需要對資料進行報表化和可視化，自動推送一系列資料給業務方。此時，我們又引入了查詢引擎Druid和superset的資料可視化。因為Druid和superset天然綁定在一起的，我們的Kafka，可以直接被Druid的資料引擎消費，以此實作完整的實時的資料鍊路閉環，構成了我們目前的大資料平台。離線是MaxCompute+DataWorks+報表可視化。實時是Flink+Kafka+Druid+superset。
再說到未來的規劃，就是引入湖倉一體的建設。這樣的規劃是從兩方面來考慮的。
未來規劃
一方面是通過湖倉一體的建設，可以讓離線和實時兩套系統拿到同一份資料，資料不需在多個地方存多個備份。能夠節省存儲成本的同時能夠保證我們資料的一緻性。并且統一存儲還能避免資料孤島問題。所有資料不管是存、寫、讀，整個平台内的資料都能做關聯的分析，甚至跳出結構化資料去做一些非結構化、半結構化資料的研究都。
另一方面是需要做冷熱資料的分離，從大資料的成本角度，存儲成本是可以優化的。很多冷資料，沒有必要放在支援密集通路的存儲媒體裡。阿裡雲目前的湖倉一體，能幫助我們去滿足這種冷熱分離的資料需求。可以把冷資料歸檔到對象存儲OSS 裡面。而每天頻繁通路的熱資料，還是放在MaxCompute裡。同時我放到OSS 裡面，可以獲得一個完整的資料備份， OSS 資料又能通過JindoFS給EMR叢集使用，幫助我們将離線和實時整個叢集的存儲打通。資料交換，資訊交換都可以通過同一媒體來完成。這就是我們未來希望能夠完成的目标。
DataWorks 官網 >> MaxCompute官網 >> MaxCompute 互動式分析（Hologres）>>【歡迎掃碼關注玩物得志技術】
【歡迎加入MaxCompute開發者社群釘釘群】