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

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

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

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

  • แมป Synapse RBAC และรูปแบบเครือข่ายกับพื้นที่ทํางาน Fabric, OneLake และการควบคุมเครือข่ายที่มีการจัดการ
  • ฟื้นฟูกระบวนการกํากับดูแลและการป้องกันโดยใช้ OneLake Catalog และ การป้องกันข้อมูลของ 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

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

ใช้ OneLake Catalog เพื่อค้นหาและควบคุมสินค้า Fabric ที่ถูกย้าย และตรวจสอบสายพันธุ์ของสินค้าเหล่านั้น ใช้ การป้องกันข้อมูลของ Microsoft 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 ตรวจสอบว่ารายการที่ย้ายปรากฏใน OneLake Catalog และตรวจสอบสายพันธุ์ของรายการเหล่านั้น
  • 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) เพื่อจัดการการเลื่อนระดับข้ามสภาพแวดล้อม

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

  • อัปเดตล่าสุดเมื่อ