การประยุกต์ใช้โค้ดต่ำในแพลตฟอร์มการวิเคราะห์

เรียนผู้อ่าน ขอให้เป็นวันที่ดี!

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

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

อย่างไรก็ตาม งานวิเคราะห์ข้อมูลสามารถพัฒนาไปสู่ปัญหาในชั้นเรียน “Rocket Science” ได้ในกรณีใดบ้าง? บางทีในขณะที่เรากำลังพูดถึงข้อมูลขนาดใหญ่จริงๆ
เพื่อให้ Rocket Science ง่ายขึ้น คุณสามารถกินช้างทีละชิ้นได้

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

ลูกค้าเกือบทั้งหมดของเรามาที่หลักการนี้ โดยได้สร้างภูมิทัศน์ขึ้นมาใหม่ตามหลักปฏิบัติด้านวิศวกรรมของทีม DevOps

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

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

ลองหาสาเหตุว่าทำไม

การวิเคราะห์ข้อมูลในสาขาโลจิสติกส์ อุตสาหกรรมโทรคมนาคม การวิจัยสื่อ ภาคการเงิน มักจะเกี่ยวข้องกับคำถามต่อไปนี้:

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

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

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

เรามาเปรียบเทียบกันด้วยภาษาการเขียนโปรแกรมระดับต่ำและระดับสูง การเปลี่ยนจากภาษาระดับต่ำไปสู่ระดับสูงคือการเปลี่ยนจากการเขียน "คำสั่งโดยตรงในภาษาฮาร์ดแวร์" ไปสู่ ​​"คำสั่งในภาษาของผู้คน" นั่นคือการเพิ่มสิ่งที่เป็นนามธรรมลงไปอีกชั้นหนึ่ง ในกรณีนี้การเปลี่ยนไปใช้แพลตฟอร์ม low-code จากภาษาการเขียนโปรแกรมระดับสูงคือการเปลี่ยนจาก "คำสั่งในภาษาของผู้คน" ไปสู่ ​​"คำสั่งในภาษาของธุรกิจ" หากมีนักพัฒนาที่เสียใจกับข้อเท็จจริงนี้ พวกเขาก็อาจจะเสียใจตั้งแต่วินาทีที่ Java Script ถือกำเนิดขึ้น ซึ่งใช้ฟังก์ชันการเรียงลำดับอาร์เรย์ และแน่นอนว่าฟังก์ชันเหล่านี้มีการใช้งานซอฟต์แวร์ภายใต้ประทุนด้วยวิธีอื่นของการเขียนโปรแกรมระดับสูงเดียวกัน

ดังนั้นโค้ดต่ำจึงเป็นเพียงรูปลักษณ์ของนามธรรมอีกระดับหนึ่ง

ประสบการณ์ประยุกต์โดยใช้โค้ดต่ำ

หัวข้อของ low-code นั้นค่อนข้างกว้าง แต่ตอนนี้ฉันอยากจะพูดถึงการประยุกต์ใช้ "แนวคิด low-code" ในทางปฏิบัติโดยใช้ตัวอย่างของหนึ่งในโครงการของเรา

แผนก Big Data Solutions ของ Neoflex เชี่ยวชาญมากขึ้นในภาคการเงินของธุรกิจ การสร้างคลังข้อมูลและทะเลสาบ และการรายงานต่างๆ โดยอัตโนมัติ ในช่องนี้ การใช้โค้ดต่ำได้กลายเป็นมาตรฐานมานานแล้ว ในบรรดาเครื่องมือที่ใช้โค้ดน้อยอื่น ๆ เราสามารถพูดถึงเครื่องมือสำหรับจัดระเบียบกระบวนการ ETL: Informatica Power Center, IBM Datastage, Pentaho Data Integration หรือ Oracle Apex ซึ่งทำหน้าที่เป็นสภาพแวดล้อมสำหรับการพัฒนาอินเทอร์เฟซอย่างรวดเร็วสำหรับการเข้าถึงและแก้ไขข้อมูล อย่างไรก็ตาม การใช้เครื่องมือพัฒนาแบบใช้โค้ดน้อยไม่ได้เกี่ยวข้องกับการสร้างแอปพลิเคชันที่ตรงเป้าหมายสูงบนสแต็กเทคโนโลยีเชิงพาณิชย์ที่มีการพึ่งพาผู้จำหน่ายอย่างชัดเจนเสมอไป

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

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

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

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

งานที่อยู่ตรงหน้าเรานั้นเต็มไปด้วยความทะเยอทะยานอย่างแท้จริง - Neoflex และ Mediascope ต้องสร้างโซลูชันทางอุตสาหกรรมภายในเวลาไม่ถึงหนึ่งปี โดยขึ้นอยู่กับการเปิดตัว MVP ภายในไตรมาสแรกของวันที่เริ่มต้น

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

เครื่องมือ Lowe-code ในแนวคิดนี้ใช้เพื่อเพิ่มประสิทธิภาพงานที่ต้องใช้แรงงานมากที่สุดในการสร้างแพลตฟอร์มการวิเคราะห์ - งานการคำนวณข้อมูล

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

ข้อได้เปรียบที่ชัดเจนของแนวทางนี้คือการเร่งกระบวนการพัฒนา อย่างไรก็ตาม นอกจากความเร็วแล้ว ยังมีข้อดีดังต่อไปนี้:

• การดูเนื้อหาและโครงสร้างของแหล่งที่มา/ผู้รับ
• ติดตามที่มาของออบเจ็กต์กระแสข้อมูลไปยังแต่ละฟิลด์ (เชื้อสาย)
• การดำเนินการแปลงบางส่วนโดยดูผลลัพธ์ระดับกลาง
• ตรวจสอบซอร์สโค้ดและปรับแต่งก่อนดำเนินการ
• การตรวจสอบความถูกต้องของการแปลงอัตโนมัติ
• ดาวน์โหลดข้อมูลอัตโนมัติ 1 ใน 1

อุปสรรคในการเข้าสู่โซลูชันที่ใช้โค้ดน้อยสำหรับการสร้างการแปลงนั้นค่อนข้างต่ำ: นักพัฒนาจำเป็นต้องรู้ SQL และมีประสบการณ์ในการทำงานกับเครื่องมือ ETL เป็นที่น่าสังเกตว่าตัวสร้างการเปลี่ยนแปลงที่ขับเคลื่อนด้วยโค้ดไม่ใช่เครื่องมือ ETL ในความหมายกว้างๆ เครื่องมือที่ใช้โค้ดน้อยอาจไม่มีสภาพแวดล้อมการเรียกใช้โค้ดของตัวเอง นั่นคือ โค้ดที่สร้างขึ้นจะถูกดำเนินการในสภาพแวดล้อมที่มีอยู่ในคลัสเตอร์ก่อนที่จะติดตั้งโซลูชันแบบ low-code เสียอีก และนี่อาจเป็นข้อดีอีกประการหนึ่งของกรรมที่มีโค้ดน้อย เนื่องจากเมื่อเทียบเคียงกับทีมที่ใช้โค้ดน้อย ทีม "คลาสสิก" จึงสามารถทำงานที่ใช้ฟังก์ชันต่างๆ ได้ เช่น ในโค้ด Scala ล้วนๆ การนำการปรับปรุงจากทั้งสองทีมมาสู่การผลิตจะง่ายและราบรื่น

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

สถาปัตยกรรมโซลูชัน

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

แหล่งข้อมูลในกรณีของเรามีความหลากหลายและหลากหลายมาก:

• เครื่องวัดผู้คน (มิเตอร์ทีวี) คืออุปกรณ์ซอฟต์แวร์และฮาร์ดแวร์ที่อ่านพฤติกรรมของผู้ใช้จากผู้ตอบแบบสอบถามเกี่ยวกับโทรทัศน์ ว่าใคร ดูช่องทีวีเมื่อใด และช่องใดในครัวเรือนที่เข้าร่วมการศึกษาวิจัยนี้ ข้อมูลที่ให้มาคือกระแสช่วงเวลาการรับชมการออกอากาศที่เชื่อมโยงกับแพ็คเกจสื่อและผลิตภัณฑ์สื่อ ข้อมูลในขั้นตอนของการโหลดลงใน Data Lake สามารถเสริมด้วยคุณลักษณะทางประชากรศาสตร์ การแบ่งชั้นทางภูมิศาสตร์ เขตเวลา และข้อมูลอื่น ๆ ที่จำเป็นสำหรับการวิเคราะห์การรับชมโทรทัศน์ของผลิตภัณฑ์สื่อเฉพาะ การวัดผลสามารถใช้เพื่อวิเคราะห์หรือวางแผนแคมเปญโฆษณา ประเมินกิจกรรมและความชอบของผู้ชม และรวบรวมเครือข่ายการออกอากาศ
• ข้อมูลอาจมาจากระบบตรวจสอบสำหรับการสตรีมรายการโทรทัศน์และการวัดการรับชมเนื้อหาทรัพยากรวิดีโอบนอินเทอร์เน็ต
• เครื่องมือวัดในสภาพแวดล้อมของเว็บ รวมถึงมาตรวัดทั้งแบบเน้นไซต์และแบบเน้นผู้ใช้เป็นหลัก ผู้ให้บริการข้อมูลสำหรับ Data Lake อาจเป็นโปรแกรมเสริมเบราว์เซอร์แถบการวิจัยและแอปพลิเคชันมือถือที่มี VPN ในตัว
• ข้อมูลอาจมาจากไซต์ที่รวบรวมผลลัพธ์ของการกรอกแบบสอบถามออนไลน์และผลการสัมภาษณ์ทางโทรศัพท์ในแบบสำรวจของบริษัท
• การปรับปรุง Data Lake เพิ่มเติมสามารถเกิดขึ้นได้โดยการดาวน์โหลดข้อมูลจากบันทึกของบริษัทคู่ค้า

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

อย่างไรก็ตาม ในบริบทของโครงการนี้ เราตัดสินใจที่จะไม่ใช้คุณลักษณะนี้ของแพลตฟอร์มแบบ low-code เนื่องจากบริษัท Mediascope ได้เริ่มทำงานโดยอิสระแล้วในการผลิตบริการที่คล้ายกันโดยใช้ชุดค่าผสม Nifi + Kafka

เป็นสิ่งที่ควรค่าแก่การระบุทันทีว่าเครื่องมือเหล่านี้ไม่สามารถใช้แทนกันได้ แต่เป็นการเสริมกัน Nifi และ Kafka สามารถทำงานได้ทั้งในการเชื่อมต่อโดยตรง (Nifi -> Kafka) และการเชื่อมต่อแบบย้อนกลับ (Kafka -> Nifi) สำหรับแพลตฟอร์มการวิจัยสื่อ มีการใช้ชุดเวอร์ชันแรก

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

ขั้นตอนต่อไปในการดำเนินโครงการคือการนำข้อมูลโดยละเอียดมาสู่รูปแบบเลเยอร์ความหมายเดียว หากเอนทิตีมีคุณลักษณะในอดีต การคำนวณจะดำเนินการในบริบทของพาร์ติชันที่ต้องการ หากเอนทิตีไม่มีประวัติ คุณสามารถเลือกคำนวณเนื้อหาทั้งหมดของออบเจ็กต์ใหม่ หรือปฏิเสธที่จะคำนวณออบเจ็กต์นี้ใหม่ทั้งหมด (เนื่องจากไม่มีการเปลี่ยนแปลง) ในขั้นตอนนี้ คีย์จะถูกสร้างขึ้นสำหรับเอนทิตีทั้งหมด คีย์จะถูกจัดเก็บไว้ในไดเร็กทอรี Hbase ที่สอดคล้องกับออบเจ็กต์หลัก ซึ่งมีความสอดคล้องกันระหว่างคีย์ในแพลตฟอร์มการวิเคราะห์และคีย์จากระบบต้นทาง การรวมเอนทิตีอะตอมมิกจะมาพร้อมกับผลลัพธ์ของการคำนวณข้อมูลการวิเคราะห์เบื้องต้น กรอบการคำนวณข้อมูลคือ Spark ฟังก์ชันการทำงานที่อธิบายไว้สำหรับการนำข้อมูลมาสู่ซีแมนทิกส์เดียวยังถูกนำไปใช้ตามการแมปจากเครื่องมือ Datagram ที่มีโค้ดน้อย

สถาปัตยกรรมเป้าหมายจำเป็นต้องมีการเข้าถึงข้อมูล SQL สำหรับผู้ใช้ทางธุรกิจ ไฮฟ์ถูกใช้สำหรับตัวเลือกนี้ ออบเจ็กต์จะถูกลงทะเบียนใน Hive โดยอัตโนมัติเมื่อคุณเปิดใช้งานตัวเลือก “Registr Hive Table” ในเครื่องมือแบบ low-code

การควบคุมการไหลของการคำนวณ

Datagram มีอินเทอร์เฟซสำหรับสร้างการออกแบบโฟลว์เวิร์กโฟลว์ การแมปสามารถเปิดใช้งานได้โดยใช้ตัวกำหนดเวลา Oozie ในอินเทอร์เฟซนักพัฒนาสตรีม คุณสามารถสร้างโครงร่างสำหรับการแปลงข้อมูลแบบขนาน ตามลำดับ หรือขึ้นอยู่กับการดำเนินการได้ มีการรองรับเชลล์สคริปต์และโปรแกรมจาวา นอกจากนี้ยังสามารถใช้เซิร์ฟเวอร์ Apache Livy ได้อีกด้วย Apache Livy ใช้เพื่อเรียกใช้แอปพลิเคชันโดยตรงจากสภาพแวดล้อมการพัฒนา

หากบริษัทมีผู้จัดเตรียมกระบวนการของตนเองอยู่แล้ว ก็สามารถใช้ REST API เพื่อฝังการแมปลงในโฟลว์ที่มีอยู่ได้ ตัวอย่างเช่น เรามีประสบการณ์ค่อนข้างประสบความสำเร็จในการฝังการแมปใน Scala ลงในตัวเรียบเรียงที่เขียนด้วย PLSQL และ Kotlin REST API ของเครื่องมือที่ใช้โค้ดน้อยประกอบด้วยการดำเนินการต่างๆ เช่น การสร้างปีที่ปฏิบัติการได้ขึ้นอยู่กับการออกแบบการแมป การเรียกการแมป การเรียกลำดับของการแมป และแน่นอนว่าการส่งพารามิเตอร์ไปยัง URL เพื่อรันการแมป

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

Airflow ก็ดีเช่นกันเพราะใช้ Python อันเป็นที่รักในการอธิบายกระบวนการคำนวณ และโดยทั่วไปแล้ว มีแพลตฟอร์มการจัดการเวิร์กโฟลว์แบบโอเพ่นซอร์สไม่มากนัก การเปิดตัวและการตรวจสอบการดำเนินการของกระบวนการ (รวมถึงแผนภูมิแกนต์) จะเพิ่มคะแนนให้กับกรรมของ Airflow เท่านั้น

รูปแบบไฟล์การกำหนดค่าสำหรับการเปิดใช้งานการแมปโซลูชันแบบ low-code ได้กลายเป็นการส่งแบบประกายไฟ สิ่งนี้เกิดขึ้นด้วยเหตุผลสองประการ ขั้นแรก spark-submit ช่วยให้คุณสามารถเรียกใช้ไฟล์ jar จากคอนโซลได้โดยตรง ประการที่สอง อาจมีข้อมูลที่จำเป็นทั้งหมดเพื่อกำหนดค่าเวิร์กโฟลว์ (ซึ่งทำให้เขียนสคริปต์ที่สร้าง Dag ได้ง่ายขึ้น)
องค์ประกอบที่พบบ่อยที่สุดของเวิร์กโฟลว์ Airflow ในกรณีของเราคือ SparkSubmitOperator

SparkSubmitOperator ช่วยให้คุณสามารถรัน jars - การแม็ป Datagram แบบแพ็กเกจพร้อมพารามิเตอร์อินพุตที่สร้างไว้ล่วงหน้าสำหรับพวกมัน

เป็นที่น่าสังเกตว่างาน Airflow แต่ละงานทำงานแยกกันและไม่รู้อะไรเกี่ยวกับงานอื่นเลย ดังนั้น การโต้ตอบระหว่างงานจึงดำเนินการโดยใช้ตัวดำเนินการควบคุม เช่น DummyOperator หรือ BranchPythonOperator

เมื่อนำมารวมกัน การใช้โซลูชัน Low-code ของ Datagram ร่วมกับการทำให้ไฟล์การกำหนดค่าเป็นสากล (การสร้าง Dag) นำไปสู่การเร่งความเร็วและลดความซับซ้อนของกระบวนการพัฒนาโฟลว์การโหลดข้อมูลอย่างมีนัยสำคัญ

การคำนวณตู้โชว์

บางทีขั้นตอนที่ต้องใช้สติปัญญามากที่สุดในการผลิตข้อมูลเชิงวิเคราะห์ก็คือขั้นตอนของการสร้างการนำเสนอผลงาน ในบริบทของกระแสการคำนวณข้อมูลของบริษัทวิจัยแห่งใดแห่งหนึ่ง ในขั้นตอนนี้ ข้อมูลจะลดลงเป็นการออกอากาศอ้างอิง โดยคำนึงถึงการแก้ไขโซนเวลาและเชื่อมโยงกับตารางการออกอากาศ นอกจากนี้ยังสามารถปรับเปลี่ยนเครือข่ายการออกอากาศท้องถิ่นได้ (ข่าวท้องถิ่นและการโฆษณา) เหนือสิ่งอื่นใด ขั้นตอนนี้จะแบ่งช่วงเวลาการดูผลิตภัณฑ์สื่ออย่างต่อเนื่องตามการวิเคราะห์ช่วงเวลาการดู ทันทีค่าการดูจะถูก "ถ่วงน้ำหนัก" ตามข้อมูลเกี่ยวกับความสำคัญ (การคำนวณปัจจัยแก้ไข)

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

มีการตัดสินใจที่จะแยกอัลกอริธึมการตรวจสอบออกเป็นขั้นตอนย่อยต่อไปนี้:

• การสร้างการถดถอยของการพึ่งพาการรับชมเครือข่ายทีวีในภูมิภาคด้วยการรับชมเครือข่ายทั้งหมดในภูมิภาคเป็นเวลา 60 วัน
• การคำนวณค่าคงเหลือของนักเรียน (ส่วนเบี่ยงเบนของค่าจริงจากที่คาดการณ์โดยแบบจำลองการถดถอย) สำหรับคะแนนการถดถอยทั้งหมดและสำหรับวันที่คำนวณ
• การเลือกคู่ภูมิภาค-เครือข่ายที่ผิดปกติ โดยที่ยอดคงเหลือของวันชำระหนี้ที่เป็นนักเรียนเกินกว่าปกติ (ระบุโดยการตั้งค่าการดำเนินการ)
• การคำนวณค่าคงเหลือ Studented ที่แก้ไขแล้วสำหรับคู่เครือข่ายทีวีภูมิภาคที่ผิดปกติสำหรับผู้ตอบแบบสอบถามแต่ละรายที่ดูเครือข่ายในภูมิภาค โดยพิจารณาถึงการมีส่วนร่วมของผู้ตอบแบบสอบถามรายนี้ (จำนวนการเปลี่ยนแปลงในค่าคงเหลือ Studented) เมื่อไม่รวมการดูของผู้ตอบแบบสอบถามรายนี้จากกลุ่มตัวอย่าง .
• ค้นหาผู้สมัครที่มีการยกเว้นทำให้ยอดคงเหลือของวันจ่ายเงินเดือนของนักเรียนกลับมาเป็นปกติ

ตัวอย่างข้างต้นยืนยันสมมติฐานที่ว่าวิศวกรข้อมูลมีความคิดในใจมากเกินไป... และถ้านี่คือ “วิศวกร” จริงๆ ไม่ใช่ “ผู้เขียนโค้ด” ก็แสดงว่ากลัวว่าวิชาชีพจะเสื่อมลงเมื่อใช้เครื่องมือที่ใช้โค้ดน้อย สุดท้ายก็ต้องล่าถอย

low-code สามารถทำอะไรได้อีก?

ขอบเขตของการใช้เครื่องมือ low-code สำหรับการประมวลผลข้อมูลแบบแบตช์และสตรีมโดยไม่จำเป็นต้องเขียนโค้ดด้วยตนเองใน Scala ไม่ได้จบเพียงแค่นั้น

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

เหนือสิ่งอื่นใด การใช้โค้ดต่ำและโดยเฉพาะอย่างยิ่งดาตาแกรม เป็นไปได้ที่จะแก้ปัญหาในการติดตามต้นกำเนิดของออบเจ็กต์สตรีมข้อมูลที่มีอะตอมมิกซิตีลงไปจนถึงแต่ละฟิลด์ (สายเลือด) ในการดำเนินการนี้ เครื่องมือที่ใช้โค้ดน้อยจะใช้อินเทอร์เฟซกับ Apache Atlas และ Cloudera Navigator โดยพื้นฐานแล้ว นักพัฒนาจำเป็นต้องลงทะเบียนชุดของออบเจ็กต์ในพจนานุกรม Atlas และอ้างอิงออบเจ็กต์ที่ลงทะเบียนไว้เมื่อสร้างการแมป กลไกในการติดตามที่มาของข้อมูลหรือการวิเคราะห์การพึ่งพาวัตถุช่วยประหยัดเวลาได้มากเมื่อจำเป็นต้องปรับปรุงอัลกอริธึมการคำนวณ ตัวอย่างเช่น เมื่อจัดทำงบการเงิน คุณลักษณะนี้ช่วยให้คุณรอดพ้นจากการเปลี่ยนแปลงทางกฎหมายได้อย่างสะดวกสบายยิ่งขึ้น ท้ายที่สุดแล้ว ยิ่งเราเข้าใจการพึ่งพาระหว่างแบบฟอร์มในบริบทของออบเจ็กต์ของเลเยอร์ที่มีรายละเอียดมากเท่าไร เราก็จะพบข้อบกพร่อง "อย่างกะทันหัน" น้อยลงและลดจำนวนการแก้ไข

คุณภาพของข้อมูลและโค้ดต่ำ

งานอื่นที่ดำเนินการโดยเครื่องมือ low-code ในโครงการ Mediascope คืองานคลาสคุณภาพข้อมูล คุณลักษณะพิเศษของการดำเนินการตามขั้นตอนการตรวจสอบข้อมูลสำหรับโครงการบริษัทวิจัยคือการไม่มีผลกระทบต่อประสิทธิภาพและความเร็วของขั้นตอนการคำนวณข้อมูลหลัก เพื่อให้สามารถประสานขั้นตอนการตรวจสอบข้อมูลที่เป็นอิสระได้ จึงมีการใช้ Apache Airflow ที่คุ้นเคยอยู่แล้ว เมื่อการผลิตข้อมูลแต่ละขั้นตอนพร้อมแล้ว ส่วนที่แยกจากไปป์ไลน์ DQ ก็เริ่มดำเนินการพร้อมกัน

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

เมื่อจับคู่เครื่องมือ low-code กับ Enterprise Architect การตรวจสอบต่อไปนี้จะถูกสร้างขึ้นโดยอัตโนมัติ:

• ตรวจสอบการมีอยู่ของค่า "null" ในช่องที่มีตัวแก้ไข "ไม่ใช่ null"
• ตรวจสอบการมีอยู่ของคีย์หลักที่ซ้ำกัน
• ตรวจสอบคีย์ต่างประเทศของเอนทิตี
• การตรวจสอบความเป็นเอกลักษณ์ของสตริงตามชุดของฟิลด์

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

แน่นอนว่า การสร้างการตรวจสอบอัตโนมัติจะต้องค่อยๆ บรรลุผล ภายในกรอบของโครงการที่อธิบายไว้ มีขั้นตอนต่อไปนี้นำหน้า:

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

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

• การตรวจสอบข้อมูลเมตาทั้งหมดจะถูกสร้างขึ้นโดยอัตโนมัติเมื่อมีการแก้ไขโมเดลใน EA
• การตรวจสอบความพร้อมใช้งานของข้อมูล (การพิจารณาถึงการมีอยู่ของข้อมูลใดๆ ในช่วงเวลาหนึ่ง) สามารถสร้างขึ้นได้จากไดเร็กทอรีที่จัดเก็บเวลาที่คาดหวังของการปรากฏของข้อมูลชิ้นถัดไปในบริบทของออบเจ็กต์
• การตรวจสอบความถูกต้องของข้อมูลธุรกิจสร้างขึ้นโดยนักวิเคราะห์ในโน้ตบุ๊ก Zeppelin จากนั้นจะถูกส่งไปยังตารางการตั้งค่าโมดูล DQ ในสภาพแวดล้อมการใช้งานจริงโดยตรง

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

โดยพื้นฐานแล้ว บริการ DQ กำลังทำงานอย่างถาวรในสภาพแวดล้อมการใช้งานจริง และพร้อมที่จะเริ่มทำงานทันทีที่ข้อมูลชิ้นต่อไปปรากฏขึ้น

แทนการสรุป

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

แน่นอนว่าโค้ดต่ำไม่ใช่ยาครอบจักรวาล และเวทมนตร์จะไม่เกิดขึ้นเอง:

• อุตสาหกรรม low-code กำลังอยู่ในช่วง "แข็งแกร่งขึ้น" และยังไม่มีมาตรฐานอุตสาหกรรมที่สม่ำเสมอ
• โซลูชันแบบ low-code จำนวนมากไม่ได้ฟรี และการซื้อโซลูชันเหล่านี้ควรเป็นขั้นตอนที่ใส่ใจ ซึ่งควรทำด้วยความมั่นใจอย่างเต็มที่ในผลประโยชน์ทางการเงินของการใช้งาน
• โซลูชันแบบ low-code จำนวนมากอาจทำงานได้ไม่ดีกับ GIT/SVN เสมอไป หรือไม่สะดวกที่จะใช้หากรหัสที่สร้างขึ้นถูกซ่อนอยู่
• เมื่อขยายสถาปัตยกรรม อาจจำเป็นต้องปรับแต่งโซลูชันแบบ low-code ซึ่งในทางกลับกัน จะกระตุ้นให้เกิดผลกระทบของ “ความผูกพันและการพึ่งพา” ต่อซัพพลายเออร์ของโซลูชันแบบ low-code
• ระดับการรักษาความปลอดภัยที่เพียงพอเป็นไปได้ แต่ต้องใช้แรงงานมากและยากต่อการนำไปใช้ในเอ็นจิ้นระบบที่ใช้โค้ดน้อย ควรเลือกแพลตฟอร์มแบบ low-code ไม่เพียงแต่บนหลักการแสวงหาผลประโยชน์จากการใช้งานเท่านั้น เมื่อเลือก ควรถามคำถามเกี่ยวกับความพร้อมใช้งานของฟังก์ชันสำหรับการควบคุมการเข้าถึง และการมอบหมาย/การยกระดับข้อมูลการระบุตัวตนให้อยู่ในระดับภูมิทัศน์ด้านไอทีทั้งหมดขององค์กร

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

หากนักพัฒนารายหนึ่งบนแพลตฟอร์มที่ใช้โค้ดน้อยทำงานได้เร็วกว่านักพัฒนาสองคนที่ไม่มีโค้ดน้อย สิ่งนี้จะทำให้บริษัทได้เปรียบกว่าทุกประการ เกณฑ์สำหรับการเข้าสู่โซลูชันที่ใช้โค้ดน้อยนั้นต่ำกว่าเทคโนโลยี "แบบดั้งเดิม" และส่งผลเชิงบวกต่อปัญหาการขาดแคลนบุคลากร เมื่อใช้เครื่องมือแบบ low-code เป็นไปได้ที่จะเร่งปฏิสัมพันธ์ระหว่างทีมงานและตัดสินใจได้เร็วขึ้นเกี่ยวกับความถูกต้องของเส้นทางการวิจัยวิทยาศาสตร์ข้อมูลที่เลือก แพลตฟอร์มระดับต่ำสามารถขับเคลื่อนการเปลี่ยนแปลงทางดิจิทัลขององค์กรได้ เนื่องจากผู้เชี่ยวชาญที่ไม่ใช่ด้านเทคนิคสามารถเข้าใจโซลูชันที่ผลิตได้ (โดยเฉพาะผู้ใช้ทางธุรกิจ)

หากคุณมีกำหนดเวลาที่จำกัด ตรรกะทางธุรกิจที่หนักหน่วง ขาดความเชี่ยวชาญทางเทคโนโลยี และคุณต้องการเร่งเวลาออกสู่ตลาด Low-code ก็เป็นวิธีหนึ่งที่สามารถตอบสนองความต้องการของคุณได้

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

ที่มา: will.com