簡介：?加和科技CTO 王可攀：技術是為業務價值而服務

王可攀 加和科技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) ? 云原生大數據平臺對加和的價值總結

最后，做了架構調整之后帶來的一些變化，從幾個角度來說：

一是響應業務需求能力提升。業務需求服務能力大幅提升，單次服務成本降低。業務成本可預估，提升業務服務效率；

二是服務穩定性和韌性提升。大幅降低資源調整耗時和難度、特定計算場景的耗時大幅下降；

三是數據團隊能力轉型。一方面從業務運維轉化為業務推動，另一方面從數據分析轉向機器學習；

四是擴展新應用場景。流程自動化和任務管理自動化、技術棧和業務的服務的持續優化。

總體來說，技術決策者，我們并沒有用到很多復雜的開源技術，優化服務架構的時候，更多的考量是我們的業務彈性，和人員組成。作為技術決策者和技術從業者，更多關注技術供應鏈，依賴阿里云提供成熟的技術，我們的團隊得以專注于解決業務問題，更多去靈活的組合市場上現有的技術，然后快速地支撐我業務的發展。這樣專業化分工，專業的人做專業的事，讓我們的團隊可以更好地為客戶服務。

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的数字营销行业大数据平台云原生升级实战的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。