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

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

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

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

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

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

(1)但店員如果忘記錄入了,那系統(tǒng)記錄有 1000 件,實(shí)際只有 999 件,這就會(huì)導(dǎo)致:實(shí)際 999 件,如果不盤點(diǎn),財(cái)務(wù)、后勤都不知道,因?yàn)橄到y(tǒng)有1000 件。

(2)之前盤點(diǎn)都是分店店員根據(jù)店里的存貨去和手賬的記錄做手工對賬,因?yàn)楣ぷ髁烤薮?所以做不了每天盤貨,只能做季度大盤。

這里有 2 個(gè)問題:人工盤點(diǎn)費(fèi)時(shí);出錯(cuò)率高。

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

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

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

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

二是有太多的業(yè)務(wù)系統(tǒng),且系統(tǒng)年齡非常悠久,他們的可維護(hù)性已經(jīng)變得越來越低。例如,有一些存儲(chǔ)過程有一兩千行,代碼是從2000年開始維護(hù)的,每一個(gè)存儲(chǔ)過程大概有十幾個(gè)人維護(hù),前前后后這種歷史原因會(huì)導(dǎo)致整個(gè)系統(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ù),直接影響了整個(gè)開發(fā)周期。

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

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

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

其次是基于實(shí)時(shí)同步+數(shù)據(jù)建模,向 ES 供數(shù),解決全文搜索的時(shí)效性問題,滿足零售行業(yè)在移動(dòng)端前臺(tái)搜索,實(shí)時(shí)看到結(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 是為客戶提了一個(gè)能夠做到實(shí)時(shí)查詢、全文搜索,然后能很快的提供數(shù)據(jù)統(tǒng)一服務(wù)的平臺(tái)。

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

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

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

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

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

第一步是將所有的數(shù)據(jù)庫,無論是 oracle,mysql 等傳統(tǒng)關(guān)系型數(shù)據(jù)庫還是非關(guān)系型也好,全部通過實(shí)時(shí)同步進(jìn)入我們的平臺(tái)。平臺(tái)采用了兩種數(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í)時(shí)數(shù)據(jù)同步

比如說商品模型,它在關(guān)系數(shù)據(jù)庫里面由二三十張表組成,我們就可以把這些表全部合并成一張固化視圖,即一張大寬表,但這張大寬表是實(shí)時(shí)業(yè)務(wù)在更新的,如果 erp 或者 mes 下了一個(gè)新的訂單,大寬表中關(guān)于那條訂單的狀態(tài)就會(huì)被更新到最新,然后再把 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ù)實(shí)時(shí)同步的方案是,首先把所有的 oracle 從 4 個(gè)地方(中國大陸及港澳臺(tái))的 pos 系統(tǒng)拿過來,通過 logminer 的方式監(jiān)聽進(jìn)來,然后經(jīng)過中間的各種處理,比如說規(guī)則處理、腳本處理、字段處理、大小寫轉(zhuǎn)換等等,再把這些全部都處理完的結(jié)果寫到 MongoDB 里面去,之后通過實(shí)時(shí)同步寫到 es 里面去。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

△ Tapdata DaaS 落地步驟

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

△ Tapdata DaaS 落地硬件配置

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

△ Tapdata DaaS 三層建模

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

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

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

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

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

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

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

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

現(xiàn)在,這個(gè)零售行業(yè)客戶已經(jīng)有十幾個(gè)大小應(yīng)用在 Tapdata 實(shí)時(shí)數(shù)據(jù)服務(wù)平臺(tái)上運(yùn)營了,因?yàn)橛辛巳诤虾蟮膶?shí)時(shí)數(shù)據(jù),原來很多的 IT 痛點(diǎn)都被解決掉了。如您想進(jìn)一步了解 Tapdata 實(shí)時(shí)數(shù)據(jù)服務(wù)平臺(tái),可訪問 Tapdata 官方技術(shù)博客,或申請?jiān)囉?Tapdata 產(chǎn)品。

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

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