คู่มือการตัดสินใจของ Microsoft Fabric: เลือกที่เก็บข้อมูล

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

ไดอะแกรมของคู่มือการตัดสินใจสําหรับการเลือกที่เก็บข้อมูลในอุดมคติใน Microsoft Fabric.

ไดอะแกรมแสดงคู่มือการตัดสินใจสําหรับการเลือกที่เก็บข้อมูล Fabric สําหรับการสตรีมข้อมูลเหตุการณ์และการวิเคราะห์เชิงโต้ตอบที่มีความละเอียดสูง ให้ใช้ Eventhouse สําหรับฐานข้อมูล NoSQL ให้ใช้ Cosmos DB ใน Fabric สําหรับปริมาณงานธุรกรรมการดําเนินงาน (OLTP) ให้ใช้ฐานข้อมูล SQL ใน Fabric หากต้องการพัฒนา AI ด้วยชนิดข้อมูลเวกเตอร์ ให้ใช้ฐานข้อมูล SQL ใน Fabric หรือ Cosmos DB ใน Fabric สําหรับการจัดเก็บข้อมูลองค์กร, BI แบบ SQL, OLAP และรองรับธุรกรรม SQL เต็มรูปแบบ ให้ใช้ Fabric คลังข้อมูล สําหรับบิ๊กดาต้าและแมชชีนเลิร์นนิงที่มีข้อมูลไม่มีโครงสร้าง กึ่งโครงสร้าง หรือมีโครงสร้าง และวิศวกรรมข้อมูล ให้ใช้บ้านริมทะเลสาบ ที่เก็บข้อมูล Fabric ทั้งหมดมีให้ใน OneLake ในรูปแบบตารางเปิดโดยค่าเริ่มต้น

กรณีการใช้งานในอุดมคติ ปริมาณงาน Microsoft Fabric ข้อมูลที่พร้อมใช้งานใน OneLake ในรูปแบบตารางแบบเปิดตามค่าเริ่มต้น
ข้อมูลเหตุการณ์การสตรีม ข้อมูลกิจกรรมที่มีความละเอียดสูง (ในเวลา พื้นที่ รายละเอียด – JSON/ข้อความ) สําหรับการวิเคราะห์แบบโต้ตอบ อีเวนต์เฮ้าส์ มีให้เลือกแบบสมัครใจ
ฐานข้อมูล NoSQL Cosmos DB ในผ้า ใช่
ฐานข้อมูลธุรกรรมเชิงปฏิบัติการ, OLTP หรือฐานข้อมูลที่ได้รับการปรับมาตรฐาน ฐานข้อมูล SQL ใน Fabric ใช่
พัฒนา AI ด้วยชนิดข้อมูลเวกเตอร์ ฐานข้อมูล SQL ใน Fabric หรือ Cosmos DB ใน Fabric ใช่
คลังข้อมูลองค์กร, BI ที่ใช้ SQL, OLAP, รองรับธุรกรรม SQL เต็มรูปแบบ และ ฟังก์ชัน AI (ตัวอย่าง) คลังข้อมูล ใช่
บิ๊กดาต้าและการเรียนรู้ของเครื่อง, ข้อมูลที่ไม่มีโครงสร้าง, กึ่งโครงสร้าง หรือข้อมูลที่มีโครงสร้าง, วิศวกรรมข้อมูล เลคเฮ้าส์ ใช่
  • สําหรับการสตรีมข้อมูลเหตุการณ์และการวิเคราะห์เชิงโต้ตอบที่มีความละเอียดสูง ให้ใช้ Eventhouse
  • สําหรับฐานข้อมูล NoSQL ให้ใช้ Cosmos DB ใน Fabric
  • สําหรับงานเชิงปฏิบัติการ ธุรกรรม OLTP หรือฐานข้อมูลเชิงสัมพันธ์ที่ปรับมาตรฐาน ให้ใช้ฐานข้อมูล SQL ใน Fabric
  • หากต้องการพัฒนา AI ด้วยชนิดข้อมูลเวกเตอร์ ให้ใช้ฐานข้อมูล SQL ใน Fabric หรือ Cosmos DB ใน Fabric
  • สําหรับการจัดเก็บข้อมูลองค์กร, BI แบบ SQL, OLAP และรองรับธุรกรรม SQL เต็มรูปแบบ ให้ใช้ Fabric คลังข้อมูล
  • สําหรับบิ๊กดาต้าและแมชชีนเลิร์นนิงที่มีข้อมูลไม่มีโครงสร้าง กึ่งโครงสร้าง หรือมีโครงสร้าง และวิศวกรรมข้อมูล ให้ใช้บ้านริมทะเลสาบ
  • ที่เก็บข้อมูล Fabric ทั้งหมดมีให้ใช้งานใน OneLake ในรูปแบบตารางเปิดโดยค่าเริ่มต้น ยกเว้นฐานข้อมูล KQL ในงานอีเวนต์เฮาส์ ซึ่ง OneLake สามารถใช้งานได้เป็นฟีเจอร์เลือกเข้าร่วม

บุคลิกและชุดทักษะ

ปริมาณงาน Microsoft Fabric บุคลิกของนักพัฒนาหลัก ชุดทักษะหลัก เครื่องมือ ภาษาหลัก
อีเวนต์เฮ้าส์ นักพัฒนาแอป, นักวิทยาศาสตร์ข้อมูล, วิศวกรข้อมูล ไม่มีรหัส KQL SQL KQL (ภาษาสืบค้น Kusto), T-SQL
Cosmos DB ในผ้า นักพัฒนา AI, นักพัฒนาแอป แนวคิด NoSQL, REST API คล้ายกับ Azure Cosmos DB การรวม REST API ผ่าน JavaScript/TypeScript, Python, C#, Java และอื่นๆ
ฐานข้อมูล SQL ใน Fabric นักพัฒนา AI, นักพัฒนาแอป, นักพัฒนาฐานข้อมูล, ผู้ดูแลระบบฐานข้อมูล การดูแลและพัฒนาฐานข้อมูล คล้ายกับ Azure SQL Database, SSMS, VS Code และเครื่องมือคิวรีที่เข้ากันได้กับ SQL Server T-SQL
คลังข้อมูลผ้า นักพัฒนาคลังข้อมูล, สถาปนิกข้อมูล, วิศวกรข้อมูล, นักพัฒนาฐานข้อมูล แนวคิดคลังข้อมูล, การออกแบบฐานข้อมูลสคีมาแบบดาว, SSMS, VS Code และเครื่องมือสืบค้นที่เข้ากันได้กับ SQL Server T-SQL ไม่มีรหัส
เลคเฮ้าส์ วิศวกรข้อมูล, นักวิทยาศาสตร์ข้อมูล PySpark, ทะเลสาบเดลต้า, โน้ตบุ๊ก Spark (Scala, PySpark, Spark SQL, R)

สถานการณ์สมมติ

ตรวจสอบสถานการณ์เหล่านี้สําหรับความช่วยเหลือเกี่ยวกับการเลือกที่เก็บข้อมูลใน Fabric

สถานการณ์จำลอง 1

Susan นักพัฒนามืออาชีพ เป็นนักพัฒนาใหม่สําหรับ Microsoft Fabric พวกเขาพร้อมที่จะเริ่มทําความสะอาด สร้างแบบจําลอง และวิเคราะห์ข้อมูล แต่ยังต้องตัดสินใจว่าจะสร้างคลังข้อมูลหรือบ้านริมทะเลสาบ หลังจากทบทวนรายละเอียดในตารางก่อนหน้า จุดตัดสินใจหลักคือชุดทักษะที่มีอยู่และความจําเป็นในการทําธุรกรรมแบบหลายโต๊ะ

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

Susan สร้างคลังข้อมูลใหม่และโต้ตอบกับคลังข้อมูลนั้นโดยใช้ T-SQL เช่นเดียวกับฐานข้อมูลเซิร์ฟเวอร์ SQL อื่น ๆ ของเธอ โค้ด T-SQL ส่วนใหญ่ที่เธอเขียนเพื่อสร้างคลังข้อมูล SQL Server ใช้ได้ผลกับ Fabric คลังข้อมูล ทําให้การเปลี่ยนผ่านง่ายขึ้น ถ้าเธอเลือกที่จะ เธอสามารถใช้เครื่องมือเดียวกันกับที่ทํางานกับฐานข้อมูลอื่น ๆ ของเธอได้ เช่น SQL Server Management Studio โดยใช้ตัวแก้ไข SQL ในพอร์ทัล Fabric ซูซานและสมาชิกทีมคนอื่น ๆ เขียนคําสั่งวิเคราะห์ที่อ้างอิงคลังข้อมูลอื่น ๆ และตาราง Delta ในบ้านพักน้ํา โดยใช้ชื่อสามส่วนในการสืบค้นข้ามฐานข้อมูล

สถานการณ์จำลอง 2

Rob วิศวกรข้อมูลจําเป็นต้องจัดเก็บและจําลองข้อมูลหลายเทราไบต์ใน Fabric ทีมมีการผสมผสานระหว่างทักษะ PySpark และ T-SQL ทีมส่วนใหญ่ที่รันคําสั่ง T-SQL เป็นผู้ใช้ทั่วไป ดังนั้นจึงไม่จําเป็นต้องเขียน INSERT, UPDATE, หรือ DELETE คําสั่ง นักพัฒนาที่เหลือจะสะดวกในการทํางานในสมุดบันทึก และเนื่องจากข้อมูลถูกเก็บไว้ใน Delta พวกเขาสามารถโต้ตอบกับไวยากรณ์ SQL ที่คล้ายกัน

Rob ตัดสินใจที่จะใช้ เลคเฮ้าส์ ซึ่งช่วยให้ทีมวิศวกรรมข้อมูลสามารถใช้ทักษะที่หลากหลายของพวกเขากับข้อมูล ในขณะที่ยังอนุญาตให้สมาชิกทีมที่มีทักษะสูงใน T-SQL สามารถใช้ข้อมูลได้

สถานการณ์จำลอง 3

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

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

สถานการณ์จำลอง 4

Kirby เป็นสถาปนิกแอปพลิเคชันที่มีประสบการณ์ในการพัฒนาแอปพลิเคชัน .NET สําหรับข้อมูลการดําเนินงาน พวกเขาต้องการฐานข้อมูลภาวะพร้อมกันสูงพร้อมการปฏิบัติตามธุรกรรมของ ACID อย่างเต็มรูปแบบและคีย์นอกที่มีการบังคับใช้อย่างรุนแรงเพื่อความสมบูรณ์เชิงสัมพันธ์ Kirby ต้องการประโยชน์ของการปรับแต่งประสิทธิภาพโดยอัตโนมัติเพื่อลดความซับซ้อนของการจัดการฐานข้อมูลประจําวัน

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

ในสถานการณ์ของ Kirby ข้อมูลจากแอปพลิเคชันการดําเนินงานต้องเข้าร่วมกับข้อมูลอื่น ๆ ใน Fabric: ใน Spark ในคลังสินค้าและจากเหตุการณ์แบบเรียลไทม์ใน Eventhouse ฐานข้อมูล Fabric ทั้งหมดมีจุดสิ้นสุดการวิเคราะห์ SQL เพื่อให้สามารถเข้าถึงข้อมูลได้แบบเรียลไทม์จาก Spark หรือคิวรี Power BI โดยใช้โหมด DirectLake โซลูชันการรายงานเหล่านี้สํารองฐานข้อมูลการดําเนินงานหลักจากค่าใช้จ่ายของปริมาณงานวิเคราะห์และหลีกเลี่ยงการดีนอร์มอลไลเซต Kirby ยังมีข้อมูลการดําเนินงานในฐานข้อมูล SQL อื่น ๆ และจําเป็นต้องนําเข้าข้อมูลนั้นโดยไม่มีการแปลง ในการนําเข้าข้อมูลการดําเนินงานที่มีอยู่โดยไม่ต้องแปลงประเภทข้อมูล Kirby ออกแบบไปป์ไลน์ด้วย Fabric Data Factory เพื่อนําเข้าข้อมูลไปยังฐานข้อมูล Fabric SQL

ขั้นตอนถัดไป