導讀：講述在業務快速疊代發展過程中，為了讓大資料更好地賦能業務，高效的為使用者提供有業務價值的資料産品和服務，百度愛番番的資料團隊建構實時和離線大資料基礎平台的心路曆程，包括如何應對業務、技術、組織等方面的挑戰和解決實際痛點過程中的思考與實踐。 全文9911字，預計閱讀時間24分鐘。
作為一站式的公私域智能營銷與銷售加速器，愛番番既承載着百度内部生态的各類推廣平台的線索資料（例如：搜尋、資訊流、基木魚自建站等營銷推廣平台的業務溝通、詢價收集、表單留資等使用者行為形成的線索）的落潛、管控、跟進以及轉化等業務能力，也有外部公域的廣告投放平台和租戶私域的自建系統裡各類使用者行為和屬性相關的線索自動化接入，同時還提供線索自拓導入的業務功能；進而形成業務資料、使用者資料、事件行為等有價值的資料為核心的大資料分析體系建設的思考與實踐。
如何在靈活疊代中持續傳遞，對客戶有價值的并且滿足其時效性、準确性和穩定性的資料分析服務，是資料團隊需要思考的長期目标；是以打造一套高屋建瓴的架構設計是至關重要的根基，本文就百度愛番番資料分析團隊因勢利導的進行資料驅動的技術實踐經驗和心得體會展開表述。
2.1【業務方面】
為了讓客戶清晰地、全面多視角的、多元度名額的檢視在愛番番系統中建立線索、配置設定線索，跟進線索，成單等過程的詳細漏鬥情況以及了解員工跟進情況，需要資料統計分析為客戶提供各環節有價值的資料産品。
1）有價值：如何為客戶提供有價值的資料産品服務，是貫穿需求審評階段需要重點考慮的問題；
2）及時性：例如客戶給自已的員工配置設定了一條線索或者員工跟進線索的細節，希望能夠快速的在系統裡秒級展示；
3）豐富度：單一的count和sum很容易實作，比較難的是為客戶的線索管理跟進以及公私域營銷活動等工作有指導性意義的資料分析産品。
2.2【技術方面】
業務資料、使用者行為事件資料、百度生态内部與外部業務資料需要體系化的接入數倉統一管理、加工、産出。
1）業務快速發展，使業務資料的體量較大，導緻業務資料庫（mysql）分庫和分表，銷售域的線索相關的核心資料的olap分析場景無法直接利用從庫查詢；
2）采集資料源和業務資料源的等中繼資料，散落在各個代碼裡，無法統一管理，遷庫、修改密碼或業務下線影響抽取資料；
3）存在一份資料多處重複存儲和使用，公共資料亟須管理降底維護成本和運作、存儲資源成本；
4）資料團隊的研發人數有限，既有運維任務，又有内部業務支撐，還有對客的分析業務産品研發工作，在規模較小的情況下，如何利用有限的人力資源來發揮更大的價值；
5）資料抽取，邏輯加工，轉儲同步等環節有成百上千的任務線上排程和運作，其穩定性如何保證。
2.3【組織方面】
在愛番番業務部将産研測、市場、商業化、客戶成功等人員劃分為15個左右的靈活小組，每個小組有自己明确的業務目标，資料團隊需要靈活支撐各團隊。
1）各團隊的月度、季度和年度的内部okr以及各團隊監測其業務所涉及的客戶增長情況、業務增長情況、營運情況，作為資料團隊如何快速響應；
2）對于僅一次性的取數情況，其投入和産出比較低，而且屢見不鮮；
3）愛番番業務的核心名額口徑一緻的問題，如何統一收口，管理和資料服務化、平台化對接。
===
在本文講述的架構實踐落地之前，基本都是保持點狀的工程思維處理業務資料，不能全面的、系統的解決所面臨的資料應用現狀，但是後來我們在實踐中不斷探索學習、思考以及注重經典方法論的運用并最終落實到技術架構中，在此過程中會從研發的人效、運維的人效、計算和存儲資源等相關成本的角度來考慮，盡量不重複造輪子，是以在建設中會使用“雲上百度”（側重将内部私有雲與外部公有雲的混合，既發揮内部自研技術能力又推動技術互通和适配）以及“百度智能雲”（緻力于提供全球領先的人工智能、大資料和雲計算服務和工具）的平台化大資料元件或解決方案。
接下來通過內建、存儲、計算、排程、治理、查詢、分析、洞察客戶價值等環節分享總體資料技術架構和實踐經驗。
提起資料架構，不得不說的是google為了高效處理海量的廣告、搜尋、營銷資料，而在2003年開始陸續釋出的“三駕馬車”，其包括可擴充的大型資料密集型應用的分布式檔案系統（gfs），超大叢集的簡單資料處理引擎（mapreduce），結構化資料的分布式存儲系統（bigtable）三篇論文，基于這三個大資料存儲和計算的元件，後來的架構師們體系化的設計了兩套主流的大資料解決方案，分别是kappa和lambda架構，其實還有一種unified架構落地有一定的局限性，是以在此不贅述unified架構，但我們要清楚的認識到沒有一種架構能解決所有問題。
nathan marz提出的lambda架構是目前進行實時和離線處理的常用架構，其設計的目的是以低延遲處理和兼顧處理離線資料、支援線性擴充和容錯機制等特點。
lambda 是充分利用了批處理和流處理各自處理優勢的資料處理架構。它平衡了延遲，吞吐量和容錯。利用批處理生成穩定且有利于聚合的資料視圖，同時借助流式處理方法提供線上資料分析能力。在展現資料之前最外層有一個實時層和離線層合并的動作，此動作是lambda裡非常重要的一個動作，可以将兩者結果融合在一起，保障了最終一緻性。
維基百科中指出lambda 經典的三大元素包括：批次處理層（batch）, 高速處理也稱為實時處理（speed or real-time），和響應查詢的服務層（serving）。
jay kreps提出的kappa架構隻關注流式計算，是在lambda架構的基礎上提出的，并不是為了取代lambda架構，除非完全吻合你的使用案例。kappa這種架構，資料以流的方式被采集過來，實時層（real-time layer）将計算結果放入服務層（serving layer）以供查詢。
kappa将實時資料處理與資料的持續從處理內建到單一流處理引擎上，且要求采集的資料流可以從新從特定位置或全部快速被回放。例如計算邏輯被更改，會重新起動一個流式計算，即圖中的虛線處，将之前的資料快速回放，重新計算并将新結果同步到服務層。
正因為之前點狀的工程思維來處理大資料不能夠全面的、系統的解決所面臨的資料應用現狀和痛點，是以我們急需要設計并研發一套适合我們愛番番這種體量和發展階段的資料處理體系的方案。
【資料形态】涵蓋私域和公域的使用者行為事件資料、使用者屬性資料以及線索管家、im溝通、營銷活動、賬号管理、潛客定投等等大量業務資料、行為事件資料、檔案資料；
【資料內建】資料團隊是不生産資料的，就需要從各業務線、終端、内部和外部管道等資料源，把資料內建進來統一進行olap（聯機分析處理）相關工作；
【資料存儲】包括離線t+1形式資料存儲需求可以存儲到afs和時效性要求較高的資料存儲需求可以存在mpp架構的分析型資料庫中；
【資料計算】包括實時計算場景和離線計算場景，實時計算采用spark streaming或flink，離線計算可以采用mr或者基礎架構部比較推薦的sparksql；
【資料治理及監控】包括平台穩定性、中繼資料管理、基礎資訊和血緣關系管理、排程管理、資料源管理、異常處理機制等方面；
【資料研發】包括考慮研發與運維的的人力資源是否夠用，資料複用、操作規範，從業務模組化到邏輯模組化再到實體模組化等通用方案落地。
【資料業務場景】包括線上業務運作過程的資料線上分析、使用者參與活動、點選、浏覽等資料用以行為分析和統計，使用者身份屬性類的資料用于id打通後用于精準營銷，内外部營運決策類的名額和報表場景，即席查詢與下載下傳、通用服務化、openapi等。
鑒于現階段愛番番的資料形态和業務需求，内部經過多輪讨論和對齊認知，最終決定兩條路并行的方式，一方面“短平快”的支撐部分緊急的對客業務需求，另一方面搭建具有長遠目标的體系化的資料架構實作。
2020年9月建設初期，恰逢銷售域（現在的線索管理及im溝通）分庫分表，因為業務發展到，不得不将原來多套系統在同一個業務資料庫裡拆分開，并且一些上億級資料量的業務表面臨分表，利用租戶id取模之後分成128張分表，這時無論是線上業務還是olap場景的業務都随之面臨重構更新，經過幾次技術評審會之後，olap場景的資料抽取，從原來的sparksql任務直接拉數方式，敲定在sqoop（開源）、dts（廠内）、watt（廠内）三個裡面選其一。
最終調研的結論是抽取業務庫選擇watt平台的方案，因為很好的支援分表接入，讀binglog時效性高，自身的監控完善、bns負載均衡、多表join、豐富的udf、有平台專職運維保障人員等等優勢特性。
三位研發同學曆經2個多月，将上圖中1.0版的僅滿足于緊急需求的架構落地，但是整個鍊路的穩定性比較牽強，經常收到内部和外部的投訴，甚至想辦法開發了一套報警電話外呼的功能，進而經常半夜起床修複作業。
回過頭來看，一直到2021年1月份1.0版的資料處理架構才穩定運作，撇開與cdc檔案互動的部分，1.0版的架構更像是kappa架構的變種，與此同時我們也進行調研行業最佳實踐經驗。
軟體産品有兩種常态，其一是有源源不斷的客戶需求驅動産品疊代，另一種是從專業的角度規劃對客戶有價值的功能。愛番番恰好處于發展期，以上兩種訴求都比較強烈。
不僅有客戶回報我們的線索分析和跟進分析等等線上産品的資料延遲嚴重，就連銷售人員拓展新客戶時，現場示範為了不突出這一産品的弱點，操作之後有意和客戶談話來延長加載時間的尴尬局面；
根據當時記錄的線上穩定性報告裡顯示，延遲最嚴重的時候達到18分鐘才出來資料，針對這樣的困局，我們做了三個改進。
【措施1】解決spring streaming運作資源搶占的問題，進行作業遷移至獨立叢集并作相關資源隔離；
【措施2】bigpipe的異地容災方案落地，正常情況下主要使用蘇州機房的bigpipe，遇到故障時立即切換到北京機房，同時做好故障切換期間的資料補償；
【措施3】利用watt具有的多binglog可join的特性，将較複雜的計算提前到watt平台上，同時在spark streaming中也做一部分資料處理，相當于原來利用線上實時現算的方式，優化為在實時流過程中增加兩次etl計算。
經過以上三個措施的改進，olap分析場景的時效性提升到10至15秒出結果。
為了戰略規劃更清晰，嗅覺更敏銳，洞察更快速，我們市場、營運、商業化銷售及客戶成功團隊的取數需求層出不窮，資料團隊僅有的幾位研發出現無力支援這麼大量的需求。
急需解決核心訴求，資料團隊梳理共性需求進行産品化落地。
對于周期性的資料需求，我們通過自動郵件等方式制作定時推送任務
</h3>
截止2021年3月份，我們仍然有較多的取數或用數的場景無法支撐，例如：業務域統一資料源，資料能力模型複用，自助取數平台化或者一次性取數等等能力輸出，鑒于我們一直對行業最佳實踐經驗的學習，發現适合愛番番現狀的技術架構需要有所調整。
在前文提到的1.0版之上，想要繼續擴充的話，比較困難，特别是諸如ad-hoc、資料模組化或研發平台化，通用資料治理等等方面。
經過與商業平台研發部門的技術交流期間，發現在之前watt平台使用經驗之上與鳳閣平台內建，實作便捷的轉儲，其産品設計的背後為使用者省去很多工作量，不僅可以提高我們的人效，而且可以解決我們的技術和業務方面的訴求。
此時産品和營運人員急需我們支援自助取數平台化即席查詢的功能，并且上司寫進團隊的okr。
poc完成後，決定将我們的架構從原來的1.0版改造為2.0版，攜手鳳閣團隊将我們的離線資料遷移到鳳閣，曆時一個半月的時間，不但支援了ad-hoc的強需求，而且很好的支援數倉分層管理、中繼資料、分主題、資料源管理、血緣關系，狀态監控等資料資産治理方面的功能。
2.0版本的架構一經推廣，幫助了營運支撐團隊解決了底層資料統一，摒棄了之前各靈活小組各自花費人力開發底層資料，更有價值的是，經過鳳閣平台化、規範化、流程化的提供可視化的開發工具之後，一位普通的研發人員，接受短暫的教育訓練就可以基于現有的底層明細資料加工出各團隊個性化的月度、季度和年度的内部okr以及各團隊監測其業務所涉及的客戶增長情況、業務增長情況、營運情況報表，為資料研發團隊解放了大量勞動力。
基于鳳閣平台進行資料的分主題模組化工作，主要采用kimball次元模組化的方法論，首先确定一緻性次元和業務過程，産出總線矩陣，再确定各主題的事實内容，聲明粒度進行相關研發工作。
評判一個數倉建設好與壞的标準，不僅從豐富完善、規範、複用等角度看，還要從資源成本，任務量是否膨脹，查詢性能及易用性，是以我們的數倉進行分層規劃，避免了牽一發而動全身的煙囪式結構。
在資料模型的設計和落地過程中，選擇以星型為主，以下用線索跟進過程的事實和次元為例，從邏輯模型到實體模型的詳細情況展示。
廣義上講，資料治理是對資料的全生命周期内任何環節進行管理，包含資料采集、存儲、清洗、計算轉換等傳統資料內建和應用環節的工作、同時還包含資料資産目錄、資料标準、品質、安全、資料開發、資料價值、資料服務與應用等，整個資料生命期而開展開的業務、技術和管理活動都屬于資料治理範疇。
可以将資料治理分為資料資産的治理和資料品質方面的治理展開讨論。
資料資産治理是建立規範的資料研發和應用标準，權限打通，實作資料内外部共享，并能夠将資料作為組織的寶貴資産應用于業務、管理、戰略決策中，發揮資料資産價值。
區分資料主題，分門别類的管理資料内容，讓使用者快速找到想要的資料。
展現出資料的歸屬性、多源性、可追溯性、層次性，這樣可以清楚地表明資料的提供方和需求方以及其他詳細資訊。
無論是産品、營運、研發在授予其資料權限之後可以友善的在平台上查詢和下載下傳資料，同時鳳閣平台的資料在“一脈平台”或其他即席查詢平台，通過拖拽勾選的方式進行靈活取數。
經過架構更新之後，運維保障工作提上了日程，諸如每日增量的資料差異監控、異常資料導緻作業鍊路阻塞、叢集穩定性監控、網絡或相關元件抖動導緻的資料缺失，如何補償恢複等方面急需完善。
通過運維腳本或工具的開發，目前長效監控或例行檢查的範圍如下圖所示。
2.0版的資料架構，趨于穩定之後，我們迎來了新的目标，正逢新的系統一站式智能營銷的上線，發現租戶的大量的營銷活動，旅程轉化等私域營銷功能，客戶無法直覺的通過量化的手段來清晰的看到營銷場景的效果資料，是以我們面臨在2.0版的基礎上做擴充延伸。
因為私域營銷是基于cdp的impala&kudu裡的資料，這裡包含了事件資料和使用者身份屬性等資料，是以我們起初的分析是直接利用imapla作為查詢引擎，後來發現已上線的表結構設計時沒有太多的兼顧分析場景的特點，并且impala的并發能力有限，也不符合愛番番的2秒内出結果的穩定性名額要求。開始的幾個需求可以勉強上線，但是分析場景和功能越來越豐富之後發現，客訴量明顯增加。
是以營銷效果分析這一業務場景經曆了impala+kudu的解決方案遷到現在的palo（doris）作為資料分析場景的存儲，這期間也參考過其他同類的主流分析型mpp架構資料庫産品，最終我們還是選擇了palo，具體對比描述如下：
在2.0版的實時鍊路的基礎上，我們與資料架構平台部交流了接下來分析場景的應用，并提前做poc和壓力測試相關工作，确定了其可行性，然後承擔實時分析的資料鍊路增加了如下部分架構：
因為時效性要求提升至2秒以内，是以不影響原有的業務資料的broker load導入方式為前提增加了以上部分的架構，與cdp合作在資料加工鍊路中，将明細資料以實時流的方式下發到kafka，然後會利用flink to palo和kafka to palo兩種導入方式，對應到doris本身的設計原理，也就是stream load方式是利用流資料計算架構flink 消費kafka的業務資料topic，使用stream load 方式，以http協定向palo寫入資料；routine load方式是送出一個常駐palo的導入任務，通過不斷的訂閱并消費kafka中的json格式消息，将資料寫入到palo中。
最終選擇palo作為分析場景的查詢引擎及存儲的方案，palo由be子產品和fe子產品組成，使用者通過mysql協定的用戶端工具查詢fe節點，fe節點和其中一個be節點進行互動，各個be節點将計算結果彙聚到負責協調的be節點并傳回給查詢用戶端。
palo的資料導入是采用lsm-tree的算法實作，寫的過程是先進入記憶體中，compaction 可以背景異步完成，不阻塞寫入，在磁盤上順序寫入同時merge sort；查詢方面支援大寬表與多表join，具有cbo優化器等特性可以很好的應對複雜的分析場景。
基于私域營銷的服務模式可以看作是b to b to c的模式，資料産品經理為了租戶多元度清晰的掌握營銷效果，建立起名額體系，我們結合資料産品經理按照私域的産品形态和有價值的對于私域的名額體系的各項邏輯計算規則生成可視化的報表以及相關實時分析服務。
解決了租戶對于其私域使用者參與營銷活動情況的掌握之後，愛番番系統自身也定制了對于租戶的使用産品情況的名額體系，例如dau、mau、每天、每周的pv和uv等，這樣很好與租戶之間建立起橋梁，更加清楚的知道哪些功能是租戶每天都要使用并依賴的，就要保留并長期優化疊代，對于使用者不使用的産品功能，進行定期清理并下線。
對于經營分析類名額和通用标準類名額，作為核心名額在營運報表系統内統一收口維護，随着業務疊代發展的的過程定期安排梳理計算邏輯，并設計通用的名額服務接口，提供給内外部統一标準化調用。
至此愛番番的資料分析體系已成為一套完整的适合現階段以及易于後期擴充的總體解決方案，從全景圖中可以清晰的看出從基礎層、平台層、中間處理層、公共服務層、資料産品化等是大資料分析體系必不可少的根基。
【業務方面】資料産品經理或分析師深入客戶的核心業務場景并梳理業務過程，對于關鍵業務過程建立營運分析名額，例如“全員推廣”這一業務場景，抽象出“獲客”、“營運”、“再培育”這三個業務過程，然後再與業務線的産品經理一起細化出這些過程中的“時間”、“地點”、“租戶”，“銷售推廣員”、“通路”、“推廣積分規則”、“推廣管道”、“是否裂變”等一緻性次元，這樣就可以得出前文提到的模組化方法論中的“總線矩陣”，基于總線矩陣可以邏輯模組化，産生星形或星座模型之後，可以多視角、多元度的計算豐富的名額，再結合使用者研究（ubs）團隊回報的剛需、産品功能上的行為埋點以及其他客戶訪談等技術和産品手段來解決自身的或客戶的業務痛點；同時會根據租戶所在行業的橫向同行水準的名額統計出合理門檻值，再通過技術手段定期主動為客戶發送業務相關的預警，最後在預警基礎上指導客戶操作相關功能提升其業務在行業内的高度；再者利于通用的名額或标簽來有引導的提示使用者完成相關操作任務或者通過多種形式直接觸使用者等資料分析服務來解決對客戶有業務價值和對業務增長有指導意義的資料産品這方面痛點。
【技術方面】技術是為産品服務的，産品是為客戶服務的，資料分析産品需要的及時性，穩定性，準确性也是技術架構需要做到的。愛番番的資料分析架構和治理體系在産品與技術相輔相承的過程中完善起來後，之前的時效性不達标，資料不準确、分庫分表技術支援不到位，資料到處散落不統一複用、業務線取數需求積壓，統計邏輯不一緻等情況都可以通過前文描述的資料分析架構解決或者快速試錯後解決。
【組織方面】經過鳳閣平台化、規範化、流程化的提供可視化的開發工具之後，一位普通的研發人員，接受短暫的教育訓練就可以基于現有的底層明細資料加工出各團隊個性化的月度、季度和年度的内部okr以及各團隊監測其業務所涉及的客戶增長情況、業務增長情況、營運情況報表，技術賦能業務的同時為資料研發團隊解放了大量勞動力；有了即席查詢和下載下傳功能之後，一次性查詢、取數變得自助化；有了資料服務化和平台化對接的模式使我們企業通用經營分析類名額和産品線個性化營運類名額的産出及維護職責分工更明确。
在過去的幾個月内，我們一直在思考并落實将離線的（天級或小時級）資料名額和報表通過實時的方案來實作，其中既有已經完成的基于使用者行為實時采集上來的資料，為租戶提供私域營銷場景的效果實時分析也有公域線索資料的實時狀态分析、實時跟時分析、銷售漏鬥分析等等，接下來會思考如何讓資料分析與cdp（内部客戶資料平台）的架構融為一體，讓使用者行為事件和業務資料結合以及全域使用者統一身份id-mapping等技術進一步配合，達到精細化營運，發揮更大的業務産品價值；
湖倉一體的技術是未來的趨勢，接下來會調研一下離線和實時數倉對接内部私有雲或百度智能雲的資料湖解決方案；
設計研發平台化的資料處理方案，讓研發工作更加便捷，提高人效；
進一步簡化資料加工鍊路，提升資料加工效率，提升資料産品的時效性；
引入中台化的思想和服務能力，落地執行資料标準，量化資料健康分，提高複用能力等智能評分體系，達到降本增效的終極目标。
---------- end ----------
百度 geek 說
百度官方技術公衆号上線啦！
技術幹貨 · 行業資訊 · 線上沙龍 · 行業大會
招聘資訊 · 内推資訊 · 技術書籍 · 百度周邊
歡迎各位同學關注