เลือกใช้ Multi-Dimensional Data Model หรือ Tabular Data Model ดี ?

ผู้เขียนเคยเขียนบทความ การสร้าง Data Model ด้วย Microsoft SQL Server Analysis Service และการเรียกใช้ เอาไว้ก่อนหน้านี้ เป็นบทความที่อธิบาย Data Model ทั้งสองแบบเอาไว้พอสังเขป พร้อมตัวอย่างการสร้างใช้งาน
สำหรับบทความนี้จะแนะนำ Data Model ทั้งสองแบบอีกครั้งในเชิงเปรียบเทียบ เพื่อให้ผู้อ่านสามารถเลือกใช้งานได้อย่างเหมาะสม

การเลือกติดตั้ง

เราต้องเลือก Server Mode ของ Microsoft SQL Server Analysis Service (SSAS) เพื่อขับเคลื่อน Data Model แบบใดแบบหนึ่งตั้งแต่ติดตั้ง โดย Instance หนึ่งสามารถมีได้ Mode เดียวเท่านั้น

เป็นเหตุผลว่าทำไมเราถึงต้องตัดสินใจเลือกว่าจะใช้ Data Model แบบไหนตั้งแต่ต้น โดย Server Mode มีให้เลือกดังนี้

• Multi-Dimensional and Data Mining Mode ในโหมดนี้จะจัดเก็บผลรวมเก็บไว้ในรูปแบบ Multi-Dimensional และสามารถนำมาแสดงผลในรูปแบบ Multi-Dimensional

• Tabular Mode ในโหมดนี้จะจัดเก็บผลรวมเก็บไว้ในรูปแบบ Column Store (หากมีโอกาสผู้เขียนจะมาอธิบายเกี่ยวกับ Columnar Database เพิ่มเติม) แต่สามารถนำมาแสดงผลในรูปแบบ Multi-Dimensional ได้

• PowerPivot Mode อันที่จริงการจัดกับก็เป็นแบบ Tabular เช่นกัน แต่ออกแบบเพื่อรองรับการใช้งาน Power Pivot for Excel บน Microsoft SharePoint

นอกเหนือจากการจัดเก็บข้อมูลที่แตกต่างกันแล้ว การเข้าถึงข้อมูลก็แตกต่างกันด้วย ในส่วนของ Tabular Data Model นั้นจะโหลดข้อมูลขึ้นไว้บนหน่วยความจำทั้งหมด
การเข้าถึงจึงเป็นการ Scan ข้อมูลแบบ Column Store (ที่มีทั้งความเป็น Index และบีบอัด) บนหน่วยความจำโดยไม่ต้องตั้งค่าใด ๆ เลย
ในขณะที่การเข้าถึงของ Multi-Dimensional Data Model นั้นต้องมาการอ่านจาก Disk ขึ้นไป Cache บนหน่วยความจำ แล้วถึง Scan ข้อมูลบนหน่วยความจำ จำเป็นต้องปรับตั้งการ Cache นี้ผ่าน Partition Aggregation

ความแตกต่างที่สำคัญ

ความแตกต่างระหว่าง Multi-Dimensional Data Model และ Tabular Data Model นั้นผู้อ่านสามารถดูรายละเอียดทั้งหมดได้จาก Comparing Analysis Services tabular and multidimensional models | Microsoft Docs
สำหรับบทความนี้ผู้เขียนเพียงหยิบยกเฉพาะจุดสำคัญที่น่าจะเป็นเกณฑ์ในการตัดสินใจเลือกประเภทของ Data Model ให้ตรงตามความต้องการ โดยแสดงเป็นข้อ ๆ ดังนี้

1. การจัดเก็บและการเข้าถึง

   • สำหรับ SSAS Tabular Data Model จะรันแบบ ‎In-Memory (Import) หรือ DirectQuery อย่างใดอย่างหนึ่ง

     • โดยค่าตั้งต้นจะเป็นการรันแบบ In-Memory ขนาดของหน่วยความจำจะกลายมาเป็นข้อจำกัดของขนาด Data Model เพราะข้อมูล รวมถึงกลไกการสืบค้นต่าง ๆ ทั้งหมดอยู่ในหน่วยความจำ รองรับแหล่งข้อมูลต้นทางหลากหลายไม่ว่าจะเป็น Relational Database (อาทิ MS SQL หรือ Oracle), Azure Cosmos DB, Azure Data Lake Store, Azure HDInsight, เอกสาร (อาทิ Excel, JSON, XML) หรือบริการออนไลน์ต่าง ๆ (อาทิ Dynamics 365, Saleforce)

จากภาพ แสดง Properties ของ Model ในที่นี้ DirectQuery Mode เป็น Off แสดงว่าอยู่ในโหมด In-Memory

และจะพบว่าสนับสนุนแหล่งข้อมูลต้นทางที่หลากหลายดังแสดง

• หากเปลี่ยนให้ Model ไปรันในโหมด DirectQuery ข้อมูลที่โหลดขึ้นหน่วยความจำจะมีเพียงโครงสร้างข้อมูล (พร้อม Sample Data จำนวนเล็กน้อย) และกลไกการสืบค้นต่าง ๆ เท่านั้น ทำให้ขนาดของหน่วยความจำไม่กลายมาเป็นข้อจำกัดขนาด Data Model อีกต่อไป และตั้งแต่ Microsoft SQL Server เวอร์ชั่น 2016 ได้มีการปรับปรุงเพื่อข้ามข้อจำกัดต่าง ๆ จำนวนมาก อีกทั้งยังเพิ่มประสิทธิภาพการทำงานขึ้น ในสมัยก่อนหากข้อมูลต้นทางมีขนาดใหญ่มาก ๆ ทางเลือกเดียวคือใช้งาน Multi-Dimensional Data Model สำหรับตอนนี้ Tabular Data Model ในใหมด DirectQuery สามารถขยับขึ้นมาทำงานใกล้เคียงมากพอสมควรแล้ว(ข้อมูลต้นทางของ SSAS ไม่ว่าจะเป็น Multi-Dimensional Data Model หรือ Tabular Data Model ควรอยู่ในรูปแบบ Dimensional Model ที่ผ่านการ ETL และ Cleansing มาอย่างดีแล้ว)

Tabular Data Model ในใหมด DirectQuery จะรองรับข้อมูลต้นทางเพียงแค่ Relational Database (อาทิ MS SQL หรือ Oracle) เท่านั้น

จากภาพ แสดงให้เห็นแหล่งข้อมูลต้นทางของ Tabular Data Model ในใหมด DirectQuery

• สำหรับ SSAS Multi-Dimensional Data Model ถูกออกแบบมาให้รองรับข้อมูลต้นทางขนาดใหญ่มาก ๆ และยังสามารถเลือกสมดุลระหว่างการใช้งานดิสก์ และหน่วยความจำได้ผ่านทาง Storage Mode ของทั้ง Dimension และ Measure Group หรือในส่วนของ Cube Partitions และ Cube Aggregations

จากภาพ แสดงให้เห็น Storage Mode ใน Dimension และ Measure Group

การปรับตั้งยังสามารถทำได้ละเอียดมากกว่านี้ ผู้อ่านที่สนใจสามารถติดตามได้ผ่านหลักสูตรฝึกอบรมของทางสถาบัน 9Expert
และการปรับตั้งค่าได้เองนี้ถือว่าเป็นข้อดีของ Multi-Dimensional Model ที่สามารถกำหนดจุดสมดุลของการใช้ดิสก์ และหน่วยความจำได้เอง ในขณะที่ Tabular ทำสิ่งนี้โดยอัตโนมัติปรับแต่งไม่ได้

2. การจัดการความสัมพันธ์

   • ความสัมพันธ์ Many-to-Many

     • บน Multi-Dimensional Data Model มีความสัมพันธ์ Many-to-Many แบบ Native อยู่แล้ว

จากภาพจะเห็นว่า DimSalesReason มีความสัมพันธ์ Many-to-Many กับ FactInternetSales โดยผ่าน FactInternetSales (ทำหน้าที่เป็น Factless Fact Table หรือ Junction Table หรือ Bridge Table แล้วแต่จะเรียก)

ตาราง FactInternetSales จะถูก Detect เป็น Factless Fact Table โดยอัตโนมัติ และตั้งค่าเป็นความสัมพันธ์ Many-to-Many ดังแสดง

ทำให้สามารถหาผลรวมของ Measure บน FactInternetSales โดย Attributes บน DimSalesReason ได้เช่น Sales Amount by Sales Reason Type ดังแสดง

• สำหรับ Tabular Data Model นั้นเพิ่งสนับสนุนความสัมพันธ์ Many-to-Many ใน Microsoft SQL Server 2019 เอง และไม่ Detect ให้อัตโนมัติจำเป็นต้องเข้าไปตั้งค่าเอง (แต่ไม่ยุ่งยากอะไร)

จากภาพเป็นการปรับตั้งความสัมพันธ์ให้เป็น Many-to-Many

• แต่หาก ใช้ Microsoft SQL Server 2016-2017 ก็สามารถตั้งค่าผ่าน Bidirectional filtering  หรือเขียน DAX ผ่านฟังก์ชั่น CROSSFILTER( ) ก็ได้

  • Role Playing Dimension

เป็นการเชื่อมความสัมพันธ์จาก Dimension Table ไปยัง Fact Table หลายครั้ง เพื่อแสดงหลายบทบาท
จากภาพจะเป็นว่า DimDate นั้นเชื่อมความสัมพันธ์ไปยัง FactInternetSales 3 ความสัมพันธ์เพื่อแสดงบทบาทในการเป็น Order Date, Due Date และ Ship Date

• สำหรับ Multi-Dimensional Data Model จะ Detect สิ่งนี้ให้อัตโนมัติ

จากภาพ จะเห็นว่า Cube Dimensions ถูกสร้างขึ้น 3 Dimensions คือ Order Date, Due Date และ Ship Date เป็นการสร้างขึ้นโดยอัตโนมัติ

และสามารถแสดงผลรวม  Sales Amount  ของ Order Date, Due Date และ Ship Date ได้ดังแสดง

ข้อดีของ Role Playing บน Multi-Dimensional Data Model ก็คือข้อมูลของ DimDate จะถูกโหลดเข้า Model เพียงครั้งเดียวแล้วนำไปอ้างอิงใช้งานใน Cube หลายครั้ง

• สำหรับ Tabular Data Model ยังคงไม่สนับสนุน Role Playing Dimension ดังนั้นแนวทางแก้ไขเพื่อให้สามารถใช้งานได้เหมือนกันสามารถทำได้ 2 วิธี

  1. โหลดข้อมูล DimDate เข้าใน Model หลายครั้งแล้วเปลี่ยนชื่อให้ไม่ซ้ำกันเพื่อแสดงแต่ละบทบาท ข้อเสียหรือขนาดของ Model จะใหญ่ขึ้น และตอนโหลดข้อมูลเข้าจะช้าลง เป็นวิธีที่พบเห็นได้บ่อย

  2. ใช้ DAX เขียนความสัมพันธ์หลายความสัมพันธ์ขึ้นมาใช้งาน
      

• Parent-child Hierarchies

  • สำหรับ Multi-Dimensional Data Model สามารถจัดการได้ง่ายกว่าผ่าน Property ของ Hierarchy

  • สำหรับ Tabular Data Model นั้นจำเป็นต้องเขียน DAX ช่วย

ข้อสรุป

• อย่างที่กล่าวไว้ตอนต้นว่ารายละเอียดจริง ๆ สามารถหาอ่านได้จาก link ของ Microsoft ที่ให้ไว้ ข้อมูลในบทความนี้เป็นเพียงสิ่งที่ผู้เขียนพบอุปสรรคขณะใช้ Model ต่างแบบกันไป

• โดยรวมแล้ว Multi-Dimensional Data Model น่าจะทำอะไรได้ง่ายและเยอะกว่า แต่อย่างไรก็ตามยังมีข้อจำกัดบางประการที่ไม่ได้พูดถึง เช่นกลุ่มฟังก์ชันที่เกี่ยวข้องกับ Measure ชนิด Semi-Additive  บน Multi-Dimensional Data Model หากไม่ได้ใช้ Microsoft SQL Server Enterprise Edition แล้ว จะใช้ได้ไม่ครบถ้วน ต้องไปหาฟังก์ชันอื่นทดแทนซึ่งยุ่งยากมากขึ้น หากมีโอกาสผู้เขียนจะมานำเสนอเรื่องนี้ในบทความต่อ ๆ ไป

ตารางเปรียบเทียบอย่างง่าย