摘要:如何打造一套企業(yè)級的實時數(shù)據(jù)融合平臺?Tapdata 已經(jīng)找到了最佳實踐,下文將以 Tapdata 的零售行業(yè)客戶為例,與您分享:基于 ES 和 MongoDB 來快速構建一套企業(yè)級的實時數(shù)據(jù)融合平臺。

在大數(shù)據(jù)時代,幾乎每家企業(yè)都有上一套數(shù)據(jù)平臺的沖動,目前也有很多的離線解決方案,包括 Hadoop 體系的 CDH、TDH,還有一些傳統(tǒng)的數(shù)倉。但是有兩大因素讓企業(yè)無從下手:一是“實時”,二是“融合”。一方面,隨著 IT 架構的迭代升級和業(yè)務端的全渠道營銷,企業(yè)對于數(shù)據(jù)的實時性要求越來越高,另一方面,過去幾十年的企業(yè)數(shù)字化造成了許多的孤島系統(tǒng)和數(shù)據(jù),只有“融合”后的數(shù)據(jù)才能真正用起來。

如何打造一套企業(yè)級的實時數(shù)據(jù)融合平臺?Tapdata 已經(jīng)找到了最佳實踐,下文將以 Tapdata 的零售行業(yè)客戶為例,與您分享:基于 ES 和 MongoDB 來快速構建一套企業(yè)級的實時數(shù)據(jù)融合平臺。

Tapdata 的案例客戶是珠寶零售行業(yè)的頭部企業(yè),歷史悠久,早在上世紀90年代就已經(jīng)開始 IT 建設,在中國大陸及港澳臺地區(qū)有超過700家線下零售門店,且產(chǎn)品線非常豐富包括珠寶及其周邊產(chǎn)品,營銷渠道還覆蓋了移動端、線上商城等。

隨著業(yè)務體量越來越大,需要對接多個電商平臺進行商品的上下架,并且開發(fā)新營銷應用的頻率越來越高,IT 部門要完成這些需求,就需要每次到各個數(shù)據(jù)庫中撈取目標數(shù)據(jù),然后才能去做迭代開發(fā),造成開發(fā)成本居高不下,數(shù)據(jù)準備階段占用過多的部門精力。

一個典型的場景是:門店庫存盤點。門店店員每賣一個貨,有銷售系統(tǒng)會登記銷售記錄,每天可以從銷售系統(tǒng)里查到當前的庫存數(shù)據(jù)。這個數(shù)據(jù)是截止到目前為止的存貨數(shù)量,但是這個數(shù)字是銷售系統(tǒng)內(nèi)的統(tǒng)計數(shù)字,不一定和實際門店的存貨數(shù)字對的起來。 比如: 門店店員賣掉一件貨,就會去銷售系統(tǒng)開一個銷售單,銷售系統(tǒng)就減掉一件貨�，F(xiàn)實中可能會發(fā)生以下情況:

(1)但店員如果忘記錄入了,那系統(tǒng)記錄有 1000 件,實際只有 999 件,這就會導致:實際 999 件,如果不盤點,財務、后勤都不知道,因為系統(tǒng)有1000 件。

(2)之前盤點都是分店店員根據(jù)店里的存貨去和手賬的記錄做手工對賬,因為工作量巨大,所以做不了每天盤貨,只能做季度大盤。

這里有 2 個問題:人工盤點費時;出錯率高。

上述問題的根本原因在于,傳統(tǒng)的 IT 開發(fā)模式中,基本都先制定需求,和 BA 確定好要做的事情,然后把業(yè)務需求背后對應的數(shù)據(jù)模型定義完,再開始做數(shù)據(jù)的開發(fā)等。但在業(yè)務需求部門看來,他們會認為這樣的需求無非就是讓 IT 部門做個頁面、加張報表,頂多一周就能搞定,于是需求不斷疊加,而 IT 部門疲于應對,這樣一來,整個新業(yè)務系統(tǒng)的上線時間將大幅拉長,短則一個月,長則兩三個月。

反過來說,業(yè)務部門也來無法接受延遲上線,比如雙11大促,業(yè)務部門提前三個月跟研發(fā)提需求,但是臨近一兩個禮拜,突然出了一個policy,因為某些原因審計過不了了,業(yè)務流程得換一個策略,研發(fā)這個時候說已經(jīng)調整不了了,導致的結果就是活動只能被迫停掉。這對于零售行業(yè)來說,錯過618、雙11這種大促機會,將對全年業(yè)績造成巨大沖擊。

這個“鍋”誰來背?深入分析,我們發(fā)現(xiàn)根本癥結是:數(shù)據(jù)架構沒有跟上需求升級的步伐。

一是數(shù)據(jù)孤島,在很多的傳統(tǒng)的企業(yè),以業(yè)務為生的企業(yè)中都會面臨這種問題。這類企業(yè)的發(fā)展進程是以業(yè)務為生,他們的 IT 系統(tǒng)大部分都來自于第三方的采購,每一套業(yè)務系統(tǒng)采購進來之后,都會帶著他們綁定的數(shù)據(jù)庫,如 oracle ,mssql,PG,以及其他一些新的非關系型的數(shù)據(jù)庫。對于企業(yè)來說,采購系統(tǒng)解決了他們的業(yè)務問題,但是對于他們的 IT 來說,一旦要在這些業(yè)務系統(tǒng)之上做新的業(yè)務就會非常的頭疼。

二是有太多的業(yè)務系統(tǒng),且系統(tǒng)年齡非常悠久,他們的可維護性已經(jīng)變得越來越低。例如,有一些存儲過程有一兩千行,代碼是從2000年開始維護的,每一個存儲過程大概有十幾個人維護,前前后后這種歷史原因會導致整個系統(tǒng)難進行有效的迭代和維護。

三是這些業(yè)務系統(tǒng)都分管于不同的業(yè)務部門,例如,有的甚至是 Hr 來管業(yè)務系統(tǒng),就導致某些業(yè)務數(shù)據(jù)很難拿到,跨部門協(xié)調數(shù)據(jù),直接影響了整個開發(fā)周期。

最后是,對于研發(fā)來說,明確需求之后就開始研發(fā),最怕做到一半的時候改需求,或者快做完了得到反饋說這不是想要這個東西。

那么,我們是如何幫助企業(yè)徹底解決這些問題呢?Tapdata 提出了基于 DaaS 架構的解決方案,通過打造一個實時數(shù)據(jù)融合平臺,并提供多個能力支撐。

首先是提供異構數(shù)據(jù)庫的實時同步,解決業(yè)務系統(tǒng)到下游系統(tǒng)的實時查詢問題。同時統(tǒng)一數(shù)據(jù),由于歷史原因導致客戶多個地區(qū)的數(shù)據(jù)庫全都是分散的,一個訂單在所有的數(shù)據(jù)庫里面都會存一份,但是狀態(tài)會不一致,當你想要拿訂單最終的一個狀態(tài)的時候,就需要去所有的數(shù)據(jù)庫里面查一遍,可想而知這個速度快不起來。

其次是基于實時同步+數(shù)據(jù)建模,向 ES 供數(shù),解決全文搜索的時效性問題,滿足零售行業(yè)在移動端前臺搜索,實時看到結果。對于很多傳統(tǒng)的零售行業(yè)來說,常用的搜索方式是在關系數(shù)據(jù)庫里面做很多的 SQL 查詢,或 like 模糊查詢,現(xiàn)有的一些系統(tǒng)可能要等待十幾秒才能出查詢結果,這大大降低了門店銷售員的查詢效率。

再次就是支持快速發(fā)布 API,形成最后的數(shù)據(jù)閉環(huán)。為下游業(yè)務系統(tǒng)提供統(tǒng)一、可靠的數(shù)據(jù)出口。標準的 RESTful API 可以極大降低研發(fā)對接成本,豐富的類 GraphQL 查詢語義,可以滿足各種業(yè)務場景的條件查詢。

綜上,Tapdata 是為客戶提了一個能夠做到實時查詢、全文搜索,然后能很快的提供數(shù)據(jù)統(tǒng)一服務的平臺。

△ Tapdata 實時數(shù)據(jù)服務平臺

值得強調的是,主數(shù)據(jù)管理在零售行業(yè)十分重要。在零售行業(yè)基本上就是訂單、庫存、商品,這三個為核心的主數(shù)據(jù),這些主數(shù)據(jù)和傳統(tǒng)數(shù)倉比較,它最大的區(qū)別就是數(shù)倉都是一些維度表、事實表,基本上用于做一些報表,而這些主數(shù)據(jù)則是所有項目都離不開的數(shù)據(jù),包括市場活動、營銷等,這種數(shù)據(jù)我們稱之為叫企業(yè)實時主數(shù)據(jù)。

出于傳統(tǒng)關系型數(shù)據(jù)庫設計,一張商品表相關的屬性表有二三十張,所以在實際開發(fā)中,有大部分的時間都消耗在數(shù)據(jù)準備上,我們需要去不同項目組獲取基礎數(shù)據(jù),或者是企業(yè)的核心數(shù)據(jù),去數(shù)據(jù)庫里面去拿一份,但是數(shù)據(jù)的一致性誰來維護?自己項目組的人來維護,最終就會造成從這個基礎庫里面出去的所有的數(shù)據(jù)鏈路會越來越多,而每一個開發(fā)組自己對于數(shù)據(jù)同步的業(yè)務邏輯理解又不一樣,最終造成出去的數(shù)據(jù)的一致性沒法得到保證。這可能導致兩個應用出來的報表在同一個維度的數(shù)字卻對不起來,這個是很多現(xiàn)在企業(yè)中面臨的問題。

不難發(fā)現(xiàn),在研發(fā)周期占比上,大部分時間都在數(shù)據(jù)準備上,而沒有把更多的時間聚焦在核心業(yè)務上,Tapdata 的實時數(shù)據(jù)融合平臺便能夠幫用戶完成從前到后的數(shù)據(jù)融合,大幅降低數(shù)據(jù)準備階段的時間和人力投入。

Tapdata 是如何實現(xiàn)的呢?

第一步是將所有的數(shù)據(jù)庫,無論是 oracle,mysql 等傳統(tǒng)關系型數(shù)據(jù)庫還是非關系型也好,全部通過實時同步進入我們的平臺。平臺采用了兩種數(shù)據(jù)庫:es + MongoDB,它們的模型非常相近,在很多的業(yè)務場景中可以互相配合。比如,es 非常適合做前端的查詢,在本文將的零售行業(yè)場景中它就是來解決用戶大批量的模糊關鍵字搜索以及一些聚合的復雜查詢,而 MongoDB 負責把所有的模型快速的處理掉,并且響應到前端去。然后我們把數(shù)據(jù)進到 MongoDB 里面并完成數(shù)據(jù)的融合。

△ Tapdata 實時數(shù)據(jù)同步

比如說商品模型,它在關系數(shù)據(jù)庫里面由二三十張表組成,我們就可以把這些表全部合并成一張固化視圖,即一張大寬表,但這張大寬表是實時業(yè)務在更新的,如果 erp 或者 mes 下了一個新的訂單,大寬表中關于那條訂單的狀態(tài)就會被更新到最新,然后再把 MongoDB 中的商品主數(shù)據(jù)推到 es 去

△ Tapdata 多表關聯(lián)

對于前端來說,我們不再只是針對于普通的 BI ,比如說 powerbi、tableau 這些展現(xiàn),或者是一些數(shù)字大屏,而更多的是面向于業(yè)務系統(tǒng),如 crm、scm、或者是一些營銷系統(tǒng),直接服務于業(yè)務和銷售。

在本零售行業(yè)案例中,數(shù)據(jù)實時同步的方案是,首先把所有的 oracle 從 4 個地方(中國大陸及港澳臺)的 pos 系統(tǒng)拿過來,通過 logminer 的方式監(jiān)聽進來,然后經(jīng)過中間的各種處理,比如說規(guī)則處理、腳本處理、字段處理、大小寫轉換等等,再把這些全部都處理完的結果寫到 MongoDB 里面去,之后通過實時同步寫到 es 里面去。

這里的 MongoDB 和 es 不一定是 1:1 的寫入,Tapdata 還會做一些模型的過濾,因為 MongoDB 中的主數(shù)據(jù)模型是一張非常完整的寬表(包括整個集團所有的商品屬性),而 es 面對于不同的前端應用查詢的時候,我們會生成不同的報表,包括一些模型給到前端,最終的目的就是對于前端來說,他要查一個聚合數(shù)字,就不需要再拿到 es 的數(shù)據(jù)之后自己去做 groupby,而是通過直接查詢 es 的某個記錄就能夠把數(shù)字查出來了。

此外,在 MongoDB 到 es 的過程中,Tapdata 也完成了實時的增量聚合處理動作,落到 es 的數(shù)據(jù)就是所有的前端業(yè)務要拿來展現(xiàn)的數(shù)據(jù),而并不是傳統(tǒng)開發(fā)模式中,需要從數(shù)據(jù)庫里面拿一條數(shù)據(jù),然后自己在前端也好,后端也好把它處理完再給出去。

從整個模式可以看到,通過這種流式處理,實時的將源端業(yè)務系統(tǒng)的數(shù)據(jù)經(jīng)過計算加工之后提供到前端。對業(yè)務和銷售人員來說,他們可以直接訪問 es 高性能查詢數(shù)據(jù)庫,從而大幅提高了查詢效率。

對于增量聚合來說,我們很多時候會面臨這樣的一個聚合場景,以往都是通過 sql,當有一條數(shù)據(jù)就得 groupby 一把,基本上都是在夜間跑批完成,現(xiàn)在還有很多企業(yè)都是在做這種方式。第二種場景就是現(xiàn)在大數(shù)據(jù)產(chǎn)生了,用 spark 去做(它其實還是通過窗口的方式在做),到最后我們現(xiàn)在有 flink 來做一些流式計算。

我們的實時聚合框架在初始化的時候逃不掉,也會做一次全量,接下來增量聚合過程中我們可以理解為,就像 groupby 一定會有 groupby fields,基于 groupby fields 去做一個小范圍的增量聚合。其實一條源端數(shù)據(jù)匹配到目標數(shù)據(jù)的可能就那么十幾條,哪怕你源端有增刪改查,我們也可以做到對目標端對應的報表數(shù)字進行回滾,或者是新增或者計算等等實時計算。

對用戶來說,他可能希望有一套完整的數(shù)據(jù)服務平臺。用戶不希望再像以前一樣,還是從 9 個 oracle 里面去取數(shù),然后自己的項目 Java code 里面去做很多計算。而是希望通過有一個統(tǒng)一的出入口,對于 dba 來說它非常容易管理,因為它只要管理統(tǒng)一的出入口的賬號權限就可以了,而對于應用端的權限來說是有統(tǒng)一的數(shù)據(jù)服務來管理的。對于應用端來說,它只要取 API 來作為一個訪問的出入口,所以 API 會連入我們的 MongoDB 和 es。

△ Tapdata 構建實時數(shù)倉和業(yè)務數(shù)據(jù)雙底座

有了這樣的一套數(shù)據(jù)服務之后,向上可以應用于全渠道商品庫存中心、營銷中心、實時盤點等,對于用戶來說,他們的對接成本會降到最低,因為他們只要接API,而API的格式采用了標準的 restful 格式。

本文的零售行業(yè)客戶案例中,所有的數(shù)據(jù)庫在底座通過 Tapdata 的批流一體方式,數(shù)據(jù)采集完之后進到 MongoDB 中進行建模(采集即數(shù)據(jù)同步),建模會參考一些數(shù)倉的規(guī)范建模,但都是基于業(yè)務來做的。

在有了主數(shù)據(jù)和貼原層數(shù)據(jù)之后,我們向上就可以提供一些業(yè)務模型。

△ Tapdata 統(tǒng)一數(shù)據(jù)服務

在有一個非常完整的商品模型和訂單庫存模型的情況下,假設要統(tǒng)計今天各個門店的銷售報表,只需要把訂單進行聚合就可以了,基于實時增量聚合的框架,就能很快算出來。再假設業(yè)務端要查一個基于月的報表,這個報表還是基于實時聚合,對于這類查詢的模型來說,永遠在查這一個庫存模型,可能會有商品模型和庫存模型合并的這種場景出現(xiàn),比如說我這個商品下面有多少個訂單,其實也就是把這兩個主數(shù)據(jù)模型進行合并,所以一旦有了我們中間這一層主數(shù)據(jù)模型之后,向上做任何的業(yè)務模型就會非常的快,整個鏈路因為又可以做到實時,所以對于應用端來說,他們拿到的API的數(shù)據(jù)也都是實時的。而且,API 是建立在 MongoDB 和 es 這類處理面向 TP 業(yè)務的數(shù)據(jù)庫,當然 Tapdata 也能做 AP,而且是實時的 AP。

總結一下,搭建實時數(shù)據(jù)融合平臺的過程,是從 oracle 進到 MongoDB,es,以API的方式提供給微服務。對于前端業(yè)務來說,所有的集團級別的業(yè)務系統(tǒng)全部都接入進來。

△ DaaS 物理部署架構圖

一個兩地兩中心的架構,在大陸這邊一個,在香港這邊也有一個中心,所有的 MongoDB 都是分布式的,es 也是采用分片集群部署,讀寫全部做分離。比如說我們的主節(jié)點是在香港,接下來我們的數(shù)據(jù)會從香港去寫入,但是對于我們的讀來說,包括業(yè)務端來說,他們會就近訪問 API,這一層的讀寫分離,包括策略的轉發(fā),是通過客戶自己的一套類似于像 apache 來做的。

最后,分享一下 Tapdata 是如何來實施的,這包括幾個關鍵步驟,第一就是了解需求,然后接下來去做一些數(shù)據(jù)源的準備,接下來就開始做建模,貼源層、主數(shù)據(jù)層、業(yè)務層,最后就上線。涉及到的一些人員分配,可能是一個人會對應多個角色,基本上都是以數(shù)據(jù)為主要核心。

△ Tapdata DaaS 落地步驟

這個案例沒有用到特別多的服務器,都是8核16g、16核64g,就能搞定整個集團的數(shù)據(jù)同步。

△ Tapdata DaaS 落地硬件配置

三層建模是我們的最佳實踐,先把所有的數(shù)據(jù)放到 MongoDB 里面去,作為貼原層數(shù)據(jù),為什么要這么放?是因為第一我們能夠極大的減少對于源端數(shù)據(jù)庫的一個壓力,因為它只做一個單表同步?jīng)]有任何計算。第二個就是放進來之后,數(shù)據(jù)就不會再冗余了,用戶的數(shù)據(jù)都在這里面存了一份,而不是所有的項目都從源端的業(yè)務庫去拉。

△ Tapdata DaaS 三層建模

接下來我們在貼源層之上,可以去快速建立一個主數(shù)據(jù)模型,在主數(shù)據(jù)模型之上去做業(yè)務模型、分析模型都會很快。當然也可以直接從貼源層去做業(yè)務模型,因為有可能它不一定會有主數(shù)據(jù)模型,或者說主數(shù)據(jù)模型太大了。這就是我們的一個實際的演進過程,大家可以看到上面就是一個訂單模型,訂單狀態(tài)的流程,他們整個一個訂單的流程、流程的 logic,原來都是寫在 Java code 和 mq 里面,后來就被放到我們的平臺里面去,所以 Tapdata 實時數(shù)據(jù)服務平臺不只是在做數(shù)據(jù)的同步,僅在貼源層做數(shù)據(jù)同步,從貼源層到主數(shù)據(jù)層就開始在做數(shù)據(jù)的建模以及業(yè)務關系的處理,訂單狀態(tài)的變更,以及對后面價格計算、金價變化等等,這些對于業(yè)務來說是比較重要的一些屬性。

△ Tapdata 實時數(shù)據(jù)處理

在搭建了企業(yè)級實時數(shù)據(jù)融合平臺后,客戶獲得了幾個核心收益:

第一個就是前端響應從10秒降到了亞秒級別。 es 承擔了整個前臺的所有業(yè)務壓力,這個組合中幫用戶的查詢性能直接降到了亞秒級別,查詢次數(shù)也從 5 次降低為 1 次。

第二個是極大降低數(shù)據(jù)維護成本。數(shù)據(jù)門戶對于 DBA 來說,幫助是非常大的,他們很多日常工作都是在數(shù)據(jù)查詢上,比如一些報表等等,現(xiàn)在有了實時數(shù)據(jù)融合平臺之后,可以通過開放數(shù)據(jù)去查,通過包括 BA 和一些非技術人員都可以去平臺上自助查詢,從而幫 DBA 釋放了很多的工作量,同時研發(fā)部門無需跨部門溝通數(shù)據(jù),極大提升了開發(fā)效率。

△ Tapdata 數(shù)據(jù)目錄

第三個是改善 API 流程,縮短研發(fā)周期。原來整個API 的研發(fā)流程可能要做兩三個月,現(xiàn)在只需要幾天,至多也不會超過一周的時間,因為所有的數(shù)據(jù)已經(jīng)都在平臺中了,包括主數(shù)據(jù)模型在 es 那邊都有了,數(shù)據(jù)在平臺里面如果暫時搜不到,那么只需要簡單的再同步一次,把數(shù)據(jù)和模型放到平臺里面,接下來如果再用到,就不用再重復的去做這個事。從提交需求-研發(fā)-上線都非�？�,另外 Tapdata 在發(fā)布 API 的時候,也會有一些 Swagger 自動生成,對研發(fā)來說就無需寫對接文檔等。

△ Tapdata DaaS API 開發(fā)流程

現(xiàn)在,這個零售行業(yè)客戶已經(jīng)有十幾個大小應用在 Tapdata 實時數(shù)據(jù)服務平臺上運營了,因為有了融合后的實時數(shù)據(jù),原來很多的 IT 痛點都被解決掉了。如您想進一步了解 Tapdata 實時數(shù)據(jù)服務平臺,可訪問 Tapdata 官方技術博客,或申請試用 Tapdata 產(chǎn)品。

本文作者:Arthur 楊慶麟,Tapdata 首席架構師,MongoDB Professionor(中國15位獲得者之一) / 平安集團mongoDB特邀講師 /CSDN 認證博客專家。擁有豐富的數(shù)據(jù)中臺架構經(jīng)驗,主導多個實時數(shù)據(jù)融合平臺的項目,涉及 零售、物聯(lián)網(wǎng)、車聯(lián)網(wǎng)、教育、制造、工業(yè)等行業(yè)。

(轉載請注明出處)