สวัสดีฮับ! ที่ Dodo Pizza Engineering เรารักข้อมูล (และใครบ้างจะไม่ชอบข้อมูลในทุกวันนี้) ตอนนี้จะมีเรื่องราวเกี่ยวกับวิธีการรวบรวมข้อมูลทั้งหมดในโลกของ Dodo Pizza และช่วยให้พนักงานของบริษัทสามารถเข้าถึงอาร์เรย์ข้อมูลนี้ได้อย่างสะดวก ภารกิจภายใต้เครื่องหมายดอกจัน: เพื่อรักษาความกังวลใจของทีมวิศวกรรมข้อมูล
เช่นเดียวกับ Plyushkins ตัวจริง เรารวบรวมข้อมูลทุกประเภทเกี่ยวกับงานร้านพิซซ่าของเรา:
- จดจำคำสั่งซื้อของผู้ใช้ทั้งหมด
- เรารู้ว่าใช้เวลานานแค่ไหนในการทำพิซซ่าครั้งแรกใน Syktyvkar
- เรามาดูกันว่าต้องใช้เวลานานแค่ไหนกว่าพิซซ่าจะเย็นบนชั้นวางเครื่องทำความร้อนในโวโรเนซตอนนี้
- เราจัดเก็บข้อมูลการตัดจำหน่ายผลิตภัณฑ์
- และอื่น ๆ อีกมากมาย
ขณะนี้หลายทีมมีหน้าที่รับผิดชอบในการทำงานกับข้อมูลที่ Dodo Pizza หนึ่งในนั้นคือทีมวิศวกรรมข้อมูล ตอนนี้พวกเขา (นั่นคือเรา) ต้องเผชิญกับภารกิจในการให้พนักงานของ บริษัท เข้าถึงข้อมูลอาร์เรย์นี้ได้อย่างสะดวก
เมื่อเราเริ่มคิดเกี่ยวกับวิธีการทำเช่นนี้ และเริ่มหารือเกี่ยวกับปัญหา เราพบแนวทางการจัดการข้อมูลที่น่าสนใจมาก - (ตามลิงค์คุณจะพบบทความที่ยอดเยี่ยมและยอดเยี่ยม) ความคิดของเธอเข้ากันได้ดีมากกับแนวคิดของเราว่าเราต้องการสร้างระบบของเราอย่างไร นอกจากนี้ในบทความ จะมีการทบทวนแนวทางนี้และวิธีที่เราเห็นการนำไปปฏิบัติใน Dodo Pizza Engineering
เราหมายถึงอะไรโดย "ข้อมูล"
ขั้นแรก เรามานิยามความหมายของข้อมูลใน Dodo Pizza Engineering กันก่อน:
- เหตุการณ์ที่ส่งโดยบริการ (เรามีบัสทั่วไปที่สร้างโดยใช้ RabbitMQ)
- บันทึกภายในฐานข้อมูล (สำหรับเรานี่คือ MySQL และ CosmosDB)
- คลิกสตรีมจากแอปพลิเคชันมือถือและเว็บไซต์
เพื่อให้ธุรกิจ Dodo Pizza ใช้และพึ่งพาข้อมูลนี้ สิ่งสำคัญคือต้องปฏิบัติตามเงื่อนไขต่อไปนี้:
- พวกเขาจะต้องสมบูรณ์ เราต้องแน่ใจว่าเราจะไม่เปลี่ยนแปลงข้อมูลในขณะที่กำลังประมวลผล จัดเก็บ และแสดงผล หากธุรกิจไม่สามารถเชื่อถือข้อมูลของเราได้ ข้อมูลนั้นก็จะไม่มีประโยชน์ใดๆ
- จะต้องมีการประทับเวลาและไม่ถูกเขียนทับ ซึ่งหมายความว่า ณ เวลาใดก็ตาม เราต้องการย้อนกลับไปดูข้อมูลจากช่วงเวลานั้นได้ ตัวอย่างเช่น ค้นหาจำนวนพิซซ่าที่ขายได้ในวันที่ 8 กรกฎาคม 2018
- พวกเขาจะต้องเชื่อถือได้ ในกระบวนการรวบรวมและจัดเก็บข้อมูล เราต้องไม่สูญเสียไม่เพียงแต่ความสมบูรณ์เท่านั้น แต่ยังรวมถึงความน่าเชื่อถือด้วย เราไม่สามารถสูญเสียข้อมูลหรือเสี้ยวเวลาได้ เพราะเมื่อรวมกับสิ่งเหล่านี้แล้ว เราก็สูญเสียความไว้วางใจจากลูกค้าของเรา (ทั้งภายนอกและภายใน)
- จะต้องมีวงจรที่เสถียร - เราเขียนคำขอสำหรับข้อมูลนี้ เราไม่อยากให้มีการเปลี่ยนแปลงมากนักกับการเปลี่ยนแปลงในโค้ดของแอปพลิเคชัน พร้อมด้วยการปรับโครงสร้างใหม่ ซึ่งการสืบค้นของเราหยุดทำงาน บุคคลที่เขียนข้อความค้นหาจะไม่มีทางรู้ว่าคุณได้ทำการปรับโครงสร้างใหม่จนกว่าทุกอย่างจะพัง ฉันไม่อยากได้ยินเรื่องนี้จากลูกค้า
เมื่อพิจารณาข้อกำหนดทั้งหมดเหล่านี้แล้ว เราก็ได้ข้อสรุปว่าข้อมูลใน Dodo เป็นผลิตภัณฑ์ เช่นเดียวกับ API สาธารณะของบริการ ดังนั้นทีมเดียวกันที่เป็นเจ้าของบริการจึงควรเป็นเจ้าของข้อมูล นอกจากนี้ การเปลี่ยนแปลงสคีมาข้อมูลจะต้องเข้ากันได้แบบย้อนหลังเสมอ
แนวทางดั้งเดิม – Data Lake
เพื่อแก้ปัญหาการจัดเก็บและการประมวลผลข้อมูลขนาดใหญ่ที่เชื่อถือได้ มีแนวทางแบบดั้งเดิมที่นำมาใช้ในหลายบริษัทที่ทำงานกับแหล่งรวมข้อมูลดังกล่าว - Data Lake ส่วนหนึ่งของแนวทางนี้ วิศวกรข้อมูลจะรวบรวมข้อมูลจากส่วนประกอบทั้งหมดของระบบและรวมไว้ในที่เก็บข้อมูลขนาดใหญ่แห่งเดียว (เช่น Hadoop, Azure Kusto, Apache Cassandra หรือแม้แต่แบบจำลอง MySQL หากข้อมูลพอดีกับ มัน).
จากนั้นวิศวกรคนเดียวกันนี้ก็เขียนคำขอไปยังที่เก็บข้อมูลดังกล่าว การใช้แนวทางนี้ใน Dodo Pizza Engineering หมายความว่าทีมวิศวกรรมข้อมูลจะเป็นเจ้าของสคีมาข้อมูลในคลังข้อมูลเชิงวิเคราะห์
ในสถานการณ์นี้ ทีมกลายเป็นแมวเศร้ามาก และนี่คือเหตุผล:
- เธอจะต้องติดตามการเปลี่ยนแปลงใน ทั้งหมด บริการภายในบริษัท และมีคำขอดึงข้อมูลจำนวนมากและมีการเปลี่ยนแปลงมากมาย (โดยเฉลี่ยแล้วเราจะรวมคำขอดึงข้อมูลประมาณ 100 รายการต่อสัปดาห์ ในขณะที่บริการจำนวนมากไม่ได้สร้างคำขอดึงข้อมูลเลย)
- เมื่อเปลี่ยนสคีมาข้อมูล เจ้าของผลิตภัณฑ์และทีมงานที่เปลี่ยนสคีมาข้อมูลต้องรอให้ Data Engineering เพิ่มโค้ดที่จำเป็นเพื่อรองรับการเปลี่ยนแปลง ในขณะเดียวกัน เราก็มีฟีเจอร์มากมายมาเป็นเวลานาน และสถานการณ์ที่ทีมหนึ่งรออีกทีมหนึ่งนั้นหายากมาก และเราไม่ต้องการให้สิ่งนี้กลายเป็นส่วนหนึ่งของกระบวนการพัฒนา "ปกติ"
- มันจะต้องจุ่มลงไป ทั้งหมด ธุรกิจของบริษัท เครือร้านพิซซ่าดูเหมือนเป็นธุรกิจที่เรียบง่าย แต่ดูเหมือนเป็นเช่นนั้นเท่านั้น เป็นเรื่องยากมากที่จะรวบรวมความสามารถเพียงพอในทีมเดียวเพื่อสร้างแบบจำลองข้อมูลที่เพียงพอสำหรับทั้งบริษัท
- มันเป็นจุดล้มเหลวจุดเดียว ทุกครั้งที่คุณต้องการเปลี่ยนแปลงข้อมูลที่ส่งคืนโดยบริการหรือเขียนคำขอ งานทั้งหมดนี้ตกเป็นหน้าที่ของทีมวิศวกรรมข้อมูล ส่งผลให้ทีมงานมีงานที่ค้างอยู่มากเกินไป
ปรากฎว่าทีมอยู่ตรงจุดที่ความต้องการจำนวนมากมาบรรจบกัน และไม่น่าจะสามารถตอบสนองความต้องการเหล่านั้นได้ ในขณะเดียวกัน คุณจะอยู่ภายใต้ความกดดันและความเครียดตลอดเวลา เราไม่ต้องการสิ่งนี้จริงๆ จึงต้องคิดหาวิธีแก้ปัญหาเหล่านี้และวิเคราะห์ข้อมูลไปพร้อมๆ กัน
การย้ายจาก Data Lake ไปยัง Data Mesh
โชคดีที่เราไม่ใช่คนเดียวที่ถามคำถามนี้กับตัวเอง ในความเป็นจริงแล้ว ปัญหาที่คล้ายกันนี้ได้รับการแก้ไขแล้วในอุตสาหกรรมนี้ (ฮาเลลูยา!) ในพื้นที่อื่น: การใช้งานแอปพลิเคชัน ใช่ ฉันกำลังพูดถึงแนวทาง DevOps ซึ่งทีมจะกำหนดวิธีปรับใช้ผลิตภัณฑ์ที่พวกเขาสร้างขึ้น
Zhamak Dehghani ที่ปรึกษาของ ThoughtWorks เสนอแนวทางที่คล้ายกันในการแก้ปัญหา Data Lake เมื่อได้ดูวิธีที่ Netflix และ Spotify แก้ไขปัญหาที่คล้ายกัน เธอจึงเขียนบทความที่น่าทึ่งขึ้นมา (ลิงก์ไปอยู่ที่จุดเริ่มต้นของบทความ) แนวคิดหลักที่เรานำมาจากมัน:
- แบ่ง Data Lake ขนาดใหญ่ออกเป็นโดเมนข้อมูล ซึ่งคล้ายกับโดเมนการออกแบบที่ขับเคลื่อนด้วยโดเมนมาก แต่ละโดเมนเป็นบริบทที่มีขอบเขตขนาดเล็ก
- ทีมงานฟีเจอร์ซึ่งรับผิดชอบโดเมน DDD ยังรับผิดชอบโดเมนข้อมูลที่เกี่ยวข้องด้วย พวกเขาจัดเก็บสคีมา ทำการเปลี่ยนแปลง และโหลดข้อมูลลงในสคีมา ในเวลาเดียวกันพวกเขาเองก็รู้ทุกอย่าง: วิธีเปลี่ยนการโหลดข้อมูลและไม่ทำลายสิ่งใด ๆ เมื่อแอปพลิเคชันเปลี่ยนแปลง ความรู้ไม่หายไปไหน พวกเขาไม่จำเป็นต้องไปที่ใดก็ได้เพื่อเปิดข้อมูล ทีมงานเองเป็นผู้นำวงจรการพัฒนาเต็มรูปแบบจากการเปลี่ยนแปลงข้อมูลการดำเนินงานไปจนถึงการให้ข้อมูลการวิเคราะห์แก่บุคคลที่สาม ทีมหนึ่งเป็นเจ้าของทุกสิ่งที่เกี่ยวข้องกับโดเมน (ทั้งโดเมนธุรกิจและโดเมนข้อมูล)
- วิศวกรข้อมูล – บทบาทภายในทีมฟีเจอร์ สิ่งนี้ไม่จำเป็นต้องเป็นรายบุคคล แต่จำเป็นที่ทีมจะต้องมีความสามารถนี้
ขณะเดียวกันทีมงาน Data Engineering...
หากคุณจินตนาการว่าทั้งหมดนี้เกิดขึ้นได้ด้วยการดีดนิ้ว คุณจะต้องตอบคำถามเพียงสองข้อเท่านั้น:
ตอนนี้ทีม Data Engineering จะทำอะไร? Dodo Pizza Engineering มีแพลตฟอร์ม/ทีมงาน SRE อยู่แล้ว เป้าหมายคือเพื่อให้นักพัฒนามีเครื่องมือในการปรับใช้บริการได้อย่างง่ายดาย ทีมวิศวกรรมข้อมูลจะทำหน้าที่เดียวกันสำหรับข้อมูลเท่านั้น
การเปลี่ยนข้อมูลการปฏิบัติงานให้เป็นข้อมูลเชิงวิเคราะห์เป็นกระบวนการที่ซับซ้อน การทำให้ข้อมูลการวิเคราะห์พร้อมใช้งานทั่วทั้งบริษัทนั้นยากยิ่งขึ้นไปอีก ปัญหาเหล่านี้เองที่ทีม Data Engineering จะต้องจัดการ
เราจะมอบชุดเครื่องมือและแนวทางปฏิบัติที่สะดวกสบายให้กับทีมฟีเจอร์ เพื่อให้สามารถเผยแพร่ข้อมูลจากบริการของพวกเขาไปยังส่วนอื่นๆ ของบริษัทได้ นอกจากนี้เรายังจะรับผิดชอบในส่วนของโครงสร้างพื้นฐานทั่วไปของไปป์ไลน์ข้อมูล (คิว พื้นที่จัดเก็บข้อมูลที่เชื่อถือได้ คลัสเตอร์สำหรับการดำเนินการแปลงข้อมูล)
ทักษะ Data Engineer จะปรากฏใน Feature Team ได้อย่างไร? ด้วยทีมฟีเจอร์มันซับซ้อนกว่ามาก แน่นอนว่าเราสามารถจ้างวิศวกรข้อมูลหนึ่งคนสำหรับแต่ละทีมได้ แต่มันยากมาก การหาคนที่มีพื้นฐานด้านวิทยาศาสตร์ข้อมูลที่ดีและโน้มน้าวให้เขาทำงานภายในทีมผลิตภัณฑ์เป็นเรื่องยาก
ข้อดีอย่างมากของ Dodo ก็คือเราชอบการฝึกอบรมภายใน ตอนนี้แผนของเราคือ: ทีมวิศวกรรมข้อมูลเริ่มเผยแพร่ข้อมูลจากบริการบางอย่าง ร้องไห้ ฉีดเข้าไปเอง แต่ยังคงกินกระบองเพชรต่อไป เมื่อเรารู้ว่าเรามีขั้นตอนการเผยแพร่แล้ว เราจะเริ่มสื่อสารกับทีมงานฟีเจอร์
เรามีหลายวิธีในการดำเนินการนี้:
- ซึ่งเราจะอธิบายให้คุณทราบว่ากระบวนการที่เราสร้างขึ้นมีลักษณะอย่างไร มีเครื่องมืออะไรบ้าง และวิธีใช้งานอย่างมีประสิทธิภาพสูงสุด
- การพูดที่ DevForum จะช่วยให้เรารวบรวมคำติชมจากนักพัฒนาผลิตภัณฑ์ หลังจากนี้ เราจะสามารถเข้าร่วมทีมผลิตภัณฑ์และช่วยพวกเขาแก้ไขปัญหาในการเผยแพร่ข้อมูล และจัดการฝึกอบรมสำหรับทีมได้
ปริมาณการใช้ข้อมูล
ตอนนี้ฉันได้พูดคุยกันมากมายเกี่ยวกับการเผยแพร่ข้อมูล แต่ก็มีการบริโภคด้วย แล้วปัญหานี้ล่ะ?
เรามีทีม BI ที่น่าทึ่งซึ่งเขียนรายงานที่ซับซ้อนมากให้กับบริษัทจัดการ ภายใน Dodo IS มีรายงานมากมายสำหรับพันธมิตรของเราที่ช่วยพวกเขาจัดการร้านพิซซ่าของตน ในรูปแบบใหม่ของเรา เราถือว่าพวกเขาเป็นผู้บริโภคข้อมูลที่มีโดเมนข้อมูลของตนเอง และเป็นผู้บริโภคที่จะต้องรับผิดชอบโดเมนของตนเอง บางครั้งโดเมนของผู้บริโภคสามารถอธิบายในคลังข้อมูลการวิเคราะห์ได้ในแบบสอบถามเดียว ซึ่งถือว่าดี แต่เราเข้าใจว่าสิ่งนี้จะไม่ได้ผลเสมอไป นั่นคือเหตุผลที่เราต้องการให้แพลตฟอร์มที่เราสร้างขึ้นสำหรับทีมผลิตภัณฑ์เพื่อให้ผู้บริโภคข้อมูลสามารถใช้งานได้ (ท้ายที่สุดแล้ว ในกรณีของรายงานภายใน Dodo IS จะเป็นทีมเดียวกัน)
นี่คือวิธีที่เราเห็นการทำงานกับข้อมูลใน Dodo Pizza Engineering เรายินดีที่จะอ่านความคิดของคุณเกี่ยวกับเรื่องนี้ในความคิดเห็น
ที่มา: will.com
