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

เลือกใช้ 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 มีให้เลือกดังนี้
การเข้าถึงจึงเป็นการ Scan ข้อมูลแบบ Column Store (ที่มีทั้งความเป็น Index และบีบอัด) บนหน่วยความจำโดยไม่ต้องตั้งค่าใด ๆ เลย
ในขณะที่การเข้าถึงของ Multi-Dimensional Data Model นั้นต้องมาการอ่านจาก Disk ขึ้นไป Cache บนหน่วยความจำ แล้วถึง Scan ข้อมูลบนหน่วยความจำ จำเป็นต้องปรับตั้งการ Cache นี้ผ่าน Partition Aggregation
สำหรับบทความนี้ผู้เขียนเพียงหยิบยกเฉพาะจุดสำคัญที่น่าจะเป็นเกณฑ์ในการตัดสินใจเลือกประเภทของ Data Model ให้ตรงตามความต้องการ โดยแสดงเป็นข้อ ๆ ดังนี้
- 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
การเข้าถึงจึงเป็นการ 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 ให้ตรงตามความต้องการ โดยแสดงเป็นข้อ ๆ ดังนี้
- การจัดเก็บและการเข้าถึง
- สำหรับ 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)
- สำหรับ SSAS Tabular Data Model จะรันแบบ In-Memory (Import) หรือ DirectQuery อย่างใดอย่างหนึ่ง

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

- หากเปลี่ยนให้ 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 ทำสิ่งนี้โดยอัตโนมัติปรับแต่งไม่ได้
และการปรับตั้งค่าได้เองนี้ถือว่าเป็นข้อดีของ Multi-Dimensional Model ที่สามารถกำหนดจุดสมดุลของการใช้ดิสก์ และหน่วยความจำได้เอง ในขณะที่ Tabular ทำสิ่งนี้โดยอัตโนมัติปรับแต่งไม่ได้
- การจัดการความสัมพันธ์
- ความสัมพันธ์ Many-to-Many
- บน Multi-Dimensional Data Model มีความสัมพันธ์ Many-to-Many แบบ Native อยู่แล้ว
- ความสัมพันธ์ Many-to-Many
จากภาพจะเห็นว่า 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 วิธี
- โหลดข้อมูล DimDate เข้าใน Model หลายครั้งแล้วเปลี่ยนชื่อให้ไม่ซ้ำกันเพื่อแสดงแต่ละบทบาท ข้อเสียหรือขนาดของ Model จะใหญ่ขึ้น และตอนโหลดข้อมูลเข้าจะช้าลง เป็นวิธีที่พบเห็นได้บ่อย
- ใช้ 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 แล้ว จะใช้ได้ไม่ครบถ้วน ต้องไปหาฟังก์ชันอื่นทดแทนซึ่งยุ่งยากมากขึ้น หากมีโอกาสผู้เขียนจะมานำเสนอเรื่องนี้ในบทความต่อ ๆ ไป
ตารางเปรียบเทียบอย่างง่าย
คุณสมบัติ | Multi-Dimensional Data Model | Tabular Data Model |
บน SQL Server Standard Edition และ Enterprise Edition
|
||
การเข้าถึง
|
เลือกสมดุลระหว่างดิสก์และหน่วยความจำได้
|
รันแบบ In-Memory (Import)
|
ขนาดของ Model
|
เรียกได้ว่า ไม่มีขอบเขต
|
ขึ้นอยู่กับขนาดของหน่วยความจำ
|
ความสัมพันธ์ Many-to-Many
|
รองรับแบบ Native
|
รองรับแบบ Native กรณี SQL Server 2019
กรณี SQL Server 2016-2017 ตั้งค่าผ่าน Bidirectional filtering หรือเขียน DAX ผ่านฟังก์ชัน CROSSFILTER
|
รองรับ Role Playing Dimension
|
รองรับแบบ Native
|
เขียน DAX เชื่อมความสัมพันธ์หลายความสัมพันธ์ขึ้นใช้งาน
|
Parent-child Hierarchies
|
ตั้งค่าผ่าน Properties ของ Dimension
|
เขียน DAX
|
Semi-Additive Aggregation function
|
มีเพียง LastChild
|
รองรับ
|
บน SQL Server Enterprise Edition เท่านั้น
|
||
Semi-Additive Aggregation function
|
รองรับ
|