ระยะที่ 4: การโยกย้ายความปลอดภัยและการกํากับดูแล

บทความนี้เป็นระยะที่ 4 จาก 4 ในชุดแนวทางปฏิบัติที่ดีที่สุดสําหรับการโยกย้าย Azure Synapse Spark ไปยัง Microsoft Fabric

ใช้บทความนี้ในขั้นตอนสุดท้ายของการย้ายข้อมูลเพื่อตรวจสอบปริมาณงาน ปรับการควบคุมความปลอดภัยและการกํากับดูแล และวางแผนการเคลื่อนย้ายการผลิตของคุณ บทความนี้ให้คําแนะนําเกี่ยวกับการแม็ปความปลอดภัยและแนวทางที่ขับเคลื่อนด้วยรายการตรวจสอบเพื่อตรวจสอบความถูกต้อง

ในบทความนี้ คุณจะได้เรียนรู้วิธีการ:

  • แมป Synapse RBAC และรูปแบบเครือข่ายกับพื้นที่ทํางาน Fabric, OneLake และการควบคุมเครือข่ายที่มีการจัดการ
  • เชื่อมต่อเวิร์กโฟลว์การกํากับดูแลอีกครั้ง รวมถึงการรวมและการติดป้ายชื่อ Microsoft Purview
  • ใช้รายการตรวจสอบการโยกย้ายทีละขั้นตอนเพื่อตรวจสอบ เพิ่มประสิทธิภาพ และดําเนินการเคลื่อนย้าย
  • วางแผนการรื้อถอนทรัพยากร Synapse Spark แบบเดิมหลังจากการเคลื่อนย้ายสําเร็จ

การควบคุมการเข้าถึง

  • บทบาท Synapse RBAC (ผู้ดูแลระบบ Synapse, ผู้ดูแลระบบ Synapse SQL, ผู้ดูแลระบบ Synapse Spark และอื่นๆ) แมปกับบทบาทพื้นที่ทํางาน Fabric (ผู้ดูแลระบบ, สมาชิก, ผู้สนับสนุน, ผู้ชม) โมเดลของ Fabric นั้นง่ายกว่าด้วยสี่บทบาท

  • บริการที่เชื่อมโยง Synapse จะถูกแทนที่ด้วย Fabric Connections สร้างการเชื่อมต่อผ่านการตั้งค่า>จัดการการเชื่อมต่อและเกตเวย์ สําหรับรหัสสมุดบันทึก ให้แทนที่การอ้างอิงบริการที่เชื่อมโยงด้วยการรับรองความถูกต้องตาม Key Vault หรือการกําหนดค่าปลายทางโดยตรง

  • OneLake RBAC ให้การควบคุมการเข้าถึงข้อมูลอย่างละเอียดในระดับโฟลเดอร์และโต๊ะภายในบ้านพักทะเลสาบ

ความปลอดภัยเครือข่าย

  • Synapse Managed VNet และ Private Endpoints จับคู่กับ Fabric Managed VNet + Managed Private Endpoints โปรดทราบว่า Fabric Spark ต้องการพูลแบบกําหนดเอง (ไม่ใช่พูลเริ่มต้น) สําหรับการสนับสนุนปลายทางส่วนตัวที่มีการจัดการ

  • รันไทม์การรวมที่โฮสต์ด้วยตนเอง (SHIR) ใน Synapse จะถูกแทนที่ด้วยเกตเวย์ข้อมูลภายในองค์กร (OPDG) ใน Fabric VNet IR ถูกแทนที่ด้วยเกตเวย์ข้อมูล VNet

การกำกับดูแล

หากคุณใช้ Azure Purview กับ Synapse Fabric จะให้การรวม Microsoft Purview แบบเนทีฟสําหรับแค็ตตาล็อกข้อมูล สายข้อมูล ป้ายชื่อระดับความลับ และนโยบายการเข้าถึง เชื่อมต่อบัญชี Purview ของคุณอีกครั้งเพื่อสแกนพื้นที่ทํางาน Fabric

รายการตรวจสอบการโยกย้าย

ใช้รายการตรวจสอบนี้เพื่อติดตามความคืบหน้าผ่านการย้าย Spark ของคุณ แต่ละเฟสสร้างขึ้นจากเฟสก่อนหน้า ทํารายการทั้งหมดในขั้นตอนก่อนที่จะไปยังขั้นตอนถัดไป

ระยะที่ 1: ประเมินและวางแผน

สําหรับคําแนะนําในการวางแผน รูปแบบการโยกย้าย และการเปรียบเทียบคุณลักษณะ โปรดดู ระยะที่ 1: กลยุทธ์และการวางแผนการโยกย้าย

  • 1.1 สินค้าคงคลังสินทรัพย์ Spark ที่สมบูรณ์: พูล Spark, สมุดบันทึก, คําจํากัดความงาน Spark, ฐานข้อมูลทะเลสาบ, ฐานข้อมูล Hive Metastore (HMS) และบริการที่เชื่อมโยงที่ใช้ในสมุดบันทึก
  • 1.2 ทบทวนความแตกต่างของคุณสมบัติ Synapse กับ Fabric ตัวบล็อกแฟล็ก: ปริมาณงาน GPU, API แค็ตตาล็อกที่ไม่รองรับ, การขึ้นต่อกันของบริการที่เชื่อมโยง
  • 1.3 เรียกใช้การตรวจสอบการปรับโครงสร้างล่วงหน้า: ค้นหาโน้ตบุ๊กทั้งหมดสําหรับรูปแบบเฉพาะของ Synapse (spark.synapse.linkedService, , getSecretWithLS, TokenLibrary) synapsesql นับสมุดบันทึกที่ได้รับผลกระทบ
  • 1.4 ตรวจสอบความเข้ากันได้ของไลบรารี: เรียกใช้ pip freeze บนพูล Synapse เปรียบเทียบกับไลบรารีในตัว Fabric รันไทม์ 1.3 แสดงรายการไลบรารีที่ต้องติดตั้งไว้ล่วงหน้า
  • 1.5 สร้างพื้นที่ทํางาน Fabric เตรียมใช้งานความจุ และสร้างรายการ Lakehouse เป้าหมาย
  • 1.6 ส่งออกการตั้งค่าคอนฟิกพูล Spark ไลบรารีแบบกําหนดเอง และคุณสมบัติ Spark จาก Synapse Studio

ระยะที่ 2: ตั้งค่าการเชื่อมต่อและข้อมูลประจําตัว

สําหรับคําแนะนําการเปลี่ยนบริการที่เชื่อมโยงและการรับรองความถูกต้อง โปรดดู ระยะที่ 2: การโยกย้ายปริมาณงาน Spark และ ระยะที่ 4: การโยกย้ายความปลอดภัยและการกํากับดูแล

  • 2.1 รายการบริการที่เชื่อมโยง Synapse ทั้งหมดที่ใช้โดยโน้ตบุ๊ก คําจํากัดความงาน Spark และการเข้าถึงข้อมูล Lakehouse
  • 2.2 สร้างการเชื่อมต่อ Fabric สําหรับแหล่งข้อมูลภายนอก (ADLS Gen2, Cosmos DB, Azure SQL และอื่นๆ) ผ่าน การตั้งค่าพื้นที่ทํางาน>จัดการการเชื่อมต่อและเกตเวย์
  • 2.3 ตั้งค่า Azure Key Vault ด้วยข้อมูลลับสําหรับแหล่งข้อมูลที่ต้องมีการตรวจสอบสิทธิ์ตามคีย์ (คีย์ Cosmos DB, คีย์บัญชีที่เก็บข้อมูล, โทเค็น Kusto) กําหนดค่านโยบายการเข้าถึงสําหรับข้อมูลประจําตัวพื้นที่ทํางาน Fabric ของคุณ
  • 2.4 กําหนดค่าข้อมูลประจําตัวของบริการหลักสําหรับการเข้าถึง OAuth ของ ADLS Gen2: ลงทะเบียนแอปใน Entra ID ให้บทบาทผู้สนับสนุนข้อมูล Blob ที่เก็บข้อมูล บันทึก ID ไคลเอ็นต์/ข้อมูลลับ/ผู้เช่า
  • 2.5 ตรวจสอบการเชื่อมต่อ: ทดสอบการเข้าถึงบัญชี Key Vault ข้อมูลลับและที่เก็บข้อมูลจากสมุดบันทึก Fabric ก่อนดําเนินการต่อ

ระยะที่ 3: ย้ายข้อมูลและ Hive Metastore

สําหรับข้อมูลเมตาของทะเลสาบและคําแนะนําในการโยกย้ายการเข้าถึงข้อมูล โปรดดูระยะที่ 3: Hive Metastore และการโยกย้ายข้อมูล และ โยกย้ายข้อมูลและไปป์ไลน์

  • 3.1 สร้างทางลัด OneLake ไปยังเส้นทาง ADLS Gen2 ที่มีอยู่ (วิธีการที่ต้องการเป็นศูนย์) ใช้ Fabric Connections ที่ตั้งค่าในเฟส 2 สําหรับการเข้าถึงตามเกตเวย์ข้อมูล
  • 3.2 สําหรับไฟล์ที่ไม่ใช่เดลต้า (CSV, JSON, Parquet) ให้สร้างทางลัดในส่วนไฟล์ หากจําเป็นต้องคัดลอกข้อมูล ให้ใช้ AzCopy หรือ Data Factory Copy Activity
  • 3.3 โยกย้ายอ็อบเจ็กต์ Hive Metastore เลือกวิธีใดวิธีหนึ่ง: ตัวเลือก A: เรียกใช้สมุดบันทึกการส่งออก/นําเข้า HMS สําหรับเมตาดาต้าทั้งหมด ตัวเลือก B: ใช้ Migration Assistant สําหรับตารางฐานข้อมูล Delta Lake + ส่งออก/นําเข้า HMS สําหรับที่ไม่ใช่ Delta เท่านั้น
  • 3.4 ตรวจสอบการลงทะเบียนอัตโนมัติของตาราง Delta ใน Lakehouse Explorer
  • 3.5 ตรวจสอบว่าตารางและทางลัดที่นําเข้าทั้งหมดมองเห็นได้ใน Lakehouse explorer และเข้าถึงได้จากสมุดบันทึก

ระยะที่ 4: โยกย้ายปริมาณงาน Spark

สําหรับคําแนะนําในการย้ายรายการ การปรับโครงสร้างโค้ด และการตั้งค่าสภาพแวดล้อม โปรดดู ระยะที่ 2: การโยกย้ายปริมาณงาน Spark

  • 4.1 เรียกใช้ Spark Migration Assistant สําหรับสมุดบันทึก ข้อกําหนดงาน Spark พูล Spark และฐานข้อมูลทะเลสาบ ตรวจสอบรายงานการย้ายข้อมูลเพื่อหาข้อผิดพลาดและคําเตือน
  • 4.2 สร้างสภาพแวดล้อม Fabric ด้วยรันไทม์ Spark เป้าหมาย การกําหนดค่าพูล และไลบรารีแบบกําหนดเอง ติดตั้งไลบรารีที่ขาดหายไปที่ระบุในเฟส 1 ไว้ล่วงหน้า
  • 4.3 สมุดบันทึก Refactor และรหัส SJD: แทนที่ mssparkutils ด้วย notebookutils อัปเดตเส้นทางไฟล์เป็นเส้นทาง OneLake abfss:// แทนที่การอ้างอิงบริการที่เชื่อมโยงด้วยการเชื่อมต่อ Key Vault หรือ Fabric และแทนที่วิธีการ spark.catalog ที่ไม่รองรับด้วยรายการเทียบเท่า Spark SQL
  • 4.4 ตัวเชื่อมต่อ Refactor: Kusto/ADX — แทนที่บริการที่เชื่อมโยงด้วยaccessTokengetToken() Cosmos DB — แทนที่getSecretWithLSด้วยgetSecret(akvName, secret)
  • 4.5 แทนที่ผู้ให้บริการโทเค็น Synapse (LinkedServiceBasedTokenProvider, TokenLibrary) ด้วย OAuth ClientCredsTokenProvider มาตรฐานผ่านspark.conf.set()
  • 4.6 ทดสอบโน้ตบุ๊กและ SJD ที่ปรับโครงสร้างใหม่ตั้งแต่ต้นจนจบกับข้อมูล (เฟส 3) และการเชื่อมต่อ (เฟส 2)

ระยะที่ 5: ความปลอดภัย การกํากับดูแล และเครือข่าย

สําหรับคําแนะนําด้านความปลอดภัย การกํากับดูแล และการแม็ปเครือข่าย โปรดดู ระยะที่ 4: การโยกย้ายความปลอดภัยและการกํากับดูแล

  • 5.1 แมปบทบาท Synapse RBAC กับบทบาทพื้นที่ทํางาน Fabric (ผู้ดูแลระบบ สมาชิก ผู้สนับสนุน ผู้ชม)
  • 5.2 กําหนดค่า OneLake RBAC สําหรับการควบคุมการเข้าถึงข้อมูลแบบละเอียดในระดับโฟลเดอร์และตาราง
  • 5.3 กําหนดค่า Managed VNet และ Managed Private Endpoints สําหรับปริมาณงาน Spark ที่เข้าถึงแหล่งข้อมูลส่วนตัว (ต้องใช้ Custom Pools)
  • 5.4 แทนที่ SHIR ด้วยเกตเวย์ข้อมูลภายในองค์กร (OPDG) และแทนที่ VNet IR ด้วยเกตเวย์ข้อมูล VNet
  • 5.5 เชื่อมต่อ Microsoft Purview อีกครั้งสําหรับป้ายชื่อการกํากับดูแล สายข้อมูล และระดับความลับ
  • 5.6 Review และใช้ป้ายกํากับระดับความลับกับรายการ Lakehouse ที่ย้ายข้อมูลตามต้องการ

ขั้นตอนที่ 6: เพิ่มประสิทธิภาพและตรวจสอบความถูกต้อง

สําหรับการตรวจสอบความถูกต้องหลังการโยกย้ายและคําแนะนําความพร้อมในการผลิต โปรดดู ระยะที่ 4: การโยกย้ายความปลอดภัยและการกํากับดูแล

  • 6.1 เปิดใช้งาน Native Execution Engine (NEE) เพื่อปรับปรุงประสิทธิภาพของ Spark บนปริมาณงาน Parquet และ Delta
  • 6.2 เรียกใช้ OPTIMIZE VORDER บนตารางที่ใช้โดย Power BI Direct Lake หรือตําแหน่งข้อมูลการวิเคราะห์ SQL
  • 6.3 เรียกใช้ปริมาณงานแบบขนานและเปรียบเทียบผลลัพธ์งาน Spark และประสิทธิภาพระหว่าง Synapse และ Fabric
  • 6.4 เปลี่ยนเส้นทางผู้บริโภคดาวน์สตรีม รวมถึงรายงาน Power BI, API และแอปพลิเคชัน ไปยังปลายทาง Fabric
  • 6.5 ตรวจสอบปริมาณงาน Fabric โดยใช้ Monitoring Hub และ Diagnostic Emitter เป็นเวลาอย่างน้อยหนึ่งถึงสองสัปดาห์

ขั้นตอนที่ 7: คัตโอเวอร์

สําหรับการตรวจสอบขั้นสุดท้าย การเปลี่ยนเส้นทางดาวน์สตรีม และคําแนะนําการเคลื่อนย้าย โปรดดู ระยะที่ 4: การโยกย้ายความปลอดภัยและการกํากับดูแล

  • 7.1 ยืนยันว่าสมุดบันทึก SJD และงาน Spark ที่ย้ายทั้งหมดทํางานสําเร็จใน Fabric
  • 7.2 ตรวจสอบความสมบูรณ์ของข้อมูลผ่านการนับแถว การตรวจสอบสคีมา และการเปรียบเทียบผลลัพธ์การสืบค้น
  • 7.3 สื่อสารการเคลื่อนย้ายไปยังผู้มีส่วนได้ส่วนเสียและปรับปรุงเอกสาร
  • 7.4 เลิกใช้งานพูล Synapse Spark โน้ตบุ๊ก และทรัพยากรที่เกี่ยวข้อง

Note

หลังจากการย้ายข้อมูล ให้พิจารณาตั้งค่าการรวม Fabric Git สําหรับสมุดบันทึกที่ย้ายและข้อกําหนดงาน Spark ของคุณ Fabric รองรับการรวม Azure DevOps Git สําหรับการควบคุมแหล่งที่มา การแยกสาขา และไปป์ไลน์การปรับใช้ ซึ่งแตกต่างจาก Synapse (ซึ่งใช้เทมเพลต ARM สําหรับ CI/CD) Fabric ใช้โมเดลตามพื้นที่ทํางานที่คุณเชื่อมต่อพื้นที่ทํางานกับสาขา Git และซิงค์รายการโดยตรง โน้ตบุ๊ก สภาพแวดล้อม และ SJD ทั้งหมดรองรับการรวม Git ตั้งค่าไปป์ไลน์การปรับใช้ (Dev → Test → Prod) เพื่อจัดการการเลื่อนระดับข้ามสภาพแวดล้อม

เนื้อหาที่เกี่ยวข้อง

  • Last updated on