ทำไมแพนด้าถึงถูกรวมเข้ากับไพ ธ อนเร็วกว่า data.table จึงถูกรวมใน R ในปี 2012?

ฉันเพิ่งเจอห้องสมุดแพนด้าสำหรับงูหลามซึ่งตามมาตรฐานนี้ทำการผสานในหน่วยความจำที่รวดเร็วมาก มันเร็วกว่าแพ็คเกจdata.tableใน R (ภาษาที่ฉันเลือกใช้ในการวิเคราะห์)

เหตุใดpandasจึงเร็วกว่าdata.tableมาก เป็นเพราะความได้เปรียบทางด้านความเร็วของงูหลามมีมากกว่า R หรือมีข้อเสียบางอย่างที่ฉันไม่ทราบ? มีวิธีการรวมภายในและภายนอกdata.tableโดยไม่หันไปmerge(X, Y, all=FALSE)และmerge(X, Y, all=TRUE)?

นี่คือรหัส Rและรหัส Python ที่ใช้ในการกำหนดมาตรฐานของแพ็คเกจต่างๆ

ดูเหมือนว่า Wes อาจค้นพบปัญหาที่ทราบแล้วdata.tableเมื่อจำนวนสตริงที่ไม่ซ้ำ ( ระดับ ) มีขนาดใหญ่: 10,000

ไม่Rprof()เปิดเผยมากที่สุดของเวลาที่ใช้ในการเรียกsortedmatch(levels(i[[lc]]), levels(x[[rc]])? นี่ไม่ใช่การรวมตัวกันจริงๆ (อัลกอริทึม) แต่เป็นขั้นตอนเบื้องต้น

ความพยายามล่าสุดได้เข้าสู่การอนุญาตให้คอลัมน์อักขระในคีย์ซึ่งควรแก้ไขปัญหานั้นโดยการรวมอย่างใกล้ชิดกับตารางแฮชสตริงของโกลบอลของ R ผลลัพธ์การวัดประสิทธิภาพบางส่วนได้รับการรายงานไปแล้วtest.data.table()แต่ยังไม่ได้ติดรหัสเพื่อแทนที่ระดับการจับคู่ให้ตรงกัน

แพนด้ารวมตัวเร็วกว่าdata.tableคอลัมน์จำนวนเต็มปกติหรือไม่ นั่นควรจะเป็นวิธีที่จะแยกอัลกอริทึมของตัวเองกับประเด็นปัจจัย

นอกจากนี้ยังdata.tableมีการรวมอนุกรมเวลาในใจ สองด้านต่อไปนี้: i) หลายคอลัมน์สั่งซื้อคีย์เช่น (id, วันที่และเวลา) ii) การเข้าร่วมอย่างรวดเร็วแลกเปลี่ยน ( roll=TRUE) การสังเกตครั้งสุดท้ายหรือการสังเกตครั้งสุดท้ายดำเนินต่อไป

ฉันจะต้องใช้เวลาสักครู่เพื่อยืนยันว่าเป็นครั้งแรกที่ฉันได้เห็นการเปรียบเทียบกับdata.tableที่นำเสนอ

อัปเดตจาก data.table v1.8.0 เผยแพร่เมื่อกรกฎาคม 2555

• ฟังก์ชันภายใน sortmatch () ถูกลบและแทนที่ด้วย chmatch () เมื่อจับคู่ระดับ i กับ x ระดับสำหรับคอลัมน์ประเภท 'factor' ขั้นตอนเบื้องต้นนี้ทำให้เกิดการชะลอตัว (รู้จัก) อย่างมีนัยสำคัญเมื่อจำนวนระดับของคอลัมน์ปัจจัยมีขนาดใหญ่ (เช่น> 10,000) ที่เลวร้ายยิ่งในการทดสอบของการเข้าร่วมสี่คอลัมน์ดังกล่าวแสดงให้เห็นโดย Wes McKinney (ผู้เขียนของแพคเกจงูหลาม Pandas) การจับคู่สตริง 1 ล้านตัวซึ่งมี 600,000 ตัวที่ไม่ซ้ำกันตอนนี้ลดลงจาก 16s เป็น 0.5s ตัวอย่างเช่น

ในรุ่นนั้นก็คือ:

• ขณะนี้อนุญาตให้ใช้คอลัมน์อักขระในคีย์และเป็นปัจจัย data.table () และ setkey () ไม่บังคับให้ใส่อักขระอีกต่อไป ปัจจัยที่ยังคงได้รับการสนับสนุน ใช้ FR # 1493, FR # 1224 และ (บางส่วน) FR # 951

• ฟังก์ชันใหม่ chmatch () และ% chin%, รุ่นที่ตรงกันเร็วกว่า () และ% in% สำหรับเวกเตอร์อักขระ ใช้สตริงแคชภายในของ R (ไม่ได้สร้างตารางแฮช) มันเร็วกว่าการแข่งขันประมาณ 4 เท่าในตัวอย่างใน? chmatch

ณ เดือนกันยายน 2013 data.table คือ v1.8.10 บน CRAN และเรากำลังทำงานกับ v1.9.0 ข่าวมีการปรับปรุงสด

แต่อย่างที่ฉันเขียนข้างต้น:

data.tableมีอนุกรมเวลาในใจ สองด้านต่อไปนี้: i) หลายคอลัมน์สั่งซื้อคีย์เช่น (id, วันที่และเวลา) ii) การเข้าร่วมอย่างรวดเร็วแลกเปลี่ยน ( roll=TRUE) การสังเกตครั้งสุดท้ายหรือการสังเกตครั้งสุดท้ายดำเนินต่อไป

ดังนั้นการรวมของ Pandas equi ของคอลัมน์อักขระสองตัวอาจจะยังเร็วกว่า data.table เนื่องจากดูเหมือนว่าจะเป็นการรวมสองคอลัมน์เข้าด้วยกัน data.table ไม่แฮชคีย์เนื่องจากมีคำสั่งที่รวมเข้าไว้ในใจ "คีย์" ใน data.table เป็นเพียงแค่การเรียงลำดับ (คล้ายกับดัชนีคลัสเตอร์ใน SQL นั่นคือวิธีการสั่งซื้อข้อมูลใน RAM) ในรายการคือการเพิ่มคีย์รองเช่น

โดยสรุปความแตกต่างของความเร็วในการส่องสว่างที่เน้นโดยการทดสอบสองตัวอักษรคอลัมน์นี้โดยเฉพาะกับ 10,000 สายที่ไม่ซ้ำกันไม่ควรจะเลวร้ายในขณะนี้เนื่องจากปัญหาที่รู้จักกันได้รับการแก้ไข

เหตุผลที่ทำให้แพนด้าเร็วกว่านั้นก็เพราะว่าฉันได้อัลกอริธึมที่ดีกว่าซึ่งมีการนำไปใช้อย่างระมัดระวังโดยใช้การแฮชตารางอย่างรวดเร็ว - klibและใน C / Cythonเพื่อหลีกเลี่ยง Python interpreter สำหรับชิ้นส่วนที่ไม่ใช่เวกเตอร์ ขั้นตอนวิธีการอธิบายไว้ในรายละเอียดบางอย่างในการนำเสนอของฉัน: ดูภายในการออกแบบและการพัฒนาหมีแพนด้า

การเปรียบเทียบdata.tableนั้นน่าสนใจเล็กน้อยเนื่องจากจุดทั้งหมดของ R data.tableคือมันมีดัชนีที่คำนวณล่วงหน้าสำหรับคอลัมน์ต่าง ๆ เพื่อเร่งการดำเนินงานเช่นการเลือกข้อมูลและการผสาน ในกรณีนี้ (รวมฐานข้อมูล) DataFrame ของ pandas ไม่มีข้อมูลที่คำนวณไว้ล่วงหน้าซึ่งจะถูกใช้สำหรับการผสานดังนั้นจะพูดว่าเป็นการผสาน "แบบเย็น" หากฉันเก็บคีย์การเข้าร่วมเวอร์ชันที่แยกตัวแล้วการรวมจะเร็วขึ้นอย่างมากเนื่องจากการแยกตัวประกอบเป็นคอขวดที่ใหญ่ที่สุดสำหรับอัลกอริทึมนี้

ฉันควรเพิ่มด้วยว่าการออกแบบภายในของ DataFrame ของแพนด้านั้นมีความสอดคล้องกับการดำเนินการประเภทนี้มากกว่า data.frame ของ R (ซึ่งเป็นเพียงรายการของอาร์เรย์ภายใน)

หัวข้อนี้มีอายุสองปี แต่ดูเหมือนว่าเป็นสถานที่ที่เป็นไปได้ที่ผู้คนจะมาถึงเมื่อพวกเขาค้นหาการเปรียบเทียบ Pandas และ data.table

เนื่องจากทั้งคู่มีการพัฒนาอยู่ตลอดเวลาฉันต้องการโพสต์การเปรียบเทียบที่ค่อนข้างใหม่ (ตั้งแต่ปี 2014) ที่นี่สำหรับผู้ใช้ที่สนใจ: https://github.com/Rdatatable/data.table/wiki/Benchmarks-:-Grouping

มันน่าสนใจที่จะทราบว่า Wes และ / หรือ Matt (ใครเป็นผู้สร้าง Pandas และ data.table ตามลำดับและมีความคิดเห็นทั้งสองข้างต้น) มีข่าวที่จะเพิ่มที่นี่เช่นกัน

- อัปเดต -

ความคิดเห็นที่โพสต์ด้านล่างโดย jangorecki มีลิงค์ที่ฉันคิดว่ามีประโยชน์มาก: https://github.com/szilard/benchm-database

กราฟนี้แสดงเวลาเฉลี่ยของการรวมและการดำเนินการเข้าร่วมสำหรับเทคโนโลยีที่แตกต่าง ( ต่ำกว่า = เร็วกว่าการเปรียบเทียบอัปเดตล่าสุดในเดือนกันยายน 2559) มันเป็นการศึกษาสำหรับฉันจริงๆ

กลับไปที่คำถามR DT keyและR DTอ้างอิงถึงคีย์ข้อมูล / ไม่มีรสชาติของ R. data.table และเกิดขึ้นได้เร็วกว่าในเกณฑ์มาตรฐานนี้กว่า Pandas ของ Python ( Py pandas)

มีคำตอบที่ยอดเยี่ยมโดยผู้เขียนของเครื่องมือทั้งสองที่คำถามถามเกี่ยวกับ คำตอบของ Matt อธิบายกรณีที่รายงานในคำถามว่าเกิดจากจุดบกพร่องไม่ใช่อัลกอริทึมผสาน ข้อผิดพลาดได้รับการแก้ไขในวันถัดไปมากกว่า 7 ปีที่แล้ว

ในคำตอบของฉันฉันจะให้เวลาที่ทันสมัยของการดำเนินการรวมสำหรับ data.table และ pandas โปรดทราบว่าจะไม่รวม plyr และ base R merge

การกำหนดเวลาที่ฉันนำเสนอนั้นมาจากโครงการdb-benchmarkซึ่งเป็นเกณฑ์มาตรฐานที่ทำซ้ำได้อย่างต่อเนื่อง มันอัพเกรดเครื่องมือเป็นเวอร์ชันล่าสุดและรันสคริปต์มาตรฐานอีกครั้ง มันทำงานโซลูชั่นซอฟต์แวร์อื่น ๆ อีกมากมาย หากคุณมีความสนใจใน Spark, Dask และอื่น ๆ ไม่กี่คนที่จะตรวจสอบการเชื่อมโยง

ณ ตอนนี้ ... (ยังต้องมีการใช้งาน: อีกหนึ่งขนาดข้อมูลและอีก 5 คำถาม)

เราทดสอบขนาดข้อมูล 2 ขนาดของตาราง LHS
สำหรับขนาดข้อมูลแต่ละขนาดเราใช้คำถามผสาน 5 คำถาม

q1: LHS Inner join RHS- เล็ก ในจำนวนเต็ม
q2 : LHS Inner join RHS- สื่อกลางในจำนวนเต็ม
q3: LHS ภายนอกเข้าร่วม RHS-Medium บนจำนวนเต็ม
q4: LHS Inner join RHS- สื่อบนปัจจัย (เด็ดขาด)
q5: LHS Inner join RHS- ใหญ่ ในจำนวนเต็ม

ตาราง RHS มีขนาดต่าง ๆ 3 ขนาด

• ขนาดเล็กแปลเป็นขนาดของ LHS / 1e6
• สื่อแปลเป็นขนาดของ LHS / 1e3
• ขนาดใหญ่แปลเป็นขนาดของ LHS

ในทุกกรณีมีแถวการจับคู่ประมาณ 90% ระหว่าง LHS และ RHS และไม่มีการทำซ้ำในคอลัมน์การเข้าร่วม RHS (ไม่มีผลิตภัณฑ์คาร์ทีเซียน)

ณ ตอนนี้ (ทำงานในวันที่ 2 พฤศจิกายน 2019)

pandas 0.25.3 เผยแพร่เมื่อวันที่ 1 พฤศจิกายน 2019
data.table 0.12.7 (92abb70) ออกเมื่อวันที่ 2 พฤศจิกายน 2019

ด้านล่างเวลาเป็นวินาทีสำหรับขนาดข้อมูลสองขนาดของ LHS คอลัมน์pd2dtถูกเพิ่มอัตราส่วนการจัดเก็บข้อมูลของจำนวนแพนด้าที่ช้ากว่า data.table กี่ครั้ง

• ข้อมูล 0.5 GB LHS

+-----------+--------------+----------+--------+
| question  |  data.table  |  pandas  |  pd2dt |
+-----------+--------------+----------+--------+
| q1        |        0.51  |    3.60  |      7 |
| q2        |        0.50  |    7.37  |     14 |
| q3        |        0.90  |    4.82  |      5 |
| q4        |        0.47  |    5.86  |     12 |
| q5        |        2.55  |   54.10  |     21 |
+-----------+--------------+----------+--------+

• ข้อมูล LHS 5 GB

+-----------+--------------+----------+--------+
| question  |  data.table  |  pandas  |  pd2dt |
+-----------+--------------+----------+--------+
| q1        |        6.32  |    89.0  |     14 |
| q2        |        5.72  |   108.0  |     18 |
| q3        |       11.00  |    56.9  |      5 |
| q4        |        5.57  |    90.1  |     16 |
| q5        |       30.70  |   731.0  |     23 |
+-----------+--------------+----------+--------+