BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//seattle2023.pydata.org//LJWGTQ
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
BEGIN:STANDARD
DTSTART:20001029T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10;UNTIL=20061029T090000Z
TZNAME:PST
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
END:STANDARD
BEGIN:STANDARD
DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
TZNAME:PST
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000402T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=20060402T100000Z
TZNAME:PDT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
END:DAYLIGHT
BEGIN:DAYLIGHT
DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
TZNAME:PDT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-cfp-LJWGTQ@seattle2023.pydata.org
DTSTART;TZID=America/Los_Angeles:20230426T110000
DTEND;TZID=America/Los_Angeles:20230426T123000
DESCRIPTION:When Pandas starts to become a bottleneck for data workloads\, 
 data practitioners seek out distributed computing frameworks such as Spark
 \, Dask\, and Ray. The problem is porting over existing code would take a 
 lot of rewrites. Though drop-in replacements exist where you can just chan
 ge the import statement\, the resulting code is still attached to the Pand
 as interface\, which is not a good grammar for a lot of distributed comput
 ing problems. In this tutorial\, we will go over some scenarios where the 
 Pandas interface can't scale\, and we'll show how to port the existing cod
 e to distributed backend with minimal rewrites.
DTSTAMP:20250709T220055Z
LOCATION:Kodiak Theatre
SUMMARY:Fugue: Porting Existing Python and Pandas Code to Spark\, Dask\, an
 d Ray - Kevin Kho\, Anthony Holten
URL:https://seattle2023.pydata.org/cfp/talk/LJWGTQ/
END:VEVENT
END:VCALENDAR