一、背景介紹

企業(yè)數(shù)據(jù)建設(shè)面臨兩大類問題：

• 第一類問題：聚焦于如何有效識別數(shù)據(jù)傳輸鏈路，特別是在各公司離線數(shù)倉規(guī)模持續(xù)擴(kuò)大的背景下。用戶常遇到以下挑戰(zhàn)：
  首先，針對多業(yè)務(wù)線場景，需要明確某一 Hive 表中包含哪些業(yè)務(wù)線的數(shù)據(jù)，以及某個業(yè)務(wù)線的數(shù)據(jù)具體存儲在哪些 Hive 表中。這要求企業(yè)具備標(biāo)簽識別能力，以清晰界定業(yè)務(wù)范圍。
  其次，隨著離線 ETL 鏈路的延伸，敏感數(shù)據(jù)的范圍也在不斷擴(kuò)大。因此，企業(yè)需要準(zhǔn)確標(biāo)注敏感數(shù)據(jù)的邊界，并實(shí)施精確的管控措施。
  再者，數(shù)據(jù)規(guī)模不斷增多，存儲成本也在持續(xù)攀升。企業(yè)需判斷哪些 Hive 表甚至 Hive 列適合進(jìn)行數(shù)據(jù)治理，以助力降本增效。
• 第二類問題聚焦于數(shù)據(jù)保護(hù)領(lǐng)域。隨著安全合規(guī)要求的日益嚴(yán)格，保障敏感數(shù)據(jù)的安全成為每個企業(yè)都必須應(yīng)對的挑戰(zhàn)。這主要包括兩方面：
  一方面，隨著 ETL 鏈路的擴(kuò)展，不同業(yè)務(wù)歸屬的數(shù)據(jù)可能最終匯聚到同一個 Hive 表或列中。這時，企業(yè)需要實(shí)施更細(xì)致的權(quán)限管控，確保下游使用數(shù)據(jù)時滿足權(quán)限最小化原則。
  另一方面，對于高度敏感的場景，企業(yè)需要對查詢結(jié)果進(jìn)行脫敏處理。在確保隱私數(shù)據(jù)安全合規(guī)的前提下，盡可能降低用戶的使用成本，使用戶能夠更便捷地利用這些數(shù)據(jù)。

基于血緣的數(shù)據(jù)發(fā)現(xiàn)&數(shù)據(jù)保護(hù)方案

針對上述問題，我們提出了一套依托 SQL 血緣能力的數(shù)據(jù)發(fā)現(xiàn)與數(shù)據(jù)保護(hù)解決方案。

針對第一類數(shù)據(jù)發(fā)現(xiàn)問題，首先利用表級和列級的血緣能力，構(gòu)建一個涵蓋所有 Hive 表的全局血緣關(guān)系圖。從全局血緣圖譜的業(yè)務(wù)起點(diǎn)出發(fā)，逐層分析各節(jié)點(diǎn)間的 SQL 語義，以此傳播標(biāo)簽信息。最終，憑借全局標(biāo)簽信息，我們能夠高效且精確地識別數(shù)據(jù)的使用情況和整體流動鏈路，進(jìn)而對數(shù)據(jù)實(shí)施精細(xì)化的運(yùn)營管理。

對于第二類數(shù)據(jù)保護(hù)場景，同樣依賴于表/列級別的血緣能力。通過深入分析 SQL 的構(gòu)成，確保在不影響計(jì)算語義的前提下，對計(jì)算結(jié)果進(jìn)行精準(zhǔn)脫敏，從而減輕對用戶側(cè)的干擾。在權(quán)限控制層面，憑借血緣能力實(shí)現(xiàn)更精細(xì)的權(quán)限提取，達(dá)到行列級別的權(quán)限管控，進(jìn)而完成權(quán)限最小化的操作。

二、血緣基礎(chǔ)能力介紹

1. 什么是 SQL 血緣

SQL 血緣是一種用于跟蹤和分析數(shù)據(jù)處理過程的技術(shù)，可以幫助我們清晰地了解數(shù)據(jù)是如何在計(jì)算鏈路中傳遞和演變的。

以上圖中的 SQL 為例，假設(shè)有三張表：table1包含 a1、a2、a3 三列，table2 包含 b1、b2、b3 三列，而 table3 則有 c1、c2 兩列?，F(xiàn)在，我們基于這三張表構(gòu)建了一個 SQL 查詢，其中 table1 作為子查詢 t1，table2 作為子查詢 t2，這兩個子查詢通過 join 操作連接，并將最終結(jié)果插入到 table3 中。

在這個查詢中可以看到，table3 的 c1 列的數(shù)據(jù)來源于 table1 的 a2 列，而 c2 列的數(shù)據(jù)則來源于 table2 的 b2 列。這種列的流動關(guān)系就構(gòu)成了右側(cè)所示的血緣關(guān)系圖。在這個關(guān)系圖譜中，三張表通過列的流轉(zhuǎn)相互關(guān)聯(lián)，清晰地展示了數(shù)據(jù)是如何在這些表之間流動的。

2. 如何實(shí)現(xiàn) SQL 血緣提取

接下來從技術(shù)角度闡述如何從 SQL 中提取血緣信息。

首要步驟是對 SQL 進(jìn)行解析和優(yōu)化，這一流程會生成一個樹狀的執(zhí)行計(jì)劃結(jié)構(gòu)。解析和優(yōu)化的流程可以參考上圖中右側(cè)部分。當(dāng)接收到用戶的 SQL 后，首先會進(jìn)入 Parser 階段，對 SQL 進(jìn)行詞法分析和語法分析，從而生成一棵抽象語法樹（SqlNode 結(jié)構(gòu)）。其次，進(jìn)入 validate 模塊，對語義正確性和元數(shù)據(jù)進(jìn)行校驗(yàn)。再次，基于新的抽象語法樹進(jìn)行 convert 和 optimize 操作，包括一些轉(zhuǎn)換和優(yōu)化步驟。經(jīng)過這些步驟后，我們就能得到一個最終的樹狀執(zhí)行計(jì)劃結(jié)構(gòu)，如上圖下方所示。

需要強(qiáng)調(diào)的是，在血緣追蹤的場景中，優(yōu)化步驟是很有必要的。因?yàn)閮?yōu)化階段會執(zhí)行諸如列裁剪、常量折疊等優(yōu)化規(guī)則，這些規(guī)則對于提高血緣提取的準(zhǔn)確率和正確率有著極大的幫助。

第一步：得到一個樹狀的執(zhí)行計(jì)劃，并基于執(zhí)行計(jì)劃去追蹤血緣。

第二步：取執(zhí)行計(jì)劃最外層每一列對應(yīng)的 Index 下標(biāo)信息，并使用這個 Index 下標(biāo)逐層的向下檢索。在離線數(shù)倉的場景中，大部分操作都是選擇一張表，將結(jié)果插入到另一張表里，因此數(shù)據(jù)的底層來源通常是另一張 Hive 表。在執(zhí)行計(jì)劃中，該 Hive 表對應(yīng)的節(jié)點(diǎn)就是 TableScan 節(jié)點(diǎn)。

基于 Index 信息遞歸向下尋找，直到找到最底層的 TableScan 節(jié)點(diǎn)，在 TableScan 節(jié)點(diǎn) Index 下標(biāo)對應(yīng)位置的列信息，就是最外層列對應(yīng)的列血緣。

以圖中左下角的 SQL 為例，具體講解這一過程的實(shí)現(xiàn)。

該 SQL 經(jīng)過解析和優(yōu)化后，會形成圖示的執(zhí)行計(jì)劃?？梢钥吹剑琒QL 中的每一個片段都能對應(yīng)到執(zhí)行計(jì)劃中的一個節(jié)點(diǎn)。

例如，SQL 的第一行 insert overwrite 操作在執(zhí)行計(jì)劃中對應(yīng)一個 TableModify 算子，第二行和第三行的 select 操作對應(yīng)執(zhí)行計(jì)劃中的 Project 算子。再向下是兩張表的 join 操作，該 join 操作對應(yīng) HashJoin 算子。join 之后，t1 和 t2 兩個子查詢是平級關(guān)系，join 的下一層有兩個平級的 Project。兩個子查詢內(nèi)部在執(zhí)行計(jì)劃中 f 分別對應(yīng) Project、Filter 和 TableScan 算子。TableScan 算子就對應(yīng)查詢的底表信息。

拿到執(zhí)行計(jì)劃后，按照前文實(shí)現(xiàn)原理中的第二步，基于 index 向下尋找。

以 DQL 部分為例：select a2 和 b2 對應(yīng)執(zhí)行計(jì)劃中的 Project 節(jié)點(diǎn)，它們最終插入的是 table3，因此對應(yīng)的列信息是 table3 的 c1 和 c2。通過找到這一列對應(yīng)的 index，逐層向下遞歸尋找。標(biāo)黃的部分是基于 index 尋找鏈路的過程，逐層尋找，最終定位到最底層的 TableScan 節(jié)點(diǎn)。

經(jīng)過尋找，我們發(fā)現(xiàn) c1 底層列來源為 table1 的 a2 這一列，即構(gòu)成血緣關(guān)系。c2 的血緣同理。

3. 基于策略的多樣化血緣提取能力

前面探討了血緣能力在底層的實(shí)現(xiàn)機(jī)制，通過該能力可以完成基礎(chǔ)的表和列級別的血緣提取，滿足大多數(shù)場景的需求。但為了滿足更多多樣化需求，我們團(tuán)隊(duì)進(jìn)一步開發(fā)了基于策略的多樣化血緣能力，并將其封裝成 SDK，以便各業(yè)務(wù)方能夠更便捷地使用。

以典型策略場景舉例子。

第一種場景為業(yè)務(wù)方不滿足于列級別的血緣追蹤，在離線數(shù)倉中，業(yè)務(wù)可能會遇到一些復(fù)雜類型的數(shù)據(jù)，如 Json、Map、Struct 等，這些復(fù)雜類型的數(shù)據(jù)可能包含更多的信息，需要復(fù)雜類型中 column key 級別的血緣追蹤。為此，我們特別設(shè)計(jì)了策略來支持復(fù)雜類型 column key 級別的血緣提取。例如，能夠追蹤到某個 JSON 字段的血緣來源于哪個 column 的哪個 key。

第二種場景為支持弱引用血緣的提取。在標(biāo)準(zhǔn)的列血緣追蹤中，抖音集團(tuán)主要通過 select 鏈路來追蹤。但實(shí)際上，列不僅被用在 select 語句中，還可能被用在 where、group by、order by 等場景中。為了滿足這些場景的需求，血緣能力也支持提取以上場景的血緣，并將其統(tǒng)一歸結(jié)為弱引用血緣，以便下游靈活使用。

第三種場景是 UDF 定制化血緣。在一些特殊情況下，例如用戶使用了 if 表達(dá)式，如果 column1 大于 10，則返回 column2 的信息，否則返回 column3 的信息。在標(biāo)準(zhǔn)的列血緣追蹤中，最終結(jié)果列會依賴 column1、column2 和 column3 這三個列。但在某些特殊情況下，上游業(yè)務(wù)側(cè)可能希望更精確地追蹤數(shù)據(jù)來源。經(jīng)過分析，我們發(fā)現(xiàn) column1 在這個 SQL 中只作為判斷條件存在，其數(shù)據(jù)并不會作為真正的結(jié)果數(shù)據(jù)存儲到最終的數(shù)據(jù)表中。因此，血緣能力配置了特定的規(guī)則，可以對此類 UDF 進(jìn)行定制化邏輯處理，從而忽略作用在條件位置的列，實(shí)現(xiàn)更精準(zhǔn)的數(shù)據(jù)來源追蹤。

最后一種場景是支持統(tǒng)計(jì)列產(chǎn)出路徑上的計(jì)算關(guān)系。以下面的 SQL 為例：select column1, max(column2) from 一張表。在該 SQL 中，column1 沒有經(jīng)過任何計(jì)算，直接作為結(jié)果返回，因此計(jì)算關(guān)系是 direct。而 column2 則經(jīng)過了一些計(jì)算，因此計(jì)算關(guān)系是 expression。通過描述這種列的計(jì)算關(guān)系，可以為下游提供更多的執(zhí)行時信息。

綜上所述，我們團(tuán)隊(duì)開發(fā)了基于策略的多樣化血緣能力能夠滿足不同業(yè)務(wù)的定制化需求，為各業(yè)務(wù)方提供便捷化的使用方式。

三、血緣能力在數(shù)據(jù)發(fā)現(xiàn)場景的應(yīng)用

上一章節(jié)主要闡述了 SQL 血緣的概念、實(shí)現(xiàn)方式，以及在 SQL 血緣基礎(chǔ)上所做的能力擴(kuò)展。

接下來，將通過具體的業(yè)務(wù)場景，來展示這些能力擴(kuò)展是如何在實(shí)際應(yīng)用中落地的。

1. 基于血緣的標(biāo)簽傳播能力

前文曾提到，離線數(shù)倉中存在著海量的 Hive 表信息，且其存儲規(guī)模還在持續(xù)擴(kuò)大。為了實(shí)現(xiàn)對數(shù)據(jù)的精細(xì)化運(yùn)營，首先需要對每一張 Hive 表乃至每一個 Hive 列都有深入的了解，并打上精確標(biāo)簽。

面對可能達(dá)到百萬級、千萬級的信息量，如何為這些信息打上清晰的標(biāo)簽成為了一個挑戰(zhàn)。為此，我們構(gòu)建了一個全局標(biāo)簽傳播系統(tǒng)。

該系統(tǒng)的整體思路分為以下三步：

• 第一步，提取所有的 SQL 任務(wù)?；诒?列級別的血緣能力，構(gòu)建離線數(shù)倉的全局血緣關(guān)系圖，提供數(shù)據(jù)流轉(zhuǎn)的全局視角。
• 第二步，從一些信息明確的業(yè)務(wù)節(jié)點(diǎn)出發(fā)，這些節(jié)點(diǎn)包括用戶已經(jīng)對其有明確感知的表和列。以這些節(jié)點(diǎn)為根基，逐層向下擴(kuò)展，通過分析每一層的 SQL 語義，利用 SQL 語義進(jìn)行標(biāo)簽的傳播，從而完成全局標(biāo)簽的擴(kuò)展。
• 第三步，基于已經(jīng)獲取的全局標(biāo)簽信息，識別數(shù)據(jù)的使用情況及整體的流動鏈路。

綜上所述，構(gòu)建全局標(biāo)簽傳播系統(tǒng)，能夠有效地為海量 Hive 表及 Hive 列打上精確的標(biāo)簽，進(jìn)而實(shí)現(xiàn)對數(shù)據(jù)的精細(xì)化運(yùn)營與管控。

下面從技術(shù)層面詳細(xì)闡述上述三步的具體實(shí)施方法。

2. 構(gòu)造全局血緣圖

第一步，構(gòu)建全局血緣圖。這一階段的首要任務(wù)是收集離線數(shù)倉中所有的 SQL 任務(wù)。得益于之前提到的 SQL 血緣提取能力，能夠?qū)@些 SQL 任務(wù)進(jìn)行血緣信息提取。

完成血緣信息的提取后，再將這些信息導(dǎo)入到一個圖數(shù)據(jù)庫中。在這個數(shù)據(jù)庫中，無論是表還是列，都被視為一個頂點(diǎn)。由于表和表之間、列和列之間，甚至表和列之間都存在依賴關(guān)系，因此它們之間會有邊進(jìn)行連接。這些頂點(diǎn)和邊共同構(gòu)成了一個全局的 Hive 資源血緣圖。

以右側(cè)給出的簡單示例為例，可以清晰地看到，在圖數(shù)據(jù)庫中，各個表和列通過邊相互連接，形成了一個完整的血緣關(guān)系網(wǎng)絡(luò)。這個全局血緣圖提供了離線數(shù)倉中數(shù)據(jù)流轉(zhuǎn)的直觀視圖，為后續(xù)的數(shù)據(jù)管理和運(yùn)營奠定了堅(jiān)實(shí)的基礎(chǔ)。

3. 逐層分析 SQL 語意

在已經(jīng)獲取全局血緣圖信息的基礎(chǔ)上，接下來依據(jù)業(yè)務(wù)的初始標(biāo)記點(diǎn)進(jìn)行逐層擴(kuò)散，以實(shí)現(xiàn)標(biāo)簽的傳播。

這一過程具體分為以下幾個關(guān)鍵步驟。

首先，確定一個業(yè)務(wù)根節(jié)點(diǎn)，即業(yè)務(wù)上具有明確認(rèn)知和清晰標(biāo)簽的節(jié)點(diǎn)。其次，利用全局血緣圖，輕松獲取到該根節(jié)點(diǎn)所有的一級下游信息。再次，深入分析根節(jié)點(diǎn)與一級下游之間的 SQL 語義，從而確定一級下游的標(biāo)簽情況。
以表的標(biāo)簽傳播為例，假設(shè) TableA 是業(yè)務(wù)根節(jié)點(diǎn)，帶有 APP 和 event 兩個標(biāo)簽。當(dāng) TableA 的數(shù)據(jù)流轉(zhuǎn)到下游表時，根據(jù) SQL 的語義來判斷標(biāo)簽的變化情況。

比如，如果 TableA 到 TableB 的流轉(zhuǎn)過程中進(jìn)行了裁剪和 filter 操作，即可基于該操作對標(biāo)簽信息進(jìn)行篩選和裁剪。因此，TableB 可能會繼承 TableA 的部分標(biāo)簽，并且這些標(biāo)簽的值可能會有所變化。

TableC 和 TableD 標(biāo)簽也同理。在傳播過程中，需要根據(jù)每個 SQL 語句的具體操作來更新標(biāo)簽的值。比如，TableC 可能只做了 APP 的過濾，所以 APP 標(biāo)簽會有所變化，而 event 標(biāo)簽則保持不變。而 TableD 如果是一個簡單的數(shù)據(jù)轉(zhuǎn)存操作，那么可能會繼承上游的全部標(biāo)簽。

這樣的逐層分析和標(biāo)簽傳播可以完成從業(yè)務(wù)根節(jié)點(diǎn)到其下游所有表的標(biāo)簽傳播過程。這一方法不僅確保了標(biāo)簽的準(zhǔn)確性和一致性，還為后續(xù)的數(shù)據(jù)管理和運(yùn)營提供了有力的支持。

4. 逐層傳遞標(biāo)簽信息

繼續(xù)沿用之前的傳播規(guī)則，逐層地進(jìn)行標(biāo)簽傳播。這一傳播過程將持續(xù)進(jìn)行，直到新一輪的傳播不再產(chǎn)生任何新的標(biāo)記節(jié)點(diǎn)，這意味著已經(jīng)到達(dá)了葉子節(jié)點(diǎn)，即下方已沒有更多的 Hive 表可以進(jìn)一步標(biāo)記。

當(dāng)這一時刻到來時，所有標(biāo)簽傳播工作便宣告完成。此時，全局中的所有 Hive 表都已被賦予了合適的標(biāo)簽語義。

這些標(biāo)簽的用途廣泛，不僅可以用于追蹤敏感資源的擴(kuò)散情況，還可以作為元數(shù)據(jù)或注釋傳播的手段。使用標(biāo)簽?zāi)軌蚋咝У毓芾砗瓦\(yùn)營數(shù)據(jù)資源，確保數(shù)據(jù)的準(zhǔn)確性和合規(guī)性。

5. 基于血緣的數(shù)據(jù)治理能力

接下來，將探討如何利用血緣關(guān)系來進(jìn)行數(shù)據(jù)治理。

這一思路與之前的標(biāo)簽傳播有相似之處，而標(biāo)簽傳播能力在數(shù)據(jù)治理領(lǐng)域同樣也能發(fā)揮巨大作用。在傳統(tǒng)的數(shù)據(jù)治理場景中，離線側(cè)通常依賴于 HDFS 的訪問日志來實(shí)現(xiàn)數(shù)據(jù)治理。由于 Hive 表的數(shù)據(jù)最終存儲在 HDFS 上，通過分析 HDFS 的訪問日志來判斷哪些數(shù)據(jù)在一段時間內(nèi)未被訪問，并據(jù)此進(jìn)行表級別或分區(qū)級別的 TTL（Time To Live）治理，以降低存儲壓力。

然而，在實(shí)際開發(fā)過程中，我們發(fā)現(xiàn)即使某個分區(qū)正在被使用，也并非該分區(qū)的所有列都在被使用。Hive 表上的不同列，其生命周期可能是不同的。這就引發(fā)了一個新問題：如何為不同的列設(shè)置專屬的 TTL，從而減少列級的存儲成本？這成為了業(yè)務(wù)側(cè)的一個新痛點(diǎn)。

為了解決這個問題，抖音集團(tuán)數(shù)據(jù)引擎研發(fā)團(tuán)隊(duì)基于 Parquet 底層能力構(gòu)建了一個名為“列級 TTL”的功能。這一功能可以為 Hive 表上的不同列配置專屬的 TTL，更精細(xì)地管理數(shù)據(jù)的生命周期，進(jìn)一步降低存儲成本，并提高數(shù)據(jù)治理的效率。

在解決了不同列生命周期不同、需要配置列級 TTL 的技術(shù)難題后，依然面臨著一個新的產(chǎn)品問題：如何讓 Hive 表的 owner 能夠合理地設(shè)置每個列的生命周期，以降低使用成本。

為了解決該問題，我們引入了基于血緣的數(shù)據(jù)治理方案。該方案與之前的標(biāo)簽傳播類似，依靠全局血緣圖來實(shí)施，但關(guān)注點(diǎn)從表層面轉(zhuǎn)移到了列層面，主要關(guān)注列的一級下游。

做法是采集每個列一級下游所有列級的最長分區(qū)使用范圍。例如，如果 ColumnA 有四個下游使用場景，分別是 ColumnB、ColumnC、ColumnD 和 ColumnE，我們會分析這些場景中使用的 SQL 語句，以確定 ColumnA 的最長分區(qū)使用范圍。

以 ColumnA 和 ColumnB 的鏈路為例，如果 SQL 語句每次都使用最近 20 天的數(shù)據(jù)來計(jì)算平均值，那么 ColumnA 到 ColumnB 的最長分區(qū)使用范圍就是 20 天。同樣地，ColumnA 的其它下游列也會計(jì)算出最長分區(qū)使用范圍。

以上信息收集起來后，可以為 ColumnA 提供一個合理的 TTL 推薦值。當(dāng)然，這個推薦值只是基于數(shù)據(jù)使用情況的建議，用戶還可以根據(jù)自己的業(yè)務(wù)場景進(jìn)行調(diào)整。

總之，以上方案是幫助用戶推薦一個合理的列級別 TTL 閾值，以降低用戶使用成本，降低存儲壓力。

四、血緣能力在數(shù)據(jù)保護(hù)場景的應(yīng)用

前文介紹了血緣能力在數(shù)據(jù)發(fā)現(xiàn)以及數(shù)據(jù)治理等場景中的應(yīng)用。

接下來將探討血緣能力在數(shù)據(jù)保護(hù)這一場景下的應(yīng)用。

1. 基于血緣能力精細(xì)化提取 SQL 權(quán)限

（1）業(yè)務(wù)背景&整體思路

目前各公司在安全合規(guī)方面面臨巨大壓力，需要遵循數(shù)據(jù)權(quán)限最小化的原則來確保數(shù)據(jù)使用的規(guī)范性。

SQL 作為大數(shù)據(jù)分析場景中最簡單、最通用的語言之一，在離線場景中有廣泛應(yīng)用。為了確保SQL場景中的權(quán)限使用規(guī)范和最小化，我們必須解決 SQL 權(quán)限精細(xì)化管控問題。

解決方案分為兩個層面：SQL 解析和權(quán)限管理。

在 SQL 解析層面，基于血緣能力定義了一套新的權(quán)限點(diǎn)提取規(guī)則，這套規(guī)則能夠完成細(xì)粒度的行列級別權(quán)限點(diǎn)提取。而在權(quán)限管理層面，我們支持了行列混合的權(quán)限管控，通過橫向和縱向權(quán)限點(diǎn)的捆綁組合，將用戶實(shí)際查詢的資源定位到行列重疊的資源單元格上，從而實(shí)現(xiàn)更細(xì)粒度的資源級別權(quán)限管控。

以抖音集團(tuán)為例，用戶提交的 SQL 會首先被發(fā)送到統(tǒng)一的 SQL 處理引擎 ByteQuery 上。ByteQuery 是一個統(tǒng)一的 SQL 解析和優(yōu)化引擎，它基于血緣能力能夠完成精準(zhǔn)的 SQL 權(quán)限點(diǎn)提取邏輯。提取到的權(quán)限點(diǎn)信息會被發(fā)送到統(tǒng)一的權(quán)限管理服務(wù)進(jìn)行鑒權(quán)。如果用戶有權(quán)限，SQL 會經(jīng)過優(yōu)化后發(fā)送到具體的執(zhí)行引擎（如 Presto、Spark 等）執(zhí)行；如果用戶沒有權(quán)限，則會返回給用戶提示缺少相應(yīng)權(quán)限，并建議其完成對應(yīng)的申請。

以具體的 SQL 查詢?yōu)槔?，如果用戶查詢的是“select name from db.table where ID=3”，從 SQL 視角來看，行業(yè)普遍的權(quán)限提取可能只涉及到表級別或列級別的權(quán)限。然而，通過深入分析用戶實(shí)際數(shù)據(jù)查詢的范圍，我們可以發(fā)現(xiàn)用戶實(shí)際查詢的是 name 列和 ID=3 的行所構(gòu)成的資源方塊。因此，無論是表級別還是列級別的管控都顯得過于粗略，資源方塊級別的管控才是更優(yōu)的方案。

為了實(shí)現(xiàn)這一目標(biāo)，抖音集團(tuán)的血緣能力在權(quán)限提取側(cè)支持了行列混合的權(quán)限提取，并在權(quán)限管控側(cè)支持了對資源方塊級別的權(quán)限管控。通過這種方法，能夠更精細(xì)地控制用戶對數(shù)據(jù)的訪問權(quán)限，確保數(shù)據(jù)的安全和合規(guī)性。

（2）權(quán)限提取方案

首先看看業(yè)界是如何處理權(quán)限提取問題的。以 Apache Hive 為例，在 SQL 解析的過程中會收集解析階段各階段的輸入（input）和輸出（output）信息。通過這些信息，Hive 能夠提取出 SQL 所使用的所有庫表信息，并將這些信息作為庫表的權(quán)限點(diǎn)。若需要更細(xì)致的控制，Hive 在優(yōu)化過程中會在對應(yīng)的 TableScan 節(jié)點(diǎn)上維護(hù)一個關(guān)聯(lián)列（reference column），這個關(guān)聯(lián)列記錄了 SQL 查詢所涉及的列信息。最終，這些信息被提取出來作為列權(quán)限使用。通過這種方法，能夠完成表權(quán)限或列權(quán)限的提取。

在我們的解決方案中，接收到用戶提交的 SQL 語句后，首先通過 ByteQuery 引擎進(jìn)行解析和優(yōu)化，將 SQL 轉(zhuǎn)化為執(zhí)行計(jì)劃，這個過程在之前的介紹中已經(jīng)提及，并展示在右側(cè)的圖中。接下來，我們根據(jù)特定的規(guī)則從該執(zhí)行計(jì)劃中提取關(guān)注的特定節(jié)點(diǎn)。在獲取這些節(jié)點(diǎn)后，再利用表列級別的 SQL 血緣能力，確定節(jié)點(diǎn)在底層查詢中實(shí)際使用的行列信息，完成庫表行列級別的權(quán)限提取。

在上述權(quán)限點(diǎn)提取完成后，會進(jìn)行權(quán)限點(diǎn)的組合與匹配，以確定最終的權(quán)限驗(yàn)證范圍。這是一個總體的概念，接下來將從庫權(quán)限、庫表權(quán)限、列權(quán)限和行權(quán)限這三個層面，通過更復(fù)雜的 SQL 語句，來詳細(xì)介紹如何執(zhí)行該過程。

本次舉例的 SQL 語句包含了一個子查詢 T1，由兩部分組成：table1 和 table2 的數(shù)據(jù)進(jìn)行了 union 操作，之后將 union 的結(jié)果與另一個子查詢 T2 進(jìn)行了 join 操作，最終生成了三個列。

（3）庫表權(quán)限提取思路

在第一部分中，主要任務(wù)是提取 SQL 中所有的庫表權(quán)限。

處理流程如下：首先，對 SQL 進(jìn)行解析和優(yōu)化。SQL 中對表的查詢操作會被映射成一個或多個 TableScan 節(jié)點(diǎn)。其次，遍歷執(zhí)行計(jì)劃，完成所有 TableScan 節(jié)點(diǎn)的提取，由此輕松地獲取到所有被查詢的表的信息。

以右側(cè)的這個 SQL 為例，當(dāng)它被轉(zhuǎn)化為執(zhí)行計(jì)劃后，如圖所示，可以看到它包含了 3 個 TableScan 節(jié)點(diǎn)。通過采集這三個 TableScan 節(jié)點(diǎn)的具體信息，可以拿到庫表級別的權(quán)限需求，用于后續(xù)的權(quán)限驗(yàn)證和授權(quán)過程。

（4）列權(quán)限提取思路

在列權(quán)限的提取過程中，首先需要定義明確的規(guī)則來確定哪些列需要進(jìn)行權(quán)限驗(yàn)證。目前，規(guī)則定義主要分為兩類：

• 返回列鑒權(quán)：對于 SQL 最終返回結(jié)果中的列信息，進(jìn)行權(quán)限驗(yàn)證。以右側(cè)的 SQL 為例，其最終返回結(jié)果包含三列數(shù)據(jù)，數(shù)據(jù)將直接展示給用戶，必須進(jìn)行權(quán)限驗(yàn)證。
• 過濾條件列鑒權(quán)：當(dāng)過濾條件為兩個列相等時，可能存在通過特殊語法傳遞數(shù)據(jù)的情況，也需進(jìn)行權(quán)限檢查。

基于上述規(guī)則，整體處理流程分為三步：

• 獲取返回列信息：從執(zhí)行計(jì)劃的最外層算子中獲取所有列信息，這些信息代表 SQL 返回結(jié)果對應(yīng)的列。
• 提取過濾條件：從執(zhí)行計(jì)劃中提取所有的 Filter 條件，特別是那些表示兩個列相等的條件。以右側(cè) SQL 為例，倒數(shù)第二行中的“T1.column1 = T2.C2”就符合這一條件，并提取出來。
• 利用血緣能力確定底表列信息：上一步提取出的列信息（如“T1.column1”）在語義上并不明確，我們無法直接知道具體代表哪個表、哪個列?；谘夑P(guān)系逐一處理上述提取的規(guī)則，就能確定每個列信息對應(yīng)的底表列信息，并最終鑒別這些底表列的權(quán)限。

以右側(cè) SQL 為例，首先，查看最外層算子持有列，如“T1.column1”，并確定它需要進(jìn)行權(quán)限驗(yàn)證。其次，基于血緣關(guān)系查看“T1.column1”的具體數(shù)據(jù)來源，最終定位到“T1.column1”的數(shù)據(jù)來源實(shí)際上是“table1.A1”和“table2.B1”。因此，針對“T1.column1”進(jìn)行鑒別的權(quán)限應(yīng)該是“table1.A1”和“table2.B1”的權(quán)限。同理，對其它列也采取相同的邏輯進(jìn)行處理，最終完成所有列的權(quán)限提取。

（5）行權(quán)限提取思路

行權(quán)限的提取過程的思路與之前的列權(quán)限提取類似，主要的提取規(guī)則是關(guān)注過濾條件中列與常量相等的情況。

處理流程的前幾個階段與之前類似：

• 遍歷執(zhí)行計(jì)劃：獲取執(zhí)行計(jì)劃中所有的過濾條件信息。
• 獲取并分類過濾條件：在獲取到 Filter 條件后，并分類，特別關(guān)注那些列與常量相等的條件。以右側(cè)的 SQL 為例，其最下面一行的“T1.column2 = 張三”就是一個列與常量相等的條件，滿足提取規(guī)則。
• 依靠血緣信息確定底表列：通過血緣關(guān)系，確定“T1.column2”實(shí)際上對應(yīng)的底表列信息，并針對此列進(jìn)行行權(quán)限的鑒別。

對于其它類型的過濾條件，也有相應(yīng)的處理策略：

• 兩個列相等：這種情況在列權(quán)限提取規(guī)則中已經(jīng)覆蓋，會按照列權(quán)限的規(guī)則進(jìn)行處理。
• 常量和常量相等：這種情況不涉及到任何權(quán)限校驗(yàn)，因?yàn)樵?SQL 優(yōu)化階段，這種無意義的比較通常會被優(yōu)化掉。

以右側(cè)的 SQL 為例，提取其所有的 Filter 信息，并追蹤列的血緣關(guān)系，最終提取到的行權(quán)限信息如上圖所示。

接下來對以上提取的權(quán)限信息進(jìn)行整合與組合，以便更清晰地了解每個查詢所涉及的具體資源。

以右側(cè)這個 SQL 為例，在 table1 上，它實(shí)際查詢的列是 A1 和 A2，而查詢的行則滿足“dt = 20230101”和“A2=zhangsan”這兩個條件。同理，對于 table2 和 table3，我們也會基于上述信息完成橫向和縱向的權(quán)限信息提取。

將這些信息映射到右側(cè)的表里（假設(shè)第一張表是 table1，第二張表是 table2，第三張表是 table3，且它們分別有 A1、A2、A3、A4、A5 等列），通過橫向和縱向的組合劃分，可以將檢索的資源精確地定位到行列交錯的標(biāo)注黃色的資源方塊上。

這一步驟標(biāo)志著，在權(quán)限提取側(cè)完成了最細(xì)粒度的權(quán)限提取，即資源方塊級別的權(quán)限提取。這為后續(xù)的權(quán)限管控奠定了堅(jiān)實(shí)的基礎(chǔ)。然而，值得注意的是，權(quán)限提取只是權(quán)限管控的一部分，只有與權(quán)限管控策略相結(jié)合，才能確保數(shù)據(jù)的安全性和合規(guī)性。

2. 血緣能力在動態(tài)脫敏場景下的應(yīng)用

動態(tài)脫敏是保障數(shù)據(jù)安全的重要手段，它能在數(shù)據(jù)展示或傳輸過程中，對數(shù)據(jù)進(jìn)行實(shí)時的脫敏處理，以保護(hù)隱私數(shù)據(jù)的安全。

這種能力主要有兩種實(shí)現(xiàn)時機(jī)：計(jì)算前脫敏和計(jì)算后脫敏。

• 計(jì)算前脫敏：當(dāng)計(jì)算引擎讀取到敏感數(shù)據(jù)時，會立即對其進(jìn)行脫敏處理。這種方式相對簡單，但它更接近于存儲層加密。因?yàn)橐坏?shù)據(jù)被脫敏，它就已經(jīng)變成了密文，這可能會影響后續(xù)的 SQL 查詢邏輯，如 Join、Filter 或 UDF 計(jì)算等。因此，計(jì)算前脫敏可能會對用戶的 SQL 使用產(chǎn)生較大影響。
• 計(jì)算后脫敏：與此相反，計(jì)算后脫敏是在計(jì)算引擎讀取到敏感數(shù)據(jù)后，優(yōu)先執(zhí)行后續(xù)計(jì)算，而在最終返回結(jié)果前再進(jìn)行脫敏處理。這種方式實(shí)現(xiàn)起來更復(fù)雜，因?yàn)樗枰獙ψ罱K結(jié)果進(jìn)行脫敏，而最終結(jié)果已經(jīng)沒有直接的數(shù)據(jù)來源信息。為了實(shí)現(xiàn)這一點(diǎn)，我們需要基于 SQL 分析數(shù)據(jù)走向，追蹤數(shù)據(jù)來源，才能做出是否需要脫敏的判斷。計(jì)算后脫敏的優(yōu)點(diǎn)在于它對用戶的影響較小，因?yàn)樗]有打破用戶對 SQL 的語義理解，仍然完成了合理的計(jì)算后才對結(jié)果做脫敏處理。

在技術(shù)實(shí)現(xiàn)上，無論采用哪種脫敏時機(jī)，都需要首先解析和優(yōu)化用戶的 SQL，將其轉(zhuǎn)化為執(zhí)行計(jì)劃信息，再讀取用戶查詢的表，檢查表中是否配置了脫敏規(guī)則?；诿撁襞渲眯畔韯討B(tài)地改寫執(zhí)行計(jì)劃，并在適當(dāng)?shù)奈恢貌迦朊撁羲阕印?/span>

接下來，將詳細(xì)介紹動態(tài)脫敏在兩個具體場景中的實(shí)現(xiàn)方式。

• 計(jì)算前脫敏場景：

在計(jì)算前脫敏的場景中，脫敏操作被直接插入到 TableScan 節(jié)點(diǎn)之前。由于能夠直接獲取到 Hive 表的信息，我們可以輕易地判斷哪些列需要進(jìn)行脫敏處理。以某個 SQL 查詢?yōu)槔?，如果我們在讀取 table1 的 A2 列時，發(fā)現(xiàn)其源數(shù)據(jù)配置被標(biāo)記為敏感數(shù)據(jù)，需要脫敏，那么我們可以在 A2 列對應(yīng)的 TableScan 算子之上，固定下標(biāo)位置插入一個 Masking 脫敏算子。這樣，后續(xù)的 Filter、Join 等計(jì)算操作都會基于脫敏后的數(shù)據(jù)進(jìn)行處理，從而輕松實(shí)現(xiàn)動態(tài)脫敏。

• 計(jì)算后脫敏場景：

與計(jì)算前脫敏不同，計(jì)算后脫敏需要將脫敏操作放置在查詢的最外層算子處。此時，脫敏操作已經(jīng)遠(yuǎn)離了標(biāo)識 Hive 表信息的 TableScan 節(jié)點(diǎn)。以某個包含 C1、C2 兩列的 SQL 查詢?yōu)槔?，我們可能無法直接判斷這兩列是否需要脫敏。為了解決這個問題，我們需要基于血緣信息來追蹤每一層的計(jì)算鏈路，并根據(jù)計(jì)算鏈路來判斷哪些列需要脫敏處理。

這個追蹤過程與前面提到的血緣追蹤類似，如果我們基于血緣判斷鏈路發(fā)現(xiàn)某列需要脫敏，就會在最外層對應(yīng)的位置插入一個脫敏算子；如果不需要脫敏，則直接返回原始列。

如果 DB.table1 中的某列（標(biāo)綠色）是敏感數(shù)據(jù)，操作步驟為拿到最外層算子，逐層追蹤該列的血緣信息。綠色的框表示追蹤范圍，最終發(fā)現(xiàn) C1 的來源是 A2，且該鏈路上需要脫敏。因此，在 C1 之上插入一個 masking 脫敏算子。而對于 C2 列，如果在追蹤過程中發(fā)現(xiàn)其底表的依賴是非敏感資源，則不需要進(jìn)行任何脫敏處理，直接返回原始列即可。

通過這種方式，我們可以在對用戶 SQL 語義影響更小的場景下，同時完成對敏感數(shù)據(jù)的保護(hù)。這種動態(tài)脫敏的實(shí)現(xiàn)方式既靈活又有效，能夠根據(jù)不同的業(yè)務(wù)場景和需求進(jìn)行適應(yīng)性調(diào)整。