事務(wù)介紹

新東方教育科技集團(tuán)定坐落以學(xué)生全面成長(zhǎng)為核心，以科技為驅(qū)動(dòng)力的綜合性教育集團(tuán)。集團(tuán)由1993年成立的北京新東方校園發(fā)展壯大而來(lái)，具有短期培訓(xùn)體系、基礎(chǔ)教育體系、文化傳播體系等事務(wù)。

在互聯(lián)網(wǎng)大潮中，新東方在IT技術(shù)上也不斷重構(gòu)，持續(xù)投入大數(shù)據(jù)建造，研發(fā)大數(shù)據(jù)的相關(guān)技術(shù)和運(yùn)用，然后快速而精準(zhǔn)地呼應(yīng)事務(wù)需求，并用數(shù)據(jù)為集團(tuán)各級(jí)領(lǐng)導(dǎo)供給決議計(jì)劃依據(jù)。新東方的大數(shù)據(jù)運(yùn)用首要包含兩部分：

• 企業(yè)運(yùn)用端的事務(wù)場(chǎng)景（B端）：包含買(mǎi)賣(mài)，教育，人員等數(shù)據(jù)，數(shù)據(jù)規(guī)劃為T(mén)B級(jí)。數(shù)據(jù)會(huì)被依照不同的條件和校園層級(jí)等，形成營(yíng)收、教育、客服、財(cái)富人事等實(shí)時(shí)報(bào)表，為CRM體系的成千上萬(wàn)名事務(wù)參謀供給線(xiàn)索和商機(jī)的明細(xì)報(bào)表查詢(xún)，一起也供各級(jí)管理人員了解事務(wù)的運(yùn)行狀況，輔佐事務(wù)決議計(jì)劃。

• 互聯(lián)網(wǎng)直接面向用戶(hù)場(chǎng)景（C端）：首要為招生引流類(lèi)、云教室等運(yùn)用，包含網(wǎng)頁(yè)版，App端，H5等，數(shù)據(jù)量為PB級(jí)。這部分?jǐn)?shù)據(jù)記錄了用戶(hù)（學(xué)員和潛在用戶(hù)）在新東方的教育閉環(huán)軌道，C端數(shù)據(jù)除了生成常規(guī)的運(yùn)營(yíng)報(bào)表外，還會(huì)制作用戶(hù)畫(huà)像，從而開(kāi)發(fā)引薦體系和圈選等運(yùn)用，改善C端各種運(yùn)用的用戶(hù)體驗(yàn)，進(jìn)一步精細(xì)化運(yùn)營(yíng)。

數(shù)倉(cāng)建造和運(yùn)用痛點(diǎn)

為了滿(mǎn)意日益增長(zhǎng)的事務(wù)需求，集團(tuán)開(kāi)始投入數(shù)倉(cāng)建造。在數(shù)據(jù)倉(cāng)庫(kù)建造的初期，以事務(wù)驅(qū)動(dòng)為主。通過(guò)阿里云的MaxCompute為核心構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)，直接集成事務(wù)庫(kù)數(shù)據(jù)以及WEB運(yùn)用的OSS日志等，然后在數(shù)據(jù)倉(cāng)庫(kù)中剖析事務(wù)數(shù)據(jù)并發(fā)生統(tǒng)計(jì)剖析成果。初期的架構(gòu)如下：

依據(jù)事務(wù)需求，將中小型規(guī)劃的成果導(dǎo)入MySQL并支撐數(shù)據(jù)更新。數(shù)據(jù)規(guī)劃較大的只讀成果則導(dǎo)入 MongoDB。

然后Web服務(wù)層查詢(xún)MySQL和MongoDB并向用戶(hù)供給服務(wù)接口， Web服務(wù)層也能夠通過(guò)Lightning加快接口直接查詢(xún)MaxCompute的數(shù)據(jù)，

Lightning協(xié)議是MaxCompute查詢(xún)加快服務(wù)，支撐以PostgreSQL協(xié)議及語(yǔ)法連接拜訪(fǎng)MaxCompute數(shù)據(jù)，相比MaxCompute供給的odps jdbc接口速度要快得多。原因是后者把每次拜訪(fǎng)作為一個(gè)Map-Reduce處理，即使很小的數(shù)據(jù)量查詢(xún)呼應(yīng)時(shí)刻也要超越10秒，而 Lightning能將延時(shí)降到百毫秒內(nèi)，滿(mǎn)意事務(wù)成果報(bào)表的展示需求。目前Lightning服務(wù)進(jìn)入服務(wù)下線(xiàn)階段，新的加快服務(wù)由Hologres加快集群代替。

運(yùn)用這套架構(gòu)能夠在較短的時(shí)刻內(nèi)滿(mǎn)意報(bào)表開(kāi)發(fā)、用戶(hù)畫(huà)像和引薦服務(wù)等需求，為新東方的日常運(yùn)營(yíng)和招生引流供給較好的數(shù)據(jù)支撐?？墒歉聞?wù)的開(kāi)展，這套架構(gòu)越來(lái)越難以滿(mǎn)意用戶(hù)的需求，首要體現(xiàn)在：

1. 實(shí)時(shí)性，事務(wù)期望能夠達(dá)到1分鐘級(jí)甚至秒級(jí)的實(shí)時(shí)性，而運(yùn)用MaxCompute只能完結(jié)批量處理，一般只能供給分鐘級(jí)（一般5分鐘以上）的延時(shí)
2. 來(lái)自Web服務(wù)層的高并發(fā)查詢(xún)，MaxCompute的大數(shù)據(jù)量查詢(xún)只能支撐到100左右的QPS，滿(mǎn)意不了來(lái)自C端運(yùn)用的高并發(fā)查詢(xún)
3. 雜亂邏輯的大數(shù)據(jù)量剖析和Ad-hoc查詢(xún)，跟著剖析數(shù)據(jù)敏捷從數(shù)百G上漲到TB級(jí)，在多個(gè)數(shù)億行以上的數(shù)據(jù)進(jìn)行雜亂報(bào)表開(kāi)發(fā)，單實(shí)例MySQL難以支撐；而MongoDB無(wú)法運(yùn)用規(guī)范的SQL進(jìn)行雜亂查詢(xún)，一起MongoDB本身雜亂的查詢(xún)事務(wù)，開(kāi)發(fā)功率很低。
4. Lightning接口盡管支撐規(guī)范的SQL而且某些場(chǎng)景上速度比較快，可是Lightning開(kāi)始逐步下線(xiàn)，需求找到替換的辦法。

實(shí)時(shí)數(shù)倉(cāng)選型

要處理以上的事務(wù)痛點(diǎn)，就需求找到能滿(mǎn)意實(shí)時(shí)數(shù)倉(cāng)建造需求的產(chǎn)品。大數(shù)據(jù)團(tuán)隊(duì)調(diào)研了多種實(shí)時(shí)數(shù)倉(cāng)方案，依據(jù)新東方的數(shù)據(jù)和運(yùn)用特色進(jìn)行選型，方案比對(duì)如下：

從以上的表格能看出，Tidb和Hologres能夠較好地處理新東方在大數(shù)據(jù)方面面對(duì)的問(wèn)題。可是Tidb需求私有云布置并運(yùn)維，而MaxCompute布置在公有云，兩者在不同的云環(huán)境。Hologres是阿里云供給的云原生服務(wù)，并與MaxCompute都布置在公有云，且在Pangu文件層緊密集成，數(shù)據(jù)交換功率遠(yuǎn)高于其他外部體系，兩者都兼容PostgreSQL，從離線(xiàn)數(shù)據(jù)倉(cāng)庫(kù)開(kāi)發(fā)遷移到實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)開(kāi)發(fā)難度降低。

依據(jù)以上的剖析，挑選Hologres作為實(shí)時(shí)數(shù)倉(cāng)。

實(shí)時(shí)數(shù)倉(cāng)建造

實(shí)時(shí)數(shù)倉(cāng)是在離線(xiàn)數(shù)倉(cāng)的基礎(chǔ)上，依據(jù)Lambda架構(gòu)構(gòu)建，離線(xiàn)和實(shí)時(shí)一起進(jìn)行建造。有關(guān)Lambda的，參閱：Lambda architecture

架構(gòu)的各組件闡明：

1）數(shù)據(jù)源：

• Binlog，即各類(lèi)運(yùn)用（B端和C端）的數(shù)據(jù)庫(kù)Binlog，關(guān)于SQL SERVER的數(shù)據(jù)庫(kù)則是CT log;
• App音訊，即App運(yùn)行時(shí)上報(bào)的事件;
• Web日志/埋點(diǎn)日志，即Web服務(wù)器所發(fā)生的ngix日志，以及Web app/H5運(yùn)行時(shí)埋點(diǎn)服務(wù)發(fā)生的日志

2）CDC數(shù)據(jù)總線(xiàn)（簡(jiǎn)稱(chēng)CDC）

• CDC數(shù)據(jù)總線(xiàn)收集數(shù)據(jù)源，寫(xiě)入Kafka Topic。關(guān)于離線(xiàn)數(shù)倉(cāng)和實(shí)時(shí)數(shù)倉(cāng), CDC都是直接交互的數(shù)據(jù)源/
• CDC包含Source Connector、Kafka 集群、Sink Connector三部分。 Source Connector 負(fù)責(zé)從數(shù)據(jù)源收集數(shù)據(jù)并寫(xiě)入Kafka集群的Topic，而Sink Connector則將Kafka Topic的數(shù)據(jù)ETL到方針庫(kù)，包含實(shí)時(shí)和離線(xiàn)數(shù)倉(cāng)。
• CDC易于布置和監(jiān)控，并供給了簡(jiǎn)略的數(shù)據(jù)過(guò)濾，本錢(qián)較低，數(shù)據(jù)ETL使命盡量選用CDC。

3）離線(xiàn)數(shù)據(jù)處理

• 離線(xiàn)數(shù)據(jù)處理依據(jù)MaxCompute建立，用于核算全量數(shù)據(jù)，數(shù)據(jù)源來(lái)自于CDC的實(shí)時(shí)導(dǎo)入。離線(xiàn)數(shù)據(jù)通過(guò)離線(xiàn)數(shù)倉(cāng)核算（ODS->DWD/DWS→ADS）導(dǎo)入Hologres作為存量數(shù)據(jù)，一部分離線(xiàn)的DWD/DWS數(shù)據(jù)也導(dǎo)入Hologres作為維表的存量數(shù)據(jù)。
• Flink核算使命會(huì)將ADS層成果Sink到MaxCompute， 用于數(shù)據(jù)備份。

4）實(shí)時(shí)數(shù)據(jù)處理

實(shí)時(shí)數(shù)據(jù)處理依據(jù)阿里云托管的 Flink流式核算引擎。與離線(xiàn)數(shù)倉(cāng)處理固定日期的數(shù)據(jù)（如T+1）不同，實(shí)時(shí)數(shù)倉(cāng)處理的是流式數(shù)據(jù)，從使命發(fā)動(dòng)開(kāi)始，就一直運(yùn)行，除非反常終止，不然不會(huì)結(jié)束。數(shù)倉(cāng)的層次與離線(xiàn)數(shù)倉(cāng)類(lèi)似，依據(jù)實(shí)時(shí)處理的特色做了簡(jiǎn)化。如下表所示:

5）Hologres 數(shù)據(jù)查詢(xún)

Hologres一起作為實(shí)時(shí)數(shù)據(jù)和MaxCompute離線(xiàn)數(shù)據(jù)加快查詢(xún)的剖析引擎，存儲(chǔ)所有的實(shí)時(shí)數(shù)倉(cāng)所需的數(shù)據(jù)表，包含維度數(shù)據(jù)表（維表）、實(shí)時(shí)成果表、存量數(shù)據(jù)表以及查詢(xún)View和外表等。數(shù)據(jù)表的界說(shuō)和用途如下表所示：

運(yùn)用場(chǎng)景

通過(guò)新的架構(gòu)，支撐了新東方集團(tuán)內(nèi)如下運(yùn)用場(chǎng)景：

1. 實(shí)時(shí)報(bào)表查詢(xún)：為CRM體系的成千上萬(wàn)名事務(wù)參謀供給線(xiàn)索和商機(jī)的明細(xì)報(bào)表查詢(xún)，一起為管理層供給實(shí)時(shí)活動(dòng)看板服務(wù)，延時(shí)秒級(jí)，輔佐事務(wù)決議計(jì)劃。
2. Ad-hoc查詢(xún)：B端和C端運(yùn)營(yíng)人員能夠直接通過(guò)Hologres定制自己的雜亂事務(wù)查詢(xún)
3. 用戶(hù)軌道和畫(huà)像場(chǎng)景：實(shí)時(shí)處理用戶(hù)來(lái)自B端和C端的數(shù)據(jù)，生成用戶(hù)軌道和標(biāo)簽，為事務(wù)快速?zèng)Q議計(jì)劃供給依據(jù)。
4. 引薦體系和圈選事務(wù)：通過(guò)Maxcompute訓(xùn)練離線(xiàn)模型，并通過(guò)Flink數(shù)據(jù)調(diào)整模型的參數(shù)。依據(jù)用戶(hù)的實(shí)時(shí)軌道數(shù)據(jù)圈選出契合條件的用戶(hù)并推送服務(wù)，進(jìn)一步精細(xì)化運(yùn)營(yíng)。

運(yùn)用實(shí)踐

一個(gè)典型的實(shí)時(shí)使命處理流程如下圖所示：

1. ODS層數(shù)據(jù)通過(guò)CDC數(shù)據(jù)總線(xiàn)導(dǎo)入MaxCompute， 供給離線(xiàn)核算源數(shù)據(jù)。 一起也會(huì)將數(shù)據(jù)寫(xiě)入到Hologres,用于做數(shù)據(jù)驗(yàn)證。 在Hologres中，維表存儲(chǔ)全量數(shù)據(jù)。而其他類(lèi)型的ODS數(shù)據(jù)表一般存儲(chǔ)時(shí)刻>離線(xiàn)的核算周期即可，如離線(xiàn)T+1，則存儲(chǔ)2天，無(wú)相應(yīng)的離線(xiàn)核算使命依據(jù)驗(yàn)證數(shù)據(jù)周期而定。

1. Flink使命讀取ODS層數(shù)據(jù)作為輸入，與存儲(chǔ)在Hologres中的維表做相關(guān)，核算的成果存儲(chǔ)到DWD/DWS層的Kafka Topic中，一起將成果寫(xiě)入到Hologres用于數(shù)據(jù)驗(yàn)證，數(shù)據(jù)存儲(chǔ)時(shí)刻與ODS層相同。

1. Flink使命讀取DWD/DWS層數(shù)據(jù)，與存儲(chǔ)在Hologres中的維表做相關(guān)， 將結(jié)算的成果存儲(chǔ)到Hologres。依據(jù)運(yùn)用需求，假如是Lambda架構(gòu)，存儲(chǔ)時(shí)刻>離線(xiàn)的核算周期即可，如離線(xiàn)T+1，則存儲(chǔ)2天，假如是Kappa架構(gòu)，保留悉數(shù)數(shù)據(jù)， 一起將成果數(shù)據(jù)寫(xiě)入離線(xiàn)數(shù)倉(cāng)用于離線(xiàn)剖析用（可選）。

下面具體介紹在每一步處理流程中的運(yùn)用實(shí)踐與經(jīng)驗(yàn)優(yōu)化，以協(xié)助達(dá)到更好的效果。

數(shù)據(jù)驗(yàn)證

因?yàn)閷?shí)時(shí)處理源數(shù)據(jù)和成果都是動(dòng)態(tài)的，數(shù)據(jù)驗(yàn)證無(wú)法在使命中進(jìn)行。能夠在Hologres中，對(duì)實(shí)時(shí)數(shù)倉(cāng)的各層落倉(cāng)成果進(jìn)行驗(yàn)證。因?yàn)閷?shí)時(shí)處理和時(shí)刻相關(guān)，每一層次的數(shù)據(jù)都需求帶上一個(gè)處理時(shí)刻戳(Process Time)。在Lambda架構(gòu)中，將實(shí)時(shí)成果和離線(xiàn)成果進(jìn)行比對(duì)，假定離線(xiàn)處理周期為T(mén)+1, 則實(shí)時(shí)處理取時(shí)刻戳與昨天的數(shù)據(jù)進(jìn)行比對(duì)，核算出準(zhǔn)確率。假如是Kappa架構(gòu)，需求進(jìn)行邏輯驗(yàn)證，并與事務(wù)人員處理的成果數(shù)據(jù)進(jìn)行比對(duì)。

全量數(shù)據(jù)初始化

Kafka Topic一般存儲(chǔ)幾天內(nèi)的數(shù)據(jù)，不能供給全量數(shù)據(jù)，所以需求從離線(xiàn)數(shù)倉(cāng)進(jìn)行全量數(shù)據(jù)初始化，將維表、ADS層成果等導(dǎo)入Hologres。

Hologres維表的Lookup和功能優(yōu)化

1）Lookup

在Flink核算使命中，流表和Hologres的維度數(shù)據(jù)表Join，便是Lookup。Lookup需求處理兩個(gè)問(wèn)題：

1. 維表索引：實(shí)際處理過(guò)程是每條流表的數(shù)據(jù)，運(yùn)用Join 條件的列去維表中查詢(xún)，將成果回來(lái)。Hologres的維表的索引需求和Flink SQL的Join key一致。
2. 維表的推遲：因?yàn)榫S表的數(shù)據(jù)導(dǎo)入是另外的使命（CDC使命或許Flink使命），就會(huì)呈現(xiàn)數(shù)據(jù)不同步的狀況，流表數(shù)據(jù)已到，而相關(guān)的維度數(shù)據(jù)沒(méi)有入庫(kù)。

關(guān)于問(wèn)題1， 在創(chuàng)立Hologres的維度表時(shí)，需求依據(jù)Flink SQL的需求去設(shè)置表的各類(lèi)索引，尤其是Distribution key和Clustering key，使之與Join的相關(guān)條件列一致，有關(guān)Hologres維表的索引會(huì)在后邊末節(jié)說(shuō)到。

關(guān)于問(wèn)題2，維表和流表Join中，處理兩者數(shù)據(jù)不同步的問(wèn)題，通過(guò)設(shè)置窗口能夠處理大部分問(wèn)題，可是因?yàn)閣atermark觸發(fā)窗口履行，需求兼顧維表數(shù)據(jù)推遲較多的狀況，因而watermark duration設(shè)置較高，然后導(dǎo)致了數(shù)據(jù)處理使命的Latency很高，有時(shí)不契合快速呼應(yīng)的事務(wù)要求，這時(shí)能夠選用聯(lián)合Join,，將雙流Join和Lookup結(jié)合起來(lái)。

維表數(shù)據(jù)包含兩部分： 1. Hologres維表，查詢(xún)?nèi)繑?shù)據(jù). 2. 從維表對(duì)應(yīng)的Kafka Topic創(chuàng)立的流表，查詢(xún)最新的數(shù)據(jù)。Join時(shí)，先取維表對(duì)應(yīng)的流表數(shù)據(jù)，假如不存在取Hologres維表的數(shù)據(jù)。

以下是一個(gè)例子，t_student(學(xué)員表)的流表和t_account(用戶(hù)表) Join獲取學(xué)員的user id

combined join //stream table:stream_uc_account val streamUcAccount: String = s""" CREATE TABLE `stream_t_account` ( `user_id` VARCHAR ,`mobile` VARCHAR .......(omitted) ,WATERMARK FOR event_time AS event_time - INTERVAL '20' SECOND ) WITH (  'connector' = 'kafka'  .......(omitted) ) """.stripMargin //dim table:t_account val odsUcAccount: String = s""" CREATE TABLE `t_account` WITH ( 'connector' = 'jdbc', .......(omitted) ) LIKE stream_t_account (excluding ALL) """.stripMargin //query sql: combined join val querySql:String = s""" select  coalesce(stm_acc.user_id,acc.user_id) as user_id from t_student stu LEFT JOIN stm_acc ON stu.stu_id  = stm_acc.student_id AND stu.modified_time  BETWEEN stm_acc.modified_time - INTERVAL '5' MINUTE  AND stm_acc.modified_time + INTERVAL '5' SECOND LEFT JOIN uc_account FOR SYSTEM_TIME AS OF stu.process_time AS acc ON stu.stu_id = acc.student_id

2）維表功能的優(yōu)化

Flink SQL在Lookup時(shí)，流表每一條數(shù)據(jù)到來(lái)，會(huì)對(duì)Join的維表履行一次點(diǎn)查，Join的條件便是查詢(xún)條件，例如關(guān)于流表stm_A和維表dim_B，Join條件為stm_A.id = dim.B.id

當(dāng) id=id1的stm_A數(shù)據(jù)到來(lái)時(shí)，會(huì)發(fā)生一條查詢(xún)： select  from dim_B where  id=id1，因?yàn)榫S表查詢(xún)的頻率非常高，所以Join的維表列應(yīng)該有索引。

Hologres索引包含： distribution key，clustering key，bitmap key，segment key(event timestamp) , 有關(guān)索引，能夠參閱 holo表的創(chuàng)立和索引

注意：維表引薦用Hologres行存表，可是在實(shí)際狀況中，因?yàn)榫S表還用于adhoc一類(lèi)的剖析查詢(xún)事務(wù)，所以本實(shí)踐中大部分維表是列存表，以下實(shí)踐定論是依據(jù)列存表和查詢(xún)狀況設(shè)定的，僅供參閱，請(qǐng)依據(jù)事務(wù)狀況合理設(shè)置。

實(shí)踐定論1：維表的Join列設(shè)置成distribution key

因?yàn)楫?dāng)時(shí)運(yùn)用列存作為維度表，維表的列數(shù)會(huì)影響查詢(xún)功能，關(guān)于同一個(gè)維表，8個(gè)列和16個(gè)列的功能相差50%以上，主張join用到的列都設(shè)置成distribution key，不能多也不能少。假如運(yùn)用行存表，沒(méi)有這個(gè)限制。

實(shí)踐定論2：盡可能減少維表的特點(diǎn)列

在運(yùn)用中，維表可能有多個(gè)維度列會(huì)被用于Join，例如表T1，有兩個(gè)維度列F1、F2別離用做和流表A，B的Join條件。依據(jù)F1和F2之間的聯(lián)系，假如F1..F2→1..n，就在F1上創(chuàng)立distribution key, 反過(guò)來(lái)則在F2上創(chuàng)立，即在粒度較大的維度列上創(chuàng)立distribution key。

實(shí)踐定論3: 一個(gè)維度表有多個(gè)維度列而且是Hierarchy時(shí)，在粒度較大的列上創(chuàng)立distribution key,并用在Join條件中

假如 F1..F2是多對(duì)多的聯(lián)系，闡明一個(gè)維表有兩個(gè)交織的維度，而不是層次維度(hierarchy)上，需求進(jìn)行拆分。查詢(xún)時(shí)，不管Lookup是否必須用到distribution key索引列，都要把distribution key索引放在Join條件里。

示例： 維表t1有兩個(gè)維度列：stu_code和roster_code，distribution key加在stu_code上

流表stm_t2需求 Lookup 維表t1，相關(guān)條件是兩個(gè)表的roster_code相同

select <field list> from FROM stm_t2 stm JOIN t1 FOR SYSTEM_TIME AS OF stm.process_time AS dim ON stm.stu_code = dim.stu_code and stm.roster_code = dim.roster_code

事務(wù)價(jià)值

通過(guò)半年的實(shí)時(shí)數(shù)倉(cāng)建造，并在集團(tuán)內(nèi)廣泛運(yùn)用。為事務(wù)的帶來(lái)的價(jià)值如下：

1. 為運(yùn)營(yíng)人員供給了1分鐘級(jí)/秒級(jí)的實(shí)時(shí)看板服務(wù)和實(shí)時(shí)報(bào)表，事務(wù)人員能夠及時(shí)了解到用戶(hù)的反饋和事務(wù)的進(jìn)程，然后調(diào)整運(yùn)營(yíng)戰(zhàn)略，進(jìn)步運(yùn)營(yíng)功率。
2. 為C端運(yùn)用供給了秒級(jí)的實(shí)時(shí)用戶(hù)畫(huà)像服務(wù)和用戶(hù)圈選服務(wù)，然后能夠讓引薦體系及時(shí)依據(jù)用戶(hù)反饋調(diào)整引薦產(chǎn)品列表，進(jìn)步用戶(hù)體驗(yàn)
3. 開(kāi)發(fā)功率大為進(jìn)步，開(kāi)發(fā)人員從之前的架構(gòu)遷移到Hologres+Flink SQL上后，開(kāi)發(fā)功率進(jìn)步了1-2倍，學(xué)習(xí)的梯度也降低了許多。
4. 運(yùn)維本錢(qián)下降，之前需求保護(hù)MySQL,  MongoDB等異構(gòu)體系，而Hologres是云原生服務(wù)，無(wú)需保護(hù)一個(gè)運(yùn)維團(tuán)隊(duì)。

作者：陳毓林， 新東方互聯(lián)網(wǎng)技術(shù)中心大數(shù)據(jù)工程師。在新東方從事多年大數(shù)據(jù)架構(gòu)研發(fā)，數(shù)據(jù)集成渠道開(kāi)發(fā)，以及事務(wù)數(shù)據(jù)剖析等，首要技術(shù)領(lǐng)域包含依據(jù)flink的實(shí)時(shí)核算和優(yōu)化，kafka相關(guān)的數(shù)據(jù)交換和集成等阿里云的云原生技術(shù)。