Databricks Pricing Guide 2026: ค่าใช้จ่าย DBU และรายละเอียด

สรุปโดยย่อ: การกำหนดราคาของ Databricks ใช้รูปแบบตามการใช้งานซึ่งรวมเอา Databricks Units (DBUs) ที่คิดค่าบริการตามประเภทของเวิร์กโหลด และค่าใช้จ่ายโครงสร้างพื้นฐานคลาวด์พื้นฐานจาก AWS, Azure หรือ GCP อัตรา DBU แตกต่างกันไปตามระดับการสมัครสมาชิก (Standard, Premium, Enterprise) และประเภทของการประมวลผล โดยค่าประมวลผลสำหรับ Jobs เริ่มต้นที่ประมาณ 0.15 ดอลลาร์สหรัฐฯ ต่อ DBU และค่าประมวลผลแบบ All-Purpose มีราคาสูงกว่า 2-3 เท่า ค่าใช้จ่ายรายเดือนทั้งหมดขึ้นอยู่กับปริมาณเวิร์กโหลด การกำหนดค่าคลัสเตอร์ และแนวทางการปรับให้เหมาะสม

การกำหนดราคาของ Databricks ทำให้ทุกคนสับสน ถามผู้นำด้านวิศวกรรมหรือ CFO เกี่ยวกับคำถามง่ายๆ คำถามหนึ่ง—"Databricks จะมีค่าใช้จ่ายเท่าไร"—และคำตอบเกือบทั้งหมดจะเป็นรูปแบบของ "ขึ้นอยู่กับ"

และนั่นก็เป็นความจริง แพลตฟอร์มนี้ทำงานบนโครงสร้างต้นทุนแบบคู่: Databricks Units (DBUs) สำหรับเวิร์กโหลดการประมวลผล บวกกับค่าใช้จ่ายโครงสร้างพื้นฐานจากผู้ให้บริการคลาวด์ที่ขับเคลื่อนแพลตฟอร์ม สิ่งที่ทำให้เรื่องนี้ท้าทายเป็นพิเศษคืออัตรา DBU ที่ผันผวนตามระดับการสมัครสมาชิก ประเภทของเวิร์กโหลด และภูมิภาคคลาวด์

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

Databricks คืออะไร?

Databricks เป็นแพลตฟอร์มบนคลาวด์สำหรับการวิเคราะห์ข้อมูลขนาดใหญ่ วิศวกรรมข้อมูล และการเรียนรู้ของเครื่องแบบร่วมมือ สร้างขึ้นบน Apache Spark มันทำงานร่วมกับผู้ให้บริการคลาวด์รายใหญ่—AWS, Azure และ Google Cloud Platform—นำเสนอสภาพแวดล้อมแบบครบวงจรสำหรับการทำงานกับ Delta Lake และเทคโนโลยีโอเพนซอร์สอื่นๆ

แพลตฟอร์มนี้วางตำแหน่งตัวเองเป็นโซลูชัน "lakehouse" ซึ่งรวมโครงสร้างคลังข้อมูลเข้ากับความยืดหยุ่นของ data lake ทีมต่างๆ ใช้ Databricks สำหรับไปป์ไลน์ ETL, การวิเคราะห์แบบเรียลไทม์, การพัฒนาโมเดลการเรียนรู้ของเครื่อง และการใช้งาน AI ในการผลิต

สิ่งที่ทำให้ Databricks แตกต่างในเชิงสถาปัตยกรรมคือการแยกการประมวลผลและการจัดเก็บข้อมูล ข้อมูลจะถูกจัดเก็บไว้ในการจัดเก็บข้อมูลบนคลาวด์ (S3 บน AWS, Blob Storage บน Azure, Cloud Storage บน GCP) ในขณะที่คลัสเตอร์ประมวลผลจะประมวลผลเวิร์กโหลดตามความต้องการ การแยกนี้หมายความว่าต้นทุนจะขยายตัวอย่างอิสระ—การจัดเก็บข้อมูลเพิ่มขึ้นเป็นเส้นตรง ในขณะที่ค่าใช้จ่ายในการประมวลผลจะถูกเรียกเก็บเฉพาะเมื่อคลัสเตอร์ทำงาน

ทำความเข้าใจรูปแบบการกำหนดราคาของ Databricks

ตามเว็บไซต์อย่างเป็นทางการ Databricks นำเสนอแนวทางการจ่ายตามการใช้งาน โดยไม่มีค่าใช้จ่ายล่วงหน้า ค่าใช้จ่ายจะสะสมตามความละเอียดต่อวินาที ซึ่งหมายความว่าคลัสเตอร์ที่ทำงานเป็นเวลา 10 นาที จะสร้างค่าใช้จ่าย 10 นาทีพอดี—ไม่ใช่หนึ่งชั่วโมงเต็ม

รูปแบบการกำหนดราคาประกอบด้วยสองส่วน:

• ค่าใช้จ่าย DBU: Databricks Units วัดความสามารถในการประมวลผลที่ปรับให้เป็นมาตรฐานตามประเภทของอินสแตนซ์และรูปแบบเวิร์กโหลด
• ค่าใช้จ่ายโครงสร้างพื้นฐานคลาวด์: อัตราต่อชั่วโมงสำหรับเครื่องเสมือน การจัดเก็บข้อมูล และเครือข่ายจาก AWS, Azure หรือ GCP

ค่าใช้จ่ายเหล่านี้จะสะสม การเรียกใช้อินสแตนซ์ m5.xlarge บน AWS จะมีทั้งอัตรา DBU (0.690 DBU ต่อชั่วโมงสำหรับเวิร์กโหลดบางประเภท) และค่าใช้จ่ายโครงสร้างพื้นฐาน (0.3795 ดอลลาร์สหรัฐฯ ต่อชั่วโมงสำหรับ VM เอง)

คุยกันตรงๆ: โครงสร้างแบบคู่ทำให้ทีมคาดไม่ถึง ฝ่ายวิศวกรรมมุ่งเน้นไปที่การปรับขนาดคลัสเตอร์และการเลือก VM ในขณะที่ฝ่ายการเงินเห็นบิลที่สูงเกินคาดเนื่องจากตัวคูณ DBU ไม่ได้ถูกนำมาคำนวณในการคาดการณ์

Databricks Units (DBUs) คืออะไร?

DBUs แทนหน่วยของความสามารถในการประมวลผล Databricks คิดค่า DBU ในอัตราที่แตกต่างกัน ขึ้นอยู่กับ:

• ประเภทของเวิร์กโหลด: การประมวลผล Jobs, การประมวลผล All-Purpose, SQL warehouses, serverless และการให้บริการโมเดลแต่ละประเภทมีอัตราที่แตกต่างกัน
• ระดับการสมัครสมาชิก: ระดับ Standard, Premium และ Enterprise มีการกำหนดราคา DBU ที่แตกต่างกัน
• การกำหนดค่าอินสแตนซ์: อินสแตนซ์ขนาดใหญ่ที่มี vCPU และหน่วยความจำมากขึ้น จะบริโภค DBU มากขึ้นต่อชั่วโมง

จำนวน DBUs ที่บริโภคต่อชั่วโมงขึ้นอยู่กับคุณสมบัติของอินสแตนซ์ จากข้อมูลที่มีอยู่ อินสแตนซ์ m5.xlarge (4 vCPUs, 16 GB memory) มีอัตรา DBU ที่ 0.690 สำหรับประเภทการประมวลผลบางประเภท

ดังนั้นหากอินสแตนซ์นั้นทำงานเป็นเวลาหนึ่งชั่วโมงบน Jobs compute ในระดับ Standard การคำนวณจะเป็นดังนี้:

• การบริโภค DBU: 0.690 DBU
• ราคา DBU (ตัวอย่าง): 0.15 ดอลลาร์สหรัฐฯ ต่อ DBU
• ต้นทุน DBU: 0.690 × 0.15 ดอลลาร์สหรัฐฯ = 0.1035 ดอลลาร์สหรัฐฯ
• ต้นทุนโครงสร้างพื้นฐาน: 0.3795 ดอลลาร์สหรัฐฯ
• ต้นทุนรวมต่อชั่วโมง: 0.483 ดอลลาร์สหรัฐฯ

แต่เดี๋ยวก่อน เปลี่ยนคลัสเตอร์เดียวกันนั้นเป็นการประมวลผลแบบ All-Purpose และราคา DBU จะพุ่งสูงขึ้นอย่างมาก—บ่อยครั้งสูงกว่า 2-3 เท่า—เนื่องจากเวิร์กโหลดแบบโต้ตอบรวมถึงสภาพแวดล้อมโน้ตบุ๊กและฟีเจอร์การทำงานร่วมกัน

ระดับการสมัครสมาชิก Databricks อธิบาย

Databricks นำเสนอระดับการสมัครสมาชิกหลักสามระดับ โดยแต่ละระดับมีราคา DBU และชุดคุณสมบัติต่างกัน ระดับเหล่านี้ไม่เพียงแต่กำหนดต้นทุนเท่านั้น แต่ยังกำหนดการเข้าถึงความสามารถในการกำกับดูแล ความปลอดภัย และการทำงานร่วมกันด้วย

ระดับ Standard

ระดับเริ่มต้นนี้มอบฟังก์ชันการทำงานหลักของ Databricks โดยไม่มีคุณสมบัติระดับองค์กรขั้นสูง ระดับ Standard เหมาะสำหรับทีมที่มุ่งเน้นการประมวลผลข้อมูลโดยตรง โดยไม่มีข้อกำหนดด้านการกำกับดูแลที่ซับซ้อน

บน Azure ค่าใช้จ่าย Jobs compute ระดับ Standard อยู่ที่ 0.15 ดอลลาร์สหรัฐฯ ต่อ DBU (ข้อมูลภูมิภาค US East) นี่คืออัตรา DBU พื้นฐานก่อนตัวคูณสำหรับประเภทการประมวลผลหรือระดับอื่นๆ

ระดับ Standard ขาดการควบคุมการเข้าถึงตามบทบาท (RBAC), การบันทึกการตรวจสอบ และคุณสมบัติด้านความปลอดภัยขั้นสูง ซึ่งยอมรับได้สำหรับสภาพแวดล้อมการพัฒนา แต่มีข้อจำกัดสำหรับเวิร์กโหลดการผลิตที่จัดการข้อมูลที่ละเอียดอ่อน

ระดับ Premium (Enterprise บน AWS/GCP)

Premium เพิ่มขีดความสามารถที่ออกแบบมาสำหรับทีมที่ต้องการขยายขนาดและประสิทธิภาพการดำเนินงาน คุณสมบัติหลัก ได้แก่:

• การควบคุมการเข้าถึงตามบทบาท (RBAC) สำหรับสิทธิ์การเข้าถึงแบบละเอียด
• บันทึกการตรวจสอบที่ติดตามการเข้าถึงและการดำเนินการทั่วทั้งพื้นที่ทำงาน
• การควบคุมความปลอดภัยและการปฏิบัติตามข้อกำหนดที่ได้รับการปรับปรุง
• โน้ตบุ๊กที่ทำงานร่วมกันพร้อมการจัดการเวอร์ชัน

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

บน Azure ระดับ Premium สอดคล้องกับสิ่งที่ AWS และ GCP เรียกว่าระดับ Enterprise ซึ่งสำคัญเมื่อเปรียบเทียบราคาข้ามคลาวด์

ระดับ Enterprise

ระดับ Enterprise มอบการกำกับดูแล การปฏิบัติตามข้อกำหนด และการสนับสนุนสูงสุดสำหรับการใช้งานในการผลิตขนาดใหญ่ คุณสมบัติเพิ่มเติมอื่นๆ นอกเหนือจาก Premium ได้แก่:

• การกำกับดูแลข้อมูลขั้นสูงและการติดตามสายข้อมูล
• Unity Catalog สำหรับการจัดการเมตาดาตาแบบรวมศูนย์
• การปรับปรุงประสิทธิภาพขั้นสูง
• การสนับสนุนลำดับความสำคัญและข้อตกลงระดับการให้บริการ (SLA)

Enterprise แสดงถึงระดับราคา DBU สูงสุด ทีมที่จัดการข้อมูลที่มีการควบคุมหรือต้องการการควบคุมการเข้าถึงที่ซับซ้อน มักจะทำงานในระดับนี้ แม้จะมีค่าใช้จ่ายที่สูงขึ้นก็ตาม

อย่าจ่ายเงินมากเกินไปสำหรับเครื่องมือข้อมูลล่วงหน้า

กำลังพิจารณาการกำหนดราคาสำหรับ Databricks? ความท้าทายมักไม่ใช่แค่เครื่องมือเดียว—ต้นทุนจะเพิ่มขึ้นตามการประมวลผล พื้นที่จัดเก็บ และเครื่องมือ AI ที่สนับสนุน

Get AI Perks ช่วยลดค่าใช้จ่ายโดยรวมก่อนที่คุณจะตัดสินใจ มันรวบรวมเครดิต ส่วนลด และข้อเสนอจากพาร์ทเนอร์ทั่วทั้งเครื่องมือ AI, คลาวด์ และนักพัฒนา เพื่อให้คุณสามารถเข้าถึงดีลที่มักจะกระจายอยู่ตามโปรแกรมต่างๆ

ด้วย Get AI Perks คุณสามารถ:

• เข้าถึงเครดิตสำหรับเครื่องมือ AI และโครงสร้างพื้นฐานข้อมูล
• ลดต้นทุนรวมทั่วทั้งสแต็คของคุณ
• ทดลองใช้เครื่องมือก่อนตัดสินใจจ่ายราคาเต็ม

หากคุณกำลังเปรียบเทียบราคา Databricks ให้เริ่มจากการลดต้นทุนโดยรวมของคุณ—ตรวจสอบ Get AI Perks

ประเภทการประมวลผล Databricks และการกำหนดราคา

การเลือกประเภทการประมวลผลทำให้เกิดความแตกต่างของต้นทุนอย่างมีนัยสำคัญ รูปแบบเวิร์กโหลดแต่ละแบบมีราคาที่แตกต่างกันซึ่งปรับให้เหมาะสมกับกรณีการใช้งาน

Jobs Compute

Jobs compute ขับเคลื่อนเวิร์กโฟลว์ ETL อัตโนมัติและการทำงานตามกำหนดเวลา คลัสเตอร์เหล่านี้จะเริ่มทำงาน ประมวลผลเวิร์กโหลด และปิดตัวเองโดยอัตโนมัติ

ข้อได้เปรียบด้านราคา: อัตรา DBU ต่ำที่สุด (น้อยกว่า All-Purpose 30-50%) เริ่มต้นที่ 0.15 ดอลลาร์สหรัฐฯ ต่อ DBU ในระดับ Standard (Azure US East) Jobs compute เป็นตัวเลือกที่ประหยัดที่สุดสำหรับเวิร์กโหลดที่คาดการณ์ได้

ทีมที่เรียกใช้ไปป์ไลน์ข้อมูลเป็นประจำควรเลือกใช้ Jobs compute การประหยัดต้นทุนจะทวีคูณอย่างรวดเร็วเมื่อใช้งานในระดับใหญ่—การเรียกใช้เวิร์กโหลดเดียวกันบน All-Purpose compute อาจมีราคาสูงกว่า 2-3 เท่า โดยไม่มีประโยชน์ในการทำงาน

All-Purpose Compute

คลัสเตอร์ All-Purpose รองรับการวิเคราะห์เชิงโต้ตอบ การพัฒนาโน้ตบุ๊ก และการสำรวจร่วมกัน คลัสเตอร์เหล่านี้จะคงอยู่ตราบเท่าที่ผู้ใช้ทำงานอยู่ ทำให้สามารถประมวลผลแบบเรียลไทม์และการพัฒนาซ้ำๆ ได้

ข้อแลกเปลี่ยน: อัตรา DBU ที่สูงขึ้นอย่างมาก All-Purpose compute ประกอบด้วยสภาพแวดล้อมโน้ตบุ๊ก ฟีเจอร์การทำงานร่วมกัน และความสามารถแบบโต้ตอบที่ช่วยสนับสนุนราคาที่สูงขึ้น

ข้อผิดพลาดทั่วไป: ปล่อยให้คลัสเตอร์ All-Purpose ทำงานโดยไม่ได้ใช้งาน ซึ่งแตกต่างจาก Jobs compute ที่จะปิดตัวเองหลังจากทำงานเสร็จสิ้น คลัสเตอร์ All-Purpose จะยังคงสะสมค่าใช้จ่ายจนกว่าจะถูกหยุดด้วยตนเองหรือปิดอัตโนมัติ การตั้งค่าการปิดอัตโนมัติที่เข้มงวด (ไม่มีการใช้งาน 5-10 นาที) จะป้องกันค่าใช้จ่ายที่บานปลาย

SQL Warehouses

SQL warehouses (เดิมคือ SQL endpoints) จัดการการสืบค้น BI และเวิร์กโหลดการวิเคราะห์ มีสามประเภท:

• Serverless: เริ่มทำงานเร็วที่สุด ประสิทธิภาพสูงสุด โครงสร้างพื้นฐานที่มีการจัดการ
• Pro: เร่งความเร็วด้วย Photon, การปรับให้เหมาะสมกับ Predictive IO
• Classic: ความสามารถ SQL พื้นฐาน ต้นทุนต่ำ

Serverless SQL warehouses นำเสนอประสิทธิภาพที่เหนือกว่าด้วย Photon Engine, Predictive IO และ Intelligent Workload Management—แต่ด้วยอัตรา DBU ที่สูงขึ้น Pro warehouses นำเสนอ Photon และ Predictive IO โดยไม่มีโครงสร้างพื้นฐาน serverless เต็มรูปแบบ Classic warehouses นำเสนอฟังก์ชันการทำงานพื้นฐานในราคาที่ลดลง

สำหรับทีม BI ที่เรียกใช้การสืบค้นตามต้องการบ่อยครั้ง การปรับปรุงประสิทธิภาพของ Serverless มักจะคุ้มค่ากับต้นทุนผ่านการประมวลผลแบบสืบค้นที่เร็วขึ้น (จำนวน DBU-ชั่วโมงน้อยลงทั้งหมด แม้ว่าอัตรา DBU จะสูงขึ้นก็ตาม)

Model Serving

Model Serving ปรับใช้โมเดลการเรียนรู้ของเครื่องเป็น API แบบเรียลไทม์ การกำหนดราคาขึ้นอยู่กับว่าการใช้งานใช้ CPU หรือ GPU อินสแตนซ์

ตามข้อมูลการกำหนดราคาอย่างเป็นทางการ อัตรา DBU สำหรับการให้บริการ GPU จะแตกต่างกันไปตามขนาดของอินสแตนซ์:

การให้บริการ GPU ใช้ DBU มากกว่าการประมวลผลมาตรฐานอย่างมาก ทีมที่ปรับใช้โมเดล ML ต้องการการคาดการณ์ปริมาณการใช้งานที่แม่นยำ—การประเมินปริมาณการสืบค้นต่ำเกินไปจะนำไปสู่ค่าใช้จ่ายที่บานปลายอย่างรุนแรงที่อัตรา DBU เหล่านี้

Serverless Compute

Serverless compute กำจัดการคลัสเตอร์ทั้งหมด Databricks จัดการการจัดเตรียมโครงสร้างพื้นฐาน การปรับขนาด และการปรับให้เหมาะสมโดยอัตโนมัติ

ข้อได้เปรียบด้านราคา: ประมาณ 50% ของอัตรา DBU ของ Jobs Compute สำหรับเวิร์กโหลดที่เทียบเท่ากัน ตามข้อมูลที่มีอยู่ การลดลงนี้สะท้อนถึงประสิทธิภาพของโครงสร้างพื้นฐานที่เพิ่มขึ้นจากทรัพยากรที่ใช้ร่วมกันและปรับให้เหมาะสม

ข้อแม้: serverless ต้องการการเปิดใช้งานในระดับพื้นที่ทำงานและอาจไม่มีให้บริการในทุกภูมิภาค สำหรับเวิร์กโหลดที่รองรับ serverless มักจะมอบต้นทุนรวมที่ต่ำที่สุดผ่านอัตรา DBU ที่ลดลงและไม่มีค่าใช้จ่ายในการจัดการ

การกำหนดราคา Databricks ทั่วทั้งผู้ให้บริการคลาวด์

Databricks ทำงานบน AWS, Azure และ Google Cloud Platform ด้วยการผสานรวมเฉพาะคลาวด์และราคาที่แตกต่างกัน กรอบการทำงาน DBU หลักยังคงเหมือนเดิม แต่ค่าใช้จ่ายโครงสร้างพื้นฐานและความพร้อมใช้งานในภูมิภาคจะแตกต่างกัน

การกำหนดราคา Databricks บน AWS

AWS Databricks ทำงานร่วมกับ S3 สำหรับการจัดเก็บข้อมูล, EC2 สำหรับการประมวลผล และ IAM สำหรับความปลอดภัย ค่าใช้จ่ายโครงสร้างพื้นฐานเป็นไปตามการกำหนดราคา AWS EC2 มาตรฐานสำหรับประเภทอินสแตนซ์ที่เลือก

ตัวอย่างเช่น อินสแตนซ์ m5.xlarge มีค่าใช้จ่าย 0.3795 ดอลลาร์สหรัฐฯ ต่อชั่วโมงในภูมิภาค US East (ราคาตามความต้องการ) เพิ่มตัวคูณ DBU ตามประเภทเวิร์กโหลดและระดับการสมัครสมาชิกเพื่อคำนวณต้นทุนรวม

AWS มี Savings Plans และ Reserved Instances สำหรับโครงสร้างพื้นฐาน EC2 ซึ่งอาจลดต้นทุน VM ลง 30-70% อย่างไรก็ตาม ข้อตกลงเหล่านี้ใช้เฉพาะกับโครงสร้างพื้นฐานเท่านั้น—ไม่ใช่ค่าใช้จ่าย DBU

การกำหนดราคา Databricks บน Azure

Azure Databricks มีสถานะเป็นบริการระดับแรกบน Microsoft Azure นำเสนอการเรียกเก็บเงินแบบรวมศูนย์และการสนับสนุนโดยตรงจาก Microsoft ระดับ Premium บน Azure สอดคล้องกับระดับ Enterprise บน AWS และ GCP

ตามแหล่งข้อมูลอย่างเป็นทางการ ค่าใช้จ่าย Jobs compute ระดับ Standard ของ Azure Databricks อยู่ที่ 0.15 ดอลลาร์สหรัฐฯ ต่อ DBU ในภูมิภาค US East ค่าใช้จ่ายโครงสร้างพื้นฐานเป็นไปตามการกำหนดราคา Azure VM สำหรับกลุ่มอินสแตนซ์ที่เลือก

Azure นำเสนอข้อได้เปรียบที่เป็นเอกลักษณ์สำหรับองค์กรที่ใช้ระบบนิเวศของ Microsoft อยู่แล้ว—การเรียกเก็บเงินแบบรวมศูนย์จะรวมค่าใช้จ่าย Databricks กับบริการ Azure อื่นๆ และการผสานรวมกับ Azure Active Directory จะช่วยลดความซับซ้อนของการจัดการข้อมูลประจำตัว

การกำหนดราคา Databricks บน Google Cloud Platform

GCP Databricks ทำงานร่วมกับ Cloud Storage, Compute Engine และ GCP IAM แพลตฟอร์มนี้ใช้กรอบการทำงาน DBU เดียวกัน แต่ใช้ประเภทอินสแตนซ์และโครงสร้างพื้นฐานระดับภูมิภาคของ GCP

โดยทั่วไป GCP นำเสนอการกำหนดค่าอินสแตนซ์ที่แตกต่างจาก AWS หรือ Azure เล็กน้อย ซึ่งส่งผลต่อทั้งค่าใช้จ่ายโครงสร้างพื้นฐานและอัตรา DBU ทีมควรตรวจสอบราคาโดยใช้เครื่องคำนวณราคา Databricks สำหรับภูมิภาค GCP ที่เฉพาะเจาะจง

การเปรียบเทียบราคาข้ามคลาวด์

อัตรา DBU ค่อนข้างคงที่ทั่วทั้งคลาวด์สำหรับระดับและการประมวลผลที่เทียบเท่ากัน ความแปรปรวนของต้นทุนหลักมาจากความแตกต่างของราคาโครงสร้างพื้นฐานระหว่าง AWS, Azure และ GCP

โดยทั่วไป ทีมควรเลือกผู้ให้บริการคลาวด์ตาม:

• ข้อตกลงโครงสร้างพื้นฐานและข้อตกลงองค์กรที่มีอยู่
• ข้อกำหนดเกี่ยวกับที่ตั้งข้อมูลและความต้องการด้านการปฏิบัติตามข้อกำหนด
• การผสานรวมบริการแบบเนทีฟ (S3 กับ Blob Storage กับ Cloud Storage)
• ความพร้อมใช้งานในภูมิภาคสำหรับคุณสมบัติ Databricks ที่ต้องการ

การเลือกผู้ให้บริการคลาวด์ส่งผลต่อค่าใช้จ่ายโครงสร้างพื้นฐานมากกว่าค่าใช้จ่าย DBU องค์กรที่มี AWS Reserved Instances หรือข้อตกลง Azure ที่มีอยู่สามารถใช้ประโยชน์จากสิ่งเหล่านี้เพื่อประหยัดค่าใช้จ่ายโครงสร้างพื้นฐานได้อย่างมาก

การใช้เครื่องคำนวณราคา Databricks

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

• ผู้ให้บริการคลาวด์ (AWS, Azure หรือ GCP)
• การเลือกภูมิภาค
• ระดับการสมัครสมาชิก (Standard, Premium, Enterprise)
• ประเภทการประมวลผล (Jobs, All-Purpose, SQL, Serverless)
• ประเภทอินสแตนซ์และขนาดคลัสเตอร์
• คาดการณ์ชั่วโมงการทำงานต่อเดือน

เครื่องคำนวณจะแสดงผลการประมาณการบริโภค DBU และค่าใช้จ่ายรายเดือนรวมที่รวมค่าใช้จ่าย DBU กับค่าธรรมเนียมโครงสร้างพื้นฐาน

ตอนนี้ นี่คือจุดที่น่าสนใจ เครื่องคำนวณให้การประมาณการ—ค่าใช้จ่ายจริงขึ้นอยู่กับรูปแบบการใช้งานจริง ทีมต่างๆ มักประเมินต่ำเกินไป:

• เวลาที่คลัสเตอร์ไม่ได้ใช้งานก่อนที่การปิดอัตโนมัติจะทำงาน
• ปริมาณเวิร์กโหลดการพัฒนาและการทดสอบ
• การรั่วไหลจากการพัฒนาเชิงโต้ตอบไปยังคลัสเตอร์การผลิต

แนวทางปฏิบัติที่ดีที่สุด: เรียกใช้เวิร์กโหลดนำร่องและตรวจสอบการใช้งานที่เรียกเก็บเงินจริงผ่านตารางระบบก่อนที่จะตัดสินใจใช้งานในวงกว้าง ตารางระบบการใช้งานที่เรียกเก็บเงิน (system.billing.usage) ให้ข้อมูลการบริโภคแบบละเอียดสำหรับการวิเคราะห์ต้นทุน

อะไรคือปัจจัยที่ขับเคลื่อนต้นทุน Databricks?

การทำความเข้าใจปัจจัยต้นทุนช่วยให้สามารถกำหนดเป้าหมายความพยายามในการปรับให้เหมาะสมได้อย่างมีประสิทธิภาพ ปัจจัยหลายประการรวมกันเพื่อกำหนดค่าใช้จ่ายรายเดือน

ปริมาณข้อมูลและความเร็วของเวิร์กโหลด

ข้อมูลที่มากขึ้นต้องการการประมวลผลมากขึ้น งานแบทช์ที่ประมวลผลเทราไบต์ต่อวัน จะบริโภค DBU-ชั่วโมงมากกว่าไปป์ไลน์ที่จัดการกิกะไบต์

ความเร็วก็มีความสำคัญเช่นกัน เวิร์กโหลดสตรีมมิ่งแบบเรียลไทม์ต้องการคลัสเตอร์ที่เปิดตลอดเวลา สะสมค่าใช้จ่ายอย่างต่อเนื่อง การประมวลผลแบบแบทช์จะเรียกใช้คลัสเตอร์เฉพาะในช่วงเวลาที่ใช้งาน ทำให้เวลาทำงานรวมลดลง

การกำหนดค่าคลัสเตอร์และการเลือกอินสแตนซ์

อินสแตนซ์ที่ใหญ่ขึ้นพร้อม vCPU และหน่วยความจำมากขึ้น มีอัตรา DBU และค่าใช้จ่ายโครงสร้างพื้นฐานที่สูงกว่า m5.8xlarge (32 vCPUs, 128 GB) มีค่าใช้จ่ายต่อชั่วโมงสูงกว่า m5.xlarge (4 vCPUs, 16 GB) อย่างมาก

ความท้าทายในการปรับให้เหมาะสม: คลัสเตอร์ที่ใหญ่เกินไปจะสิ้นเปลืองเงินผ่านความจุที่ไม่จำเป็น ในขณะที่คลัสเตอร์ที่เล็กเกินไปจะทำงานนานขึ้นเพื่อให้งานเสร็จสมบูรณ์—ซึ่งอาจมีค่าใช้จ่าย DBU-ชั่วโมงรวมสูงกว่า

การกระจายประเภทเวิร์กโหลด

การผสมผสานประเภทการประมวลผลจะกำหนดอัตรา DBU เฉลี่ย องค์กรที่ใช้ Jobs compute เป็นหลัก จะมีค่าใช้จ่ายน้อยกว่าองค์กรที่ใช้คลัสเตอร์ All-Purpose เป็นจำนวนมาก

เวิร์กโหลดด้านวิศวกรรม (ETL) โดยทั่วไปมีค่าใช้จ่ายน้อยที่สุด ในขณะที่เวิร์กโหลดด้านวิทยาศาสตร์ข้อมูล (การพัฒนา ML) อาจมีค่าใช้จ่ายสูงขึ้น 3-4 เท่าเนื่องจากการใช้คลัสเตอร์ All-Purpose และรอบการทดลองที่ยาวนานขึ้น

เวลาที่คลัสเตอร์ไม่ได้ใช้งานและการปิดอัตโนมัติ

คลัสเตอร์ All-Purpose จะยังคงสะสมค่าใช้จ่ายเมื่อไม่ได้ใช้งาน เว้นแต่การตั้งค่าการปิดอัตโนมัติจะหยุดคลัสเตอร์ คลัสเตอร์ที่เปิดทิ้งไว้ตลอดคืน จะสะสมค่าใช้จ่ายที่ไม่จำเป็น 8-12 ชั่วโมง

การตั้งค่าการปิดอัตโนมัติเป็น 5-10 นาทีสำหรับคลัสเตอร์การพัฒนาจะป้องกันค่าใช้จ่ายที่บานปลาย คลัสเตอร์ Jobs ในการผลิตควรปิดทันทีหลังจากการทำงานเสร็จสิ้น

ค่าใช้จ่ายในการจัดเก็บข้อมูล

แม้ว่าต้นทุนการจัดเก็บข้อมูลต่อ GB จะน้อยกว่าการประมวลผล แต่ data lake ขนาดใหญ่จะสะสมค่าใช้จ่ายรายเดือนจำนวนมาก ราคาการจัดเก็บข้อมูลบนคลาวด์แตกต่างกันไป:

• ราคาการจัดเก็บข้อมูล AWS S3 Standard เริ่มต้นที่ 0.023 ดอลลาร์สหรัฐฯ ต่อ GB สำหรับ 50 TB แรก/เดือน ในหลายภูมิภาค แต่เป็น 0.021 ดอลลาร์สหรัฐฯ ต่อ GB ใน US East (N. Virginia)
• Azure Blob Storage: ราคาใกล้เคียงกันพร้อมตัวเลือกการแบ่งระดับ
• GCP Cloud Storage: ราคาใกล้เคียงกันพร้อมความแปรปรวนของภูมิภาค

คุณสมบัติการปรับให้เหมาะสมของ Delta Lake ช่วยควบคุมต้นทุนการจัดเก็บข้อมูลผ่านการรวมไฟล์และการจัดวางข้อมูลอัจฉริยะ

กลยุทธ์การปรับต้นทุน Databricks ให้เหมาะสม

การปรับให้เหมาะสมนั้นไปไกลกว่าแนวทางปฏิบัติที่ดีที่สุดในทางทฤษฎี ไปสู่เทคนิคที่ช่วยลดบิลรายเดือนได้อย่างแท้จริง นี่คือสิ่งที่ได้ผลในระดับใหญ่

จับคู่ประเภทการประมวลผลกับรูปแบบเวิร์กโหลด

ใช้ Jobs compute สำหรับไปป์ไลน์อัตโนมัติและงานที่กำหนดเวลาไว้ สงวนคลัสเตอร์ All-Purpose ไว้สำหรับการพัฒนาและสำรวจเชิงโต้ตอบเท่านั้น

การใช้ job clusters กับอินสแตนซ์แบบ spot สามารถลดต้นทุน VM ลงได้ถึง 50% สำหรับเวิร์กโหลดที่ทนต่อความผิดพลาด โดยที่ค่าใช้จ่าย DBU ยังคงเหมือนเดิม อินสแตนซ์แบบ spot ให้ราคาโครงสร้างพื้นฐานที่ลดลง เพื่อแลกกับการหยุดชะงักที่อาจเกิดขึ้น

ใช้งานการปิดอัตโนมัติที่เข้มงวด

กำหนดค่าการปิดอัตโนมัติสำหรับคลัสเตอร์ All-Purpose ที่ไม่มีการใช้งาน 5-10 นาที คลัสเตอร์การพัฒนาที่ไม่ได้ใช้งานจะใช้ DBU โดยไม่มีการสร้างมูลค่า

คลัสเตอร์ Jobs ในการผลิตควรปิดทันทีหลังจากการทำงานเสร็จสิ้น Databricks คิดค่าบริการต่อวินาที—คลัสเตอร์ที่หยุดทันทีหลังจากการทำงานเสร็จสิ้นจะหลีกเลี่ยงค่าใช้จ่ายที่ไม่จำเป็น

ปรับขนาดคลัสเตอร์ให้เหมาะสม

ปรับขนาดคลัสเตอร์ให้เหมาะสมตามความต้องการของเวิร์กโหลด แทนที่จะใช้ค่าเริ่มต้นกับอินสแตนซ์ขนาดใหญ่ เริ่มต้นด้วยการกำหนดค่าที่เล็กกว่าและเพิ่มขนาดขึ้นเฉพาะเมื่อเมตริกประสิทธิภาพบ่งชี้ถึงปัญหาคอขวด

ตรวจสอบเมตริกคลัสเตอร์ผ่านตารางระบบการใช้งานที่เรียกเก็บเงิน คลัสเตอร์ที่แสดงการใช้ CPU หรือหน่วยความจำต่ำอย่างต่อเนื่อง บ่งชี้ถึงโอกาสในการปรับขนาด

เปิดใช้งาน Photon Acceleration

Photon เป็นเอนจินประมวลผลแบบเวกเตอร์ในตัวที่ช่วยเร่งการประมวลผลแบบสืบค้นสำหรับ SQL และการดำเนินการ DataFrame การประมวลผลที่เร็วขึ้นหมายถึง DBU-ชั่วโมงที่บริโภคน้อยลง แม้ว่าอัตรา DBU จะเท่ากันก็ตาม

อย่างไรก็ตาม Photon ทำงานได้ดีที่สุดสำหรับ SQL และการดำเนินการ DataFrame UDF Python ที่ซับซ้อนหรือโค้ดที่กำหนดเองอาจได้รับประโยชน์จากการเร่งความเร็วเพียงเล็กน้อย

ใช้ Serverless เมื่อพร้อมใช้งาน

อัตรา DBU ของ Serverless compute โดยทั่วไปสูงกว่า (เช่น 0.35 – 0.40 ดอลลาร์สหรัฐฯ ต่อ DBU) กว่าอัตรา DBU ของ Jobs Compute (0.07 – 0.15 ดอลลาร์สหรัฐฯ ต่อ DBU) แม้ว่าจะไม่มีค่าใช้จ่ายโครงสร้างพื้นฐานก็ตาม

Serverless ช่วยลดภาระในการจัดการคลัสเตอร์ และปรับการใช้โครงสร้างพื้นฐานให้เหมาะสมโดยอัตโนมัติ—ทั้งสองอย่างช่วยลดต้นทุนการดำเนินงานเกินกว่าการประหยัด DBU โดยตรง

ใช้อินสแตนซ์ Spot สำหรับเวิร์กโหลดที่ทนต่อความผิดพลาด

AWS Spot Instances และ Azure Spot VMs ให้โครงสร้างพื้นฐานในราคาที่ลดลง 60-90% เมื่อเทียบกับราคาตามความต้องการ เวิร์กโหลด Jobs compute ที่มีตรรกะการลองใหม่ในตัวสามารถใช้อินสแตนซ์ spot เพื่อลดต้นทุนโครงสร้างพื้นฐานได้อย่างมาก

ค่าใช้จ่าย DBU ยังคงเหมือนเดิม—อินสแตนซ์ spot เพียงลดราคาเฉพาะส่วนโครงสร้างพื้นฐาน แต่โครงสร้างพื้นฐานนั้นคิดเป็น 40-60% ของต้นทุนทั้งหมดสำหรับเวิร์กโหลดจำนวนมาก

ตรวจสอบต้นทุนผ่านตารางระบบ

ตารางระบบการใช้งานที่เรียกเก็บเงิน (system.billing.usage) รวบรวมข้อมูลการบริโภคจากทุกภูมิภาคของพื้นที่ทำงาน ตามเอกสารอย่างเป็นทางการ ตารางนี้จะอัปเดตเป็นประจำพร้อมกับการบริโภค DBU รายละเอียด SKU และข้อมูลเมตาดาตาการใช้งาน

การสืบค้นตัวอย่างสามารถระบุปัจจัยต้นทุน:

• พื้นที่ทำงานและคลัสเตอร์ที่บริโภค DBU สูงสุด
• คลัสเตอร์ All-Purpose ที่มีเวลาไม่ได้ใช้งานมากเกินไป
• เวิร์กโหลดที่ทำงานบนอินสแตนซ์ที่ใหญ่เกินไป
• การเพิ่มขึ้นของการใช้งานที่ไม่คาดคิดซึ่งต้องมีการตรวจสอบ

การตรวจสอบต้นทุนในการดำเนินงาน—แทนที่จะตรวจสอบใบแจ้งหนี้รายเดือนหลังจากนั้น—ช่วยให้สามารถปรับให้เหมาะสมเชิงรุกได้

ความท้าทายและข้อผิดพลาดในการกำหนดราคา Databricks

หลายแง่มุมของการกำหนดราคา Databricks ทำให้ทีมคาดไม่ถึง การรับทราบช่วยหลีกเลี่ยงความประหลาดใจที่มีค่าใช้จ่ายสูง

ค่าใช้จ่าย DBU และโครงสร้างพื้นฐานถูกเรียกเก็บแยกกัน

ผู้ให้บริการคลาวด์เรียกเก็บค่าใช้จ่ายโครงสร้างพื้นฐาน (VMs, พื้นที่จัดเก็บ, เครือข่าย) ในขณะที่ Databricks เรียกเก็บการบริโภค DBU ทีมต้องกระทบยอดทั้งสองเพื่อให้เข้าใจต้นทุนรวมในการเป็นเจ้าของ

ตาม Databricks' Cloud Infra Cost Field Solution บริษัทต่างๆ สามารถรวมข้อมูลการใช้งาน Databricks กับค่าใช้จ่ายโครงสร้างพื้นฐานคลาวด์เพื่อให้ได้มุมมอง TCO แบบครบวงจรในระดับคลัสเตอร์และแท็ก

ความสับสนของระดับระหว่าง Azure และ AWS/GCP

ระดับ Premium ของ Azure สอดคล้องกับระดับ Enterprise บน AWS และ GCP เอกสารบางครั้งอ้างอิงชื่อระดับที่แตกต่างกันสำหรับฟังก์ชันการทำงานที่เทียบเท่ากัน สร้างความสับสนระหว่างการเปรียบเทียบข้ามคลาวด์

ควรตรวจสอบชุดคุณสมบัติของระดับเสมอ แทนที่จะสันนิษฐานว่าชื่อเหมือนกัน

ค่าใช้จ่ายที่ซ่อนอยู่ในระบบควบคุมการเข้าถึงแบบละเอียด

การควบคุมการเข้าถึงแบบละเอียด (ตัวกรองแถว, หน้ากากคอลัมน์, มุมมองแบบไดนามิก) บนการประมวลผลแบบเฉพาะกิจ ขณะนี้ใช้ serverless compute สำหรับการกรองข้อมูล ซึ่งต้องเปิดใช้งาน serverless ในระดับพื้นที่ทำงาน

บน Databricks Runtime 15.4 LTS หรือสูงกว่า การบังคับใช้การควบคุมการเข้าถึงแบบละเอียดบนการประมวลผลแบบเฉพาะกิจ จะใช้ serverless compute สำหรับการกรองข้อมูล—เพิ่มค่าใช้จ่าย serverless แม้ว่าเวิร์กโหลดหลักจะทำงานบนคลัสเตอร์แบบเฉพาะกิจก็ตาม

การอัปเดตคลัสเตอร์อัตโนมัติเพิ่มค่าใช้จ่ายในการปฏิบัติตามข้อกำหนด

การเปิดใช้งานการอัปเดตคลัสเตอร์อัตโนมัติสำหรับการแก้ไขความปลอดภัย จะเพิ่มค่าใช้จ่ายของส่วนเสริม Enhanced Security and Compliance โดยอัตโนมัติ สิ่งนี้ใช้กับทรัพยากร compute plane แบบคลาสสิก แต่ไม่ใช่ serverless

คุณสมบัตินี้ให้ประโยชน์ผ่านการแพตช์อัตโนมัติ แต่ทีมควรนำต้นทุนส่วนเสริมมาพิจารณาในงบประมาณ

ค่าใช้จ่าย GPU ของ Model Serving เพิ่มขึ้นอย่างรวดเร็ว

การให้บริการ GPU ใช้ DBU 10-628 ต่อชั่วโมง ขึ้นอยู่กับการกำหนดค่า อินสแตนซ์ Large 8X 40GB (A100 40GB × 8 GPU) ที่ทำงานต่อเนื่องจะใช้ DBU 538.40 ต่อชั่วโมง—บวกกับค่าใช้จ่ายโครงสร้างพื้นฐานสำหรับ GPU อินสแตนซ์เอง

การใช้ 0.15 ดอลลาร์สหรัฐฯ ต่อ DBU เป็นตัวอย่าง จะอยู่ที่ประมาณ 80.76 ดอลลาร์สหรัฐฯ ต่อชั่วโมงเฉพาะค่าใช้จ่าย DBU หรือประมาณ 58,147 ดอลลาร์สหรัฐฯ ต่อเดือนสำหรับการทำงานต่อเนื่อง เพิ่มค่าใช้จ่ายโครงสร้างพื้นฐานและต้นทุนทั้งหมดจะสูงขึ้นอย่างมาก

การประมาณค่าใช้จ่าย Databricks รายเดือน

การประมาณต้นทุนที่แม่นยำต้องอาศัยความเข้าใจเกี่ยวกับ "3 V" ของเวิร์กโหลดข้อมูล: Volume, Velocity และ Variety

Volume: ข้อมูลที่มากขึ้นหมายถึงพื้นที่จัดเก็บข้อมูลมากขึ้น บวกกับการประมวลผลที่มากขึ้นเพื่อประมวลผล ทีมที่ประมวลผล data lakes ระดับเพตะไบต์จะบริโภค DBU เป็นสัดส่วนที่มากขึ้นกว่าทีมที่ทำงานกับเทราไบต์

Velocity: การสตรีมแบบเรียลไทม์หมายถึงคลัสเตอร์ที่เปิดตลอดเวลา การประมวลผลแบบแบทช์จะเรียกใช้คลัสเตอร์เป็นระยะๆ ทำให้เวลาทำงานรวมและค่าใช้จ่ายที่เกี่ยวข้องลดลง

Variety: ข้อมูลที่ไม่มีโครงสร้าง (รูปภาพ วิดีโอ เอกสาร) มีค่าใช้จ่ายในการประมวลผลมากกว่าตาราง SQL ที่มีโครงสร้าง การแปลงที่ซับซ้อนจะใช้ทรัพยากรการประมวลผลมากขึ้นต่อระเบียน

แนวทางการประมาณการเชิงปฏิบัติ:

1. ระบุประเภทเวิร์กโหลดและคาดการณ์ชั่วโมงการทำงานต่อเดือน
2. เลือกประเภทการประมวลผลที่เหมาะสม (Jobs vs All-Purpose vs SQL)
3. เลือกระดับการสมัครสมาชิกตามข้อกำหนดด้านการกำกับดูแล
4. ใช้เครื่องคำนวณราคาด้วยประเภทอินสแตนซ์และการกำหนดค่าคลัสเตอร์ที่เฉพาะเจาะจง
5. เพิ่มบัฟเฟอร์ 20-30% สำหรับการพัฒนา การทดสอบ และการใช้งานที่ไม่คาดคิด

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

คำถามที่พบบ่อย

บทสรุป: ทำให้การกำหนดราคา Databricks ได้ผล

การกำหนดราคาของ Databricks ดูซับซ้อนเพราะมันสะท้อนความหลากหลายของเวิร์กโหลดที่แท้จริง—ETL แบบแบทช์, การวิเคราะห์เชิงโต้ตอบ, การสตรีมแบบเรียลไทม์ และการให้บริการ ML ที่เร่งความเร็วด้วย GPU ทั้งหมดมีโปรไฟล์ทรัพยากรและโครงสร้างต้นทุนที่แตกต่างกัน

แต่กรอบการทำงานจะจัดการได้เมื่อส่วนประกอบต่างๆ ชัดเจน: การบริโภค DBU ตามประเภทการประมวลผลและระดับ, บวกกับค่าใช้จ่ายโครงสร้างพื้นฐานจากผู้ให้บริการคลาวด์, เรียกเก็บเงินต่อวินาทีสำหรับการใช้งานจริง

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

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

พร้อมที่จะปรับปรุงการใช้จ่ายแล้วหรือยัง? เข้าถึงเครื่องคำนวณราคา Databricks บนเว็บไซต์อย่างเป็นทางการ, เปิดใช้งานตารางระบบการใช้งานที่เรียกเก็บเงินสำหรับการตรวจสอบ, และเริ่มวัดประสิทธิภาพการบริโภค DBU จริงเทียบกับมูลค่าเวิร์กโหลดที่ส่งมอบ