王可攀 加和科技CTO
本文将基于加和科技大資料平台更新過程中面臨的問題和挑戰、如何調整資料平台架構以及調整後的變化，為大家介紹數字營銷行業大資料平台雲原生更新實戰經驗。主要分為以下三個部分。
- 加和簡介
- 加和的大資料服務挑戰
- 加和大資料平台更新
一、加和簡介
加和科技于2014年創立，2015年搭建自己的技術服務，整個的服務模式為品牌廣告客戶，現在也涉及到主要有營銷需求的客戶提供營銷的技術解決方案。
(1) 加和服務模式
以下是加和科技對接的媒體方和資料方。
加和服務模式是把所有的媒體流量形成一個管道，當客戶需要在不同的媒體之間做聯合的控頻，比如說同一個使用者在優酷上看到一個廣告，在愛奇藝上又看到一次廣告，客戶希望使用者隻看到三次廣告。加和科技可以做一個跨平台的管控，同時客戶希望有第三方的挑選和監控，就和其他的服務商協作，為客戶提供一個廣告的服務。
(2) 加和資料規模
加和科技資料量級增長的非常迅速，最開始的時候流量可能還不如一個中小型的媒體，上個月峰值達到800億的請求。資料的複雜度也比較高，每一個請求都帶着相應的廣告的資訊，每一個請求裡面有近百個相關的次元需要處理。每天日均觸達的達到5億+次，全年上線的活動5000+，服務100+品牌的客戶。
二、加和的大資料服務挑戰
(1) 服務場景的挑戰
随着體量的增大，遇到一些問題和痛點：
一是資料量級大，服務運算複雜。服務的量級很大，這個量級每天都要去實時，需要分析或者是查找。客戶在一定的時間範圍内做活動資訊的歸納，或者是跨媒體的去重的處理。
二是客戶需求多變，需求複雜度大。客戶的需求也是多變的，服務的客戶分析的資料的次元非常多，每一個媒體使用者不同标簽屬性上去做拆分去重，并不是統一化的需求，是以需要在大資料的範圍内對這些需求進行處理。
三是計算量起伏大，峰值難以預估。随着客戶的需求而走，整個計算的量級起伏也會比較大。客戶有一波緊急的投放，會導緻很多的媒體的流量都包下來，導緻在短期的流量峰值會非常高。如果客戶這段時間沒有下單，量級也會相應的有些下降，服務成本和能力之間需要一個彈性支援的。
四是服務保障要求高。從媒體到請求，把資訊發給第三方或者是流量監控的平台，再回來，最終把決策好要給使用者産生什麼樣的素材，整個過程在100毫秒之内完成，要考慮多次的網絡延時和計算的延時。如果産生一些資料的錯誤，會對客戶的服務造成很大的影響。
(2) 自建大資料架構
加和科技選擇自建的服務平台，數量級沒那麼大的時候選擇了一款商用資料庫去做整體的資料的支援。加和科技的服務體系一直在阿裡雲上面，但是資料庫選擇了一個商用資料庫。當時也是平衡人員成本和服務的性能的要求，在複雜的分析的體系之下，商用資料庫的性能還是比自己搭建的叢集要好很多，而且相應的伺服器成本也會更低。
當時的資料來源主要是從ECS獲得的一些日志，對資料實時性要求不高，更多的是離線分析。是以一開始用的是把日志做壓縮，然後定時彙總到的資料叢集去做處理的方式。再利用Kafka收集合作方的相關資料的資訊，整合到業務報表後給客戶呈現。
曆史資料是存在OSS 上面，另外一個自研的BI 是用于展示對應的複雜資料報表，結果支援一些自主自拖拽的分析。從成本考慮，簡化了資料分析的部分，利用小時級别的這種離線資料，再加上Redis 的緩存資料，去做了線上統計的子產品。
(3) 曆史架構服務痛點
曆史結構有很多痛點，随着業務增長、資料量增長，出現了越來越多的問題。
首先，是計算彈性差。資料量不大的情況下，商用資料群還是可以比較快的做一些擴縮容。負載越大越難擴充、 應對突發故障困難、增減資源耗時不可控整，就會對業務造成拖累。如果出現伺服器發生故障，整體的業務就會産生很大的影響。
其次，是資料管理很複雜。曆經多年後，形成了很多中間表，資料難以劃分、調控複雜度高、業務之間依賴高、 任務資源争搶，中間的邏輯關系很難梳理的。在計算中又産生一些資源消耗，就進一步加劇了對彈性的需求。
再次，是特定場景效率低。服務的場景經常用到大規模的資料交集，涉及對大量資料交集的查詢。單一的資料引擎在某些場景下很快的，但在一些特定場景下效率不高，因為把資料都放在同樣的叢集裡面去，是以它的效率會受比較大的影響。
最後，是計算消耗難以預估。這個從業務角度考量，成本不可控、 計算任務難以和業務打通，很難為客戶提供一個标準化、可視化服務。
三、 加和大資料平台更新
(1) 更新後架構
調整最重要的環節在整個計算引擎的部分，把資料搬遷到了MaxCompute的平台上面，用DataWorks去做資料的排程和管理。 MaxCompute的使用帶來了大幅的靈活性提升。
使用雲環境擴縮容是比較友善的，計算的資源和存儲的資源都獲得了保障。也可以把原來的資料表做更好的分區分表的管理，可以看清楚這些資料怎樣用，在中間的關系是怎樣的，可以做更好的業務流程的管理。
在搬遷的時候，MaxCompute不支援這種開源的排程，後來是聯合阿裡雲的一塊開發，最終支援調用MaxCompute的任務的方式。變化比較大的是自研的BI2.0子產品，之前的服務子產品是自拖拽的一個産品，發現有的客戶不會拖拽，這種方式也是難以接受的，現在改善成自動生成報表服務。這個服務目前看起來可以讓客戶大幅用起來，資料查詢的數量會大幅的提升。
(2) 架構調整效果-資料方面
架構調整的效果，最顯著的是資料方面。首先是日均使用者數量有很大量的提升，從原來的每年的幾百個實時的請求上升到幾千個，一部分的耗時很高的任務通過MaxCompute也得到了解決。以前部分高耗時任務等待時間非常長，現在時間縮減5倍。以前整個資源的調整時間平均大概72小時左右，現在可能都不到半小時的時間，這是雲帶來的能力。
(3) 雲原生大資料平台對加和的價值總結
最後，做了架構調整之後帶來的一些變化，從幾個角度來說：
一是響應業務需求能力提升。業務需求服務能力大幅提升，單次服務成本降低。業務成本可預估，提升業務服務效率；
二是服務穩定性和韌性提升。大幅降低資源調整耗時和難度、特定計算場景的耗時大幅下降；
三是資料團隊能力轉型。一方面從業務運維轉化為業務推動，另一方面從資料分析轉向機器學習；
四是擴充新應用場景。流程自動化和任務管理自動化、技術棧和業務的服務的持續優化。
總體來說，我們并沒有用到很多複雜的開源技術，優化服務架構的時候，更多的考量是我們的業務彈性，和人員組成。作為技術決策者和技術從業者，更多關注技術供應鍊，依賴阿裡雲提供成熟的技術，我們的團隊得以專注于解決業務問題，更多去靈活的組合市場上現有的技術，然後快速地支撐我業務的發展。這樣專業化分工，專業的人做專業的事，讓我們的團隊可以更好地為客戶服務。
更多關于大資料計算、雲資料倉庫技術交流，歡迎掃碼檢視咨詢。