Big Data Lakes จำเป็นต้องมีความชาญฉลาดมากขึ้น

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

องค์กรต่างๆ ได้ลงทุนมหาศาลในการจัดหาชุดซอฟต์แวร์ เปิดใช้โปรแกรมการฝึกอบรม ตลอดจนการตั้งค่าทรัพยากรศูนย์ข้อมูลสำหรับ Big Data Lake

สถาปัตยกรรม Big Data Lake ได้รับการสร้างขึ้นจากผลิตภัณฑ์โอเพ่นซอร์ส เช่น Hadoop และ Spark เป็นต้น

อย่างไรก็ตาม การลงทุนเพื่อสร้าง Big Data Lake ไม่ได้ให้ผลตอบแทนที่สมน้ำสมเนื้อในแง่ของผลประโยชน์ทางธุรกิจ

ผลตอบแทนจากเงินทุนที่จับต้องได้ในแง่ของการประหยัด OPEX จะไม่ปรากฏให้เห็นโดยตรงในงบดุล

การวิเคราะห์และการรายงานยังคงเป็นกรณีการใช้งานหลักที่ใช้กันอย่างแพร่หลายทั่วทั้งอุตสาหกรรม

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

ทะเลสาบข้อมูลและหลุมดำ

เราสามารถวาดความคล้ายคลึงระหว่าง Data Lake สมัยใหม่กับปรากฏการณ์จักรวาลของหลุมดำที่อธิบายไว้ด้านล่าง

ล่าสุดภาพนี้เผยแพร่โดย NASA ถ่ายโดย Event Horizon Telescope (EHT)

เพื่อให้เข้าใจวิธีการทำงานของหลุมดำ เราจะตรวจสอบคุณลักษณะของหลุมดำอย่างรวดเร็ว -

• มันมีแรงโน้มถ่วงมหาศาลจนไม่อาจต้านทานได้
• แม้แต่แสงก็ไม่สามารถหนีจากแรงโน้มถ่วงของมันได้ ดังนั้นหลุมดำจึงไม่สามารถมองเห็นได้ในสเปกตรัมที่มองเห็นได้
• สิ่งใดเข้าไปในหลุมดำ ย่อมไม่ออกมา มันสูญสิ้นไปตลอดกาล
• มันมีความจุไม่จำกัด สสารยังคงถูกดูดเข้าไป

ฟังดูคุ้นเคยเมื่อเราทำการเปรียบเทียบกับ Big Data Lake

• ไม่อาจต้านทานได้: สำหรับองค์กรต่างๆ การมี Big Data Lake ในปัจจุบันกลายเป็นสิ่งจำเป็น ไม่มีใครสามารถต้านทานได้ ไม่เช่นนั้นจะถูกตราหน้าว่า "ล้าสมัย"
• การมองเห็นข้อมูล:เมื่อมีการตั้งค่า Data Lake และเราเริ่มสตรีมข้อมูลลงไป การได้รับการมองเห็นและการวิเคราะห์ต้องใช้ความพยายามอย่างมาก ตั้งแต่การเขียนงาน Spark จนถึงการจัดเก็บข้อมูลที่ได้รับการปรับปรุงใน HBase ไปจนถึงการสร้างการแสดงภาพ . ยิ่งไปกว่านั้น ไม่ว่าคุณจะมีประโยชน์ใดๆ สำหรับจุดข้อมูลที่กำหนดหรือไม่ “ทุกอย่าง” จะถูกทิ้งลงใน Data Lake อย่างสุ่มสี่สุ่มห้า
• อะไรก็ตามที่เข้าไป ไม่มีวันหลุดออกมา: เนื่องจาก Data Lake จัดเก็บข้อมูลดิบ หลังจากนั้นบางครั้งจึงเป็นไปไม่ได้ที่จะติดตามข้อมูลที่เราใส่ลงไปใน Lake กองข้อมูลยังคงไม่ได้รับการวิเคราะห์และตัดการเชื่อมต่อ การแสดงภาพถูกสร้างขึ้นบนชุดข้อมูลขนาดเล็กมากที่มีอยู่ใน Data Lake ข้อมูลที่เหลือยังคงไม่ได้ใช้
• ความจุ Data Lake ไม่ได้ไม่มีที่สิ้นสุดเหมือนหลุมดำขนาดมหึมา: เมื่อมีการนำเข้าข้อมูลมากขึ้นเรื่อยๆ ปัญหาก็ทวีคูณ องค์กรต่างๆ ต้องลงทุนมากขึ้นในด้านการจัดเก็บและการประมวลผล เพื่อที่จะพิสูจน์การลงทุนเหล่านี้ พวกเขาจะต้องสนับสนุนประโยชน์ของ Data Lake ต่อไปและช่วยพวกเขาได้มากเพียงใด ดังนั้น Data Lake จึงมีขนาดและราคาเพิ่มขึ้นเรื่อยๆ

การได้มาซึ่งคุณค่าผ่านการเรียนรู้ของเครื่อง

การเรียนรู้ของเครื่อง (ML) กลายเป็นสิ่งจำเป็นสำหรับระบบธุรกิจอัจฉริยะและระบบอัตโนมัติ

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

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

คุณลักษณะข้อมูลถูกกำหนดให้เป็นคุณลักษณะของข้อมูลซึ่งเกี่ยวข้องกับกรณีการใช้งานที่กำหนด สิ่งนี้เรียกอีกอย่างว่า “วิศวกรรมคุณลักษณะ”ในวิทยาศาสตร์ข้อมูล

ดังนั้น เราต้องดึงคุณลักษณะข้อมูลบางอย่างที่ "เกี่ยวข้อง" สำหรับกรณีการใช้งานออกจาก Data Lake ขนาดมหึมาที่กำลังขยายตัวอยู่เรื่อยๆ และคุณลักษณะข้อมูลเหล่านี้จะขับเคลื่อนอัลกอริธึม ML

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

แนวทางนี้ต้องการปริมาณงานก่อนการประมวลผลจำนวนมากผ่านงาน Spark และเปลืองทรัพยากรการประมวลผลจำนวนมาก

คิดใหม่เกี่ยวกับสถาปัตยกรรม Data Lake

มีความจำเป็นเร่งด่วนที่จะต้องคิดใหม่เกี่ยวกับสถาปัตยกรรม Data Lake และทำให้มีความคล่องตัวมากขึ้น เป็นมิตรต่อการวิเคราะห์ และคุ้มต้นทุน

ในส่วนนี้ เราจะพูดถึงแง่มุมทางสถาปัตยกรรมบางส่วนของ Data Lake ที่ถูกจินตนาการใหม่ หรือที่เรียกว่า "Intelligent Data Lake" สถาปัตยกรรม -

1. การนำเข้าข้อมูลแบบปรับเปลี่ยนได้

ควรกำหนดคุณลักษณะของข้อมูลได้ ณ เวลาที่นำเข้า

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

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

ด้วยเหตุนี้ เราจึงต้องเขียนงาน Spark เพื่อทำความเข้าใจข้อมูลนี้ และแยกส่วนเพื่อให้สามารถวิเคราะห์ได้

<แข็งแกร่ง>2. การทำให้ข้อมูลเวลานำเข้าเป็นมาตรฐาน

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

นี่เป็นกระบวนการที่เกิดขึ้นหลังจากการนำเข้าผ่านงาน Spark แบบกำหนดเองด้วย

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

3. การจัดระเบียบคุณลักษณะข้อมูลตามบริบท

หลังการนำเข้า ข้อมูลมักจะถูกทิ้งลงในโฟลเดอร์ HDFS ซึ่งเป็นข้อมูลดิบ

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

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

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

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

4. รองรับการแจ้งเตือนข้อมูล Webhook

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

เพื่อจุดประสงค์นี้ งาน Spark จะถูกกำหนดเวลาโดยใช้ Mesos หรือ Yarn เพื่อดำเนินการเป็นระยะ

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

ควรกำหนดค่ากฎในข้อมูลที่เชื่อมโยงนี้ ซึ่งเมื่อประเมินเป็นจริง จะนำไปสู่การเรียก API ของ Webhook

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

5. Data Lake แบบกระจาย

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

Data Lake แบบรวมศูนย์กลายเป็นจุดเดียวของความล้มเหลวและนำไปสู่เวลาแฝงที่สูงขึ้นสำหรับการนำเข้าข้อมูล

Data Lake แบบกระจายช่วยให้สามารถนำเข้าข้อมูลภายในเครื่องที่ Edge ได้ (เช่น กรณีการใช้งาน IoT และ 5G)

ควรเป็นไปได้ที่จะดำเนินการปริมาณงานจากส่วนกลางหรือที่ Edge ขึ้นอยู่กับกรณีการใช้งาน

ตัวอย่างเช่น การประมวลผลข้อมูล IoT เชิงอุตสาหกรรมควรเกิดขึ้นใกล้กับ Edge มากขึ้น

6. รองรับการจำลองแบบแบบเลือกสรร

ใน Data Lake ในปัจจุบัน ข้อมูลที่นำเข้าใน HDFS จะถูกจำลองแบบตามปัจจัยการจำลอง (RF)

เราจำเป็นต้องระบุจำนวนสำเนาข้อมูลที่เราต้องการโดยการตั้งค่า RF

Data Lake รุ่นต่อไปควรอนุญาตให้มีการจำลองแบบแบบเลือกได้

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

ซึ่งจะช่วยลดต้นทุนการจัดเก็บได้อย่างมาก

7. รองรับ GraphQL สำหรับ Data Lake

เพื่อเปิดใช้งานกรณีการใช้งานที่หลากหลายโดยไม่จำเป็นต้องปรับแต่งงาน Spark อย่างต่อเนื่อง จำเป็นต้องเปิดเผยความสามารถของ Data Lake โดยใช้ GraphQL

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

นอกจากนี้ การเชื่อมโยงข้อมูลควรได้รับการกำหนดเป็นพื้นฐานกฎนโยบายหลังการนำเข้าตามที่อธิบายไว้ก่อนหน้านี้

เลเยอร์ที่อยู่ด้านบนของความสามารถเหล่านี้ควรเป็นเลเยอร์ GraphQL ซึ่งสามารถเรียกใช้ได้โดยตรงจาก Spark

8. สตรีมมิ่งแบบสอบถามและผลลัพธ์

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

ชุดผลลัพธ์การสตรีมแบบเรียลไทม์นี้จะเปิดใช้งานกรณีการใช้งานที่หลากหลายซึ่งต้องการเวลาแฝงต่ำ

9. ภูมิภาค Data Lake และการแคช

ฟีเจอร์ข้อมูลบางอย่างไม่ได้เกิดมาเท่ากัน Data Lake ยุคใหม่ควรสนับสนุนแนวคิดระหว่างข้อมูลอุ่นกับข้อมูลเย็น

ชุดข้อมูลที่ต้องมีการอ่าน อัปเดต หรือเขียนบ่อยครั้งควรจัดหมวดหมู่เป็นข้อมูลอุ่น ณ เวลาที่นำเข้า

ชุดข้อมูลเหล่านี้ควรมีสิ่งอำนวยความสะดวกสำหรับการจัดเก็บในแคชแบบกระจาย เพื่อลดเวลาแฝงเพิ่มเติม

ในทางกลับกันข้อมูลเย็นสามารถคงอยู่บนดิสก์ได้ทั้งหมด

ในขณะนี้ เราไม่มีการควบคุมโดยละเอียดเกี่ยวกับประเด็นเหล่านี้ใน Data Lake

เครื่องมือค้นหา – Data Lake ที่ใหญ่ที่สุดในโลก

หากเราย้อนกลับไปและคิดว่า เครื่องมือค้นหาของ Google อาจเป็นตัวอย่างที่ดีที่สุดของ Data Lake อัจฉริยะที่ใหญ่ที่สุดในโลก

ลักษณะของเครื่องมือค้นหาของ Google จะไม่สามารถทำได้หากเป็นไปตามสถาปัตยกรรม Data Lake ในปัจจุบัน -

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

สรุป

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

ฉันคาดการณ์ว่าการหยุดชะงักครั้งใหญ่กำลังจะเกิดขึ้นในระบบนิเวศข้อมูลขนาดใหญ่

หากคุณชอบบทความนี้ อย่าลังเลที่จะเชื่อมต่อกับ LinkedIn