更新原則概觀

適用於： ✅Microsoft網狀架構✅Azure 數據總管

更新原則是當新數據寫入數據表時觸發的自動化機制。 其可藉由執行查詢來轉換擷取的數據，並將結果儲存至目的地數據表，藉以消除特殊協調流程的需求。 單一數據表可以定義多個更新原則，以允許不同的轉換，並將數據同時儲存至多個數據表。 目標數據表可以有不同的架構、保留原則，以及源數據表中的其他原則。

例如，高速率追蹤源資料表可以包含格式化為自由文字資料行的資料。 目標資料表可以包含特定的追蹤行，其中包含使用 parse 運算子從源資料表自由文字資料轉換所產生的結構良好架構。 如需詳細資訊， 常見案例。

下圖描述更新原則的高階檢視。 它會顯示將數據新增至第二個源數據表時觸發的兩個更新原則。 觸發之後，轉換的數據會新增至兩個目標數據表。

更新原則受限於與一般擷取相同的限制和最佳做法。 原則會根據事件倉儲大小相應放大，而且在處理大量擷取時更有效率。

注意

• 來源和目標數據表必須位於相同的資料庫中。
• 更新原則函式架構和目標數據表架構必須符合其數據行名稱、類型和順序。
• 更新原則函式可以參考其他資料庫中的數據表。 若要這樣做，更新原則必須以 ManagedIdentity 屬性定義，而且受控識別必須在參考的資料庫上具有viewer角色。 擷取格式化的數據可改善效能，因為 CSV 是定義完善的格式，因此偏好使用 CSV。 不過，有時候，您無法控制數據的格式，或想要擴充內嵌的數據，例如，將記錄與資料庫中的靜態維度數據表聯結在一起。

更新原則查詢

如果在目標數據表上定義更新原則，可以在內嵌至源數據表的數據上執行多個查詢。 如果有多個更新原則，則執行順序不一定是已知的。

查詢限制

• 原則相關的查詢可以叫用預存函式，但：
  • 它無法執行跨事件倉儲查詢。
  • 它無法存取外部資料或外部資料表。
  • 它無法進行圖說文字（使用外掛程式）。
• 查詢沒有已啟用 RestrictedViewAccess 原則之數據表的讀取許可權。
• 如需串流擷取中的更新原則限制，請參閱 串流擷取限制。

警告

不正確的查詢可防止數據擷取到源數據表。 請務必注意，限制以及查詢結果與來源和目的地數據表架構之間的相容性，可能會導致不正確的查詢防止數據擷取至源數據表。

這些限制會在原則的建立和執行期間進行驗證，但不會在查詢可能參考的任意儲存函式更新時進行驗證。 因此，請務必謹慎進行任何變更，以確保更新原則保持不變。

在參考 Source 原則部分的數據表 Query 時，或在元件所參考 Query 的函式中：

• 請勿使用數據表的限定名稱。 請改用 TableName。
• 不要使用此 database("<DatabaseName>").TableName 或 cluster("<EventhouseName>").database("<DatabaseName>").TableName。

更新原則物件

數據表可以有零個或多個與其相關聯的更新原則物件。 每個這類對象都會以 JSON 屬性包表示，並定義下列屬性。

屬性	類型​	描述
IsEnabled	bool	如果更新原則為 true ，則為狀態 - 已啟用或 false - 已停用
來源	string	觸發更新原則調用的數據表名稱
Query	string	用來產生更新數據的查詢
IsTransactional	bool	如果更新原則是交易式或否，則狀態為 false。 如果原則為交易式，且更新原則失敗，則不會更新源數據表。
PropagateIngestionProperties	bool	如果在擷取源數據表期間指定的屬性，例如 範圍標籤 和建立時間，則會套用至目標數據表。
ManagedIdentity	string	代表執行更新原則的受控識別。 受控識別可以是物件標識碼或 system 保留字。 當查詢參考具有已啟用 數據列層級安全策略之其他資料庫或數據表中的數據表時，必須設定更新原則與受控識別。 如需詳細資訊，請參閱 使用受控識別來執行更新原則。

注意

在生產系統中，設定 IsTransactional：true 以確保目標數據表不會在暫時性失敗中遺失數據。

注意

允許級聯更新，例如從數據表 A、數據表 B 到數據表 C。不過，如果更新原則是以迴圈方式定義，則會在運行時間偵測到此原則，而且會剪下更新鏈結。 數據只會內嵌至鏈結中的每個數據表一次。

管理命令

更新原則管理命令包括：

• .show table *TableName* policy update 顯示數據表的目前更新原則。
• .alter table *TableName* policy update 定義數據表的目前更新原則。
• .alter-merge table *TableName* policy update 將定義附加至數據表的目前更新原則。
• .delete table *TableName* policy update 會刪除資料表的目前更新原則。

更新原則是在擷取之後起始的

更新原則會在數據內嵌或移至源數據表時生效，或是在源數據表中建立範圍。 這些動作可以使用下列任何命令來完成：

• .ingest （pull）
• .ingest （內嵌）
• .set | .append | .set-or-append | .set-or-replace
• .move 範圍
• .replace extents
  • 命令 PropagateIngestionProperties 只會在擷取作業中生效。 當更新原則在 或 .replace extents 命令中.move extents觸發時，此選項沒有任何作用。

警告

當更新原則叫用為命令的一 .set-or-replace 部分時，衍生數據表中的數據預設會以與源數據表中相同的方式取代。 如果叫用 命令，則所有數據表中的數據可能會遺失，且 replace 具有更新原則關聯性。 請考慮改用 .set-or-append。

從源數據表移除數據

將資料擷取至目標數據表之後，您可以選擇性地從源數據表中移除它。 在源數據表的保留原則中設定 （或00:00:00） 的虛刪除期間0sec，並將更新原則設定為交易式。 適用於下列條件：

• 源數據無法從源數據表查詢
• 源數據不會保存在永久性記憶體中，作為擷取作業的一部分
• 作業效能會改善。 擷取后的資源會減少，以便對源數據表中的範圍進行背景清理作業。

注意

當源數據表具有 （或00:00:00） 的0sec虛刪除期間時，參考此數據表的任何更新原則都必須是交易式。

效能影響

更新原則可能會影響效能，而數據範圍擷取會乘以目標數據表的數目。 請務必優化原則相關的查詢。 您可以在建立或變更原則之前，或在搭配查詢使用的函式上叫用原則，以測試更新原則的效能影響。

評估資源使用量

使用 .show queries，以下列參數評估資源使用量（CPU、記憶體等）：

• 將 Source 屬性、源數據表名稱設定為 MySourceTable
• Query設定 屬性以呼叫名為 的函式MyFunction()

// '_extentId' is the ID of a recently created extent, that likely hasn't been merged yet.
let _extentId = toscalar(
    MySourceTable
    | project ExtentId = extent_id(), IngestionTime = ingestion_time()
    | where IngestionTime > ago(10m)
    | top 1 by IngestionTime desc
    | project ExtentId
);
// This scopes the source table to the single recent extent.
let MySourceTable =
    MySourceTable
    | where ingestion_time() > ago(10m) and extent_id() == _extentId;
// This invokes the function in the update policy (that internally references `MySourceTable`).
MyFunction

交易式設定

更新原則設定會定義更新原則 IsTransactional 是否為交易式，而且可能會影響原則更新的行為，如下所示：

• IsTransactional:false：如果值設定為預設值 false，則更新原則不保證來源和目標數據表中的數據之間的一致性。 如果更新原則失敗，數據只會內嵌至源數據表，而不是擷取至目標數據表。 在此案例中，擷取作業成功。
• IsTransactional:true：如果值設定為 true，則此設定可保證來源數據表和目標數據表中的數據之間的一致性。 如果更新原則失敗，數據不會內嵌至來源或目標數據表。 在此案例中，擷取作業失敗。

處理失敗

當原則更新失敗時，會根據設定為 IsTransactional 或 false，以不同的方式處理這些更新true。 更新原則失敗的常見原因是：

• 查詢輸出架構與目標資料表不符。
• 任何查詢錯誤。

您可以使用 命令搭配下列命令來檢視原則更新失敗.show ingestion failures：在任何其他情況下，您可以手動重試擷取。

.show ingestion failures
| where FailedOn > ago(1hr) and OriginatesFromUpdatePolicy == true

擷取、轉換、載入的範例

您可以使用更新原則設定來執行擷取、轉換、載入 （ETL）。

在此範例中，使用更新原則搭配簡單的函式來執行 ETL。 首先，我們會建立兩個數據表：

• 源數據表 - 包含內嵌數據的單一字串型別數據行。
• 目標數據表 - 包含所需的架構。 更新原則定義在此數據表上。

1. 讓我們建立源數據表：

   .create table MySourceTable (OriginalRecord:string)
   

2. 接下來，建立目標數據表：

   .create table MyTargetTable (Timestamp:datetime, ThreadId:int, ProcessId:int, TimeSinceStartup:timespan, Message:string)
   

3. 然後建立函式以擷取數據：

   .create function
    with (docstring = 'Parses raw records into strongly-typed columns', folder = 'UpdatePolicyFunctions')
        ExtractMyLogs()
       {
       MySourceTable
       | parse OriginalRecord with "[" Timestamp:datetime "] [ThreadId:" ThreadId:int "] [ProcessId:" ProcessId:int "] TimeSinceStartup: " TimeSinceStartup:timespan " Message: " Message:string
       | project-away OriginalRecord
   }
   

4. 現在，設定更新原則以叫用我們建立的函式：

   .alter table MyTargetTable policy update
   @'[{ "IsEnabled": true, "Source": "MySourceTable", "Query": "ExtractMyLogs()", "IsTransactional": true, "PropagateIngestionProperties": false}]'
   

5. 若要在將資料內嵌至目標數據表之後清空源數據表，請在源數據表上定義保留原則，使其具有0作為。SoftDeletePeriod

    .alter-merge table MySourceTable policy retention softdelete = 0s
   

相關內容

• 使用數據表更新原則的常見案例
• 教學課程：使用數據表更新原則路由數據