วิธีการสร้างแพลตฟอร์มข้อมูล Lakehouse ที่ปรับขนาดได้และประหยัดต้นทุน

ในช่วงทศวรรษที่ผ่านมา เราได้เปลี่ยนจากคลังข้อมูลที่เข้มงวดไปสู่เดตาเลคที่ยืดหยุ่น และเมื่อไม่นานมานี้ไปสู่สถาปัตยกรรมเลคเฮาส์ที่สัญญาว่าจะรวมข้อดีของทั้งสองโลก

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

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

ทำไมประวัติศาสตร์ล้วนๆ ของบิ๊กดาต้าจึงไม่มีประโยชน์อีกต่อไป

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

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

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

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

เลคเฮาส์ในฐานะจุดเปลี่ยน

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

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

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

ความท้าทายด้านโครงสร้างและการกำกับดูแลในการนำเดตาเลคเฮาส์มาใช้

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

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

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

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

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

การเพิ่มประสิทธิภาพต้นทุนในฐานะกฎข้อแรก

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

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

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

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

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

การเลือกแนวทางสถาปัตยกรรมที่เหมาะสม

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

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

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

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

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

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

ข้อมูลเชิงลึกจากภาคสนาม

หากผมออกแบบตั้งแต่ต้น ผมจะทำบางอย่างแตกต่างจากวิธีที่อุตสาหกรรมเข้าหาข้อมูลในอดีต

ด้านล่างนี้คือบทเรียนที่ผมได้เรียนรู้จากการใช้งานจริงและสิ่งที่ผมแนะนำในตอนนี้

1. เริ่มเล็ก ส่งมอบเร็ว

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

1. แปลความต้องการทางธุรกิจตั้งแต่เนิ่นๆ

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

1. จับคู่เทคโนโลยีกับความสามารถขององค์กร

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

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