事務(wù)介紹

新東方教育科技集團(tuán)定坐落以學(xué)生全面成長(zhǎng)為核心，以科技為驅(qū)動(dòng)力的綜合性教育集團(tuán)。集團(tuán)由1993年成立的北京新東方校園發(fā)展壯大而來，具有短期培訓(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端）：包含買賣，教育，人員等數(shù)據(jù)，數(shù)據(jù)規(guī)劃為TB級(jí)。數(shù)據(jù)會(huì)被依照不同的條件和校園層級(jí)等，形成營(yíng)收、教育、客服、財(cái)富人事等實(shí)時(shí)報(bào)表，為CRM體系的成千上萬名事務(wù)參謀供給線索和商機(jī)的明細(xì)報(bào)表查詢，一起也供各級(jí)管理人員了解事務(wù)的運(yùn)行狀況，輔佐事務(wù)決議計(jì)劃。

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

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

為了滿意日益增長(zhǎng)的事務(wù)需求，集團(tuán)開始投入數(shù)倉(cāng)建造。在數(shù)據(jù)倉(cāng)庫(kù)建造的初期，以事務(wù)驅(qū)動(dòng)為主。通過阿里云的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ù)層查詢MySQL和MongoDB并向用戶供給服務(wù)接口， Web服務(wù)層也能夠通過Lightning加快接口直接查詢MaxCompute的數(shù)據(jù)，

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

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

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

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

要處理以上的事務(wù)痛點(diǎ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ì)的問題。可是Tidb需求私有云布置并運(yùn)維，而MaxCompute布置在公有云，兩者在不同的云環(huán)境。Hologres是阿里云供給的云原生服務(wù)，并與MaxCompute都布置在公有云，且在Pangu文件層緊密集成，數(shù)據(jù)交換功率遠(yuǎn)高于其他外部體系，兩者都兼容PostgreSQL，從離線數(shù)據(jù)倉(cāng)庫(kù)開發(fā)遷移到實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)開發(fā)難度降低。

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

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

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

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

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

• Binlog，即各類運(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ù)總線（簡(jiǎn)稱CDC）

• CDC數(shù)據(jù)總線收集數(shù)據(jù)源，寫入Kafka Topic。關(guā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ù)并寫入Kafka集群的Topic，而Sink Connector則將Kafka Topic的數(shù)據(jù)ETL到方針庫(kù)，包含實(shí)時(shí)和離線數(shù)倉(cāng)。
• CDC易于布置和監(jiān)控，并供給了簡(jiǎn)略的數(shù)據(jù)過濾，本錢較低，數(shù)據(jù)ETL使命盡量選用CDC。

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

• 離線數(shù)據(jù)處理依據(jù)MaxCompute建立，用于核算全量數(shù)據(jù)，數(shù)據(jù)源來自于CDC的實(shí)時(shí)導(dǎo)入。離線數(shù)據(jù)通過離線數(shù)倉(cāng)核算（ODS->DWD/DWS→ADS）導(dǎo)入Hologres作為存量數(shù)據(jù)，一部分離線的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流式核算引擎。與離線數(shù)倉(cāng)處理固定日期的數(shù)據(jù)（如T+1）不同，實(shí)時(shí)數(shù)倉(cāng)處理的是流式數(shù)據(jù)，從使命發(fā)動(dòng)開始，就一直運(yùn)行，除非反常終止，不然不會(huì)結(jié)束。數(shù)倉(cāng)的層次與離線數(shù)倉(cāng)類似，依據(jù)實(shí)時(shí)處理的特色做了簡(jiǎn)化。如下表所示:

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

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

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

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

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

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

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

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

1. Flink使命讀取ODS層數(shù)據(jù)作為輸入，與存儲(chǔ)在Hologres中的維表做相關(guān)，核算的成果存儲(chǔ)到DWD/DWS層的Kafka Topic中，一起將成果寫入到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í)刻>離線的核算周期即可，如離線T+1，則存儲(chǔ)2天，假如是Kappa架構(gòu)，保留悉數(shù)數(shù)據(jù)， 一起將成果數(shù)據(jù)寫入離線數(shù)倉(cāng)用于離線剖析用（可選）。

下面具體介紹在每一步處理流程中的運(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)證無法在使命中進(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í)成果和離線成果進(jìn)行比對(duì)，假定離線處理周期為T+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ù)，所以需求從離線數(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è)問題：

1. 維表索引：實(shí)際處理過程是每條流表的數(shù)據(jù)，運(yùn)用Join 條件的列去維表中查詢，將成果回來。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ù)沒有入庫(kù)。

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

關(guān)于問題2，維表和流表Join中，處理兩者數(shù)據(jù)不同步的問題，通過設(shè)置窗口能夠處理大部分問題，可是因?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é)合起來。

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

以下是一個(gè)例子，t_student(學(xué)員表)的流表和t_account(用戶表) 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ù)到來，會(huì)對(duì)Join的維表履行一次點(diǎn)查，Join的條件便是查詢條件，例如關(guān)于流表stm_A和維表dim_B，Join條件為stm_A.id = dim.B.id

當(dāng) id=id1的stm_A數(shù)據(jù)到來時(shí)，會(huì)發(fā)生一條查詢： select  from dim_B where  id=id1，因?yàn)榫S表查詢的頻率非常高，所以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一類的剖析查詢事務(wù)，所以本實(shí)踐中大部分維表是列存表，以下實(shí)踐定論是依據(jù)列存表和查詢狀況設(shè)定的，僅供參閱，請(qǐng)依據(jù)事務(wù)狀況合理設(shè)置。

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

因?yàn)楫?dāng)時(shí)運(yùn)用列存作為維度表，維表的列數(shù)會(huì)影響查詢功能，關(guān)于同一個(gè)維表，8個(gè)列和16個(gè)列的功能相差50%以上，主張join用到的列都設(shè)置成distribution key，不能多也不能少。假如運(yùn)用行存表，沒有這個(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, 反過來則在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)行拆分。查詢時(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à)值

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

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

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