ย้ายจาก Fabric Runtime 1.3 ไปยัง Runtime 2.0

Fabric Runtime 2.0 เป็นรันไทม์ล่าสุดที่มีให้ใช้งานทั่วไป (GA) และเป็นรันไทม์เริ่มต้นสําหรับงาน Apache Spark ใน Microsoft Fabric มันอัปเดตระบบปฏิบัติการ Java, Scala, Python, R, Apache Spark และ Delta Lake เนื่องจากการอัปเดตหลายรายการข้ามขอบเขตของเวอร์ชันหลัก ให้ตรวจสอบสมุดบันทึก คํานิยามงาน Spark ไลบรารี และท่อข้อมูลก่อนย้ายงานผลิตจาก Runtime 1.3

คู่มือนี้อธิบายการเปลี่ยนแปลงที่อาจส่งผลต่อการย้ายข้อมูล และให้กระบวนการแบบแบ่งขั้นตอนสําหรับการย้ายงานของคุณไปยัง Runtime 2.0

สิ่งที่เปลี่ยนแปลงใน Runtime 2.0

ตารางต่อไปนี้เปรียบเทียบส่วนประกอบหลักใน Runtime 1.3 และ Runtime 2.0

Runtime 2.0 ยังมีความสามารถใหม่ของ Apache Spark 4.1 รวมถึงVARIANTชนิดข้อมูล ฟังก์ชันที่ผู้ใช้กําหนดเองใน SQL ตัวแปรเซสชัน ไวยากรณ์ของท่อ การจัดเรียงสตริง Python API Python Data Source ฟังก์ชันตารางที่ผู้ใช้กําหนดเอง การจัดโปรไฟล์ PySpark แบบรวมศูนย์ และ API การจัดการสถานะและดีบัก Structured Streaming ใหม่ ๆ สําหรับภาพรวม ดูที่ Runtime 2.0 ใน Fabric

ตรวจสอบการเปลี่ยนแปลงความเข้ากันได้

ตรวจสอบพื้นที่ต่อไปนี้ก่อนที่คุณจะเปลี่ยนพื้นที่ทํางานหรือสภาพแวดล้อมเป็น Runtime 2.0

ไลบรารีในตัวและแบบกําหนดเอง

Runtime 2.0 ลบแพ็กเกจ Python และ R ที่ติดตั้งไว้ล่วงหน้าหลายตัวที่มีใน Runtime 1.3 การลดชุดแพ็กเกจเริ่มต้นช่วยให้รันไทม์มีความกระชับและลดพื้นที่สําหรับเหตุการณ์ความปลอดภัยที่อาจเกิดขึ้น แพ็กเกจที่พร้อมใช้งานโดยไม่ต้องกําหนดค่าใน Runtime 1.3 อาจจําเป็นต้องถูกเพิ่มอย่างชัดเจนในสภาพแวดล้อม Runtime 2.0 ของคุณ

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

• เปรียบเทียบรายการแพ็กเกจ Runtime 1.3 และ Runtime 2.0 ในที่เก็บข้อมูล Fabric runtime release
• เพิ่มไลบรารี PyPI, Conda, Maven, R หรือไลบรารีที่กําหนดเองที่ขาดหายไปลงในสภาพแวดล้อมและเผยแพร่
• เวอร์ชันพินสําหรับงานผลิตเพื่อให้การแก้ไขการพึ่งพาสามารถทําซ้ําได้
• ยืนยันว่าแพ็กเกจ Python รองรับ Python 3.13 แพ็กเกจที่มีส่วนขยายเนทีฟต้องมีวงล้อ Linux ที่รองรับ หรือสร้างบน Azure Linux 3.0 ได้สําเร็จ
• แทนที่การพึ่งพาของ Scala 2.12 ด้วยอาร์ติแฟกต์ของ Scala 2.13 ชื่อวัตถุมักรวมถึงเวอร์ชันไบนารีของ Scala เช่น _2.12 หรือ _2.13.
• คอมไพล์ไฟล์ JAR แบบกําหนดเองใหม่บน Java 21, Scala 2.13 และ Spark 4.1 ทดสอบการพึ่งพาแบบถ่ายโอนสําหรับความขัดแย้งกับไลบรารีที่จัดเตรียมโดย runtime
• สร้างไลบรารีเนทีฟแบบกําหนดเองสําหรับ Azure Linux 3.0 ใหม่

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

แพ็กเกจที่ถูกลบออกจากสภาพแวดล้อมเริ่มต้น

รายการต่อไปนี้ประกอบด้วยแพ็กเกจที่ผู้ใช้ใช้งานและความสัมพันธ์ระดับต่ําหรือแบบถ่ายโอน ค้นหารายการเหล่านี้เพื่อหาแพ็กเกจที่งาน Runtime 1.3 ของคุณใช้ หากมีแพ็กเกจอยู่ในรายการ ให้เพิ่มเวอร์ชันที่เข้ากันได้กับ Python 3.13 หรือ R 4.5 ผ่าน Library Manager ในสภาพแวดล้อม Runtime 2.0 ของคุณ

การเปลี่ยนแปลงการตั้งค่าประกายไฟ

Runtime 2.0 เพิ่มและลบการตั้งค่า Spark และเปลี่ยนค่าเริ่มต้นบางส่วน Fabric ยังใช้การตั้งค่าเริ่มต้นที่แตกต่างจาก Apache Spark สําหรับบางการตั้งค่า

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

การเปลี่ยนแปลงค่าตั้งต้นที่สําคัญ

ตารางต่อไปนี้แสดงการเปลี่ยนแปลงฐานที่เลือกไว้ ไม่ตั้งค่า หมายความว่าค่าฐานไม่ได้กําหนดค่าอย่างชัดเจน;ไม่ได้หมายความว่าฟีเจอร์นั้นถูกปิดใช้งาน

Runtime 2.0 ยังใช้ ROCKSDB แทน LEVELDB for spark.shuffle.service.db.backend และตั้งค่า spark.shuffle.service.removeShuffle เป็น true. Spark ใช้บริการสับเปลี่ยนภายนอกเพื่อลบบล็อกสับเปลี่ยนที่ไม่จําเป็นสําหรับผู้ดําเนินการที่ถูกยกเลิก

การโหลดสแนปช็อตแบบขนานแบบเดลต้า การข้ามข้อมูลแบบขนาน และการโหลดสแนปช็อตฝั่งคนขับก็เปลี่ยนไปด้วยfalsetrue ทดสอบความหน่วงของคิวรีและการใช้ทรัพยากรไดรเวอร์ โดยเฉพาะสําหรับคิวรีที่เข้าถึงหลายตาราง Delta

การแทนที่การเริ่มต้นเซสชันและการทํางานแบบเนทีฟ

การเปิดตัวฟีเจอร์ Fabric สามารถแทนที่ค่าพื้นฐานเมื่อเริ่มเซสชันได้

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

• ตรวจสอบการใช้งานหน่วยความจําโดยขนาดชุดคอลัมน์เริ่มต้นเพิ่มขึ้นจาก 4,096 เป็น 10,240
• เปรียบเทียบแผนการสับเปลี่ยนและประสิทธิภาพกับเกณฑ์การสับแบบคอลัมน์ที่อิงการจัดเรียงลดลงจาก 100,000 เป็น 4,000 พาร์ติชัน
• เปรียบเทียบผลลัพธ์และประสิทธิภาพจากการแสดงออกปกติ การรองรับ regex Java แบบเนทีฟเอนจินจะเปลี่ยนจากปิดเป็นเปิดใช้งาน และการตั้งค่าที่ regex ทั้งหมดกลับไปใช้ Spark จะเปลี่ยนจาก true เป็น false.

ค่าเริ่มต้นของ Apache Spark 4.1 ถูกเก็บไว้ใน Fabric แตกต่างกัน

Fabric Runtime 2.0 ตั้งใจแทนที่ค่าเริ่มต้นของ Apache Spark 4.1 ดังต่อไปนี้ อย่าคิดว่าค่าเริ่มต้นของ Spark 4.1 ต้นทางจะใช้ได้เหมือนเดิมใน Fabric

พฤติกรรมของ Spark SQL และ DataFrame

Spark 4.1 แนะนําการเปลี่ยนแปลงพฤติกรรมที่อาจเปลี่ยนแปลงผลลัพธ์ของคําสั่งค้นหาหรือทําให้คําสั่งค้นหาที่เคยได้รับการยอมรับล้มเหลว ให้ความสนใจเป็นพิเศษกับพฤติกรรม SQL ของ ANSI, การแปลงข้อมูล, การดําเนินการวันที่และเวลาประทับ, ชนิดข้อมูล, การแมป JDBC และการตั้งค่า SQL ที่ถูกยกเลิกการใช้งาน

รันการทดสอบถดถอยที่เปรียบเทียบ:

• สคีมาผลลัพธ์ รวมถึงประเภท ความแม่นยํา ขนาด และ nullability
• จํานวนแถวและผลลัพธ์รวม
• พฤติกรรมการแปลงเป็นศูนย์, ล้น, หารด้วยศูนย์ และ cast ไม่ถูกต้อง
• วันที่ เวลา เขตเวลา และช่วงเวลา ผลลัพธ์
• การแมปประเภทต้นทางและซิงก์ของ JDBC
• แผนการสืบค้นและประสิทธิภาพของงานสําหรับงานสําคัญ

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

API ของ Python และ pandas บน Spark

Runtime 2.0 ย้ายจาก Python 3.11 มาเป็น Python 3.13 และรวมการเปลี่ยนแปลงของ PySpark ที่เพิ่มเข้ามาใน Spark 4.1 Spark 4.1 ยังเพิ่มเวอร์ชันขั้นต่ําที่รองรับของ pandas, NumPy และ PyArrow และลบ API ที่ถูกยกเลิกในเวอร์ชันก่อนหน้า

API แพนด้าที่พบบ่อยในการอัปเดต Spark ได้แก่:

• แทนที่ DataFrame.iteritems และ Series.iteritems ด้วย items.
• แทนที่ DataFrame.append และ Series.append ด้วย ps.concat.
• แทนที่พารามิเตอร์ที่ถูกลบ inplace ในการดําเนินการเชิงหมวดหมู่ด้วยการกําหนดค่า
• ตรวจสอบชื่อพารามิเตอร์ที่เปลี่ยนแปลงและค่าเริ่มต้น เช่น inclusive และSeries.str.replace(regex=...)
• ตรวจสอบชื่อคอลัมน์ผลลัพธ์ ชื่อดัชนี ประเภท DTYPES และลําดับ

สําหรับรายการทั้งหมด โปรดดูคู่มือการย้ายข้อมูล PySpark

แอปพลิเคชัน Java และ Scala

Scala 2.13 ไม่สามารถใช้งานร่วมกับ Scala 2.12 ได้แบบไบนารี การใช้ JAR ของ Runtime 1.3 ซ้ําใน Runtime 2.0 อาจทําให้เกิดข้อผิดพลาดในการโหลดคลาส แม้ว่าซอร์สโค้ดจะยังไม่เปลี่ยนแปลง สร้างอาร์ติแฟกต์ Runtime 2.0 แยกต่างหากและอัปเดตการพึ่งพาข้ามระบบที่สร้างใน Scala ทั้งหมด

Spark 4.1 ยังเปลี่ยนการอ้างอิง API servlet ภายในจาก javax เป็น jakarta. ตรวจสอบผู้ฟังแบบกําหนดเอง, ส่วนขยาย Spark และไลบรารีที่มีปฏิสัมพันธ์กับภายในของ Spark สําหรับการเปลี่ยนแปลงระดับเอนจินอื่น ๆ โปรดดูคู่มือการย้ายระบบ Spark Core

การสตรีมงานและตัวเชื่อมต่อ

ซอฟต์แวร์ที่ถูก EventHubConnector ยกเลิกใน Runtime 1.3 ไม่มีให้ใช้งานใน Runtime 2.0 ใช้ตัวเชื่อมต่อ Apache Spark Kafka กับปลายทางที่เข้ากันได้กับ Kafka สําหรับ Azure Event Hubs สําหรับคําแนะนําในการตั้งค่า ดูที่ Use Apache Spark with Azure Event Hubs for Apache Kafka.

สําหรับสถานการณ์ที่เกี่ยวข้อง คุณยังสามารถประเมิน Fabric eventstream เพื่อรับข้อมูลสตรีมและประมวลผลในโน้ตบุ๊กด้วย Spark Structured Streaming สําหรับข้อมูลเพิ่มเติม ดูที่ Query eventstream in Microsoft Fabric from a notebook with Spark Structured Streaming

สําหรับแต่ละภาระงาน Structured Streaming:

• ทดสอบว่าคําสั่ง Runtime 2.0 สามารถรีสตาร์ทจากสําเนาของจุดตรวจสอบที่มีอยู่ได้หรือไม่
• ตรวจสอบการดําเนินการแบบสถานะ, ลายน้ําเวลาเหตุการณ์, ทริกเกอร์, ตัวเลือกต้นทางและซัด, และสคีมาผลลัพธ์
• เก็บข้อมูลต้นทางและจุดตรวจสอบต้นฉบับไว้จนกว่าการตรวจสอบจะเสร็จสิ้น
• ถ้าจุดตรวจไม่เข้ากัน ให้วางแผนรีสตาร์ทแบบควบคุมด้วยจุดตรวจใหม่ คํานึงถึงการรีเพลย์หรือการข้ามอินพุต และตั้งค่าซิงค์ให้เป็น idempotent ก่อนเริ่มใหม่

ตรวจสอบ คู่มือการย้ายข้อมูลแบบ Structured Streaming เพื่อดูการเปลี่ยนแปลงความเข้าได้ของต้นทาง

ตารางทะเลสาบเดลต้า

Delta Lake รักษาความเข้ากันได้ย้อนหลังสําหรับตารางที่มีอยู่ ดังนั้น Runtime 2.0 จึงสามารถทํางานร่วมกับตารางที่สร้างโดย Runtime 1.3 ได้ อย่างไรก็ตาม การเปิดใช้งานฟีเจอร์ตารางใหม่อาจทําให้โปรโตคอลอ่านหรือเขียนของตารางสูงขึ้น และป้องกันไม่ให้เอนจินเก่าหรือประสบการณ์ Fabric อื่น ๆ ใช้ตารางได้

ในระหว่างการย้ายข้อมูลขณะรันไทม์ครั้งแรก:

• อย่าอัปเกรดโปรโตคอลตารางหรือเปิดใช้งานฟีเจอร์ของ Delta Lake 4.2
• ตรวจสอบฟีเจอร์และเวอร์ชันโปรโตคอลของตารางที่สร้างใหม่ รวมถึงตารางที่มีอยู่แล้ว Runtime 2.0 ตั้งค่า spark.databricks.delta.properties.defaults.enableDeletionVectors เป็น true; ตรวจสอบเมตาดาต้าของตารางที่ได้ แทนที่จะสมมติว่าการหลีกเลี่ยงการเปิดใช้งานฟีเจอร์ด้วยตนเองจะรักษาความเข้ากันได้
• ทดสอบการอ่าน เขียน รวม การพัฒนาสคีมา การบํารุงรักษา และการเข้าถึงพร้อมกัน
• ระบุเอนจินทุกตัวที่อ่านหรือเขียนแต่ละตาราง รวมถึงปลายทางวิเคราะห์ SQL, Power BI, pipeline, dataflows, eventstreams และเอนจินภายนอก
• เปิดใช้งานฟีเจอร์ Delta ใหม่ก็ต่อเมื่อผู้บริโภคทุกคนสนับสนุนแล้ว

ฟีเจอร์เฉพาะของ Delta Lake 4.2 ยังเป็นการทดลองใน Fabric และจํากัดเฉพาะประสบการณ์ของ Spark เท่านั้น สําหรับเมทริกซ์สนับสนุนและเวอร์ชันโปรโตคอลเริ่มต้น ดูที่ ความสามารถในการทํางานร่วมกันของตาราง Delta Lake

ย้ายงานของคุณ

ใช้การย้ายข้อมูลแบบแบ่งขั้นตอนแทนการเปลี่ยนเวลารันไทม์สําหรับพื้นที่ทํางานในการผลิตทันที

1. จัดทําบัญชีงาน Runtime 1.3 ของคุณ

บันทึกข้อมูลดังต่อไปนี้:

• สมุดบันทึก, คํานิยามงาน Spark, pipeline, ตารางเวลา และรายการที่ขึ้นกับกัน
• การกําหนดสภาพแวดล้อมระดับพื้นที่ทํางานและระดับรายการ
• การกําหนดค่าสปาร์ก รวมถึงการตั้งค่าความเข้ากันได้แบบเก่า
• ไลบรารีสาธารณะ ส่วนตัว และแบบกําหนดเอง รวมถึงเวอร์ชันที่แก้ไขแล้ว
• ไฟล์ JAR แบบกําหนดเอง, วงล้อ Python, แพ็กเกจ R, ไลบรารีเนทีฟ และตรรกะการเริ่มต้น
• แหล่งข้อมูล ปลายทาง ความลับ การเชื่อมต่อ และความต้องการเครือข่าย
• ตารางเดลต้าและผู้ใช้ตารางเหล่านั้นที่ไม่ใช่ Spark ทุกคน
• การสตรีมจุดตรวจสอบ, สคีมา, ออฟเซ็ต และข้อกําหนดการกู้คืน
• สคีมาผลลัพธ์ที่คาดหวัง จํานวนแถว การตรวจสอบคุณภาพข้อมูล และค่าพื้นฐานประสิทธิภาพ

จัดลําดับความสําคัญของงานที่ใช้ไลบรารีที่กําหนดเอง โค้ดเนทีฟ Scala สถานะสตรีมมิ่ง หรือฟีเจอร์ขั้นสูงของ Delta

2. สร้างสภาพแวดล้อมทดสอบ Runtime 2.0

สร้างรายการสภาพแวดล้อมแยกต่างหากและเลือก 2.0 (Spark 4.1, Delta 4.2) เป็นเวลารันไทม์ เพิ่มไลบรารีที่จําเป็น บันทึกสภาพแวดล้อม และเผยแพร่ แนบสภาพแวดล้อมกับสําเนาสมุดบันทึกตัวแทนและคํานิยามงาน Spark ในพื้นที่ทํางานพัฒนาหรือทดสอบ

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

เพื่อยืนยันการอัปเดต Runtime 2.0 ที่จะมาถึงก่อนที่จะถึงช่องทางเริ่มต้น ให้ใช้ช่องทางการปล่อยเวอร์ชัน Early Access ในสภาพแวดล้อมทดสอบของคุณ สําหรับข้อมูลเพิ่มเติม โปรดดูที่ Fabric runtime release channels

3. อัปเดตไลบรารีและโค้ด

นําการเปลี่ยนแปลงที่ระบุในการตรวจสอบความเข้ากันได้ไปใช้:

1. แทนที่แพ็กเกจที่ขาดหายไปด้วยสภาพแวดล้อมที่ขึ้นกับสภาพแวดล้อมอย่างชัดเจน
2. อัปเกรดหรือเปลี่ยนแพ็กเกจที่ไม่รองรับ Python 3.13, Java 21, Scala 2.13 หรือ Azure Linux 3.0
3. สร้างไฟล์ JAR แบบกําหนดเองและไบนารีเนทีฟใหม่.
4. อัปเดตได้ลบ API ของ PySpark และ pandas ออกเมื่อเรียก Spark
5. เปลี่ยน EventHubConnector เป็นขั้วต่อ Kafka
6. ลบการตั้งค่า Spark สําหรับการกําหนดค่าที่ไม่มีใน Runtime 2.0 และตรวจสอบการแทนที่การกําหนดค่าที่ค่าเริ่มต้นถูกเปลี่ยนอย่างชัดเจน
7. แก้ไขความแตกต่างของพฤติกรรม Spark SQL ในโค้ดแทนที่จะพึ่งพาการตั้งค่าเดิมอย่างถาวร
8. รักษาฟีเจอร์และโปรโตคอลของตาราง Delta ที่มีอยู่ให้คงที่ในขั้นตอนนี้

4. รันการทดสอบความเข้ากันได้และการถดถอย

รันอินพุตตัวแทนเดียวกันบน Runtime 1.3 และ Runtime 2.0 เปรียบเทียบ:

• สถานะการเสร็จสิ้น บันทึก คําเตือน และการลองใหม่
• สคีมาและชนิดข้อมูล
• ผลลัพธ์ระดับแถวและผลรวม
• ประวัติและโปรโตคอลของตารางเดลต้า
• ความคืบหน้าในการสตรีม สถานะ ความหน่วง และการจัดการไฟล์ซ้ํา
• ระยะเวลาการดําเนินการ การใช้ทรัพยากร และต้นทุน
• ผลลัพธ์ที่ปลายทางจะนําไปสู่ปลายทางการวิเคราะห์ SQL, Power BI, ท่อส่งข้อมูล และผู้บริโภคอื่น ๆ

รวมการทดสอบความล้มเหลวและการกู้คืน ไม่ใช่แค่การทดสอบที่ประสบความสําเร็จเท่านั้น การรีสตาร์ทเซสชันทดสอบ, การรีไทร์งาน, การกู้คืนจุดตรวจสอบ และการเข้าถึงตารางพร้อมกัน

5. เปิดตัว Runtime 2.0

ย้ายงานในชุดงานที่ควบคุมได้:

1. เผยแพร่สภาพแวดล้อม Runtime 2.0 ที่ผ่านการตรวจสอบแล้ว
2. แนบกับชุดสมุดบันทึกการผลิตขนาดเล็กหรือคํานิยามงานของ Spark
3. รันชุดและตรวจสอบผลลัพธ์และผู้บริโภคปลายทาง
4. ดําเนินการกับงานที่เหลือหลังจากช่วงเวลาสังเกตการณ์
5. ตั้งค่า Runtime 2.0 เป็นค่าเริ่มต้นของพื้นที่ทํางานหลังจากการย้ายข้อมูลระดับรายการเสร็จสิ้น

การเปลี่ยนแปลงเวลารันไทม์ของ workspace จะมีผลต่อเซสชัน Spark ใหม่ เซสชันที่มีอยู่ยังคงใช้เวลารันปัจจุบันจนกว่าจะหยุดทํางาน

6. รักษาเส้นทางการย้อนกลับ

เก็บสภาพแวดล้อม Runtime 1.3, อาร์ติแฟกต์, ข้อกําหนดไลบรารี และจุดตรวจสอบการสตรีมไว้จนกว่าช่วงเวลาการสังเกต Runtime 2.0 จะสิ้นสุดลง หากต้องการย้อนกลับ ให้แนบสภาพแวดล้อม Runtime 1.3 ใหม่หรือกู้คืน workspace runtime ก่อนหน้าและเริ่มเซสชัน Spark ใหม่

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

ก่อนที่คุณจะทําการย้ายข้อมูลให้เสร็จสิ้น โปรดยืนยันว่า:

• [ ] แพ็กเกจ Python และ R ที่จําเป็นทุกตัวมีให้ใช้งานและเข้ากันได้กับ Python 3.13 หรือ R 4.5 อย่างชัดเจน
• [ ] ไฟล์ JAR แบบกําหนดเองมุ่งเป้าไปที่ Java 21, Scala 2.13 และ Spark 4.1
• [ ] Native dependencies ทํางานบน Azure Linux 3.0
• [ ] การตั้งค่าการกําหนดงานของ Workspace, Environment, สมุดบันทึก และ Spark จะไม่ใช้การกําหนดค่า Spark ที่ถูกลบออก
• [ ] งานจะถูกทดสอบกับค่าเริ่มต้นการกําหนดค่า Runtime 2.0 Spark ที่เปลี่ยนแปลง
• [ ] การทดสอบถดถอย Spark SQL และ PySpark ผ่านการทดสอบ
• [ ] เวิร์กโหลดของ Event Hubs ใช้ตัวเชื่อมต่อ Kafka
• [ ] ภาระงาน Structured Streaming จะรีสตาร์ทและกู้คืนตามที่ออกแบบไว้
• [ ] โปรโตคอลและฟีเจอร์ของตารางเดลต้ายังคงเข้ากันได้กับผู้บริโภคทุกประเภท
• [ ] คุณภาพข้อมูล ประสิทธิภาพ และผลลัพธ์ด้านต้นทุนตรงตามเกณฑ์การยอมรับของคุณ
• [ ] ขั้นตอนการเปิดตัวการผลิต การตรวจสอบ และการย้อนกลับถูกบันทึกและทดสอบ

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

• รันไทม์ 2.0 ใน Fabric
• รันไทม์ Apache Spark ใน Fabric
• วงจรชีวิตการทํางานของ Apache Spark ใน Fabric
• จัดการไลบรารีในสภาพแวดล้อม Fabric
• การปล่อยและอัปเดต Spark Runtime