色偷偷噜噜噜亚洲男人,国模冰莲自慰肥美胞极品人体图,日韩国产精品无码一区二区三区

文件分類器：由于文件在OSS上面是按照目錄存儲(chǔ)的，當(dāng)通過(guò)Schema識(shí)別器識(shí)別出了葉子節(jié)點(diǎn)目錄下面的Schema情況后，如果每個(gè)葉子節(jié)點(diǎn)目錄創(chuàng)建一張表，表會(huì)很多，管理復(fù)雜且難以分析。因此需要有一套文件分類器來(lái)聚合生成最終的表。且支持增量文件的Schema變更，比如添加字段、添加分區(qū)等。下面是整個(gè)分類算法過(guò)程，根據(jù)目錄樹形的結(jié)構(gòu)，第一步先深度遍歷并結(jié)合“文件Schema識(shí)別器”在每個(gè)節(jié)點(diǎn)聚合子節(jié)點(diǎn)的Schema是否兼容，如果兼容則把子目錄向上合并為分區(qū)，如果不兼容則每個(gè)子目錄創(chuàng)建一張表。經(jīng)過(guò)第一步后每個(gè)節(jié)點(diǎn)是否可以創(chuàng)建表、分區(qū)信息，以及合并后的Schema都會(huì)存儲(chǔ)在節(jié)點(diǎn)上面；第二步再次遍歷可以生成對(duì)應(yīng)的Meta創(chuàng)建事件。

這種通用的算法可以識(shí)別任意目錄擺放，但是由于面向海量分區(qū)的場(chǎng)景，事先不知道分區(qū)目錄是否可以聚合，這樣每個(gè)目錄都需要采樣識(shí)別，且在聚合時(shí)如果某個(gè)分區(qū)和其他分區(qū)兼容度達(dá)不到要求，會(huì)拆分生成大量的表，在這種場(chǎng)景下性能一般。如果用戶的OSS目錄結(jié)構(gòu)按照典型的數(shù)倉(cāng)結(jié)構(gòu)，庫(kù)、表、分區(qū)模式規(guī)劃，那么在分區(qū)識(shí)別及表識(shí)別上面會(huì)有固定的規(guī)則，這樣可以對(duì)上面的算法遍歷過(guò)程剪枝，分區(qū)間的采樣率進(jìn)一步減少，且容錯(cuò)率更高。數(shù)倉(cāng)模式的目錄規(guī)劃需要如下：

3、海量分區(qū)處理技術(shù)
分區(qū)投影
在大數(shù)據(jù)場(chǎng)景中，分區(qū)是用于提升性能非常常見的方法，合理劃分分區(qū)有利于計(jì)算引擎過(guò)濾掉大量無(wú)用的數(shù)據(jù)從而提升計(jì)算性能。但是如果分區(qū)非常多，比如單表數(shù)百萬(wàn)的分區(qū)，那么計(jì)算引擎從元數(shù)據(jù)服務(wù)查詢分區(qū)所需要的時(shí)間就會(huì)上升，從而使得查詢的整體時(shí)間變長(zhǎng) 。比如我們客戶有張表有130多萬(wàn)分區(qū)，一個(gè)簡(jiǎn)單的分區(qū)過(guò)濾查詢?cè)獢?shù)據(jù)訪問(wèn)這塊就花了4秒以上的時(shí)間，而剩下的計(jì)算時(shí)間卻不到1秒！
針對(duì)這個(gè)問(wèn)題，我們?cè)O(shè)計(jì)開發(fā)出了一種叫做“分區(qū)映射”的功能，分區(qū)映射讓用戶指定分區(qū)的規(guī)則，然后具體每個(gè)SQL查詢的分區(qū)會(huì)直接通過(guò)SQL語(yǔ)句中的查詢條件結(jié)合用戶創(chuàng)建表時(shí)候指定的規(guī)則直接在計(jì)算引擎中計(jì)算出來(lái)，從而不用去查詢外部的元數(shù)據(jù)，避免元數(shù)據(jù)爆炸帶來(lái)的性能問(wèn)題。經(jīng)測(cè)試，上述場(chǎng)景下，利用分區(qū)投影生成分區(qū)需要的時(shí)間降為1秒以下，大大提升查詢效率。

基于OSS的Metatable技術(shù)
可以看到DLA的分區(qū)投影技術(shù)降低了海量分區(qū)情況下，訪問(wèn)Meta服務(wù)的時(shí)間開銷，該技術(shù)通過(guò)計(jì)算側(cè)計(jì)算分區(qū)的方法來(lái)規(guī)避掉海量分區(qū)的訪問(wèn) 。DLA目前基于Apache Hudi實(shí)現(xiàn)DLA Lakehouse，提供高效的湖倉(cāng) 。其中在海量分區(qū)處理這塊，Apache Hudi將表的海量分區(qū)映射信息存儲(chǔ)在一個(gè)OSS上面的Object里面，這樣通過(guò)讀取若干個(gè)Object文件可以獲取所有的分區(qū)信息，規(guī)避訪問(wèn)Meta服務(wù)的開銷。下面介紹DLA Lakehouse基于Hudi的Metatable技術(shù)：

從上圖可以看到DLA Meta中會(huì)存儲(chǔ)庫(kù)、表、分區(qū)的信息，使用當(dāng)前方案OSS上面分區(qū)目錄對(duì)應(yīng)的分區(qū)信息會(huì)存儲(chǔ)在DLA Meta服務(wù)中，當(dāng)分析引擎訪問(wèn)這張表的時(shí)候，會(huì)通過(guò)DLA Meta服務(wù)讀取大量的分區(qū)信息，這些分區(qū)信息會(huì)從底層的RDS中讀出，這樣會(huì)有一定的訪問(wèn)開銷。如果使用到DLA Lakehouse方案，可以將大量的分區(qū)映射信息單獨(dú)存儲(chǔ)在基于OSS對(duì)象的Hudi Metatable中，Metatable底層基于HFile支持更新刪除，通過(guò)KV存儲(chǔ)方式提高分區(qū)查詢效率。這樣分析引擎在訪問(wèn)分區(qū)表的時(shí)候，可以只在Meta中讀取庫(kù)、表輕量的信息，分區(qū)信息可以通過(guò)讀取OSS的對(duì)象獲取。目前該方案還在規(guī)劃中，DLA線上還不支持。