隨著大數(shù)據(jù)技術(shù)的飛速發(fā)展，海量數(shù)據(jù)存儲(chǔ)和計(jì)算的解決方案層出不窮，生產(chǎn)環(huán)境和大數(shù)據(jù)環(huán)境的交互日益密切。數(shù)據(jù)倉庫作為海量數(shù)據(jù)落地和扭轉(zhuǎn)的重要載體，承擔(dān)著數(shù)據(jù)從生產(chǎn)環(huán)境到大數(shù)據(jù)環(huán)境、經(jīng)由大數(shù)據(jù)環(huán)境計(jì)算處理回饋生產(chǎn)應(yīng)用或支持決策的重要角色。

數(shù)據(jù)倉庫的主題覆蓋度、性能、易用性、可擴(kuò)展性及數(shù)據(jù)質(zhì)量都是衡量數(shù)據(jù)倉庫解決方案好壞的重要指標(biāo)。攜程機(jī)票部門數(shù)據(jù)倉庫也在不斷摸索向著這些目標(biāo)砥礪前行。

攜程機(jī)票部門的數(shù)據(jù)倉庫建設(shè)主要基于公司公共部門的大數(shù)據(jù)基礎(chǔ)環(huán)境及數(shù)據(jù)調(diào)度平臺(tái)，輔以部分自運(yùn)維的開源存儲(chǔ)引擎和基于開源組件二次開發(fā)的數(shù)據(jù)同步工具和運(yùn)維工具。

機(jī)票部門的數(shù)據(jù)倉庫源于2008年，當(dāng)時(shí)生產(chǎn)環(huán)境數(shù)據(jù)落地主要使用SQLServer，數(shù)據(jù)倉庫處理的目標(biāo)數(shù)據(jù)體量不大，因此選擇的SQLServer、Informaticas、Kettle這樣的數(shù)據(jù)倉庫方案，數(shù)據(jù)模型設(shè)計(jì)及報(bào)表定制使用SAP的商用平臺(tái)BO。

隨著機(jī)票業(yè)務(wù)系統(tǒng)的日益復(fù)雜，特別是生產(chǎn)環(huán)境引入消息中間件Kafka存儲(chǔ)日志數(shù)據(jù)后，這套方案不可擴(kuò)展性的缺點(diǎn)日趨明顯，SQLServer的存儲(chǔ)和計(jì)算能力很大程度上限制了數(shù)倉數(shù)據(jù)的主題覆蓋度及性能。

在2014年，公司公共部門hadoop集群部署上線，并且引入了zeus調(diào)度平臺(tái)及DataX同步工具，各個(gè)BU的數(shù)據(jù)倉庫開始逐步轉(zhuǎn)為基于Hive建設(shè)。

隨著生產(chǎn)業(yè)務(wù)對(duì)實(shí)時(shí)監(jiān)控、流量回放的需求增強(qiáng)，2016年機(jī)票部門部署了ElasticSearch，用以實(shí)時(shí)落地從Kafka同步的各個(gè)主流程服務(wù)日志，并通過統(tǒng)一的交易標(biāo)識(shí) (transactionID) 串聯(lián)用戶的一次完整的搜索、下單等行為，用于生產(chǎn)排障和流量回放。基于Hive的搜索性能一直被廣泛詬病，特別是針對(duì)adhoc查詢，機(jī)票部門在2016年調(diào)研并部署了Facebook開源的基于內(nèi)存和Pipeline的查詢引擎Presto，在沒有享受到local數(shù)據(jù)獲取的前提下，查詢性能較原生的Hive引擎或者Spark引擎都有很大的提升。

在2018年，為了支持?jǐn)?shù)倉數(shù)據(jù)的可視化運(yùn)營平臺(tái)，我們先后引入了ClickHouse和CrateDB作為后臺(tái)的存儲(chǔ)和查詢引擎，特別是引入CrateDB以后，億級(jí)體量的表四個(gè)維度的聚合耗時(shí)P90下降到了4秒。

實(shí)時(shí)數(shù)據(jù)處理技術(shù)也經(jīng)過了Esper，Storm，Spark Streaming和Flink的迭代，并慢慢收斂到Flink?？傮w的技術(shù)演進(jìn)歷史如圖1所示。

圖1 數(shù)倉技術(shù)演進(jìn)歷史

生產(chǎn)環(huán)境的數(shù)據(jù)可以大致分成三類：

1）業(yè)務(wù)數(shù)據(jù)，主要存儲(chǔ)在MySQL和SQLServer，在這些關(guān)系型數(shù)據(jù)庫里面有數(shù)以萬計(jì)的表承接著各種生產(chǎn)服務(wù)的業(yè)務(wù)數(shù)據(jù)寫入；

2）基礎(chǔ)數(shù)據(jù)，也是存儲(chǔ)在MySQL和SQLServer中，生產(chǎn)應(yīng)用時(shí)一般會(huì)建立一層中心化緩存（如Redis）或者本地緩存；

3）日志數(shù)據(jù)，這類數(shù)據(jù)的特點(diǎn)是”append only”，對(duì)已經(jīng)生成的數(shù)據(jù)不會(huì)有更新的操作，考慮到這類數(shù)據(jù)的高吞吐量，生產(chǎn)環(huán)境一般會(huì)用消息隊(duì)列Kafka暫存；

數(shù)據(jù)倉庫在實(shí)施數(shù)據(jù)同步時(shí)，會(huì)根據(jù)需求在實(shí)時(shí)、近實(shí)時(shí)以及T+1天等不同的頻率執(zhí)行數(shù)據(jù)同步，并且在大數(shù)據(jù)環(huán)境會(huì)用不同的載體承接不同頻率同步過來的數(shù)據(jù)。在攜程機(jī)票，實(shí)時(shí)同步的目標(biāo)載體是ElasticSearch、CrateDB或者HBase，近實(shí)時(shí)（一般T+1小時(shí)）或者T+1天的目標(biāo)載體是Hive。

從生產(chǎn)的數(shù)據(jù)載體來講，主要包括DB和消息隊(duì)列，他們的數(shù)據(jù)同步方案主要是：

1）生產(chǎn)DB到Hive的同步使用taobao開源的DataX，DataX由網(wǎng)站運(yùn)營中心DP團(tuán)隊(duì)做了很多擴(kuò)展開發(fā)，目前支持了多種數(shù)據(jù)源之間的數(shù)據(jù)同步。實(shí)時(shí)同步的場(chǎng)景主要在MySQL，使用DBA部門使用Canal解析并寫入至消息隊(duì)列的bin log。

2）從Kafka到Hive同步使用Camus，但是由于Camus的性能問題及消費(fèi)記錄和消費(fèi)過期較難監(jiān)控的問題，我們基于spark-sql-kafka開發(fā)了hamal，用于新建的Kafka到Hive的同步；Kafka實(shí)時(shí)同步的載體主要是ElasticSearch或者CrateDB，主要通過Flink實(shí)施。

生產(chǎn)數(shù)據(jù)被同步數(shù)據(jù)倉庫后，會(huì)在數(shù)倉內(nèi)完成數(shù)據(jù)清洗、信息整合、聚合計(jì)算等數(shù)據(jù)扭轉(zhuǎn)流程，最終數(shù)據(jù)出倉導(dǎo)入到其它載體，這一系列的流程調(diào)度由公司DP團(tuán)隊(duì)運(yùn)維的調(diào)度平臺(tái)Zeus完成。

圖2 攜程機(jī)票數(shù)倉技術(shù)棧

當(dāng)前機(jī)票部門的數(shù)據(jù)倉庫建設(shè)主要基于離線數(shù)據(jù)，一方面跟OTA銷售產(chǎn)品不屬于快消品相關(guān)，實(shí)時(shí)當(dāng)前并不是剛需；另一方面實(shí)時(shí)處理場(chǎng)景下需要對(duì)計(jì)算資源、存儲(chǔ)資源穩(wěn)定性有更高的要求，保持?jǐn)?shù)據(jù)一致性的代價(jià)很大。結(jié)合兩方面，如果業(yè)務(wù)對(duì)實(shí)時(shí)需求不高就鋪開做實(shí)時(shí)數(shù)倉，ROI很難達(dá)標(biāo)。

當(dāng)然，隨著攜程業(yè)務(wù)體量的增長，數(shù)據(jù)使用方對(duì)數(shù)據(jù)實(shí)時(shí)性要求日益增高，我們團(tuán)隊(duì)在2020年也會(huì)探索實(shí)時(shí)數(shù)據(jù)倉庫的實(shí)施方案，并在一兩個(gè)重要的數(shù)據(jù)主題域上先行試點(diǎn)。

從團(tuán)隊(duì)職能上來講，數(shù)據(jù)倉庫團(tuán)隊(duì)需要負(fù)責(zé)從生產(chǎn)環(huán)境同步數(shù)據(jù)，在內(nèi)部完成各層級(jí)的扭轉(zhuǎn)計(jì)算，參與所有數(shù)倉流程及報(bào)表的運(yùn)維，并基于數(shù)倉公共數(shù)據(jù)層和應(yīng)用數(shù)據(jù)層數(shù)據(jù)開發(fā)相關(guān)應(yīng)用。

為了保持?jǐn)?shù)倉數(shù)據(jù)主題覆蓋足夠全面，我們部門幾乎將所有生產(chǎn)表和Kafka topics都同步到了Hive。以下會(huì)對(duì)同步最常見的兩種場(chǎng)景DB->Hive和Kafka->Hive相關(guān)的實(shí)踐做介紹。

3.1.1 DB同步到Hive

特別對(duì)生產(chǎn)表到Hive的同步，人工配置腳本的方式顯然不能處理數(shù)以萬計(jì)的表，因此需要一個(gè)自動(dòng)化的同步方案。自動(dòng)同步方案需要不僅僅要解決自動(dòng)創(chuàng)建表腳本、創(chuàng)建對(duì)應(yīng)的同步腳本問題，還需要在當(dāng)表結(jié)構(gòu)發(fā)生變更的時(shí)候，能夠自動(dòng)地感知表結(jié)構(gòu)的變化，并且修改表結(jié)構(gòu)和對(duì)應(yīng)的同步腳本。

DB到Hive同步需要依賴兩個(gè)數(shù)據(jù)源，1）Schema表的元數(shù)據(jù)信息，簡單地包括各個(gè)字段信息、字段類型及主鍵定義；2）統(tǒng)計(jì)數(shù)據(jù)，它主要描述的是這個(gè)表在數(shù)據(jù)產(chǎn)生后有沒有UPDATE和DELETE，這個(gè)決定著后續(xù)表的分區(qū)方式。

對(duì)業(yè)務(wù)型數(shù)據(jù)，一條數(shù)據(jù)生成后可能會(huì)有Update，因?yàn)樵跀?shù)倉里絕大部分場(chǎng)景需要用到數(shù)據(jù)的最新狀態(tài)，所以我們會(huì)用一個(gè)分區(qū)存放所有歷史數(shù)據(jù)的最新狀態(tài)，這類表我們稱之為歷史切片表。對(duì)日志型數(shù)據(jù)，生產(chǎn)上數(shù)據(jù)產(chǎn)生后就不會(huì)有任何修改，我們會(huì)選擇使用增量分區(qū)，每個(gè)分區(qū)會(huì)放當(dāng)天的增量數(shù)據(jù)。對(duì)基礎(chǔ)數(shù)據(jù)，整個(gè)表的數(shù)據(jù)增加、更新的頻率都非常低，在ods層我們會(huì)每天全量同步一份到最新數(shù)據(jù)分區(qū)，并且會(huì)建立一個(gè)無分區(qū)的下游維表，將數(shù)據(jù)狀態(tài)為有效的數(shù)據(jù)放到這張下游無分區(qū)維表中方便流程使用。

有了上述這兩個(gè)數(shù)據(jù)源以后，我們會(huì)根據(jù)DBA Schema服務(wù)返回的元數(shù)據(jù)信息生成Hive表的腳本，并調(diào)度執(zhí)行生成新的Hive表，再依據(jù)統(tǒng)計(jì)數(shù)據(jù)決定表的分區(qū)方式，進(jìn)而生成對(duì)應(yīng)新建表的同步腳本。當(dāng)表創(chuàng)建或者表結(jié)構(gòu)發(fā)生變更的時(shí)候，通過Schema服務(wù)兩天輸出的比對(duì)，我們會(huì)發(fā)現(xiàn)表結(jié)構(gòu)的變更并映射到對(duì)應(yīng)Hive表結(jié)構(gòu)變更，同時(shí)可以改變對(duì)應(yīng)的同步腳本。還有一種思路是可以通過DB發(fā)布系統(tǒng)的日志，獲知每天DB創(chuàng)建、表創(chuàng)建以及表結(jié)構(gòu)變化的增量。

圖3 生產(chǎn)DB到Hive的同步

有一個(gè)坑點(diǎn)就是生產(chǎn)物理刪除，如果出現(xiàn)了物理刪除并且需要在Hive表里將刪除數(shù)據(jù)識(shí)別并標(biāo)記出來，當(dāng)前可能需要通過全量同步的方法（考慮到從生產(chǎn)環(huán)境取數(shù)的代價(jià)，全量同步業(yè)務(wù)主鍵字段即可）解決，特別對(duì)SQLServer。因此可以跟生產(chǎn)的開發(fā)協(xié)商盡量使用邏輯刪除，這樣數(shù)倉對(duì)刪除數(shù)據(jù)的感知代價(jià)會(huì)小很多。

3.1.2 Kafka同步到Hive

當(dāng)前我們非實(shí)時(shí)同步主要在使用Linkedin很久以前的一個(gè)工具Camus，當(dāng)然DP團(tuán)隊(duì)經(jīng)過優(yōu)化和企業(yè)本地化二次開發(fā)。但從使用感受來看，Camus會(huì)有如下可能不足的地方：

1）基于mapreduce，mapreduce在yarn集群上搶占資源的能力較弱，在資源競(jìng)爭(zhēng)高峰會(huì)有同步變慢的情況發(fā)生；

2）消費(fèi)記錄存儲(chǔ)在HDFS各個(gè)文件里，這樣對(duì)消費(fèi)記錄的獲取和針對(duì)消費(fèi)過期的監(jiān)控都很不方便；

3）Kafka Topic和Hive表的血緣關(guān)系獲取不方便；

因此，我們基于spark-sql-kafka開發(fā)hamal，旨在解決如上痛點(diǎn)并且讓配置更加的簡潔。實(shí)現(xiàn)的過程大概包括，spark-sql-kafka會(huì)根據(jù)輸入的任務(wù)從Kafka各個(gè)Partition消費(fèi)出payload數(shù)據(jù)，對(duì)每條payload執(zhí)行解編碼、解壓、magic code等操作，此時(shí)會(huì)將payload數(shù)據(jù)轉(zhuǎn)化成json字符串，這個(gè)json字符串可以直接作為一個(gè)字段寫入到Hive表里，也可以根據(jù)事先配置提取出對(duì)應(yīng)的節(jié)點(diǎn)和值作為列和列值寫入到Hive中，甚至可以通過Json的Schema推斷出Hive表結(jié)構(gòu)，并將Json各節(jié)點(diǎn)對(duì)應(yīng)寫到Hive表的各列中。

圖4 轉(zhuǎn)化為json字符串RDD代碼示例

如果選擇推斷的模式，實(shí)現(xiàn)的時(shí)候可以使用sampling的方式，類似spark jsonRDD第二個(gè)參數(shù)，比如說0.001，Hamal可以直接指定采樣數(shù)據(jù)條數(shù)，從Kafka topic中拉取出來，通過jsonRDD推斷出StructType，并映射成Hive建表語句。對(duì)于建好的表，通過表的字段匹配獲取數(shù)據(jù)，最終寫入Hive表，最后會(huì)提交消費(fèi)記錄到一張Hive的ConsumerRecord表里面。這樣其實(shí)基于這個(gè)表，我們既可以獲取Kafka topic和Hive表的血緣，也可以方便地監(jiān)控每次同步的數(shù)據(jù)量。

圖5 Kafka同步至Hive Hamal設(shè)計(jì)

分層設(shè)計(jì)主要參考公司推行的數(shù)據(jù)規(guī)范，將數(shù)據(jù)倉庫的流程分成了生產(chǎn)鏡像層(ods)、中間層(edw)、公共數(shù)據(jù)層(cdm)及應(yīng)用數(shù)據(jù)層(adm)。在中間層對(duì)ods表做異常數(shù)據(jù)剔除、NULL值處理、枚舉值統(tǒng)一等數(shù)據(jù)清理和綁定維表信息工作，在公共數(shù)據(jù)層對(duì)中間層表進(jìn)行進(jìn)一步的整合，豐富表主題的維度和度量，一般以寬表的形式呈現(xiàn)，用以后續(xù)的adhoc取數(shù)、報(bào)表。

根據(jù)機(jī)票本身的業(yè)務(wù)特點(diǎn)，我們將數(shù)據(jù)劃分成流量、產(chǎn)量、收益、生產(chǎn)KPI、業(yè)務(wù)考核等幾大主題域，對(duì)數(shù)據(jù)表的業(yè)務(wù)分類和有效管理有重要意義。

圖6 數(shù)倉分層設(shè)計(jì)

數(shù)據(jù)在同步至數(shù)據(jù)ods層后，產(chǎn)品經(jīng)常會(huì)提的一個(gè)需求是將ods層某個(gè)含報(bào)文字段的表按照字段設(shè)計(jì)展開，如果要支持此類需求，數(shù)據(jù)開發(fā)就需要了解生產(chǎn)上這個(gè)表各個(gè)字段含義及報(bào)文字段的契約定義，而這些對(duì)應(yīng)表的寫入開發(fā)非常熟悉。因此，為了提高整體的工作效率，我們開發(fā)了一套數(shù)據(jù)解析框架，對(duì)業(yè)務(wù)開發(fā)封裝了大數(shù)據(jù)組件的API調(diào)用及相關(guān)參數(shù)調(diào)整，讓業(yè)務(wù)開發(fā)更高效地完成熟悉的單條數(shù)據(jù)解析開發(fā)。

圖7 數(shù)據(jù)解析框架

數(shù)據(jù)倉庫擁有所有生產(chǎn)表的鏡像表、數(shù)以萬計(jì)的生產(chǎn)數(shù)據(jù)同步流程、數(shù)據(jù)扭轉(zhuǎn)流程以及后續(xù)報(bào)表，對(duì)如此規(guī)模的數(shù)倉實(shí)體的管理和運(yùn)維需要一個(gè)不斷迭代的系統(tǒng)支持，從而可以大幅度提高數(shù)據(jù)工程師的效率。

我們根據(jù)數(shù)倉建設(shè)中遇到的一些費(fèi)力度較高且需要重復(fù)做的操作，開發(fā)了一套運(yùn)維工具集合，目前還在持續(xù)迭代中。運(yùn)維工具集功能主要包括數(shù)據(jù)實(shí)體通用搜索，報(bào)表收件人批量變更，維表導(dǎo)入，Oncall錄入，腳本模板生成，序列化與反序列化等等。工具開發(fā)難度不大，但對(duì)提高效率的幫助很大。

對(duì)龐大的數(shù)據(jù)倉庫實(shí)體建設(shè)完善的數(shù)據(jù)質(zhì)量監(jiān)控體系，光靠人工one by one設(shè)置檢驗(yàn)規(guī)則是不夠的，需要對(duì)幾乎所有的實(shí)體建立相應(yīng)的監(jiān)控，并且不能給大數(shù)據(jù)集群帶來很多額外的計(jì)算代價(jià)。當(dāng)這樣的覆蓋面很廣的監(jiān)控完善后，配合著元數(shù)據(jù)信息，就有可能在故障的Root Cause點(diǎn)第一時(shí)間發(fā)現(xiàn)故障，并可以清晰地知曉故障的影響范圍以及故障恢復(fù)的流程優(yōu)先級(jí)調(diào)度。

因此，建立完善的數(shù)據(jù)質(zhì)量體系需要完善元數(shù)據(jù)管理，建立輕量的覆蓋面廣的質(zhì)量監(jiān)控，并且對(duì)特別重要的流程，需要增加額外的業(yè)務(wù)相關(guān)校驗(yàn)。

在生產(chǎn)環(huán)境和大數(shù)據(jù)環(huán)境存在多種實(shí)體，這些實(shí)體包括應(yīng)用、各類表(如SQLServer、MySQL、MongoDB的表等)、消息隊(duì)列topic、ElasticSearch的index、Hive的表等等，這些實(shí)體相互關(guān)聯(lián)，共同支撐著線上的系統(tǒng)，線下的分析。對(duì)這些信息的治理，實(shí)體的元數(shù)據(jù)管理至關(guān)重要。

在數(shù)倉體系中，元數(shù)據(jù)主要包含基礎(chǔ)信息、血緣關(guān)系以及標(biāo)簽?；A(chǔ)信息跟數(shù)據(jù)表相關(guān)，具體包括表的字段、存儲(chǔ)、分區(qū)類型等；血緣會(huì)涉及到各類的實(shí)體，表、流程、報(bào)表、郵件推送等，這些實(shí)體之間存在著上下游調(diào)用與被調(diào)用關(guān)系，成體系地管理好這些實(shí)體之間的關(guān)系，可以清晰地了解到數(shù)倉邊界，使得對(duì)故障的Root Cause追溯以及該Root Cause帶來的影響面評(píng)估非常便捷。標(biāo)簽是對(duì)實(shí)體的分類描述，如層級(jí)是屬于哪一層，安全是否有涉密，重要等級(jí)，是否有非常重要的流程在上面，業(yè)務(wù)標(biāo)簽是屬于訂單、前端還是訂后。

數(shù)據(jù)質(zhì)量的問題其實(shí)一般可以在流程執(zhí)行的日志中看出端倪，因?yàn)槿斯づ挪楣收系臅r(shí)候，除了常規(guī)通過SQL查詢驗(yàn)證表的增量、業(yè)務(wù)主鍵、某些字段值是否正常，另外一個(gè)有效手段就是分析運(yùn)行日志。

從運(yùn)行日志中可以獲取以下信息，流程的開始時(shí)間、截止時(shí)間流程執(zhí)行時(shí)間、完成狀態(tài)、每天增量的字節(jié)數(shù)、增量條數(shù)，引擎執(zhí)行的參數(shù)，在用Spark或者M(jìn)apReduce執(zhí)行時(shí)消耗資源的情況等等一系列特征。通過對(duì)各類計(jì)算引擎產(chǎn)生日志的分析，可以獲得各類引擎下記錄日志數(shù)據(jù)的pattern，從而提取出相關(guān)的特征信息。遇到特殊的流程或者引擎，可以借用其他手段補(bǔ)齊特征數(shù)據(jù)，如用SQL，用Hadoop的命令。

圖8 數(shù)據(jù)質(zhì)量相關(guān)特征

這是我們簡單的一個(gè)日志輸出，第一張是Spark的執(zhí)行日志，下面一張是MapReduce的執(zhí)行日志。

圖9 MR和Spark引擎執(zhí)行日志示例

有了數(shù)據(jù)質(zhì)量特征提取的邏輯，實(shí)時(shí)流程異常發(fā)現(xiàn)可以如下實(shí)施：我們可以將質(zhì)量特征數(shù)據(jù)計(jì)算分成兩塊，一塊是實(shí)時(shí)的針對(duì)單個(gè)流程日志的解析出相關(guān)特征，一塊是離線的基于歷史特征數(shù)據(jù)的統(tǒng)計(jì)。我們從消息隊(duì)列中消費(fèi)實(shí)時(shí)獲取執(zhí)行完成的流程id和actionid，通過運(yùn)維團(tuán)隊(duì)提供的詳情日志查詢接口獲取完整日志，通過特征解析邏輯，解析出實(shí)時(shí)的流程質(zhì)量相關(guān)特征，匹配歷史數(shù)據(jù)，應(yīng)用規(guī)則。當(dāng)滿足異常規(guī)則，可以通過元數(shù)據(jù)信息中的血緣判斷影響的范圍，推送告警信息。

圖10 實(shí)時(shí)流程異常監(jiān)控實(shí)施方案

攜程作為平臺(tái)方，對(duì)機(jī)票價(jià)格沒有定價(jià)權(quán)，價(jià)格由產(chǎn)品提供方來提供。在每年航班計(jì)劃換季的時(shí)候，產(chǎn)品提供方會(huì)有一小部分概率將價(jià)格錄入錯(cuò)。錯(cuò)誤的運(yùn)價(jià)，特別是很低的錯(cuò)誤運(yùn)價(jià)會(huì)讓航司或供應(yīng)商蒙受超大的損失。本著公平交易的原則，攜程作為銷售平臺(tái)，做了機(jī)票價(jià)格監(jiān)控系統(tǒng)。上線至今，發(fā)現(xiàn)了數(shù)十起價(jià)格異常事件。

在生產(chǎn)的消息隊(duì)列中，我們落地了用戶查詢返回的所有航班組合和價(jià)格信息，數(shù)據(jù)倉庫完成近實(shí)時(shí)同步，將數(shù)據(jù)解析處理成異常價(jià)格相關(guān)特征集，每天的增量在百億級(jí)別。我們從Kafka實(shí)時(shí)消費(fèi)兩類日志數(shù)據(jù)，一類是查詢?nèi)罩?，一類是下單日志，建立匹配，建立?guī)則集發(fā)現(xiàn)可疑的低價(jià)交易標(biāo)識(shí)，并且進(jìn)一步監(jiān)控跟交易標(biāo)識(shí)是否進(jìn)入下單流程。當(dāng)某個(gè)疑似異常特征帶來的訂單超過一定閾值時(shí)，系統(tǒng)會(huì)對(duì)這疑似異常特征對(duì)應(yīng)的查詢進(jìn)行自動(dòng)禁售。

圖11 價(jià)格監(jiān)控系統(tǒng)

一套完整的數(shù)據(jù)倉庫實(shí)施方案應(yīng)該包括但不局限于上面介紹的數(shù)據(jù)同步方案、數(shù)據(jù)存儲(chǔ)方案、數(shù)據(jù)規(guī)范、元數(shù)據(jù)建設(shè)、數(shù)據(jù)質(zhì)量體系、運(yùn)維工具等，每個(gè)實(shí)施團(tuán)隊(duì)?wèi)?yīng)該根據(jù)面臨的實(shí)際情況選擇針對(duì)每個(gè)點(diǎn)的具體技術(shù)方案。

攜程機(jī)票數(shù)據(jù)倉庫團(tuán)隊(duì)也正朝著建設(shè)全面、規(guī)范、易用、高效、精準(zhǔn)的數(shù)倉路上探索前行，當(dāng)前在數(shù)據(jù)同步、數(shù)倉數(shù)據(jù)扭轉(zhuǎn)以及出倉應(yīng)用方面的實(shí)踐方案還在隨著需求的變化而迭代。接下來，我們團(tuán)隊(duì)會(huì)著重在數(shù)據(jù)倉庫規(guī)范徹底落地以及實(shí)時(shí)數(shù)倉實(shí)施這些方向上努力。