Data Engineer or die: เรื่องราวของนักพัฒนาคนหนึ่ง

เมื่อต้นเดือนธันวาคม ฉันทำผิดพลาดร้ายแรงและเป็นจุดเปลี่ยนในชีวิตของฉันในฐานะนักพัฒนา และได้ย้ายไปร่วมงานกับทีม Data Engineering (DE) ภายในบริษัท ในบทความนี้ ผมจะแบ่งปันข้อสังเกตบางอย่างที่ผมได้ทำระหว่างสองเดือนของการทำงานในทีม DE

Data Engineer or die: เรื่องราวของนักพัฒนาคนหนึ่ง

ทำไมต้องวิศวกรรมข้อมูล?

การเดินทางของฉันไปยัง DE เริ่มขึ้นในฤดูร้อนปี 2019 เมื่อเรา Xneg ไปกันเถอะ สำนักวิชาคอมพิวเตอร์แบบกระจายข้าพเจ้าก็บรรลุพระโพธิญาณ ณ ที่นั้น. ฉันเริ่มสนใจหัวข้อนี้ ศึกษาอัลกอริธึม และแม้แต่เกี่ยวกับพวกเขา เพื่อเขียนจากนั้นจึงคิดถึงขอบเขตของการใช้งานและพบว่าการใช้งานจริงในบริษัทของเรานั้นเป็นฐานข้อมูลแบบกระจาย

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

หากคุณต้องการเป็น Data Driven ขั้นแรกให้กลายเป็น Event Driven

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

โดยทั่วไปมีหลายสิ่งที่ต้องคิดและนั่นคือเหตุผลว่าทำไมบริเวณนี้จึงมีเสน่ห์ มันบังเอิญว่าในบริษัทของเรา Data Engineer มีความรับผิดชอบที่กว้างกว่าคนที่เขียนไปป์ไลน์ ETL/ELT มาก (หากคุณไม่รู้ว่าตัวย่อเหล่านี้หมายถึงอะไร ให้มาที่ พบ. เป็นการโฆษณาตามบริบท).

เราจัดการกับสถาปัตยกรรมการจัดเก็บข้อมูล การสร้างแบบจำลองข้อมูล ปัญหาที่เกี่ยวข้องกับความปลอดภัยของข้อมูล และไปป์ไลน์เองแน่นอน เรายังต้องแน่ใจว่าในอีกด้านหนึ่ง การปรากฏตัวของเราไม่ได้เป็นภาระมากสำหรับนักพัฒนาผลิตภัณฑ์ และพวกเขาจะต้องถูกเบี่ยงเบนความสนใจจากข้อกำหนดของเราให้น้อยที่สุดเท่าที่จะทำได้เมื่อตัดคุณสมบัติใหม่เข้าสู่ระบบ และในทางกลับกัน เรา จำเป็นต้องจัดเตรียมข้อมูลการจัดเก็บข้อมูลที่สะดวกสำหรับนักวิเคราะห์และทีม BI นั่นคือวิธีที่เรามีชีวิตอยู่

ความยากลำบากเมื่อเปลี่ยนจากการพัฒนา

ในวันแรกของการทำงาน ฉันพบกับความยากลำบากมากมายที่อยากจะแบ่งปันกับคุณ

1. สิ่งแรกที่ฉันเห็นคือการไม่มีการสอนและการฝึกฝนบางอย่าง ยกตัวอย่างเช่น การครอบคลุมโค้ดพร้อมการทดสอบ เรามีกรอบการทดสอบหลายร้อยกรอบในการพัฒนา เมื่อทำงานกับข้อมูล ทุกอย่างจะซับซ้อนมากขึ้น ใช่ เราสามารถทดสอบไปป์ไลน์ ETL กับข้อมูลทดสอบได้ แต่เราต้องทำทั้งหมดด้วยตนเองและค้นหาวิธีแก้ปัญหาสำหรับแต่ละกรณีโดยเฉพาะ เป็นผลให้ความครอบคลุมของการทดสอบแย่ลงมาก โชคดีที่มีความคิดเห็นอีกชั้นหนึ่งในรูปแบบของการตรวจสอบและบันทึก แต่สิ่งนี้ทำให้เราต้องโต้ตอบในเชิงรับมากกว่าเชิงรุก ซึ่งสร้างความโมโหและทำให้ตกใจ

2. โลกจากมุมมองของ DE ไม่ได้เป็นอย่างที่เห็นสำหรับนักพัฒนาผลิตภัณฑ์ทั่วไป (แน่นอนว่าผู้อ่านไม่ใช่แบบนั้นและเขารู้ทุกอย่างอยู่แล้ว แต่ฉันไม่รู้ และตอนนี้ฉันกำลังสับสน มันขึ้น) ในฐานะนักพัฒนา ฉันสร้างไมโครเซอร์วิสของตัวเอง ใส่ข้อมูลใน [ฐานข้อมูลที่คุณเลือก] บันทึกสถานะของฉันที่นั่น รับบางอย่างด้วย ID และมันก็ไม่เป็นไร บริการช้า คำสั่งซื้อเกิดความสับสน แค่นั้นเอง พวกเขาขอให้ฉันค้นหาสถานะของฉันในบริการอื่น ดังนั้นฉันจะโยนเหตุการณ์ลงใน RabbitMQ บางส่วน เท่านี้ก็เรียบร้อย และที่นี่เรากลับมาที่ประเด็นเหตุการณ์ที่อธิบายไว้ข้างต้นอีกครั้ง

บริการที่จำเป็นสำหรับการปฏิบัติงานไม่เหมาะกับเราสำหรับข้อมูลในอดีต ดังนั้นคำถามเกี่ยวกับสัญญาบริการการทำงานใหม่และการทำงานอย่างใกล้ชิดกับทีมพัฒนาจึงเริ่มต้นขึ้น คุณไม่สามารถจินตนาการได้เลยว่าเราใช้เวลากี่ชั่วโมงในการตกลงกัน: เขาเป็นผู้ขับเคลื่อนกิจกรรมประเภทใดในบริษัทของเรา

3. คุณต้องคิดด้วยหัวของคุณ ไม่ ฉันไม่ได้หมายความว่า Developer ไม่คิดว่า (แม้ว่าฉันจะเป็นใครเพื่อพูดแทนทุกคนก็ตาม) เพียงแต่ในการพัฒนาผลิตภัณฑ์บ่อยครั้งคุณมีสถาปัตยกรรมบางประเภทอยู่แล้ว และคุณตัดการสับเปลี่ยนต่างๆ ออกจากงานที่ค้างอยู่ แน่นอนว่าสิ่งนี้ต้องมีการวางแผนและความคิด แต่นี่คืองานต่อเนื่อง ซึ่งปัญหาหลักคือต้องทำได้ดีและมีประสิทธิภาพ

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

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

ขณะนี้เป็นเรื่องยากที่จะหาการประชุมหรือการพบปะที่เพียงพออย่างน้อยหนึ่งครั้งในพื้นที่ของเรา ไม่แน่นอน มีการพบปะกันมากมายกับคำว่า Data แต่ถัดจากคำนี้มักจะมีตัวย่อแปลกๆ เช่น ML หรือ AI นี่ไม่ใช่สำหรับเรา เรากำลังพูดถึงวิธีสร้างสถานที่จัดเก็บ ไม่ใช่วิธีทำให้เซลล์ประสาทเลอะเทอะ ฮิปสเตอร์เหล่านี้ได้ยึดครองทุกสิ่งทุกอย่างแล้ว ส่งผลให้เราไม่มีชุมชน อย่างไรก็ตาม หากคุณเป็น Data Engineer และรู้จักชุมชนที่ดี โปรดเขียนความคิดเห็นไว้

สรุปและประกาศผลการประชุม

เราจะจบลงด้วยอะไร? ประสบการณ์ครั้งแรกของฉันบอกฉันว่าความรู้สึกในฐานะวิศวกรข้อมูลจะเป็นประโยชน์สำหรับนักพัฒนาทุกคน มันช่วยให้เรามองสิ่งต่าง ๆ ที่แตกต่างออกไป และไม่แปลกใจเมื่อดวงตาของเราแดงก่ำเมื่อเราเห็นว่านักพัฒนาปฏิบัติต่อข้อมูลของพวกเขาอย่างไร ดังนั้น หากมี DE ในบริษัทของคุณ แค่พูดคุยกับคนเหล่านี้ คุณจะได้เรียนรู้สิ่งใหม่ๆ มากมาย (เกี่ยวกับตัวคุณเอง)

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

เมื่อใช้โอกาสนี้ ฉันขอเชิญชวนทุกคนที่สนใจมาเข้าร่วมมีตติ้งชุมชนครั้งแรกของเราในชื่อที่มีแนวโน้มดีว่า "DE or DIE" ซึ่งจะจัดขึ้นในวันที่ 27.02.2020 กุมภาพันธ์ XNUMX ที่สำนักงาน Dodo Pizza รายละเอียดได้ที่ ไทม์แพด.

หากมีอะไรเกิดขึ้น ฉันจะอยู่ที่นั่น คุณสามารถบอกฉันเป็นการส่วนตัวว่าฉันคิดผิดเกี่ยวกับนักพัฒนาอย่างไร

ที่มา: will.com

เพิ่มความคิดเห็น