สาขาวิศวกรรมข้อมูลกำลังประสบกับการแบ่งแยกที่สำคัญซึ่งก่อให้เกิดการอภิปรายอย่างดุเดือดในหมู่ผู้เชี่ยวชาญ ในขณะที่บางฝ่ายสนับสนุนการบรรจบกับแนวปฏิบัติวิศวกรรมซอฟต์แวร์แบบดั้งเดิม อีกฝ่ายหนึ่งกลับปกป้องแนวทางปัจจุบันของเวิร์กโฟลว์ที่ใช้ SQL และเครื่องมือเฉพาะทาง
การแบ่งแยกครั้งใหญ่ในบทบาทวิศวกรรมข้อมูล
การแบ่งแยกที่ชัดเจนได้เกิดขึ้นระหว่างสองค่ายของผู้เชี่ยวชาญด้านข้อมูล ฝ่ายหนึ่งคือวิศวกรที่มีพื้นฐานด้านวิทยาการคอมพิวเตอร์ซึ่งเน้นหลักการวิศวกรรมซอฟต์แวร์ เช่น การควบคุมเวอร์ชัน การรวมแบบต่อเนื่อง และเฟรมเวิร์กการทดสอบที่เหมาะสม อีกฝ่ายหนึ่งคือนักวิเคราะห์ที่กลายมาเป็นวิศวกรข้อมูล ซึ่งทำงานกับ SQL การกำหนดค่า YAML และอินเทอร์เฟซแบบชี้และคลิกผ่านเครื่องมือเช่น dbt เป็นหลัก
การแบ่งแยกนี้ได้สร้างความตึงเครียดในอุตสาหกรรม โดยผู้เชี่ยวชาญบางรายรู้สึกว่าทักษะของพวกเขาถูกลดค่า วิศวกรที่สามารถตั้งค่าไปป์ไลน์ CI/CD และปรับใช้ระบบที่ซับซ้อนได้ พบว่าตัวเองถูกจัดกลุ่มเดียวกันกับผู้ที่รู้เพียงการดำเนินการ SQL พื้นฐาน ทำให้เกิดความหงุดหงิดเกี่ยวกับค่าตอบแทนและความคาดหวังในบทบาทงาน
การจำแนกบทบาทวิชาชีพ:
- Data Engineers แบบดั้งเดิม: ผู้เชี่ยวชาญที่มีการศึกษาด้าน CS ที่เน้นการปฏิบัติงานด้าน software engineering, CI/CD และการจัดการโครงสร้างพื้นฐาน
- นักวิเคราะห์ที่เปลี่ยนมาเป็น Data Engineers: ผู้เชี่ยวชาญที่ใช้งาน SQL, YAML และเครื่องมือแบบ point-and-click อย่าง dbt เป็นหลัก
- Tool Jockeys: ผู้เชี่ยวชาญด้านข้อมูลที่มุ่งเน้นความเชี่ยวชาญในแพลตฟอร์มเฉพาะโดยไม่มีทักษะด้านวิศวกรรมในวงกว้าง
- Platform Engineers: วิศวกรที่จัดการโครงสร้างพื้นฐานข้อมูล การจัดทำดัชนี และการเพิ่มประสิทธิภาพการประมวลผลขนาดใหญ่
ปัญหา Notebook และความพร้อมสำหรับการใช้งานจริง
ความกังวลสำคัญที่ชุมชนยกขึ้นมาคือการใช้ Jupyter notebooks อย่างแพร่หลายในสภาพแวดล้อมการใช้งานจริง องค์กรจำนวนมากถือว่าเวิร์กโฟลว์ที่ใช้ notebook เป็นระบบที่พร้อมสำหรับการใช้งานจริง แม้จะขาดการควบคุมเวอร์ชันที่เหมาะสม กระบวนการทดสอบอัตโนมัติ และกระบวนการปรับใช้
แนวทางนี้ได้สร้างสิ่งที่บางคนเรียกว่า notebook hell ซึ่งไปป์ไลน์ข้อมูลที่สำคัญมีอยู่ในรูปของ notebooks ที่กระจัดกระจายพร้อมการจัดการ dependency ที่ไม่ดี ปัญหานี้ดูเหมือนจะรุนแรงเป็นพิเศษในแพลตฟอร์มเช่น Databricks ซึ่งการรวม git มักหมายถึงการ checkout โค้ดและ commit ไปยัง main branch โดยตรงโดยไม่มีกระบวนการ code review ที่เหมาะสม
มีการทำสิ่งต่างๆ ใน notebooks และเรียกว่าพร้อมสำหรับการใช้งานจริง มันบ้าสิ้นดี
แพลตฟอร์มเทคโนโลยีหลักที่กล่าวถึง:
- ClickHouse: ฐานข้อมูลวิเคราะห์ประสิทธิภาพสูงที่ให้เวลาการค้นหาภายในวินาที
- Databricks: แพลตฟอร์มวิเคราะห์บนคลาวด์ที่มีเวิร์กโฟลว์แบบ notebook-centric
- dbt: เครื่องมือการแปลงข้อมูลที่นำ version control มาใช้กับเวิร์กโฟลว์ SQL
- Airflow / Prefect: แพลตฟอร์มการจัดระเบียบเวิร์กโฟลว์สำหรับ data pipelines
- Snowflake: คลาวด์ data warehouse ที่มีความสามารถใน Python stored procedure
- AWS Glue: บริการ Apache Spark แบบจัดการให้สำหรับการประมวลผลข้อมูล
- DuckDB: ฐานข้อมูลวิเคราะห์แบบ in-process ที่กำลังได้รับความนิยมสำหรับ workloads ที่เร็วขึ้น
 |
|---|
| ผลลัพธ์จาก Terminal ที่แสดงการตั้งค่าสภาพแวดล้อมการพัฒนาสำหรับโครงสร้างพื้นฐานข้อมูล เน้นย้ำถึงความท้าทายด้านความพร้อมสำหรับการใช้งานจริงที่กล่าวถึง |
ปรากฏการณ์ Tool Jockey
ประเด็นสำคัญอีกประการหนึ่งที่ชุมชนเน้นย้ำคือการแพร่หลายของ tool jockeys ในทีมข้อมูล ผู้เชี่ยวชาญเหล่านี้กลายเป็นผู้เชี่ยวชาญในแพลตฟอร์มเฉพาะ แต่ขาดทักษะวิศวกรรมพื้นฐาน เช่น การทดสอบอัตโนมัติ การควบคุมเวอร์ชัน และ infrastructure as code
สถานการณ์นี้มักเกิดจากข้อจำกัดขององค์กรที่ทีมต้องใช้เครื่องมือมาตรฐานและมุ่งเน้นไปที่การทำให้งานทำงานได้ภายในสภาพแวดล้อมเหล่านั้น แทนที่จะสร้างระบบที่แข็งแกร่งและดูแลรักษาได้ ผลลัพธ์คือโครงสร้างพื้นฐานข้อมูลที่เปราะบางซึ่งเสียบ่อยและใช้เวลามากเกินไปในการดูแลรักษา
โซลูชันที่เกิดขึ้นใหม่และแนวทางสมัยใหม่
แม้จะมีความท้าทายเหล่านี้ ทีมบางทีมก็ประสบความสำเร็จในการเชื่อมช่องว่างระหว่างงานข้อมูลแบบดั้งเดิมกับแนวปฏิบัติวิศวกรรมซอฟต์แวร์ แนวทางสมัยใหม่รวมถึงการใช้ภาษาโปรแกรมมิ่งจริงพร้อมการแยกแยะที่เหมาะสม การใช้กลยุทธ์การทดสอบที่ครอบคลุมพร้อมการตรวจสอบคุณภาพข้อมูล และการใช้แพลตฟอร์มการจัดการเช่น Airflow สำหรับเวิร์กโฟลว์การใช้งานจริง
เครื่องมือเช่น dbt ได้ช่วยโดยการนำการควบคุมเวอร์ชันมาสู่การแปลง SQL และเปิดใช้งานการ rehydration แบบต่อเนื่องของโมเดลข้อมูล อย่างไรก็ตาม ชุมชนยังคงแบ่งแยกเกี่ยวกับว่าแนวทางแบบ declarative ที่ใช้ YAML เพียงพอหรือไม่ หรือจำเป็นต้องใช้ภาษาโปรแกรมมิ่งแบบดั้งเดิมมากกว่าสำหรับระบบข้อมูลที่ซับซ้อน
การอภิปรายเผยให้เห็นว่าแม้การบรรจบกันระหว่างวิศวกรรมข้อมูลและวิศวกรรมซอฟต์แวร์อาจกำลังเกิดขึ้นในองค์กรบางแห่ง แต่สาขานี้ยังคงเผชิญความท้าทายที่สำคัญในการกำหนดมาตรฐานแนวปฏิบัติที่ดีที่สุดและความคาดหวังทางวิชาชีพทั่วทั้งอุตสาหกรรม
อ้างอิง: Data engineering and software engineering are converging
 |
|---|
| อินเทอร์เฟซโปรแกรมแก้ไขโค้ดที่แสดงการใช้งาน TypeScript สำหรับไปป์ไลน์ข้อมูล สะท้อนแนวทางปฏิบัติด้านวิศวกรรมสมัยใหม่ในวิศวกรรมข้อมูล |