คู่มือการตัดสินใจของ Microsoft Fabric: เลือกที่เก็บข้อมูล
ใช้คู่มืออ้างอิงนี้และสถานการณ์ตัวอย่างเพื่อช่วยให้คุณเลือกที่เก็บข้อมูลสําหรับปริมาณงาน Microsoft Fabric ของคุณ
คุณสมบัติของที่เก็บข้อมูล
ตารางนี้เปรียบเทียบกับที่เก็บข้อมูล เช่น คลังสินค้า lakehouse Datamart Power BI และ eventhouse ตามปริมาณข้อมูล ประเภท บุคลิกของนักพัฒนา ชุดทักษะ การดําเนินงาน และความสามารถอื่น ๆ
| คลังสินค้า | เลคเฮ้าส์ | Power BI Datamart | อีเวนต์เฮ้าส์ | |
|---|---|---|---|---|
| ปริมาณข้อมูล | ไม่จำกัด | ไม่จำกัด | สูงสุด 100 GB | ไม่จำกัด |
| ชนิดของข้อมูล | แบบโครงสร้าง | ไม่มีโครงสร้าง กึ่งมีโครงสร้าง มีโครงสร้าง | แบบโครงสร้าง | ไม่มีโครงสร้าง กึ่งมีโครงสร้าง มีโครงสร้าง |
| บุคลลสําหรับนักพัฒนาหลัก | นักพัฒนาคลังข้อมูล, วิศวกร SQL | วิศวกรข้อมูล นักวิทยาศาสตร์ข้อมูล | นักพัฒนาพลเมือง | นักวิทยาศาสตร์ข้อมูลพลเมือง วิศวกรข้อมูล นักวิทยาศาสตร์ข้อมูล วิศวกร SQL |
| ชุดทักษะนักพัฒนาหลัก | SQL | Spark(Scala, PySpark, Spark SQL, R) | ไม่มีรหัส SQL | ไม่มีรหัส KQL SQL |
| ข้อมูลที่ถูกจัดระเบียบโดย | ฐานข้อมูล สคีมา และตาราง | โฟลเดอร์และไฟล์ ฐานข้อมูล และตาราง | ฐานข้อมูล ตาราง คิวรี | ฐานข้อมูล สคีมา และตาราง |
| อ่านการดําเนินการ | T-SQL, Spark (รองรับการอ่านจากตารางโดยใช้ทางลัด ยังไม่สนับสนุนการเข้าถึงมุมมอง กระบวนงานที่เก็บไว้ ฟังก์ชัน ฯลฯ) | Spark, T-SQL | Spark, T-SQL, Power BI | KQL, T-SQL, Spark, Power BI |
| การดําเนินการเขียน | T-SQL | Spark(Scala, PySpark, Spark SQL, R) | กระแสข้อมูล, T-SQL | KQL, Spark, ระบบนิเวศของตัวเชื่อมต่อ |
| ธุรกรรมแบบหลายตาราง | ตกลง | ไม่ | ไม่ | ใช่ สําหรับการนําเข้าหลายตาราง ดู นโยบายการอัปเดต |
| อินเทอร์เฟซการพัฒนาหลัก | สคริปต์ SQL | สมุดบันทึก Spark,ข้อกําหนดงาน Spark | Power BI | คิวรี KQL, ฐานข้อมูล KQL |
| ความปลอดภัย | ระดับวัตถุ (ตาราง มุมมอง ฟังก์ชัน ขั้นตอนการจัดเก็บ ฯลฯ) ระดับคอลัมน์ ระดับแถว DDL/DML การปกปิดข้อมูลแบบไดนามิก | ระดับแถว ระดับคอลัมน์ (สําหรับ lakehouse ที่เข้าถึงผ่านจุดสิ้นสุดการวิเคราะห์ SQL) ระดับตาราง (เมื่อใช้ T-SQL) ไม่มีสําหรับ Spark | ตัวแก้ไข RLS ในตัว | การรักษาความปลอดภัยระดับแถว |
| เข้าถึงข้อมูลผ่านปุ่มลัด | ใช่ ผ่านเลคเฮ้าส์โดยใช้ชื่อสามส่วน | ตกลง | ไม่ | ใช่ |
| สามารถเป็นแหล่งข้อมูลสําหรับทางลัด | ใช่ (ตาราง) | ใช่ (ไฟล์และตาราง) | ไม่ใช่ | ใช่ |
| คิวรีข้ามรายการ | ใช่ คิวรีข้ามเลคเฮ้าส์และตารางคลังสินค้า | ใช่ คิวรีข้ามเลคเฮ้าส์และตารางคลังสินค้า คิวรีข้ามเลคเฮ้าส์ (รวมถึงทางลัดโดยใช้ Spark) | ไม่ | ใช่ คิวรีข้ามฐานข้อมูล KQL เลคเฮ้าส์ และโกดังที่มีทางลัด |
สถานการณ์สมมติ
ตรวจสอบสถานการณ์เหล่านี้สําหรับความช่วยเหลือเกี่ยวกับการเลือกที่เก็บข้อมูลใน Fabric
สถานการณ์สมมติ 1
Susan นักพัฒนามืออาชีพ เป็นนักพัฒนาใหม่สําหรับ Microsoft Fabric พวกเขาพร้อมที่จะเริ่มต้นการทําความสะอาด การวางรูปแบบ และการวิเคราะห์ข้อมูล แต่จําเป็นต้องตัดสินใจสร้างคลังข้อมูลหรือเลคเฮ้าส์ หลังจากการตรวจทานรายละเอียดในตารางก่อนหน้านี้แล้ว จุดสําหรับการตัดสินใจหลักคือชุดทักษะที่พร้อมใช้งานและความจําเป็นสําหรับธุรกรรมแบบหลายตาราง
Susan ได้ใช้เวลาหลายปีในการสร้างคลังข้อมูลในเครื่องมือฐานข้อมูลเชิงสัมพันธ์ และมีความคุ้นเคยกับไวยากรณ์และฟังก์ชันการทํางานของ SQL เมื่อคิดเกี่ยวกับทีมขนาดใหญ่ ผู้บริโภคหลักของข้อมูลนี้ยังมีทักษะด้วยเครื่องมือวิเคราะห์ SQL และ SQL Susan ตัดสินใจที่จะใช้ คลังข้อมูล ซึ่งช่วยให้ทีมสามารถโต้ตอบกับ T-SQL เป็นหลัก ในขณะที่ยังอนุญาตให้ผู้ใช้ Spark ใด ๆ ในองค์กรสามารถเข้าถึงข้อมูลได้
ซูซานสร้างเลคเฮ้าส์ใหม่และเข้าถึงความสามารถของคลังข้อมูลด้วยจุดสิ้นสุดการวิเคราะห์ของเลคเฮ้าส์ SQL ใช้พอร์ทัล Fabric สร้างทางลัดไปยังตารางข้อมูลภายนอกและวางไว้ใน /Tables โฟลเดอร์ ตอนนี้ Susan สามารถเขียนคิวรี T-SQL ที่อ้างอิงทางลัดไปยังคิวรีข้อมูล Delta Lake ในเลคเฮาส์ได้แล้ว ทางลัดจะปรากฏเป็นตารางในจุดสิ้นสุดการวิเคราะห์ SQL โดยอัตโนมัติและสามารถคิวรีกับ T-SQL โดยใช้ชื่อสามส่วน
สถานการณ์สมมติ 2
Rob วิศวกรข้อมูลจําเป็นต้องจัดเก็บและจําลองข้อมูลหลายเทราไบต์ใน Fabric ทีมมีการผสมผสานระหว่างทักษะ PySpark และ T-SQL ทีมส่วนใหญ่ที่ใช้คิวรี T-SQL เป็นผู้บริโภค ดังนั้นจึงไม่จําเป็นต้องเขียนคําสั่ง INSERT, UPDATE หรือ DELETE นักพัฒนาที่เหลือจะสะดวกในการทํางานในสมุดบันทึก และเนื่องจากข้อมูลถูกเก็บไว้ใน Delta พวกเขาสามารถโต้ตอบกับไวยากรณ์ SQL ที่คล้ายกัน
Rob ตัดสินใจที่จะใช้ เลคเฮ้าส์ ซึ่งช่วยให้ทีมวิศวกรรมข้อมูลสามารถใช้ทักษะที่หลากหลายของพวกเขากับข้อมูล ในขณะที่ยังอนุญาตให้สมาชิกทีมที่มีทักษะสูงใน T-SQL สามารถใช้ข้อมูลได้
สถานการณ์สมมติ 3
Ash นักพัฒนาพลเมืองเป็นนักพัฒนา Power BI แผนภูมิเหล่านี้จะคุ้นเคยกับ Excel, Power BI และ Office พวกเขาจําเป็นต้องสร้างผลิตภัณฑ์ข้อมูลสําหรับหน่วยธุรกิจ พวกเขารู้ว่าพวกเขาไม่มีทักษะในการสร้างคลังข้อมูลหรือเลคเฮ้าส์และดูเหมือนว่ามากเกินไปสําหรับความต้องการและปริมาณข้อมูลของพวกเขา พวกเขาตรวจสอบรายละเอียดในตารางก่อนหน้าและดูว่าจุดการตัดสินใจหลักเป็นทักษะของตนเองและความจําเป็นสําหรับการบริการตนเองไม่มีความสามารถของโค้ดและปริมาณข้อมูลต่ํากว่า 100 GB
Ash ทํางานร่วมกับนักวิเคราะห์ธุรกิจที่คุ้นเคยกับ Power BI และ Microsoft Office และรู้ว่าพวกเขามีการสมัครใช้งานความจุพรีเมียมอยู่แล้ว เมื่อพวกเขาคิดถึงทีมขนาดใหญ่พวกเขาตระหนักถึงผู้บริโภคหลักของข้อมูลนี้อาจเป็นนักวิเคราะห์คุ้นเคยกับเครื่องมือวิเคราะห์ที่ไม่มีรหัสและ SQL แอชตัดสินใจที่จะใช้ Datamart ของ Power BI ซึ่งช่วยให้ทีมสามารถโต้ตอบสร้างความสามารถได้อย่างรวดเร็วโดยใช้ประสบการณ์ที่ไม่มีรหัส คิวรีสามารถดําเนินการผ่าน Power BI และ T-SQL ในขณะที่ยังอนุญาตให้ผู้ใช้ Spark ใด ๆ ในองค์กรสามารถเข้าถึงข้อมูลได้เช่นกัน
สถานการณ์จำลอง 4
Daisy เป็นนักวิเคราะห์ธุรกิจที่มีประสบการณ์ในการใช้ Power BI ในการวิเคราะห์ปัญหาคอขวดของห่วงโซ่อุปทานสําหรับห่วงโซ่การค้าปลีกขนาดใหญ่ทั่วโลก พวกเขาจําเป็นต้องสร้างโซลูชันข้อมูลที่ปรับขนาดได้ ซึ่งสามารถจัดการแถวข้อมูลหลายพันล้านแถว และสามารถใช้เพื่อสร้างแดชบอร์ดและรายงานที่สามารถใช้เพื่อทําการตัดสินใจทางธุรกิจ ข้อมูลมาจากโรงงาน ซัพพลายเออร์ ผู้ขนส่ง และแหล่งข้อมูลอื่น ๆ ในรูปแบบที่มีโครงสร้าง กึ่งมีโครงสร้าง และไม่มีโครงสร้าง
Daisy ตัดสินใจที่จะใช้ eventhouse เนื่องจากความสามารถในการปรับขนาด เวลาตอบสนองที่รวดเร็ว ความสามารถในการวิเคราะห์ขั้นสูงรวมถึงการวิเคราะห์อนุกรมเวลา ฟังก์ชันเชิงพื้นที่ และโหมดคิวรีโดยตรงอย่างรวดเร็วใน Power BI คิวรีสามารถดําเนินการได้โดยใช้ Power BI และ KQL เพื่อเปรียบเทียบระหว่างช่วงเวลาปัจจุบันและก่อนหน้านี้ ระบุปัญหาที่เกิดขึ้นใหม่อย่างรวดเร็ว หรือให้การวิเคราะห์ทางภูมิศาสตร์ของเส้นทางที่ดินและทางทะเล