一、背景

大數(shù)據(jù)挑戰(zhàn)

大數(shù)據(jù)時(shí)代，餓了么面臨數(shù)據(jù)管理、數(shù)據(jù)使用、數(shù)據(jù)問(wèn)題等多重挑戰(zhàn)。具體可以參考下圖：

 

 

數(shù)據(jù)問(wèn)題：多種執(zhí)行、存儲(chǔ)引擎，分鐘、小時(shí)、天級(jí)的任務(wù)調(diào)度，怎樣梳理數(shù)據(jù)的時(shí)間線變化?

數(shù)據(jù)使用：任務(wù)、表、列、指標(biāo)等數(shù)據(jù)，如何進(jìn)行檢索、復(fù)用、清理、熱度Top計(jì)算?

數(shù)據(jù)管理：怎樣對(duì)表、列、指標(biāo)等進(jìn)行權(quán)限控制、任務(wù)治理以及上下游依賴影響分析?

元數(shù)據(jù)定義與價(jià)值

元數(shù)據(jù)打通數(shù)據(jù)源、數(shù)據(jù)倉(cāng)庫(kù)、數(shù)據(jù)應(yīng)用，記錄了數(shù)據(jù)從產(chǎn)生到消費(fèi)的完整鏈路。它包含靜態(tài)的表、列、分區(qū)信息(也就是MetaStore);動(dòng)態(tài)的任務(wù)、表依賴映射關(guān)系;數(shù)據(jù)倉(cāng)庫(kù)的模型定義、數(shù)據(jù)生命周期;以及ETL任務(wù)調(diào)度信息、輸入輸出等。

元數(shù)據(jù)是數(shù)據(jù)管理、數(shù)據(jù)內(nèi)容、數(shù)據(jù)應(yīng)用的基礎(chǔ)。例如可以利用元數(shù)據(jù)構(gòu)建任務(wù)、表、列、用戶之間的數(shù)據(jù)圖譜;構(gòu)建任務(wù)DAG依賴關(guān)系，編排任務(wù)執(zhí)行序列;構(gòu)建任務(wù)畫(huà)像，進(jìn)行任務(wù)質(zhì)量治理;數(shù)據(jù)分析時(shí)，使用數(shù)據(jù)圖譜進(jìn)行字典檢索;根據(jù)表名查看表詳情，以及每張表的來(lái)源、去向，每個(gè)字段的加工邏輯;提供個(gè)人或BU的資產(chǎn)管理、計(jì)算資源消耗概覽等。

開(kāi)源解決方案

 

 

WhereHows是LinkedIn開(kāi)源的元數(shù)據(jù)治理方案。Azkaban調(diào)度器抓取job執(zhí)行日志，也就是Hadoop的JobHistory，Log Parser后保存DB，并提供REST查詢。WhereHows太重，需要部署Azkaban等調(diào)度器，以及只支持表血緣，功能局限。

 

 

Atlas是Apache開(kāi)源的元數(shù)據(jù)治理方案。Hook執(zhí)行中采集數(shù)據(jù)(比如HiveHook)，發(fā)送Kafka，消費(fèi)Kafka數(shù)據(jù)，生成Relation關(guān)系保存圖數(shù)據(jù)庫(kù)Titan，并提供REST接口查詢功能，支持表血緣，列級(jí)支持不完善。

二、餓了么元數(shù)據(jù)系統(tǒng)架構(gòu)

 

 

DB保存任務(wù)的SQL數(shù)據(jù)、任務(wù)基礎(chǔ)信息、執(zhí)行引擎上下文信息;

Extract循環(huán)抽取SQL并解析成表、列級(jí)血緣Lineage;

DataSet包含Lineage關(guān)系數(shù)據(jù)+任務(wù)信息+引擎上下文;

將DataSet數(shù)據(jù)集保存到Neo4j，并提供關(guān)系查詢;保存ES，提供表、字段等信息檢索。

SQL埋點(diǎn)與采集

 

 

餓了么的SQL數(shù)據(jù)，以執(zhí)行中采集為主+保存前submit為輔。因?yàn)槿蝿?wù)的SQL可能包含一些時(shí)間變量，比如dt、hour，以及任務(wù)可能是天調(diào)度、小時(shí)調(diào)度。執(zhí)行中采集SQL實(shí)時(shí)性更高，也更容易處理。

EDW是餓了么的調(diào)度系統(tǒng)，類比開(kāi)源的AirFlow。調(diào)度系統(tǒng)執(zhí)行任務(wù)，并將任務(wù)相關(guān)的信息，比如appId、jobId、owner、SQL等信息存入DB。

計(jì)算引擎實(shí)現(xiàn)相關(guān)的監(jiān)聽(tīng)接口，比如Hive實(shí)現(xiàn)Execute With Hook Context接口;Spark實(shí)現(xiàn)Spark Listener接口;Presto實(shí)現(xiàn)Event Listener接口。將計(jì)算引擎相關(guān)的上下文Context、元數(shù)據(jù)MetaData、統(tǒng)計(jì)Statistics等信息存入DB。

SQL解析

解析SQL的方案，以Hive為例。先定義詞法規(guī)則和語(yǔ)法規(guī)則文件，然后使用Antlr實(shí)現(xiàn)SQL的詞法和語(yǔ)法解析，生成AST語(yǔ)法樹(shù)，遍歷AST語(yǔ)法樹(shù)完成后續(xù)操作。

但對(duì)于SELECT *、CTAS等操作，直接遍歷AST，不去獲取Schema信息來(lái)檢查表名、列名，就無(wú)法判定SQL的正確性，導(dǎo)致數(shù)據(jù)污染。

綜上所述，餓了么的SQL解析方案，直接參考Hive的底層源碼實(shí)現(xiàn)。

 

 

以本土做簡(jiǎn)單示例，先經(jīng)過(guò)Semantic Analyzer Factory類進(jìn)行語(yǔ)法分析，再根據(jù)Schema生成執(zhí)行計(jì)劃QueryPlan。關(guān)于表、列的血緣，可以從LineageInfo、LineageLogger類中獲得解決方案。

當(dāng)然，你需要針對(duì)部分類型SQL設(shè)置Hive Conf，比如“開(kāi)啟動(dòng)態(tài)分區(qū)非嚴(yán)格模式”。對(duì)于CTAS類型，需要設(shè)置Context。UDF函數(shù)需要修改部分Hive源碼，避免UDF Registry檢查。

 

 

餓了么解析血緣的SQL支持的操作有：Query(包含selectinsert intoinsert overwrite)、CreateTable、CreateTableAsSelect、DropTable、CreateView、AlterView�；�本覆蓋餓了么生產(chǎn)環(huán)境99%+的SQL語(yǔ)法。

舉個(gè)栗子

 

 

舉個(gè)栗子，根據(jù)上面的SQL，分別產(chǎn)生表、列血緣結(jié)構(gòu)。

input是表、列輸入值;output是表、列輸出值;operation代表操作類型。比如表A+B通過(guò)insert，生成表C，則延展成A insert C; B insert C。

列式也一樣：

input：name,
operation: coalesce(name, count(id)),
output: lineage_name;

input: id,
operation: coalesce(name, count(id)),
output：lineage_name

 

表血緣結(jié)構(gòu)

 

 

列血緣結(jié)構(gòu)

 

 

圖存儲(chǔ)

 

 

有了input、operation、output關(guān)系，將input、output保存為圖節(jié)點(diǎn)，operation保存為圖邊。圖數(shù)據(jù)庫(kù)選用Gremlin+Neo4j。

Gremlin是圖語(yǔ)言，存儲(chǔ)實(shí)現(xiàn)方案比較多，Cypher查詢不太直觀，且只能Neo4j使用。社區(qū)版Neo4j只能單機(jī)跑，我們正在測(cè)試OrientDB。

三、餓了么部分使用場(chǎng)景

下面是餓了么在元數(shù)據(jù)應(yīng)用上的部分場(chǎng)景：

 

 

靜態(tài)的Hive MetaStore表，比如DBS、TBLS、SDS、COLUMNS_V2、TABLE_PARAMS、PARTITIONS，保存表、字段、分區(qū)、Owner等基礎(chǔ)信息，便于表、字段的信息檢索功能。

 

 

提供動(dòng)態(tài)的表依賴血緣關(guān)系查詢。節(jié)點(diǎn)是表基礎(chǔ)信息，節(jié)點(diǎn)之間的邊是Operation信息，同時(shí)附加任務(wù)執(zhí)行Id、執(zhí)行時(shí)間等屬性。列血緣結(jié)構(gòu)展示等同表血緣結(jié)構(gòu)。

 

 

根據(jù)SQL的input、output構(gòu)建表的依賴關(guān)系，進(jìn)一步構(gòu)建任務(wù)的DAG依賴結(jié)構(gòu)�？梢詫�(duì)任務(wù)進(jìn)行DAG調(diào)度，重新編排任務(wù)執(zhí)行序列。

Q & A

Q1：咱們的數(shù)據(jù)生命周期是如何管理的，能具體說(shuō)下嗎?

A：表級(jí)數(shù)據(jù)進(jìn)行熱度分析，比如近三個(gè)月沒(méi)人訪問(wèn)，是否可以下線，特別是一些臨時(shí)表 需要定時(shí)清理。

Q2：質(zhì)量監(jiān)控會(huì)影響到任務(wù)調(diào)度編排么?

A：會(huì)影響質(zhì)量編排，構(gòu)建DAG依賴執(zhí)行。

Q3：把從SQL中的埋點(diǎn)數(shù)據(jù)存儲(chǔ)到MySQL中，是如何規(guī)劃的?這些埋點(diǎn)信息不應(yīng)該像是日志數(shù)據(jù)一樣被處理嗎?存儲(chǔ)在MySQL中是有自增全局ID的么?還是說(shuō)你們是對(duì)任務(wù)和表分別有MySQL表，然后更新MySQL表中任務(wù)和表甚至列的信息么?這里的MySQL表就是您說(shuō)的DataSet么?

A：任務(wù)jobid進(jìn)行唯一，MySQL只保存執(zhí)行的SQL，以及任務(wù)本身的信息，比如owner time jobid等等。

Q4：當(dāng)前的支持非SQL形式生成表么?比如直接用Spark RDD任務(wù)或者Spark MLlib任務(wù)取表和生成表?

A：只支持SQL表達(dá)。

Q5：你們是怎么做熱度分析的?剛才的講解里，這個(gè)點(diǎn)講得比較少。

A：任務(wù)操作的SQL產(chǎn)生input output表，對(duì)表進(jìn)行counter就能top counter，列也一樣。

Q6：你們管理的表分線上表和線下表么?在處理的時(shí)候用到了一些臨時(shí)表該怎么處理?

A：對(duì)的，線上還是線下，任務(wù)調(diào)度系統(tǒng)埋點(diǎn)，臨時(shí)表根據(jù)temp就知道了。

Q7：數(shù)據(jù)血緣關(guān)系如果使用Hive hook方式獲取，是需要在每個(gè)執(zhí)行節(jié)點(diǎn)中做捕捉嗎?

A：Hive hook就是執(zhí)行時(shí)調(diào)用，可以去了解下底層。

Q8：解析那種復(fù)雜度很高的HQL的血緣，你們平臺(tái)的解析思路是什么樣子的?如何保證正確率呢?

A：會(huì)有很多復(fù)雜的ppt有代碼示例，會(huì)有部分SQL需要修改Hive解析實(shí)現(xiàn)。

Q9：表血緣圖里面的上下級(jí)關(guān)系就是數(shù)據(jù)的流向?從上到下?字段的血緣是什么樣子的跟表的血緣有什么不同?有字段的血緣圖嗎?

A：ppt里解析那里可以看到，字段也一樣，input output列然后operation

Q10：SQL埋點(diǎn)，引擎埋點(diǎn)，是要去重寫(xiě)Hive等的源碼嗎?

A：重寫(xiě)倒不至于，只要實(shí)現(xiàn)ppt里的接口，很簡(jiǎn)單。

標(biāo)簽： Mysql 大數(shù)據(jù) 大數(shù)據(jù)時(shí)代 代碼 權(quán)限 數(shù)據(jù)分析 數(shù)據(jù)庫(kù)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。