更新原則概觀

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

例如，高比率追蹤來源資料表可以包含格式化為任意文字資料行的資料。 目標資料表可包含特定的追蹤行，以及使用 parse 運算子，從來源資料表的任意文字資料轉換所產生的結構完善結構描述。 如需詳細資訊， 請參閱常見案例。

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

更新原則受限於一般擷取的相同限制和最佳做法。 原則會根據叢集大小擴增，在處理大量擷取時更有效率。

注意

• 來源和目標資料表必須位於相同的資料庫中。
• 更新原則函式結構描述和目標資料表結構描述必須符合其資料行名稱、類型和順序。

擷取格式化資料可改善效能，最好是使用 CSV，因為這是定義完善的格式。 不過，有時候，您無法控制數據的格式，或想要藉由將記錄與資料庫中的靜態維度數據表聯結，來擴充內嵌的數據。

更新原則查詢

如果在目標資料表上定義更新原則，可以在擷取到來源資料表的資料上執行多個查詢。 如果有多個更新原則，則不一定知道執行順序。

查詢限制

• 原則相關的查詢可以叫用預存函式，但：
  • 它無法執行跨叢集查詢。
  • 它無法存取外部資料或外部資料表。
  • 它無法使用外掛程式) 來 (圖說文字。
• 查詢對於已啟用 RestrictedViewAccess 原則的數據表沒有讀取許可權。
• 如需串流擷取的更新原則限制，請參閱串流擷取限制。

警告

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

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

在原則的 Query 部分中或由 Query 部分參考的函數中，參考 Source 資料表時：

• 請勿使用資料表的限定名稱。 請改用 TableName。
• 請勿使用 database("DatabaseName").TableName 或 cluster("ClusterName").database("DatabaseName").TableName。

更新原則物件

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

屬性	類型	描述
IsEnabled	bool	更新原則的狀態，true - 已啟用，或 false - 已停用
來源	string	觸發更新原則叫用的資料表名稱
查詢	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 (提取)
• .ingest (內嵌)
• .set | .append | .set-or-append | .set-or-replace
• .move extents
• .replace extents
  • PropagateIngestionProperties 命令只會在擷取作業中生效。 當更新原則在 .move extents 或 .replace extents 命令過程中觸發時，此選項沒有任何作用。

警告

當更新原則在 .set-or-replace 命令過程中叫用時，衍生資料表中的資料預設會以來源資料表中的相同方式取代。 如果叫用 replace 叫用命令，則具有更新原則關聯性的所有資料表中的資料可能會遺失。 請考慮改用 .set-or-append。

移除來源資料表中的資料

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

• 來源資料無法從來源資料表查詢
• 在擷取作業過程中，來源資料不會保存在永久性儲存體中
• 作業效能會改善。 針對來源資料表中範圍的背景清理作業，會減少擷取後資源。

注意

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

效能影響

更新原則會影響叢集效能，而資料範圍的擷取會乘以目標資料表的數目。 請務必將原則相關的查詢最佳化。 您可以藉由在已經存在的範圍中、在建立或改變原則之前，或在搭配查詢使用的函式上叫用原則，來測試更新原則的效能影響。

評估資源使用量

搭配下列參數使用 .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:false時，即使原則未執行，數據仍然可以擷取至源數據表。

設定 IsTransactional:true 可保證來源數據表和目標數據表中的數據之間的一致性。 但是，如果原則條件失敗，資料就不會擷取到來源資料表。 或者，視條件而定，有時會將資料擷取到來源資料表，而不是目標資料表。 不過，如果您的原則定義不正確，或架構不符，則不會將數據內嵌至來源或目標數據表。 例如，從目標資料表中卸除資料行，可能會導致查詢輸出結構描述與目標資料表不相符。

您可以使用 .show ingestion failures 命令來檢視失敗。

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

失敗的處理

非交易原則

當設定為 IsTransactional:false時，會忽略執行原則的任何失敗。 不會自動重試擷取。 您可以手動重試擷取。

交易式原則

當設定為 IsTransactional:true時，如果擷取方法是 pull，則涉及 資料管理 服務，而且會根據下列條件自動重試擷取：

• 系統會執行重試，直到符合下列其中一個可設定的限制設定：DataImporterMaximumRetryPeriod 或 DataImporterMaximumRetryAttempts
• 根據預設， DataImporterMaximumRetryPeriod 設定為 2 天，且 DataImporterMaximumRetryAttempts為 10
• 輪詢期間是從 2 分鐘開始，以兩倍數增加。 因此，等候的開始時間是 2 分鐘，然後增加至 4 分鐘、8 分鐘、16 分鐘，依此類推。

在其他任何情況下，您可以手動重試擷取。

擷取、轉換、載入的範例

您可以使用更新原則設定來執行擷取、轉換、載入 (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. 若要在資料擷取至目標資料表之後清空來源資料表，請在來源資料表上定義保留原則，使其 SoftDeletePeriod 為 0。

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

相關內容

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