來源：資料社

今日分享從不同角度看資料團隊的工作。

作為一個『二進宮』的阿里人，這個月剛好是入職 Lazada 的兩週年。雖然兩次與阿里結緣都是在資料團隊（DT），但這次從資料中臺到業務前臺，從個人貢獻者到 TL，團隊和身份的轉變讓我對個人的發展及未來要做的事情都有了更深入的瞭解和認識，這裡也和大家分享一下在業務前臺做資料工程的經驗與思考。

作為一名前端開發出身的工程師，16 年在 DT 時對於資料團隊在整個企業中扮演的角色其實是沒有很深的體感的，只知道自己做的是面向淘系商家的資料產品『生意參謀』。而在 18 年加入 Lazada 資料團隊後，作為當時大團隊裡的第一個工程同學，才第一次有機會一窺資料團隊的全貌。

資料團隊的組成

從最粗的粒度上來講，資料團隊可以分為 4 大部分，即資料採集，資料倉儲，資料服務和資料產品。4 個部分自下而上地融通出了一條條資料管道，讓透過各個渠道採集過來的明細資料最終成為了驅動業務決策和運營的資料洞見（Insight）。所以從本質上來講，資料團隊並不生產資料，因為資料其實是來源於真實使用者與業務系統的日常互動（投放、瀏覽、點選、購買、訂單、物流等）。資料團隊更像是資料的搬運工，並在搬運的過程中對資料進行適當加工，讓海量、零散的資料最終可以成為業務決策的關鍵因子來影響下一輪真實使用者與業務系統的互動方式，從而形成資料閉環。

工程團隊的定位

在資料採集，資料倉儲，資料服務和資料產品這 4 個部分中，工程團隊很顯然承擔的是『資料服務』這一層。資料服務作為資料工程團隊的交付物，如果我們再把『服務』這個詞具象化，又可以拆解為資料介面，資料包表，資料產品和資料大屏這 4 類，分別對應工程師（上下游系統）、分析師、業務運營/商家、媒體，這 4 種不同的使用者。

在搞清楚了我們是誰以及我們的客戶是誰這 2 個關鍵問題之後，下一個要解決的問題就是如何服務好他們，並在此基礎上沉澱出一定的技術積累。

怎麼做資料介面

資料介面作為最基礎的資料流通方式，一直以來都在各個業務系統之間扮演著非常重要的角色。

在許多人眼中，資料團隊不就是提供資料的嗎？只要能拿到想要的資料，一張數倉中的表和一個介面之間到底有什麼區別呢？其實這個問題也從一個側面代表了我在過去兩年中的很多焦慮，那就是對於一個資料團隊來說，工程研發到底重不重要？資料團隊是不是隻需要資料研發就夠了，剩下的事情都交給下游的業務團隊去做是不是也可以？關於這個問題，透過過去兩年的實踐，答案是越來越清晰的，那就是對於數量眾多的下游系統而言，資料團隊能夠提供一個統一、安全、易用的介面層是一件非常重要的事情。

對於工程團隊而言，統一性一直都是一個非常重要的話題。在工程界，各種各樣的語言、資料庫、框架等層出不窮，一方面帶來了繁榮的生態，但另一方面也帶來了許多系統之間互動的一致性問題。從這個方面來講，其實資料倉儲是解決得更好的，不論資料生產的過程中涉及到了多少技術棧，最終產出的結果就是一張張的寬表，這大大降低了比如像演算法和資料研發之間的協作成本，解決了不同系統模組之間資料流轉的問題。但數倉再往下，到了資料庫這層，我們就又會發現許多的不一致性。MySQL，HBase，AnalyticDB 等等這些不同的資料庫解決方案分別適用於不同的業務場景，也都有各自的成本考量，很難有一個 DB 可以解決所有問題。而這也就是集團內部在資料服務層的拳頭產品 OneService 所要解決的問題，那就是讓所有的後端應用都可以有一個統一的能夠面向各種資料庫的介面層。

而我們作為業務前臺的工程團隊，關注更多的還是業務邏輯，基於 OneService 我們為下游的兄弟團隊提供了許多如指標查詢服務，商家分層查詢服務，商傢俬域使用者標籤查詢服務等等。這些業務屬性較強的資料服務同樣需要一個統一的平臺來管理，讓呼叫方式，返回格式，版本迭代等資訊持續保持對下游系統透明。這就是我們在過去一年中建設的 Lazada 資料統一閘道器層（Data Gateway），一方面解決對下游透明的問題，另一方面也在團隊內部收斂如 BUC 鑑權、請求代理、訊息推送等通用的後端能力。在解決了團隊內部服務管理的問題之後，今年也會全面地將統一閘道器層升級為 Lazada 資料開放平臺（Data Open Platform），讓更多還未透過具體業務需求找到我們的團隊更方便地瞭解 Lazada 資料團隊已有的資料服務能力，避免同一份資料在不同團隊之間的重複建設，也讓和下游團隊之間簽訂的 SLA 可以具體落地到平臺上更細粒度的監控指標上去，更好地調配日常及大促期間的機器資源，提高系統穩定性。另外，透過這樣一個開放平臺統一的服務註冊和申請機制，資料團隊也可以方便地管控所有對外暴露的資料服務，做到所有操作和呼叫安全可追溯。

怎麼做資料包表

資料包表作為資料介面和資料產品之間承上啟下的一層，在日常的業務決策中扮演著非常重要的角色。

在報表搭建這方面，集團內部是有非常成熟的解決方案的，有了這樣的珠玉在前，業務前臺如何能夠在報表搭建方面更進一步，是我們一直在思考的問題。時間回到 2 年前，當時集團內部的搭建平臺還沒有徹底得國際化，對於本地的同學來講，使用起來門檻非常高。在明確了要解決『國際化』這樣一個問題之後，團隊利用業務開發之外的時間研發了一款新的搭建平臺，以支撐國際業務的資料產品搭建。除了平臺本身的國際化外，我們還創新地提出了『搭建產品國際化』這樣一個目標，希望能夠做到一次搭建，支援所有語言。

除了『國際化』之外，在資料包表方面另一個我們一直在思考的問題是：資料包表和業務系統之間的邊界在哪裡？關於這個問題，我們給出的答案是，業務系統是可以直接使用的資料包表。

長期以來，業務系統和資料包表之間一直存在著相當的割裂，一方面是因為生產環境中執行的業務系統和每天大量新增的資料包表從數量上來講就不在一個量級。業務系統和資料包表之間也並不存在著嚴格意義上的對應關係，很難有人可以明確地指出說哪幾張報表是用來指導運營在某一個業務場景下做決策的。久而久之，大家更習慣地是將這樣的決策鏈路籠統地歸於行業經驗的範疇，即相信業務側的同學在看到了特定的資料後就知道去哪個業務系統裡進行相應的操作。但從邏輯上來講，這並不是一個非常站得住腳的說法，因為報表數量多本身也是一件需要去治理的事情，企業更希望的是能夠在紛繁複雜的業務中抽象出統一的幾張或幾十張報表來長期地指導業務運營。臨時的取數和分析需求，從技術的角度來講應該收斂在自助取數/分析的平臺上，而不應該形成一批數量龐大卻事實上在使用過一次後就鮮有人問津的報表。

回到技術的解決方案上來，在明確了要解決『能使用』和『方便與業務系統之間打通』這 2 個問題後，我們發現『微前端』的解決方案其實非常適合用來解決資料包表的問題。這裡的『微前端』指的並不是現在許多團隊在投入的基於微前端架構的應用框架，而是能夠適應各種前端框架和渲染環境的報表元件。換句話說，我們要做的不是一個可以擺放任意東西的架子，而是一個個可以放在任何架子上的實物。另外，在現有的搭建平臺基本都解決了搭建頁面內部元件可互動的問題後，為了實現『能使用』這一目標，我們還需要為所有搭建平臺支援的元件新增一個對外的出口，讓其具備可以和外界 API 進行基於 POST 請求通訊的能力。最後，雖然『微前端』聽起來像是一個全新的概念，但在落地時卻又很容易簡單地實現為所有元件都發一個包含所有依賴的獨立 NPM 包。如果給這樣簡單粗暴的解決方案套上一個『微前端』的概念，確實有些名不副實。個人認為『微前端』其實是對整個前端開發流程的一次挑戰，需要各個前端團隊跳出原來以應用為最小粒度開發的模式，轉向以元件為最小粒度。這要求配套的單元件研發平臺，多元件除錯平臺，元件釋出平臺和公共依賴管理平臺等多方面都需要達到一定的要求，才能夠真正享受到『微前端』帶來的紅利。否則光是公共依賴重複打包導致程式碼膨脹和元件/嵌入系統平行升級困難這兩個問題，都會讓許多團隊不得不得退回到應用粒度的開發模式。

回到資料包表的問題上來，相信在賦予了靜態資料包表『易嵌入』和『可使用』這兩大新特性後，它所能帶來的業務價值也一定會有質的突破。

怎麼做資料產品

資料產品作為資料域中與傳統工程應用最為接近的一種交付物，與核心的業務系統一樣，對系統的穩定性和擴充套件性都有著很高的要求。對比傳統的 C 端應用，資料產品在技術上也有其一定的特點。不同於重併發輕計算的 C 端應用，資料產品更聚焦在大資料量下的快速複雜計算。又因為在電商的場景下，資料產品服務的物件更多是商家側，所以從服務使用者的上限來講，對系統併發的要求不及 C 端應用那麼嚴苛。

談起資料產品，就不得不提到其中最原子的組成部分：資料指標。資料指標是一切資料產品的基礎，如何快速準確地計算並管理數以千計的資料指標及其衍生指標，是每一個資料工程團隊首先要解決的問題。好在集團內部也已經有了較為成熟的類 FaaS 的邏輯引擎解決方案，極大地降低了團隊在最初落地時的成本。

雖然前面提到了資料產品在併發方面並不像 C 端那樣動輒要服務上億的使用者，但如 Lazada 生意參謀這樣的資料產品，每天也有大量的商家會登入檢視自己的經營資料，應用的 QPS 也隨著業務的發展，從 18 年到現在翻了 10 倍不止。既然要做對外的服務，大到應用的基礎架構，上下游的依賴梳理，小到應用的釋出管控，頁面級別的漸進式更新迭代，都是真正考驗一個工程團隊內功的事情。如果說過去兩年，在基礎架構方面我們有哪些事情做對了的話，那一定是在業務需求交付不間斷的前提下，保持了前後端核心框架和庫的漸進式升級。

以前端為例，在過去的兩年中，團隊經歷了從 Class Component 到 Hooks，從 redux-saga 到 laz-fetch，從 AntD v3 到 v4 等一系列的底層依賴升級並沉澱出了團隊內部狀態管理、程式碼稽核、自動釋出等一整套的工具鏈，沒有陷入到大型應用在維護了幾年之後底層架構慢慢腐爛，只能推倒重來的困境裡去。

一個技術團隊的好壞，團隊 TL 作為一號位是責無旁貸的。這裡有兩點經驗想和大家分享，一是如何在不影響業務交付的前提下對應用進行持續的技術升級。我認為這是一個『意願大於能力』的事情，也是對技術 TL 追求卓越的真實考驗。如果一個技術團隊只有做業務的能力，而不具備持續升級技術的能力，那這個技術團隊註定是走不遠的。第二個經驗是技術 TL 應該如何看待『重複造輪子』。誠然，如上文中提到的，團隊在過去兩年中的技術積累一點都不 fancy，在相關領域或許也都有更成熟的解決方案。但我認為，對於一個超過 10 人的技術團隊，在開發規範和工具鏈上是需要給予團隊成員一定自由度的。一方面是因為總有些特殊的業務需求，是開源或其他團隊現有工具覆蓋不到的，在團隊底層工具鏈中保持一定的自主性和靈活性，是能夠更好服務業務的基礎。另一方面這也可以給團隊成員帶來更多成長的機會，讓他們有機會去造一些重複卻又具有一定創新的輪子。我們反對的，是毫無新意的重複造輪子，對於面向解決具體業務域問題的重複造輪子，技術 TL 還是要給與適當的鼓勵與引導，這也是在保護未來團隊有機會能夠做出一些自主創新的土壤。

怎麼做資料大屏

講完了資料服務，資料包表和資料產品，我們再來談談資料大屏。很長時間以來，人們都對資料大屏的價值有著比較深的誤解，認為資料大屏不過是大促或某些特定時間拿出來炫技的東西，在業務價值方面和上面提到的這 3 種交付物之間存在著明顯的差距。從我個人的角度來講，資料大屏存在的意義其實用一個詞就可以概括，那就是『講故事』。好的資料大屏可以為企業營造出一個特殊的『場』，讓其更好地向外界傳達公司的願景，使命以及在達成這些目標過程中公司的進展。誠然，這種對於人心和市場情緒的影響很難量化，但『講故事』的能力確實在整個人類的進化歷程中都扮演了非常重要的角色，而大屏恰好是對『講故事』最好的輔助。

過去 2 年中，團隊在大屏方面的投入不多，但也落地了以大航海為背景的第一塊講述東南亞電商故事的資料大屏，之後有機會可以再跟大家詳細介紹。