The Semantic Lakehouse อธิบาย

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

สถาปัตยกรรมข้อมูลและการวิเคราะห์แบบดั้งเดิม

ในปี 2006 Amazon ได้เปิดตัว Amazon Web Services (AWS) ซึ่งเป็นวิธีใหม่ในการถ่ายโอนศูนย์ข้อมูลภายในองค์กรไปยังระบบคลาวด์ บริการหลักของ AWS คือการจัดเก็บข้อมูลไฟล์ และด้วยเหตุนี้ Amazon S3 จึงเกิด Data Lake บนคลาวด์แห่งแรก ผู้จำหน่ายระบบคลาวด์รายอื่นๆ จะแนะนำโครงสร้างพื้นฐาน Data Lake บนระบบคลาวด์เวอร์ชันของตนเองหลังจากนั้น

เกือบตลอดชีวิต Cloud Data Lake ถูกผลักไสให้มีบทบาทโง่และราคาถูก การจัดเก็บข้อมูล - การแสดงละคร พื้นที่สำหรับข้อมูลดิบจนกว่าข้อมูลจะสามารถประมวลผลเป็นสิ่งที่มีประโยชน์ได้ สำหรับการวิเคราะห์ Data Lake จะทำหน้าที่เป็นปากกาจับข้อมูลจนกว่าจะสามารถคัดลอกและโหลดลงในแพลตฟอร์มการวิเคราะห์ที่ได้รับการปรับปรุงได้ โดยทั่วไปแล้วจะเป็นคลังข้อมูลบนคลาวด์เชิงสัมพันธ์ที่ป้อนคิวบ์ OLAP, เครื่องมือแยกข้อมูลระบบธุรกิจอัจฉริยะ (BI) ที่เป็นกรรมสิทธิ์ เช่น Tableau Hyper หรือ Power BI Premium หรือทั้งหมดข้างต้น จากรูปแบบการประมวลผลนี้ ข้อมูลจึงต้องถูกจัดเก็บอย่างน้อยสองครั้ง ครั้งแรกในรูปแบบดิบ และอีกครั้งในรูปแบบ "เพิ่มประสิทธิภาพการวิเคราะห์" 

ไม่น่าแปลกใจเลยที่สถาปัตยกรรมการวิเคราะห์บนคลาวด์แบบดั้งเดิมส่วนใหญ่จะมีลักษณะเหมือนแผนภาพด้านล่าง:

อย่างที่คุณเห็น “คลังข้อมูลการวิเคราะห์” มีหน้าที่รับผิดชอบฟังก์ชันส่วนใหญ่ที่ส่งมอบการวิเคราะห์ให้กับผู้บริโภค ปัญหาเกี่ยวกับสถาปัตยกรรมนี้มีดังนี้:

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

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

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

การกำเนิดของ Data Lakehouse

คำว่า “Lakehouse” เปิดตัวในปี 2020 ด้วยเอกสารไวท์เปเปอร์ Databricks อันทรงคุณค่า “เลคเฮาส์คืออะไร” โดย Ben Lorica, Michael Armbrust, Reynold Xin, Matei Zaharia และ Ali Ghodsi ผู้เขียนได้แนะนำแนวคิดที่ว่า Data Lake สามารถทำหน้าที่เป็นกลไกในการส่งมอบการวิเคราะห์ ไม่ใช่แค่ที่เก็บไฟล์แบบคงที่

ผู้จำหน่าย Data Lakehouse ส่งมอบวิสัยทัศน์ของตนโดยการแนะนำกลไกสืบค้นความเร็วสูงที่ปรับขนาดได้ ซึ่งทำงานกับไฟล์ข้อมูลดิบใน Data Lake และแสดงอินเทอร์เฟซ SQL มาตรฐาน ANSI ด้วยนวัตกรรมที่สำคัญนี้ ผู้เสนอสถาปัตยกรรมนี้ยืนยันว่า Data Lake สามารถทำงานเหมือนกับคลังข้อมูลการวิเคราะห์ โดยไม่จำเป็นต้องทำซ้ำข้อมูล

อย่างไรก็ตาม ปรากฎว่าคลังข้อมูลการวิเคราะห์ทำหน้าที่สำคัญอื่นๆ ที่สถาปัตยกรรม Data Lakehouse เพียงอย่างเดียวไม่พอใจ รวมถึง:

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

ดังนั้น เพื่อให้ Data Lakehouse เข้ามาแทนที่คลังข้อมูลการวิเคราะห์ได้อย่างแท้จริง เราต้องการอย่างอื่น

บทบาทของเลเยอร์ความหมาย

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

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

1. มอบ “ความเร็วของการสืบค้นทางความคิด” บน Data Lakehouse โดยใช้การจำลองเสมือนของข้อมูลและการปรับแต่งประสิทธิภาพการสืบค้นแบบอัตโนมัติ
2. มอบชั้นความหมายที่เป็นมิตรต่อธุรกิจ ซึ่งจะมาแทนที่มุมมองความหมายที่เป็นกรรมสิทธิ์ซึ่งฝังอยู่ภายในเครื่องมือ BI แต่ละรายการ และช่วยให้ผู้ใช้ทางธุรกิจสามารถถามคำถามโดยไม่จำเป็นต้องเขียนคำสั่ง SQL
3. มอบการกำกับดูแลข้อมูลและความปลอดภัยในเวลาที่สืบค้น

แพลตฟอร์มเลเยอร์ความหมายจะส่งส่วนที่ขาดหายไปซึ่ง Data Lakehouse ขาดหายไป ด้วยการรวมเลเยอร์ความหมายเข้ากับ Data Lakehouse องค์กรต่างๆ จึงสามารถ:

1. กำจัดสำเนาข้อมูลและลดความซับซ้อนของไปป์ไลน์ข้อมูล
2. รวมการกำกับดูแลข้อมูลและความปลอดภัยเข้าด้วยกัน
3. มอบ "แหล่งความจริงแห่งเดียว" สำหรับการวัดผลทางธุรกิจ
4. ลดความซับซ้อนในการดำเนินงานโดยเก็บข้อมูลไว้ใน Data Lake
5. ให้การเข้าถึงข้อมูลมากขึ้นและข้อมูลที่ทันเวลามากขึ้นแก่ผู้บริโภคด้านการวิเคราะห์

Semantic Lakehouse: ทุกคนชนะ

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

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

• เนื้อหาที่ขับเคลื่อนด้วย SEO และการเผยแพร่ประชาสัมพันธ์ รับการขยายวันนี้
• เพลโตบล็อคเชน Web3 Metaverse ข่าวกรอง ขยายความรู้. เข้าถึงได้ที่นี่.
• ที่มา: https://www.dataversity.net/the-semantic-lakehouse-explained/