Databricks เพิ่มฟีเจอร์ปรับจำนวนพาร์ติชันสถานะตามต้องการสำหรับ Spark Structured Streaming
Databricks ประกาศเปิดตัวฟีเจอร์ Public Preview ที่ให้เควรี Structured Streaming เปลี่ยนจำนวนพาร์ติชันได้โดยไม่ต้องสร้างเชคพอยต์ใหม่
คำตอบโดยย่อ
Databricks ประกาศอะไรเกี่ยวกับการจัดการสถานะของ Apache Spark Structured Streaming
Databricks ประกาศฟีเจอร์การปรับจำนวนพาร์ติชันสถานะตามต้องการ (on-demand state repartitioning) ซึ่งเป็นฟีเจอร์ระดับ Public Preview บน Databricks Runtime 18 ขึ้นไป ที่ช่วยให้เควรี Structured Streaming แบบมีสถานะสามารถเปลี่ยนจำนวนพาร์ติชันได้ด้วยการรีสตาร์ทพร้อมค่าคอนฟิกใหม่ โดยไม่สูญเสียหรือต้องสร้างสถานะเชคพอยต์ขึ้นใหม่
ประเด็นสำคัญ
- Databricks ประกาศฟีเจอร์การปรับจำนวนพาร์ติชันสถานะตามต้องการสำหรับ Apache Spark Structured Streaming ซึ่งขณะนี้อยู่ในระดับ Public Preview บน Databricks Runtime 18 ขึ้นไป
- ฟีเจอร์นี้ช่วยให้ผู้ใช้เปลี่ยนจำนวนพาร์ติชันของเควรีสตรีมมิงแบบมีสถานะได้ผ่านค่าคอนฟิกใหม่ spark.sql.streaming.stateStore.partitions ซึ่งมีความสำคัญเหนือกว่า spark.sql.shuffle.partitions สำหรับเควรีแบบมีสถานะ
- เดิมทีจำนวนพาร์ติชันจะถูกล็อกไว้ตั้งแต่ตอนสร้างเชคพอยต์ และการเปลี่ยน spark.sql.shuffle.partitions จะไม่มีผลใดๆ เว้นแต่จะทิ้งเชคพอยต์เดิมและสูญเสียสถานะที่สะสมไว้
- Databricks ระบุว่าเงื่อนไขในการใช้งานคือต้องใช้ Databricks Runtime 18 ขึ้นไป และตัวจัดเก็บสถานะ RocksDB ซึ่งเป็นค่าเริ่มต้นใน DBR 17.3 ขึ้นไป
- Databricks ระบุว่า Coveo ซึ่งเป็นผู้ใช้งานรายแรกๆ สามารถลดค่าใช้จ่ายด้าน Amazon S3 API ที่เกี่ยวข้องลงได้ถึง 40% หลังจากนำความสามารถดังกล่าวไปใช้งาน ตามคำกล่าวของ Alexis Chicoine จาก Coveo ที่ระบุไว้ในประกาศดังกล่าว
Databricks ประกาศเปิดตัวฟีเจอร์การปรับพาร์ทิชันสถานะตามความต้องการ (on-demand state repartitioning) สำหรับ Apache Spark Structured Streaming ซึ่งเป็นความสามารถในระดับ Public Preview ที่ช่วยให้วิศวกรปรับจำนวนพาร์ทิชันในสตรีมมิงเควรีแบบมีสถานะ (stateful) ได้โดยไม่ต้องสร้างเชกพอยต์ใหม่หรือสูญเสียสถานะที่สะสมไว้ ฟีเจอร์นี้พร้อมใช้งานบน Databricks Runtime 18 ขึ้นไป
สิ่งที่เปลี่ยนแปลง
Databricks ระบุว่า ที่ผ่านมาสตรีมมิงเควรีแบบมีสถานะจะถูกล็อกจำนวนพาร์ทิชันไว้ตั้งแต่ตอนที่สร้างเชกพอยต์ การเปลี่ยนค่าคอนฟิกมาตรฐานอย่าง spark.sql.shuffle.partitions แล้วรีสตาร์ตเควรีจะไม่มีผลใดๆ เพราะโครงสร้างพาร์ทิชันถูกฝังไว้ในเชกพอยต์แล้ว ทางเลือกเดียวที่มีมาก่อนหน้านี้ ตามที่ Databricks ระบุ คือการทิ้งเชกพอยต์เดิมแล้วเริ่มต้นใหม่ ซึ่งหมายถึงการสูญเสียสถานะทั้งหมดที่เควรีสะสมไว้ เช่น ข้อมูลการติดตามการฉ้อโกงในบัญชีนับล้าน หรือหน้าต่างเซสชันที่ครอบคลุมหลายวัน
Databricks ระบุว่าฟีเจอร์การปรับพาร์ทิชันสถานะตามความต้องการช่วยขจัดข้อจำกัดดังกล่าว โดยสามารถใช้ได้กับสตรีมมิงเควรีแบบมีสถานะทุกประเภท ไม่ว่าจะเป็นการรวมข้อมูล (aggregation) การจอยน์แบบสตรีมต่อสตรีม (stream-stream join) การขจัดข้อมูลซ้ำ (deduplication) การจัดกลุ่มเซสชัน (sessionization) และงานที่ใช้ transformWithState
วิธีการทำงาน
Databricks ระบุว่าผู้ใช้ต้องตั้งค่าคอนฟิกเฉพาะ spark.sql.streaming.stateStore.partitions แล้วรีสตาร์ตเควรี ค่านี้จะมีความสำคัญเหนือกว่า spark.sql.shuffle.partitions สำหรับเควรีแบบมีสถานะ เมื่อรีสตาร์ต เควรีจะทำไมโครแบตช์ที่ค้างอยู่ให้เสร็จก่อน จากนั้นจะดำเนินการปรับพาร์ทิชันครั้งเดียว ซึ่งจะกระจายข้อมูลสถานะใหม่ตามจำนวนพาร์ทิชันที่กำหนด พร้อมแฮชคีย์ใหม่ให้ไปอยู่ในตำแหน่งที่ถูกต้อง เมื่อขั้นตอนนี้เสร็จสิ้น เควรีจะกลับมาประมวลผลต่อภายใต้จำนวนพาร์ทิชันใหม่
Databricks ระบุว่าเงื่อนไขในการใช้ฟีเจอร์นี้คือต้องใช้ Databricks Runtime 18 ขึ้นไป และต้องใช้ตัวให้บริการสถานะแบบ RocksDB (RocksDB state store provider) ซึ่งเป็นค่าเริ่มต้นสำหรับเควรีใหม่ที่สร้างบน DBR 17.3 ขึ้นไป
การตรวจสอบ
Databricks ระบุว่าระยะเวลาในการปรับพาร์ทิชันจะปรากฏในอีเวนต์ StreamingQueryProgress มาตรฐาน โดยเฉพาะในเมตริก durationMs ภายใต้ฟิลด์ที่ชื่อว่า controlBatch.REPARTITION บริษัทระบุว่าระยะเวลาในการปรับพาร์ทิชันจะแปรผันตามปริมาณสถานะที่เกี่ยวข้อง แต่คาดว่าสำหรับงานส่วนใหญ่จะใช้เวลาเพียงไม่กี่วินาที
กรณีการใช้งานที่ยกตัวอย่าง
Databricks อธิบายสถานการณ์การใช้งาน 3 รูปแบบสำหรับฟีเจอร์นี้ ได้แก่ การปรับขนาดเควรีให้เหมาะสมหลังเปิดใช้งานจริง เมื่อจำนวนพาร์ทิชันเริ่มต้นที่ตั้งไว้สำหรับโครงการนำร่องขนาดเล็กไม่เพียงพอต่อการเติบโตอีกต่อไป เช่น สตรีมการให้คะแนนการฉ้อโกงที่ขยายจากภูมิภาคเดียวไปสู่หลายภูมิภาค การปรับตัวตามภาระงานที่เปลี่ยนแปลง เช่น ไปป์ไลน์การประมูลโฆษณาที่สามารถเพิ่มจำนวนพาร์ทิชันในช่วงกลางวันที่มีทราฟฟิกสูง และลดลงในช่วงกลางคืน และการเติมข้อมูลย้อนหลัง (backfilling) ซึ่งสามารถใช้จำนวนพาร์ทิชันที่สูงขึ้นเป็นการชั่วคราวเพื่อเร่งการประมวลผลข้อมูลในอดีตให้เร็วขึ้น ก่อนจะปรับลดกลับสู่ระดับปกติสำหรับทราฟฟิกในภาวะคงที่
ตัวอย่างจากลูกค้า
Databricks อ้างคำพูดของ Alexis Chicoine ตำแหน่ง Senior Software Developer ที่ Coveo ซึ่งเป็นหนึ่งในผู้ใช้งานฟีเจอร์นี้ในระยะแรก โดยระบุว่า Coveo รันไปป์ไลน์สตรีมมิงแบบมีสถานะขนาดใหญ่ที่มีปริมาณข้อมูลผันผวน และสามารถลดค่าใช้จ่ายด้าน Amazon S3 API ที่เกี่ยวข้องได้ถึง 40% จากการใช้ความสามารถนี้ Chicoine กล่าวว่าก่อนหน้านี้บริษัทต้องเลือกระหว่างการจัดสรรทรัพยากรเผื่อไว้เกินความจำเป็น หรือการสร้างเชกพอยต์ใหม่ทั้งหมด ซึ่งทำให้ค่าใช้จ่ายด้าน storage API เข้าใกล้ค่าใช้จ่ายด้านการประมวลผล และปัจจุบันบริษัทสามารถปรับขนาดได้โดยไม่รบกวนสถานะที่มีอยู่หรือกระตุ้นให้เกิดการย้ายเชกพอยต์
ที่มา: Databricks blog, "Announcing On-Demand State Repartitioning for Apache Spark™ Structured Streaming on Databricks," เผยแพร่เมื่อวันที่ 14 กันยายน 2026
คำถามที่พบบ่อย
- การปรับจำนวนพาร์ติชันสถานะตามต้องการคืออะไร
- เป็นฟีเจอร์ระดับ Public Preview จาก Databricks ที่ช่วยให้เควรี Apache Spark Structured Streaming แบบมีสถานะสามารถเปลี่ยนจำนวนพาร์ติชันสถานะได้ ด้วยการหยุดและรีสตาร์ทเควรี โดยยังคงสถานะเชคพอยต์เดิมไว้ครบถ้วน
- ต้องมีอะไรบ้างจึงจะใช้ฟีเจอร์นี้ได้
- Databricks ระบุว่าต้องใช้ Databricks Runtime 18 ขึ้นไป และตัวจัดเก็บสถานะ RocksDB ซึ่งเป็นค่าเริ่มต้นอยู่แล้วสำหรับเควรีใหม่ที่สร้างบน DBR 17.3 ขึ้นไป
- จะเปลี่ยนจำนวนพาร์ติชันได้อย่างไร
- Databricks ระบุว่าให้หยุดเควรี ตั้งค่าคอนฟิก spark.sql.streaming.stateStore.partitions เป็นค่าใหม่ แล้วรีสตาร์ทเควรีโดยใช้เชคพอยต์เดิม จากนั้นเควรีจะกระจายสถานะใหม่ให้ตรงกับจำนวนที่กำหนดก่อนกลับมาประมวลผลต่อ
- จะตรวจสอบการดำเนินการปรับพาร์ติชันได้อย่างไร
- Databricks ระบุว่าอีเวนต์ StreamingQueryProgress จะรายงานระยะเวลาของการดำเนินการนี้ในเมทริก durationMs ภายใต้ฟิลด์ controlBatch.REPARTITION