Azure Data Lake Storage (ADLS) Gen2 เปิดให้ใช้อย่างเป็นทางการเมื่อปีที่แล้ว ซึ่งมีการพัฒนาและปรับปรุงอย่างต่อเนื่องจนถึงปัจจุบัน จึงควรทำความเข้าใจเกี่ยวกับประโยชน์ และสิ่งที่ควรรู้ก่อนเริ่มใช้งาน
- แนวคิดของ Data Lake ใน Azure ถูกรวมเป็นหนึ่งแล้วด้วยการเปิดตัว ADLS Gen2
ก่อนที่จะมีการเปิดให้ใช้ ADLS Gen2 นั้น เวลาที่เราต้องการ Storage บนคลาวด์ของ Azure เพื่อติดตั้งระบบ Data Lake ก็จำเป็นต้องตัดสินใจเลือกระหว่าง Azure Data Lake Storage Gen1 (หรือที่รู้จักในชื่อเดิมว่า Azure Data Lake Store) กับ Azure Storage (ที่เป็น Storage แบบ Blob จำเพาะ) ซึ่งการตัดสินใจนี้จะต้องพิจารณาถึงความต้องการทั้งทางธุรกิจและทางเทคนิค เทียบกับฟีเจอร์ที่มีเพื่อดูว่าบริการไหนเหมาะสมมากที่สุด แต่บริการ ADLS Gen2 ใหม่นี้พัฒนาขึ้นบนระบบ Azure Storage เป็นหลัก เมื่อเปิดใช้งานคุณสมบัติของ Namespace แบบตามโครงสร้างหรือ HNS จะทำให้บัญชี Storage แบบใช้งานทั่วไปแบบ V2 มาตรฐานจะกลายเป็น ADSL Gen2 นี่จึงเป็นเหตุผลที่ว่าคุณจะไม่เห็นรายการ ADSL Gen2 อยู่ใน Azure ในฐานะเซอร์วิสของตัวเอง เนื่องจากตัว ADSL Gen1 เป็นเซอร์วิสของตัวเองอยู่แล้ว การเปลี่ยนแปลงนี้จึงสร้างความสับสันให้หลายต่อหลายคน อย่างไรก็ตามก็มีวิธีที่ตรวจสอบได้ว่ามีการเปิดใช้ ADLS Gen2 กับบัญชี Storage แล้วหรือไม่ดังนี้
เวลาดูรายละเอียดบัญชี Azure Storage นั้น ถ้าเซอร์วิสไฟล์ซิสเต็มแสดงขึ้นตามภาพ ก็แสดงว่าเปิดการรองรับ ADLS Gen2 แล้ว > จากรูปภาพประกอบ แสดงให้ทราบถึงเมื่อเราต้องการตรวจสอบว่า Azure Storage ที่ใช้งานอยู่เปิดการใช้งานเป็นแบบ ADLS Gen2 แล้วหรือยัง สามารถตรวจสอบได้ตามภาพ
อีกวิธีหนึ่งทำได้โดย ตรวจสอบดูที่ละเอียดในส่วนของคุณสมบัติการตั้งค่าบัญชี Azure Storage ถ้ามีการเปิดใช้งาน Hierarchical Namespace (HNS) ก็สามารถบอกได้ว่า Storage ที่เลือกใช้เป็นแบบ ADLS Gen2 แล้ว
สรุป:
เมื่อเราต้องการใช้งาน Data Lake สำหรับ Azure Analytic Services เราไม่จำเป็นต้องเลือกระหว่าง independent services อีกต่อไป เราสามารถใช้ Azure Storage ร่วมกับ hierarchical namespace นี่คือวิธีการที่ง่ายขึ้นในการสร้าง Data Lake โดยใช้ Azure Cloud Storage
- ADSL Gen2 การผสมผสานกันระหว่าง Object Storage และ Hierarchical File Storage
โดยพื้นฐานแล้ว ตัว ADLS Gen2 จะพยายามใช้ประโยชน์จากข้อดีของระบบแบบfile system ซึ่งจะไม่กระทบต่อการขยับขยายในอนาคต ทั้งในด้านของ scalability และ cost-effective ที่มีใน Object Storage
นอกจากนี้ ฟีเจอร์ที่จะเข้ามารองรับ ADLS Gen2 ยังมีการพัฒนาเพิ่มขึ้นอย่างต่อเนื่องดังจะกล่าวถึงเพิ่มเติมในหัวข้อที่ 4 สำหรับแผนภาพแสดงรูปแบบที่จะเกิดขึ้นในระยะยาวเป็นดังต่อไปนี้:
Azure Data Lake Storage:
ส่วนที่เป็น Box สีน้ำเงินเข้มเป็นฟีเจอร์ใหม่ที่เข้ามาพร้อมกับ ADLS Gen2
องค์ประกอบใหม่ 3 ส่วนที่แสดงให้เห็นข้างต้นนั้นได้แก่:
- ระบบแบบไฟล์ (File System) ใน ADSL Gen2 คำว่า File System จะถูกนำมาใช้แทน Concept ของ container (ที่ถูกเรียกใน Blob Storage)
- Namespace แบบโครงสร้างลำดับชั้น หรือ Hierarchical Namespace (HNS) มาพร้อมกับ Endpoint DFS ช่วยยกระดับทั้งด้านประสิทธิภาพและความปลอดภัย โดยจะกล่าวในรายละเอียดในหัวข้อที่ 3
- DFS Endpoint และ File System Driver ADLS Gen2 ใช้ประโยชน์จาก ABFS Driver ซึ่งเป็นส่วนหนึ่งของ Apache Hadoop สำหรับการเชื่อมต่อกับ ADLS Gen2 นั้น ABFS Driver จะใช้ประโยชน์จาก Endpoint แบบ DFS เพื่อยกระดับทั้งประสิทธิภาพและความปลอดภัย
- ABFS = Azure Blob File System
- DFS = Distributed File System
ประเด็นสำคัญ: ในระยะยาวนั้น (ตามที่แสดงในภาพข้างต้น) ที่จะมีการสื่อสารระหว่างกันเต็มรูปแบบระหว่าง Object Store Model และ File System Model จะทำให้เราสามารถจัดเก็บข้อมูลครั้งเดียว แต่เข้าถึงได้หลากหลายรูปแบบขึ้นกับกรณีการใช้งาน ซึ่งเราเรียกการเข้าถึงแบบนี้ว่า Multi-Protocol Access
- ADLS Gen2 มีจุดเด่นที่ประสิทธิภาพและความปลอดภัยสำหรับ Analytic Workloads ทั้ง Object Store Model (เช่น Blob Storage บน MS-Azure) และ Hierarchical File System Model (ใน ADLS Gen1 และ Gen2) จะสามารถทำงานร่วมกันได้กับ HDFS (Hadoop Distributed File System) ซึ่งมาพร้อมกับ Driver ที่ติดตั้งบนฝั่งเซิร์ฟเวอร์ของระบบ HDFS สำหรับใช้ในการ translate ให้อยู่ในรูปแบบของ remote storage API ทำให้ ADLS Gen2 ทำงานได้เหมือนกับระบบ Native HDFS แบบดั้งเดิม อย่างไรก็ตาม ก็ยังมีความแตกต่างที่สำคัญระหว่าง Object Store Model และ Hierarchical File System Storage ในด้านประสิทธิภาพและความปลอดภัย
สำหรับ Object Store Model นั้น โฟลเดอร์จะอยู่ในรูป Virtual เท่านั้น แม้ลักษณะจะดูเหมือนเราสามารถสร้างโฟลเดอร์บน Object Store Model ได้ เนื่องจากเป็นการเลียนแบบด้วยสตริง URI (หรือบางครั้งจะใช้ Meta Data เป็นทางเลือกแทน) แม้ว่าจะมองเผินๆ ดูเหมือนเป็นสิ่งเดียวกัน แต่จริงๆ แล้วมีจุดที่ด้อยดังนี้
- ประสิทธิภาพในการ Query เวลาส่งคำร้องขอ (Query) ที่ต้องการแค่ข้อมูลส่วนเดียว ถ้าเป็นระบบไฟล์โครงสร้างลำดับชั้นอย่างใน ADLS Gen2 ก็จะสามารถใช้ประโยชน์จากการสแกนบางส่วนเพื่อกรองข้อมูลเบื้องต้น (เรียกว่า Predicate Pushdown) ซึ่งจะช่วยยกระดับประสิทธิภาพการ Query ร้องขอข้อมูลได้เป็นอย่างมากสำหรับ Engine ประมวลผลที่รู้วิธีใช้ประโยชน์จากฟีเจอร์ Partition Scan นี้
ประสิทธิภาพในการโหลดข้อมูล (data load performance) ในบางครั้งเราจำเป็นต้องเปลี่ยนชื่อหรือเปลี่ยนตำแหน่งไฟล์จาก Directory หนึ่งไปยัง Directory อื่นๆ
ซึ่งการใช้ Object Storage Driver, ส่วนของ directory operation ไม่ได้มี efficiency เท่าที่ควร จากรูปถ้ามี files จำนวน 10,000 files การย้าย files เหล่านี้ไปยัง permanent directory จะก่อให้เกิด operation ทั้งหมด 20,000 ครั้ง โดยมี rename operation 10,000 ครั้ง , delete operation 10,000 ครั้ง
ในทางกลับกัน ด้วยระบบไฟล์ของ ADLS Gen2 เมื่อเชื่อมต่อผ่าน Endpoint DFS ก็จะเป็นแค่การจัดการกับMeta data เท่านั้น จึงทำให้ได้ประสิทธิภาพที่ดีกว่ามากในการโหลดข้อมูล โดยเฉพาะข้อมูลที่มีปริมาณมหาศาล
และนอกจากการยกระดับประสิทธิภาพการ Query แล้ว การจัดการผ่าน Metadata อย่างเดียวก็ยังให้ความคุ้มค่ากับค่าใช้จ่ายด้วย เนื่องจากใช้ทรัพยากรประมวลผลของ Engine น้อยกว่า
- ได้ความต่อเนื่องของข้อมูลด้วยการจัดการแบบ ย้อนกลับไปพิจารณาตัวอย่างก่อนหน้าที่มีการย้ายไฟล์ 10,000 ไฟล์ Object Storage Driver ไม่ได้รองรับการดำเนินการแบบ Atomic ซึ่งถ้าเกิดความล้มเหลวขึ้น ข้อมูลอาจอยู่ในสถานะที่ไม่เสถียรได้ กลับกัน ระบบไฟล์แบบใน ADLS Gen2 รองรับการดำเนินการแบบ Atomic ผ่าน Endpointแบบ DFS ซึ่งจะช่วยยกระดับความต่อเนื่องของข้อมูลด้วยเหตุที่การดำเนินการทั้งหมดจะล้มเหลวหรือสำเร็จในรูปของหน่วยเดียวทั้งหน่วยการดำเนินการ
- ได้ความปลอดภัยระดับ Granular ทั้งในระดับ Directory และระดับไฟล์ ระบบ File System แบบ Hierarchical ของ ADSL Gen2 (และ Gen1) เป็น POSIX Compliance ส่วนของ Access Control สามารถ define ได้ทั้งในระดับของ Directory Level และ File Level เพื่อควบคุมความปลอดภัยแบบ granular security
ประเด็นสำคัญ: การเปิดใช้ฟีเจอร์ Hierarchical Namespace สำหรับบัญชี Azure Storage ร่วมกับการเชื่อมต่อด้วย Driver ABFS ช่วยสนับสนุนข้อได้เปรียบของระบบแบบไฟล์ที่ส่งผลทั้งประสิทธิภาพ ความถูกต้องต่อเนื่องของข้อมูล และความปลอดภัย
- ฟีเจอร์ที่ออกมาสนับสนุน ADLS Gen2 มีพัฒนาขึ้นมามากขึ้นเรื่อยๆ
แม้ ADLS Gen2 จะเปิดตัวออกมาให้ใช้ทั่วไปอย่างเป็นทางการแล้วก็ตาม แต่ยังมีฟีเจอร์หลายตัวที่มีการวางแผนเปิดตัวในอนาคตอย่างต่อเนื่อง ซึ่งถือเป็นเรื่องปกติของผู้จำหน่ายผลิตภัณฑ์เทคโนโลยีอย่างไมโครซอฟท์ที่พยายามเปิดตัวฟีเจอร์ใหม่ออกสู่ตลาดให้เร็วที่สุดเท่าที่เป็นไปได้จนกว่าจะถึงจุดอิ่มตัวของผลิตภัณฑ์ ซึ่งส่วนแรกที่ ADLS Gen2 ให้ความสำคัญตั้งแต่เปิดตัวคือการรองรับแหล่งเก็บข้อมูลสมัยใหม่ และการใช้งานแบบอนาไลติกขั้นสูง
ประเด็นสำคัญ: การเข้าถึงข้อมูลแบบ Multi-Protocol (ตามที่อธิบายไว้ในแผนภาพของหัวข้อที่ 2) ถือเป็นฟีเจอร์ที่สำคัญมาก และกำลังได้รับการพัฒนาอย่างต่อเนื่อง ซึ่งเมื่อเปิดตัวมาแล้ว ได้ให้ความยืดหยุ่นอย่างมากในการฝากข้อมูลผ่าน Endpointที่ต้องการ (ตัวอย่างเช่น การรองรับแอพพลิเคชั่นหรือเซอร์วิสรุ่นเก่าหรือไม่ได้รับการอัพเดต) และมีการใช้ Endpointใหม่เพื่อประมวลผลทางอนาไลติกเพื่อให้ได้ประโยชน์ด้านประสิทธิภาพเพิ่มขึ้นด้วย
- ADLS Gen2 เป็น Storage ที่อยู่เบื้องหลัง Power BI Dataflow
ตัว Power BI Dataflow เป็นฟีเจอร์ใหม่ที่ใช้เตรียมความพร้อมข้อมูลแบบบริการด้วยตนเอง และนำกลับมาใช้ใหม่ได้ ซึ่งเอาต์พุตที่ได้จากคำร้องขอที่มีการเตรียมไว้ผ่านหน้าเว็บ Power Query Online นั้นเป็นเอาต์พุตของ ADLS Gen2 นั่นเอง เป้าหมายของฟีเจอร์นี้คือการจัดการทั้งคำร้องขอข้อมูลและการเตรียมข้อมูลไปพร้อมกัน เพื่อส่งไปเป็นชุดข้อมูลของ Power BI
Dataflow นี้สามารถจัดการได้อย่างเต็มที่ผ่าน Power BI ในกรณีที่ใช้บัญชีแบบ ADLS Gen2 แต่จะเห็นได้จากแค่บน Interface ใช้งานของ Power BI Dataflow เท่านั้น สำหรับทางเลือกอื่น อย่างกรณี “นำ Storage ของตัวเองมาใช้” (ตามแผนภาพด้านล่าง) ก็ถือว่าเหมาะกับองค์กรที่ต้องการใช้ข้อมูลใน Data Lake ผ่านทูลและ Engine ประมวลผลอื่นเพิ่มเติมที่นอกเหนือจาก Power BI:
ประเด็นสำคัญ: บริการ Storage ที่คอยสนับสนุนเบื้องหลัง Power BI Dataflow คือ ADLS Gen2 ซึ่งสามารถนำมาเป็นส่วนสำคัญของยุทธศาสตร์ข้อมูลทางธุรกิจแบบช่วยเหลือตนเองได้ – ติดตามต่อตอนที่สองได้ในเร็วๆ นี้
ถ้าท่านใดมีข้อสงสัยและต้องการที่จะสอบถามเพิ่มเติมสามารถติดต่อ บริษัท อินแกรม ไมโคร (ประเทศไทย) จำกัด ได้ทางอีเมล์ TH-MSCSP@ingrammicro.com
