ปฏิรูปแพลตฟอร์มข้อมูลในคลาวด์

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

รากฐานของแพลตฟอร์มข้อมูลบนคลาวด์

มี 3 เลเยอร์สำคัญ ได้แก่ การนำเข้าข้อมูล (Ingestion), การประมวลผล (Processing) และการจัดเก็บข้อมูล (Storage) ซึ่งเป็นแกนหลักของแพลตฟอร์มข้อมูล

1.การนำเข้าข้อมูล (Ingestion)

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

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

ในทางกลับกัน ไปป์ไลน์การส่งผ่านข้อมูลแบบสตรีมยังสามารถป้อนไปป์ไลน์การประมวลผลแบบกลุ่ม ตัวอย่างเช่น คุณสามารถมีหัวข้อ Kafka ที่ข้อมูลมาถึงแบบเรียลไทม์ แต่งานชุด Spark จะดึงและประมวลผลข้อมูลที่มาใหม่ทุก ๆ 3 ชั่วโมงเท่านั้น

2.การประมวลผล (Processing)

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

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

3.การจัดเก็บข้อมูล (Storage)

เลเยอร์ Storage เก็บข้อมูลอย่างต่อเนื่อง จะต้องสามารถจัดเก็บข้อมูลในทุกรูปแบบที่มีอยู่ในแหล่งที่มา ซึ่งหมายความว่าสามารถจัดเก็บข้อมูลที่มีโครงสร้างได้ (เช่น ข้อมูลจากฐานข้อมูลเชิงสัมพันธ์), ข้อมูลกึ่งโครงสร้าง (เช่น เอกสาร JSON ในฐานข้อมูล NoSQL เชิงเอกสาร) และข้อมูลที่ไม่มีโครงสร้าง (เช่น รูปภาพในรูปแบบไฟล์ที่จัดเก็บไว้ในที่จัดเก็บอ็อบเจ็กต์)

ข้อมูลสามารถจัดเก็บเป็นขั้นตอนกลางในไปป์ไลน์การประมวลผลที่นี่ เพื่อเรียกค้นโดยแอปพลิเคชันอื่นจากภายนอกแพลตฟอร์มข้อมูลบนคลาวด์หรือเพื่อวัตถุประสงค์ในการเก็บถาวร เลเยอร์เพิ่มเติมที่เรียกว่า Unified Data Governance จะครอบคลุมแพลตฟอร์มข้อมูลบนคลาวด์ทั้งหมด มีความสามารถ เช่น Identity&Access Management (IAM) และการควบคุมความปลอดภัยเพื่อให้แน่ใจว่าเฉพาะผู้ที่ได้รับอนุญาตให้เข้าถึงแพลตฟอร์มข้อมูลได้เลย

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

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

การใช้แพลตฟอร์มข้อมูลบนคลาวด์

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

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

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

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

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

สิ่งนี้เกิดขึ้นผ่านการเปิดเผย API ซึ่งระบบเหล่านี้สามารถเชื่อมต่อหรือโหลดข้อมูลลงในที่เก็บข้อมูลภายในระบบเหล่านี้ผ่านส่วนประกอบการประมวลผลข้อมูล เช่น Spark หรือเครื่องมือการรวมอื่น ๆ ในกรณีนี้ การจัดเก็บข้อมูลอาจเป็นฐานข้อมูลเชิงสัมพันธ์, ฐานข้อมูล NoSQL หรือคิวข้อความแบบกระจาย เช่น Kafka การรวมแอปพลิเคชันยังมีบทบาทสำคัญในการวิเคราะห์แบบเรียลไทม์ ในกรณีส่วนใหญ่ คนในฝั่งธุรกิจไม่ได้ใช้แดชบอร์ดที่เปลี่ยนแปลงตามเวลาจริง ผลลัพธ์จากไปป์ไลน์การวิเคราะห์แบบเรียลไทม์จะต้องถูกป้อนกลับเข้าสู่ระบบธุรกิจแบบเรียลไทม์ ลองนึกภาพผู้ค้าปลีกที่ตรวจพบว่าขณะนี้คู่แข่งกำลังใช้แคมเปญการกำหนดราคาสำหรับหมวดหมู่ผลิตภัณฑ์หรือส่วนย่อยที่เฉพาะเจาะจง แทนที่จะตอบสนองต่อสิ่งนี้ด้วยตนเอง ซึ่งเป็นแนวทางที่ต้องใช้เวลาอันมีค่า คุณสามารถเรียกใช้แคมเปญการกำหนดราคาของคุณเองแบบเรียลไทม์ได้โดยอัตโนมัติ ดังนั้นทำให้แน่ใจว่าคู่แข่งของคุณจะไม่ได้รับรายได้ทั้งหมด

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

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

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

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

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

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

การบริหารจัดการ (Managed Services)

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

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

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

Resource : https://vladimir-elvov.medium.com