ในไม่กี่ปีที่ผ่านมา Data Lakes ได้เคลื่อนย้ายจากพื้นที่เทคโนโลยีที่ไม่ค่อยได้รับความสนใจ สู่ท้องที่น่าความสนใจระดับชั้นนำของวิทยาการข้อมูล ทำไมถึงเกิดขึ้น และทำไมจึงสำคัญ? คำตอบสั้นๆ … เพราะมีคุณค่าอยู่ที่นั่น
ข้อมูลมีคุณค่า
เพิ่มขึ้นเรื่อยๆ ที่ชัดเจนว่าข้อมูลของบริษัทมีศักยภาพคุณค่าอย่างมาก สำหรับยักษ์ใหญ่อินเทอร์เน็ตอย่าง Google, Facebook และอื่นๆ คุณค่าของพวกเขามาจากข้อมูลในส่วนใหญ่ แต่คุณไม่จำเป็นต้องเป็นยักษ์ใหญ่อินเทอร์เน็ตถึงจะได้คุณค่าจากข้อมูลของคุณ ข้อมูลถูกใช้โดยบริษัทอุตสาหกรรมเพื่อทำนายความล้มเหลวของเครื่องจักร โดยสถาบันการเงินเพื่อจัดการความเสี่ยงที่ดีขึ้น โดยผู้ค้าปลีกรายออนไลน์เพื่อเพิ่มการเก็บรักษาลูกค้า และโดยองค์กรอื่นๆ อีกมากมายเพื่อค้นพบข้อมูลเชิงลึกใหม่ๆ ดูเหมือนจะเป็นสูตรที่ง่ายดาย: ให้นำข้อมูลไปยังเครื่องมือวิเคราะห์ธุรกิจหรือระบบ Machine Learning (ML) และได้ข้อมูลเชิงลึก ในความเป็นจริง ไม่ได้ง่ายขนาดนั้น เราต้องปฏิบัติตามข้อกำหนดเบื้องต้นที่สำคัญหนึ่งอย่างก่อนที่จะแก้ปัญหาการวิเคราะห์ได้ เราต้องมีข้อมูลที่แท้จริงซึ่งมีข้อมูลเชิงลึกอยู่
นี่ไม่ใช่แค่โซลูชัน Data Warehouse อีกตัวหนึ่งไหม?
คุณอาจคิดว่า "นี่ไม่ใช่ปัญหาที่ data warehouses แก้ไขไหม?" ไม่จริงๆ Data warehouses สร้างขึ้นเพื่อแก้ปัญหาชุดที่กำหนดไว้ของธุรกิจ การนำเข้าข้อมูล Data warehouse ใช้ workflow extract, transform, load (ETL) ข้อมูลถูกดึงจากระบบต้นทาง แปลงเป็นโครงสร้างของ data warehouse จากนั้นโหลดเข้า data warehouse จนถึงขั้นนี้ ข้อมูลได้ถูกจัดโครงสร้าง กรอง และจัดการอื่นๆ เพื่อตัดข้อมูลที่ไม่เกี่ยวข้องกับชุดปัญหาธุรกิจที่กำหนดไว้ ในกระบวนการ ETL เราได้ ไม่ว่าจะโดยนัยหรือโดยตรง เก็บค่าข้อมูลบางส่วนและทิ้งบางส่วน เพิ่มข้อมูล สร้างความสัมพันธ์ระหว่างรายการข้อมูล และไม่สนใจบางอย่าง แล้วจะเกิดอะไรขึ้นถ้ามีปัญหาธุรกิจใหม่ที่ถูกค้นพบซึ่งต้องการข้อมูลที่ถูกทิ้ง? สภาพแวดล้อมทางธุรกิจเปลี่ยนแปลงตลอดเวลา และปัญหาในอนาคตไม่สามารถทำนายได้ ไม่ว่ากระบวนการ ETL จะถูกต้องเพียงใดสำหรับชุดปัญหาธุรกิจปัจจุบัน จำนวนมากของคุณค่าทiềmนัยในอนาคตกำลังสูญหายจากการตัดสินใจเหล่านี้เมื่อป้อนข้อมูลเข้า data warehouse
เข้าสู่ Data Lakes
เพื่อรักษาคุณค่าทiềmนัยให้มากที่สุด เราไม่สามารถทิ้งข้อมูลต้นฉบับได้ ทำไมเราไม่เก็บข้อมูลทั้งหมดในรูปแบบ raw และตัดสินใจภายหลังว่าจะใช้อย่างไร? เราสามารถปล่อยให้ข้อมูลไหลเหมือนแม่น้ำเข้าสู่ที่เก็บรวมกลาง สร้าง "ทะเลสาบ" ของ "ข้อมูล" :) อีกนัยหนึ่ง คือ extract และเก็บข้อมูล แล้ว transform และ load ตามที่ต้องการ (บ่อยครั้งเรียกว่า Extract, Load, and Transform, ELT – สลับ 'T' และ 'L' ใน ETL)
ในอดีต ต้นทุนการจัดเก็บและการสกัดโครงสร้างที่มีความหมายในอนาคต หนักกว่าคุณค่าทiềmนัยของข้อมูลที่อาจมีอยู่ อย่างไรก็ตาม ต้นทุนการจัดเก็บและต้นทุนการกลั่นโครงสร้างที่มีประโยชน์ออกจากความวุ่นวาย ลดลง ทำให้มีคุ้มค่ามากขึ้นสำหรับบริษัทมากขึ้นที่จะทำเช่นนั้น
การรวบรวมข้อมูล Raw ใดๆ ก็เป็น Data Lake ไหม?
โอเค ง่ายพอดี แค่ทิ้งข้อมูล raw ทั้งหมดลงในสถานที่เดียว และเราเสร็จแล้วไหม? ไกลมาก! การนำเข้าข้อมูลต้องทำอย่างถูกต้องเพื่อปกป้องลูกค้า บริษัท และข้อมูล ในขณะที่ทำให้ข้อมูลพร้อมใช้งานสำหรับนักวิทยาศาสตร์ข้อมูลและนักวิเคราะห์ในอนาคต เพื่อทำเช่นนี้ เราต้องพิจารณาปัจจัยสำคัญมากมาย
-
นักวิทยาศาสตร์ข้อมูลและนักวิเคราะห์ในอนาคตจะค้นหาสิ่งที่ต้องการอย่างไร? ข้อมูล raw ต้องถูกทำดัชนี (indexed)
-
ข้อมูลจะถูกดึงออกมาได้อย่างมีประสิทธิภาพอย่างไร? ข้อมูลต้องจัดเก็บในรูปแบบไฟล์ที่มีประสิทธิภาพ เช่น รูปแบบคอลัมน์ (columnar format)
-
ข้อมูลส่วนบุคคล (PII), ข้อมูลสุขภาพที่คุ้มครอง (PHI), ข้อมูลบัตร (CD) และข้อมูลละเอียดอ่อนอื่นๆ จะจัดการอย่างไร? ต้องการการปิดบังข้อมูล (Data obfuscation)
-
จะจัดการความเป็นส่วนตัวของข้อมูล (เช่น GDPR), อนุภาครัฐของข้อมูล และควบคุมการเข้าถึงอย่างไร เพื่อไม่ได้กลายเป็นข่าวหัวข้อจากการรั่วไหลข้อมูลอีกครั้ง? Identity and access management ต้องถูกนำไปใช้เพื่อให้สิทธิ์และการควบคุมการเข้าถึงที่เหมาะสม
การลบข้อมูลซ้ำหรือการจับคู่เรคคอร์ดที่ไม่มีการแบ่งปันคีย์ระบุตัวตนบ้าง จะจัดการอย่างไร? 123 Main St, Some Town, USA เป็นสถานที่เดียวกับ 123 Main Street, Some Town, USA ไหม? Robert Smith และ Bob Smith เป็นคนเดียวกันไหม? ตามที่คุณนึกไว้ นี่เป็นสถานการณ์ง่ายๆ สถานการณ์ซับซ้อนกว่านี้มีอยู่มากในชุดข้อมูลจริง
เมื่อข้อมูลอยู่ใน data lake และมีการทำดัชนีและการควบคุมที่เหมาะสมแล้ว ข้อมูลต้องถูกแปลงเป็นรูปแบบที่มีโครงสร้างก่อนที่จะใช้งานได้ โดยทั่วไป หมายถึงการใช้ schema just-in-time ขณะอ่าน รูปแบบต้นทาง raw ต่างๆ ถูกฉาย (projected) เข้าโครงสร้างที่รู้จัก เพื่อให้สามารถนำไปใช้โดย ML, warehousing หรือระบบ Business Intelligence (BI) ได้ (ฉันชอบเรียกกระบวนการนี้ว่า EtS-TL, Extract transform Store – Transform and Load เพราะมีการแปลงข้อมูลแบบไม่สูญเสียข้อมูลบางส่วนเมื่อข้อมูลเข้าสู่ lake แต่การอภิปรายเรื่อง nomenclature เป็นหัวข้อสำหรับเวลาอื่น)
การใช้ข้อมูล
ข้อมูลตอนนี้อยู่ใน lake แต่อยู่ในรูปแบบที่ใช้งานไม่ได้ในปัจจุบัน การตัดสินใจแปลงข้อมูลที่เลื่อนออกไป ต้องตัดสินใจตอนนี้ เมื่อ schema ถูกตัดสินใจและข้อมูลถูกดึงออกมา แล้วต้องทำความสะอาดในลักษณะเฉพาะ schema ข้อมูลที่ไม่ถูกต้องสำหรับ schema/การวิเคราะห์หนึ่ง อาจถูกต้องอย่างสมบูรณ์สำหรับอีกอัน ตัวอย่างเช่น พิจารณาชุดข้อมูลกรรมสิทธิ์ที่ดิน ที่มีชื่อเจ้าของ ที่อยู่ทรัพย์สิน ค่าทรัพย์สิน การชำระค้างช้า การใช้ที่ดิน (เช่น ที่อยู่อาศัย อาคารสำนักงาน หรืออุตสาหกรรม) และหมายเลขบัญชีภาษีทรัพย์สิน การตรวจสอบว่ามีความสัมพันธ์ระหว่างการใช้ที่ดินและการชำระค้างช้าหรือไม่ ไม่ต้องการชื่อเจ้าของ ขณะเดียวกัน การค้นหาความสัมพันธ์ระหว่างค่าทรัพย์สินและการใช้ที่ดิน ไม่ต้องการข้อมูลการค้างช้า หากรายการข้อมูลหายไปจากแถวใน slice ข้อมูลหนึ่ง มันไม่ทำให้แถวเดียวกันใน slice ข้อมูลอื่นไม่ถูกต้อง Data Lakes ให้คุณรักษาตัวเลือกการวิเคราะห์ข้อมูลของคุณเปิดอยู่ แต่ก็มาพร้อมกับความซับซ้อนและต้นทุนของตัวเอง
เมื่อทุกขั้นตอนเสร็จสิ้น เราอยู่ที่จุดที่เครื่องมือวิเคราะห์ข้อมูล ระบบ BI หรือโมเดล ML ของเราสามารถเริ่มทำงานได้ อย่างไรก็ตาม ด้วยการใช้ประโยชน์จาก data lake เราไม่ได้ทำลายคุณค่าทiềmนัยในอนาคตที่พบในข้อมูลโดยไม่ได้ตั้งใจ คำถามทางธุรกิจในอนาคตสามารถสำรวจได้โดยไม่ต้องรู้อนาคต
สรุป
ในขณะที่ Data Warehouses ถูกกรอง เตรียมพร้อม และใช้งานได้ทันที Data lakes เป็นอ่างเก็บน้ำ ไม่ได้ตั้งใจให้บริโภคในรูปแบบ raw แทนที่จะเป็นเช่นนั้น ข้อมูลในนั้นต้องเตรียมก่อนที่จะบริโภคได้ เหมือนกับอ่างเก็บน้ำใดๆ พวกเขาต้องได้รับการจัดการอย่างถูกต้องเพื่อให้พร้อมใช้งานสำหรับการบริโภคในอนาคต สิ่งนี้ทำได้ผ่านการจัดการการไหลเข้า (รูปแบบไฟล์จัดเก็บและการปิดบังข้อมูล) การเข้าใจเนื้อหา (การทำดัชนีและการลบซ้ำ) การรักษาความปลอดภัยจากการใช้งานผิด (Identity and Access Management) และสิ่งอำนวยความสะดวกการบริสุทธิ์ (การดึงข้อมูล การประยุกต์ใช้ schema และการทำความสะอาดข้อมูล)
เพียงปลายของ айซ์เบิร์ก
โชคดีที่ในยุคคลาวด์ เราไม่ต้องสร้างเครื่องมือและเทคโนโลยีของตัวเองเพื่อนำ data lake ไปใช้งาน ตัวอย่างเช่น AWS Lake Formation จัดการปัญหาเครื่องมือและเทคโนโลยีที่เกี่ยวข้องกับ data lake โดยตรง อย่างไรก็ตาม มีคำถามที่ยากมากเหลืออยู่ คุณรู้ไหมว่าจะใช้เครื่องมือเหล่านี้อย่างถูกต้องอย่างไร? คุณมีความเชี่ยวชาญในการตั้งค่าการเชื่อมต่อเครือข่ายที่เหมาะสมเพื่อให้สามารถนำเข้าข้อมูลของคุณได้ไหม? VPN เพียงอย่างเดียวพอหรือต้องการ dedicated circuit (Direct Connect)? คุณกำลังนำเหมืองทองของข้อมูลบริษัทขึ้นคลาวด์ คุณมั่นใจไหมว่าคุณได้รักษาความปลอดภัยอย่างถูกต้องเพื่อป้องกันการเข้าถึงที่ไม่ได้รับอนุญาต? คุณเข้าถึงข้อมูลอย่างคุ้มค่าทางต้นทุนไหม? จำไว้ การ transfer ออกมาไม่ฟรี
ที่ Rackspace เรามี Cloud Architects และความเชี่ยวชาญที่จะช่วยให้คุณได้ data lake ที่ทำงานได้อย่างรวดเร็ว ปลอดภัย และมีประสิทธิภาพ โทรหาเราหรือเยี่ยมชมเราที่ Rackspace Managed AWS เพื่อข้อมูลเพิ่มเติม
ใช้แท็บ Feedback เพื่อแสดงความคิดเห็นหรือถามคำถาม
