事務(wù)介紹

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

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

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

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

數(shù)倉建造和運用痛點

為了滿意日益增長的事務(wù)需求，集團開始投入數(shù)倉建造。在數(shù)據(jù)倉庫建造的初期，以事務(wù)驅(qū)動為主。通過阿里云的MaxCompute為核心構(gòu)建數(shù)據(jù)倉庫，直接集成事務(wù)庫數(shù)據(jù)以及WEB運用的OSS日志等，然后在數(shù)據(jù)倉庫中剖析事務(wù)數(shù)據(jù)并發(fā)生統(tǒng)計剖析成果。初期的架構(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接口速度要快得多。原因是后者把每次拜訪作為一個Map-Reduce處理，即使很小的數(shù)據(jù)量查詢呼應(yīng)時刻也要超越10秒，而 Lightning能將延時降到百毫秒內(nèi)，滿意事務(wù)成果報表的展示需求。目前Lightning服務(wù)進入服務(wù)下線階段，新的加快服務(wù)由Hologres加快集群代替。

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

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

實時數(shù)倉選型

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

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

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

實時數(shù)倉建造

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

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

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

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

2）CDC數(shù)據(jù)總線（簡稱CDC）

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

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

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

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

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

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

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

運用場景

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

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

運用實踐

一個典型的實時使命處理流程如下圖所示：

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

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

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

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

數(shù)據(jù)驗證

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

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

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

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

1）Lookup

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

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

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

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

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

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

當 id=id1的stm_A數(shù)據(jù)到來時，會發(fā)生一條查詢： select  from dim_B where  id=id1，因為維表查詢的頻率非常高，所以Join的維表列應(yīng)該有索引。

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

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

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

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

實踐定論2：盡可能減少維表的特點列

在運用中，維表可能有多個維度列會被用于Join，例如表T1，有兩個維度列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。

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

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

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

流表stm_t2需求 Lookup 維表t1，相關(guān)條件是兩個表的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ù)價值

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

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

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