ระบุอัลกอริทึมที่ใช้ในการ Join ข้อมูลจากสองตาราง ช่วยให้คุณควบคุมประสิทธิภาพการทำงานได้ดีขึ้น
| อาร์กิวเมนต์ | ชนิด | คำอธิบาย |
|---|---|---|
| [JoinAlgorithm.Dynamic]ไม่บังคับ | number (0) | ปล่อยให้ Power Query เลือกอัลกอริทึมที่เหมาะสมเอง โดยดูจากลักษณะของข้อมูลและตาราง (ค่าเริ่มต้น) |
| [JoinAlgorithm.PairwiseHash]ไม่บังคับ | number (1) | เก็บข้อมูลของทั้งสองตารางไว้ในหน่วยความจำก่อน แล้วค่อย Join ทีหลัง ใช้ได้ดีถ้าข้อมูลน้อยเท่านั้น |
| [JoinAlgorithm.SortMerge]ไม่บังคับ | number (2) | Join โดยถือว่าทั้งสองตารางถูกเรียงลำดับแล้ว เร็วและประหยัดหน่วยความจำ แต่ต้องแน่ใจว่าข้อมูลเรียงตาม Join Key จริงๆ |
| [JoinAlgorithm.LeftHash]ไม่บังคับ | number (3) | เก็บข้อมูลตารางซ้ายไว้เป็น Lookup Table แล้ว Stream ข้อมูลตารางขวา เหมาะเวลาตารางซ้ายเล็กกว่า |
| [JoinAlgorithm.RightHash]ไม่บังคับ | number (4) | เก็บข้อมูลตารางขวาไว้เป็น Lookup Table แล้ว Stream ข้อมูลตารางซ้าย เหมาะเวลาตารางขวาเล็กกว่า |
| [JoinAlgorithm.LeftIndex]ไม่บังคับ | number (5) | ใช้ Key จากตารางซ้ายเพื่อ Query ตารางขวา เหมาะตารางขวาใหญ่ที่รองรับ Query Folding |
| [JoinAlgorithm.RightIndex]ไม่บังคับ | number (6) | ใช้ Key จากตารางขวาเพื่อ Query ตารางซ้าย เหมาะตารางซ้ายใหญ่ที่รองรับ Query Folding |
[ ] = อาร์กิวเมนต์ที่ไม่บังคับ
เวลาที่เราทำ Join ข้อมูลจากตารางสองตางในตัวกำหนด Power Query ด้านหลังส่วนใหญ่คนไม่เห็นอัลกอริทึมที่ใช้คำนวณ แต่ผมบอกให้ฟังนะ อัลกอริทึมที่ถูกเลือกมันส่งผลกับความเร็วและการใช้หน่วยความจำเยอะเลยครับ
ที่เจ๋งคือ JoinAlgorithm.Type มันให้คุณเลือกใช้อัลกอริทึมที่เหมาะสมเอง ไม่ว่าจะเป็น Dynamic (ปล่อยให้ Power Query เลือก) LeftHash RightHash SortMerge หรือ Index-based ต่างๆ แต่ละตัวมีจุดเด่นที่แตกต่างกันครับ
ส่วนตัวผมตรวจสอบชนิดข้อมูลและขนาดตารางก่อนเลือกอัลกอริทึม ถ้าตารางเล็กกว่าก็ใช้ Hash ถ้าตารางใหญ่ก็ลองใช้ Index หรือ SortMerge แล้วดูว่าไหนเร็วกว่า 😎
ใช้ JoinAlgorithm.Dynamic เป็นตัวเลือกเริ่มต้นที่ปลอดภัยที่สุด Power Query จะตรวจสอบข้อมูลและเลือกอัลกอริทึมที่ดีที่สุดโดยอัตโนมัติ
เมื่อตารางซ้ายมีจำนวนแถวน้อย (SmallTable) ให้ใช้ LeftHash มันจะเก็บ SmallTable ไว้ในหน่วยความจำแล้ว Stream ข้อมูลจาก LargeTable ทีละแถว ประหยัดหน่วยความจำและเร็วกว่า
ถ้าข้อมูลเรียงลำดับแล้ว SortMerge เป็นตัวเลือกที่ดีที่สุด มันเร็วมากและใช้หน่วยความจำน้อยกว่า Hash algorithms ผมชอบใช้วิธีนี้เวลาข้อมูลมากๆ
เมื่อตารางขวามีจำนวนแถวน้อย (SmallTable) ให้ใช้ RightHash มันจะเก็บตารางขวาไว้ในหน่วยความจำแล้ว Stream ข้อมูลจากตารางซ้าย ประสิทธิภาพดีเมื่อตารางขวาเล็กกว่า
JoinAlgorithm.Type นั่นแหละคือตัวควบคุมว่า Power Query จะใช้อัลกอริทึมไหนในการ Join ข้อมูลครับ ผมเห็นมาหลายครั้งที่คนเขียน M code ลืมใส่ใจเรื่องนี้ แล้วได้ผลลัพธ์ที่ช้ามากๆ เลือกอัลกอริทึมที่เหมาะสมกับข้อมูลของคุณแล้วเร็วเลย
LeftHash เก็บตารางซ้ายไว้ในหน่วยความจำ Stream ตารางขวา ใช้เวลาตารางซ้ายเล็กกว่า RightHash เก็บตารางขวาไว้ในหน่วยความจำ Stream ตารางซ้าย ใช้เวลาตารางขวาเล็กกว่า ผมมักตรวจสอบว่าตารางไหนเล็กกว่าแล้วเลือกให้เหมาะสม
ผมแนะนำให้ใช้ SortMerge เมื่อข้อมูลเรียงลำดับแล้วตามพื้นฐาน Join Key แล้วครับ มันเร็วมากและประหยัดหน่วยความจำ แต่ต้องแน่ใจจริงๆ ว่าข้อมูลเรียงแล้ว ถ้าไม่เรียงผลลัพธ์จะผิดแน่ๆ
LeftIndex ใช้ Key จากตารางซ้ายเพื่อ Query ตารางขวา เหมาะตารางขวาใหญ่ที่รองรับ Query Folding (เช่น SQL database) RightIndex ใช้ Key จากตารางขวาเพื่อ Query ตารางซ้าย เหมาะตารางซ้ายใหญ่ ผมใช้มากเวลาทำงานกับ Database ที่รองรับ Folding
ส่วนตัวผมแนะนำให้เริ่มด้วย Dynamic (ค่าเริ่มต้น) ปล่อยให้ Power Query เลือกเอง แต่ถ้า Performance ไม่ดีหรือคุณรู้ลักษณะข้อมูลได้ดีก็ให้ระบุอัลกอริทึมเฉพาะครับ
ฟังก์ชันที่ผู้เขียนโยงไว้กับ JoinAlgorithm.Type จัดกลุ่มตามหมวด · ชี้ที่ชื่อใดชื่อหนึ่ง แล้วฟังก์ชันที่ใช้คู่กันจะมีจุดทอง
Table.Join ใช้รวมตารางสองตารางโดยจับคู่ค่าในคอลัมน์กำหนด สนับสนุนทุกประเภท join (Inner, Left Outer, Right Outer, Full Outer, Anti, Semi) เหมือน SQL Join
Table.NestedJoin เชื่อมตารางสองตารางด้วยคีย์ที่กำหนด และสร้างคอลัมน์ใหม่ที่เก็บตารางย่อยของแถวที่จับคู่ได้ เหมาะกับงาน Merge ที่ต้องการเก็บรายละเอียดฝั่งขวาไว้เป็น nested table ก่อนจะ Expand หรือทำขั้นตอนต่อ
เรียงลำดับข้อมูลในตารางตามคอลัมน์ที่ระบุ รองรับการเรียงหลายระดับและกำหนดทิศทางการเรียง
JoinKind.Type คือ enum ที่ระบุประเภทของการ Join (Inner, Outer, Anti, Semi) เมื่อรวมตารางข้อมูลสองตาราง ใช้กับ Table.Join เพื่อควบคุมว่าแถวไหนจะปรากฏในผลลัพธ์
ยังไม่มีบทความที่เกี่ยวข้องกับฟังก์ชันนี้
Comments
อีเมลของคุณจะไม่ถูกเผยแพร่