當資料流程寫入接收器時，任何自訂分割都會在寫入之前立即發生。 和原始碼一樣，大多數情況下建議你保留 「使用當前分割 區」作為選中的分割區選項。 分割資料寫入速度遠快於未分割的資料，即使你的目的地沒有分割。 以下是各種水槽類型的個別考量。
Azure SQL Database 接收器
使用 Azure SQL 資料庫時，預設的分割方式在大多數情況下應該是可行的。 有可能你的 sink 有太多分割區，SQL 資料庫無法處理。 如果您遇到此問題，請減少 SQL 資料庫匯出器的分割區數量。
根據來源中缺少的資料列，在接收器中刪除資料列的最佳做法
以下是逐步影片，說明如何在資料流程中使用 exists、alter row 和 sink 轉換，實現這種常見模式：
錯誤列處理對效能的影響
當你在資料匯入轉換中啟用對錯誤列的處理功能（「錯誤後繼續」）時，服務會在將相容的列寫入目的資料表前，額外執行一步。 這個額外步驟會有些微的效能損耗，此步驟可能會額外增加約 5% 的效能負擔；如果您也設定將不相容的資料列寫入記錄檔，還會再增加一些額外且輕微的效能影響。
使用 SQL 腳本停用索引
在 SQL 資料庫載入前停用索引，能大幅提升對資料表的寫入效能。 在寫入 SQL 匯入前，先執行以下指令。
ALTER INDEX ALL ON dbo.[Table Name] DISABLE
寫入完成後，使用以下指令重建索引：
ALTER INDEX ALL ON dbo.[Table Name] REBUILD
這些都可以在 Azure SQL 資料庫或 Synapse sink 的映射資料流中，使用 Pre-SQL 和 Post-SQL 腳本原生完成。
警告
停用索引時，資料流實際上接管了資料庫，查詢此時不太可能成功。 因此，許多 ETL 作業會在深夜觸發，以避免衝突。 欲了解更多資訊，請了解 停用 SQL 索引的限制
擴充資料庫
在管線執行前，排定調整來源與接收器 Azure SQL DB 和 DW 的大小，以提高輸送量，並在您達到 DTU 限制後將 Azure 節流降到最低。 管線執行完成後，請將資料庫調整回一般執行速率。
Azure Synapse Analytics 接收器
在寫入 Azure Synapse Analytics 時，請確保 「啟用暫存 」設定為 true。 這使得服務能夠使用 SQL COPY 指令寫入，實際上是批量載入資料。 使用 Staging 時，您需要參考 Azure Data Lake Storage gen2 或 Azure Blob 儲存體帳戶，以作為資料暫存區。
除了暫存之外，Azure Synapse Analytics 和 Azure SQL Database 也遵循相同的最佳實務。
檔案型接收器
雖然資料流支援多種檔案類型，但建議採用 Spark 原生的 Parquet 格式以達到最佳讀寫時間。
如果資料分布均勻， 使用目前分割 是寫入檔案時最快的分割選項。
檔案名稱選項
在撰寫檔案時，你可以選擇多個命名選項，每個都會影響效能。
選擇 預設 選項寫入速度最快。 每個分割區對應一個 Spark 預設名稱的檔案。 如果您只是從資料資料夾讀取，這會很有幫助。
設定命名 模式 會將每個分割檔重新命名為更友善的名稱。 此操作在寫入後進行，速度略慢於選擇預設值。
每個分區允許您手動命名每個分區。
如果欄位對應於你想輸出的資料方式，你可以選擇 「名稱檔案」作為欄位資料。 這會重新排列資料，若欄位分布不均，可能會影響效能。
如果欄位對應於你想產生資料夾名稱的方式，請選擇 「名稱資料夾」作為欄位資料。
輸出到單一檔案時，將 所有資料合併成一個分割區。 這會導致寫入時間過長，尤其是對大型資料集而言。 除非有明確的商業理由，否則不建議使用這個選項。
Azure Cosmos DB 接收器
當你寫入 Azure Cosmos DB 時，在資料流執行時調整吞吐量和批次大小可以提升效能。 這些變更僅在資料流活動執行期間生效，結束後會回復到原始的集合設定。
批次大小： 通常，從預設的批次大小開始就足夠了。 為了進一步調整這個數值，請計算資料的大致物件大小，並確保物件大小乘以批次大小小於 2MB。 如果是的話，你可以增加批次大小以提升產量。
吞吐量： 在這裡設定更高的吞吐量設定，讓文件能更快寫入 Azure Cosmos 資料庫。 請記住，較高輸送量設定會帶來較高的 RU 成本。
寫入吞吐量預算： 使用一個比每分鐘總 RU 小的數值。 如果你的資料流中有大量 Spark 分割區，設定預算吞吐量可以讓這些分割區間更平衡。
相關內容
請參閱其他與效能相關的資料流程文章：