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

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

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

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

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

一個典型的場景是:門店庫存盤點。門店店員每賣一個貨,有銷售系統(tǒng)會登記銷售記錄,每天可以從銷售系統(tǒng)里查到當(dā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 件,這就會導(dǎo)致:實際 999 件,如果不盤點,財務(wù)、后勤都不知道,因為系統(tǒng)有1000 件。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

△ Tapdata 多表關(guān)聯(lián)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

△ DaaS 物理部署架構(gòu)圖

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

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

△ Tapdata DaaS 落地步驟

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

△ Tapdata DaaS 落地硬件配置

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

△ Tapdata DaaS 三層建模

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

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

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

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

第二個是極大降低數(shù)據(jù)維護(hù)成本。數(shù)據(jù)門戶對于 DBA 來說,幫助是非常大的,他們很多日常工作都是在數(shù)據(jù)查詢上,比如一些報表等等,現(xiàn)在有了實時數(shù)據(jù)融合平臺之后,可以通過開放數(shù)據(jù)去查,通過包括 BA 和一些非技術(shù)人員都可以去平臺上自助查詢,從而幫 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ù)的去做這個事。從提交需求-研發(fā)-上線都非常快,另外 Tapdata 在發(fā)布 API 的時候,也會有一些 Swagger 自動生成,對研發(fā)來說就無需寫對接文檔等。

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

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

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

(轉(zhuǎn)載請注明出處)