ไลบรารี R และ / หรือ Python สมัยใหม่ทำให้ SQL ล้าสมัยหรือไม่

ฉันทำงานในสำนักงานที่ SQL Server เป็นกระดูกสันหลังของทุกสิ่งที่เราทำตั้งแต่การประมวลผลข้อมูลไปจนถึงการทำความสะอาด เพื่อนร่วมงานของฉันมีความเชี่ยวชาญในการเขียนฟังก์ชั่นที่ซับซ้อนและขั้นตอนการจัดเก็บเพื่อประมวลผลข้อมูลที่เข้ามาอย่างเป็นระบบเพื่อให้สามารถเป็นมาตรฐานและนำไปใช้งานในรายงานการแสดงภาพและโครงการวิเคราะห์ ก่อนที่จะเริ่มต้นที่นี่ฉันมีประสบการณ์น้อยมากเกี่ยวกับ SQL นอกเหนือจากการเขียนข้อความค้นหาพื้นฐานที่สุด งานเตรียมการวิเคราะห์ส่วนใหญ่ของฉันเสร็จสิ้นแล้วในอาร์. เจ้านายของฉันยืนยันว่าฉันพัฒนาทักษะ SQL ของฉันแม้ว่าดูเหมือนจะมีงานมอบหมายน้อยมากที่ไม่สามารถทำได้อย่างมีประสิทธิภาพมากขึ้น แพคเกจเช่น dplyr, data.table และ tidyr (เพื่อชื่อไม่กี่) คำถามของฉันคือ - นี่สมเหตุสมผลไหม

สองสามสัปดาห์ที่ผ่านมาฉันพบว่าตัวเองต้องเผชิญกับงานของการรับรายชื่อคอลัมน์สำหรับแต่ละแถวในตารางที่ตรงกับเกณฑ์บางอย่างและเชื่อมต่อพวกเขาเป็นเวกเตอร์ของสตริง มีกำหนดเวลาที่แน่นและในเวลานั้นฉันประสบปัญหาการอุดตันและไม่สามารถปิดหัวปัญหาได้ ฉันถามหัวหน้าของฉันใครจะขอให้เพื่อนร่วมงานของฉันเขียนสคริปต์ TSQL เพื่อแก้ปัญหา ในขณะที่เขากำลังทำงานอยู่ฉันก็หาวิธีที่จะทำมันในการเขียนฟังก์ชั่นที่ค่อนข้างง่ายและใช้มันในกรอบข้อมูล เพื่อนร่วมงานของฉันกลับมาพร้อมกับสคริปต์ของเขาประมาณสองชั่วโมงต่อมา อย่างน้อย 75 บรรทัดประกอบด้วยสองซ้อนกันสำหรับลูป ฉันขอให้เขาบอกเมื่อมันทำงานเสร็จและเขาบอกว่ามันจะใช้เวลาหลายชั่วโมง ในขณะเดียวกันสคริปต์ R ของฉันก็สามารถวนรอบระเบียนประมาณ 45,000 รายการได้ในเวลาประมาณ 30 วินาที

ฉันคิดถูกหรือไม่ว่า R เป็นตัวเลือกที่ดีกว่ามากสำหรับการทำความสะอาดและการบันทึกข้อมูล? บางทีผู้พัฒนา SQL ในสำนักงานของฉันไม่ทำงาน ฉันอยากรู้ว่าใครที่ทำงานกับทั้ง R และ SQL (หรือ Python และ SQL สำหรับเรื่องนั้น) มีความคิดเกี่ยวกับเรื่องนี้

R และ SQL เป็นสัตว์ร้ายสองชนิดที่แตกต่างกันโดยสิ้นเชิง SQL เป็นภาษาที่คุณสามารถใช้เพื่อสืบค้นข้อมูลที่เก็บไว้ในฐานข้อมูลตามที่คุณเคยมีประสบการณ์มาแล้ว ประโยชน์ของ SQL กับ R นั้นส่วนใหญ่อยู่ในความเป็นจริงของเซิร์ฟเวอร์ฐานข้อมูล (MS SQL, Oracle, PostgreSQL, MySQL, ฯลฯ )

เซิร์ฟเวอร์ฐานข้อมูลที่ทันสมัยส่วนใหญ่ถ้าไม่ใช่ทั้งหมดนั้นอนุญาตให้ผู้ใช้หลายคนทำการสืบค้นข้อมูลจากแหล่งข้อมูลเดียวกันและทำการแทรกอัปเดตและลบข้อมูลในตารางเดียวกันได้ทั้งหมดในขณะที่มั่นใจได้ว่าข้อมูลยังคงสอดคล้องกัน นี่เป็นสิ่งสำคัญสำหรับการพูดบันทึกธุรกรรมธนาคาร คุณลองนึกภาพว่าใช้ธนาคารเป็น R นั่นคือสิ่งที่เซิร์ฟเวอร์ฐานข้อมูลเข้ามาพวกเขามั่นใจได้ว่าคุณสมบัติ ACID ของกระบวนการทำงานบนฐานข้อมูล กรดหมายถึง Atomicity, ภาวะพร้อมกัน, การแยกและความทนทาน (ดูรายละเอียดของกรดในวิกิพีเดีย ) R เป็นแพลตฟอร์มผู้ใช้เดียวที่ทุกอย่างเกิดขึ้นในหน่วยความจำ ดังนั้นหากคอมพิวเตอร์ของคุณหยุดทำงานครึ่งทางในการทำงานครั้งใหญ่ข้อมูลของคุณจะไม่ถูกจัดเก็บ คุณเป็นคนเดียวที่สามารถเข้าถึงข้อมูลได้ เพื่อความชัดเจน R ไม่ถือเป็นทางเลือกสำหรับเซิร์ฟเวอร์ฐานข้อมูลและ / หรือ SQL

ประโยชน์หลักอีกประการของเซิร์ฟเวอร์ฐานข้อมูลคือการออกแบบฐานข้อมูลที่ดีจะทำให้แน่ใจว่าคุณสามารถสืบค้นฐานข้อมูลของคุณได้อย่างรวดเร็วโดยทำการปรับให้เหมาะสมของแบบสอบถาม เพื่อให้บรรลุเซิร์ฟเวอร์ฐานข้อมูลนี้ติดตามการออกแบบของตาราง ดูการสนทนาแบบเต็มของหัวข้อนี้หน้าวิกิพีเดีย R ไม่สามารถทำการปรับให้เหมาะสมของแบบสอบถาม การออกแบบฐานข้อมูลไม่ดีอาจนำไปสู่การประมวลผลคำสั่งของคุณช้า เซิร์ฟเวอร์ฐานข้อมูลสามารถทำการปรับให้เหมาะสมกับคิวรีที่เคียวรีหลายตารางได้หากใช้คีย์ต่างประเทศในการออกแบบฐานข้อมูลอย่างเหมาะสม

ภาษา SQL มีไวยากรณ์ที่แตกต่างกันมากและฉันแบ่งปันประสบการณ์ของคุณว่าสั้นกว่าที่จะเขียนขั้นตอนการบันทึกข้อมูลโดยใช้ตารางข้อมูลหรือไวยากรณ์ dplyr อย่างไรก็ตามบางครั้งข้อมูลของคุณมีขนาดใหญ่เกินไปสำหรับ R หรือคุณต้องการเก็บผลลัพธ์ไว้ในฐานข้อมูลเป็นส่วนหนึ่งของงานแบทช์เป็นงวดซึ่งจะต้องใช้รหัสตรรกะของคุณใน SQL

จากประสบการณ์ของฉันมีกรณีการใช้งานเฉพาะสำหรับ SQL และ R / Python SQL เหมาะอย่างยิ่งสำหรับการจัดเก็บข้อมูลทางธุรกิจที่สำคัญและช่วยให้ผู้ใช้หลายคนสามารถเข้าถึงแก้ไขแทรกและลบข้อมูลในสภาพแวดล้อมแบบรวมศูนย์ สำหรับข้อมูลใด ๆ ก็ตามที่มีการปิด R และ Python นั้นยอดเยี่ยม หากการบันทึกข้อมูลของคุณต้องดำเนินการเป็นระยะคุณจะต้องพอร์ตสคริปต์ R / Python ของคุณไปยัง SQL

สิ่งเหล่านี้ไม่ได้เปรียบเทียบกันจริง ๆ SQL เป็นภาษาที่ใช้ในการเข้าถึงข้อมูล R เป็นภาษาที่ใช้ในการทำงานกับข้อมูล

SQL ไม่ได้เป็นเครื่องมือที่มีประสิทธิภาพสำหรับการ munging เพราะมันยากที่จะเห็นขั้นตอนกลางและเมื่อมันเกิดข้อผิดพลาดมันไม่น่าจะอยู่ที่แบบฟอร์ม / คุณภาพ / โครงสร้างของข้อมูลของคุณ

โดยทั่วไปขั้นตอนการทำงานของฉัน:

1. รับข้อมูลดิบจากแบบสอบถาม SQL (ใน R)
2. สร้างกิจวัตร munging
3. ถ้าเป็นไปได้ให้เขียนแบบสอบถาม SQL อีกครั้งเพื่อให้บรรลุการตั้งค่าที่สำเร็จใน R

ยังตระหนักว่าผู้ใช้ข้อมูลไม่ได้ใช้ R แต่ผู้ใช้หลายคนยังคงเชื่อมต่อแพลตฟอร์มที่พวกเขาเลือกกับข้อมูลโดยใช้ SQL

library (dbplyr)มีวิธีการที่ถูกต้อง: เขียนทุกอย่างเป็น R (โดยใช้ tidyverse) และปล่อยให้ไลบรารี "คอมไพล์" รหัส R-time ลงใน SQL ระดับต่ำ

เนื่องจากการแปลทั้งหมดไม่สามารถแปลได้วิธีการอื่นจึงเป็นวิธีที่ดำเนินการโดย SQL Server: อนุญาตให้เรียกใช้ข้อมูลโค้ด R จากคำสั่ง "select" ของ SQL

วิธีการ 1. , 2. , 3. ที่กล่าวถึงโดย HEITZ นั้นเป็นไปได้ในประสบการณ์ของฉันที่สามารถขยายได้ด้วยทางเลือกสำหรับ 3. ที่คุณเขียนข้อมูลของคุณจาก R (data.table) กลับสู่ MySQL

ดังนั้นขั้นตอนแบบเต็มคือ MySQL-> data.table-> MySQL

ถ้าคุณแน่ใจว่าคุณใช้ data.table ซิงก์ที่คุณไม่ได้คัดลอก DT มันยังเป็นมิตรกับแรม

ในคำNO SQLเป็นวิธีที่กระชับและยืดหยุ่นในการอธิบายและสรุปโครงสร้างกึ่งโครงสร้างที่มีโครงสร้างและแม้กระทั่งข้อมูลที่ไม่มีโครงสร้าง - เมื่อวางเลเยอร์ล่ามที่เหมาะสมไว้บนสุด โดยวิธีการที่sqlถือว่าเป็นเกือบจะต้องมีสำหรับนักวิทยาศาสตร์ข้อมูล

SQL เป็นวิธีที่กระชับและมีประสิทธิภาพในการดำเนินการหลักของ:

• ประมาณการ ( เลือก .. )
• การกรอง ( ที่ไหน .. )
• การจัดกลุ่ม / การกรอง ( จัดกลุ่มตามและมี )
• การรวมพื้นฐาน ( นับ , ผลรวม , เฉลี่ย .. )
• ร่วม

อำนาจที่แท้จริงมาเมื่อรวมผลการใช้มุมมองแบบอินไลน์ เมื่อผมต้องทำอย่างนั้นผมจะใช้อย่างใดอย่างหนึ่งsqldf, pandasql, pysparkSql/ sparkSqlหรือการเชื่อมต่อ RDBMS โดยตรง เขียนเดียวกันในลักษณะที่รัดกุมมากที่สุดด้วยdata.table(ดีกว่าdata.frame) หรือdatatable(ดีกว่าpandas) ยังคง clunky มากขึ้นมาก clunky หรือเกือบเป็นไปไม่ได้ขึ้นอยู่กับความซับซ้อนของคำสั่งมากขึ้นพยายาม

สำหรับ data munging : นั่นเป็นเรื่องที่แตกต่าง: การดำเนินการบางอย่างจะแสดงใน sql และไม่มากนัก เมื่อใดก็ตามที่คุณรวมUDFs จะมีละติจูดที่กว้างขึ้นของสิ่งที่สามารถทำได้ งานปัจจุบันของฉันรวมถึงจำนวนของUDFที่จะทำสิ่งต่างๆเช่นลูกค้าแยกการดำเนินงานที่กำหนดเองรวมตัวและกำหนดเองวิธีการให้คะแนน