Azure Data Lake Storage (ADLS) Gen2 เปิดให้ใช้อย่างเป็นทางการเมื่อปีที่แล้ว ซึ่งมีการพัฒนาและปรับปรุงอย่างต่อเนื่องจนถึงปัจจุบัน จึงควรทำความเข้าใจเกี่ยวกับประโยชน์ และสิ่งที่ควรรู้ก่อนเริ่มใช้งาน โดยครั้งที่แล้วเสนอไป 5 เรื่องควรรู้ ส่วนในครั้งนี้มาต่อกันอีก 5 เรื่องสุดท้ายที่น่าสนใจ
6. มีระบบความปลอดภัยถึง 2 ระดับใน ADLS Gen2
มีระบบความปลอดภัยอยู่ 2 ลำดับชั้นที่นำมาใช้กับ ADLS Gen2 ได้ และยังมีผลกับระบบแบบ ADLS Gen1 ด้วย แม้ระบบความปลอดภัยนี้จะไม่ใช่เรื่องใหม่ แต่ก็ควรมาทำความเข้าใจกับความปลอดภัย 2 ระดับนี้อีกครั้งเนื่องจากถือเป็นองค์ประกอบพื้นฐานในการเริ่มทำงานกับ Data Lake ที่มักสร้างความสับสนกับผู้ที่เพิ่งเริ่มต้นเข้ามาใช้งาน ดังนี้
(1) Role-Based Access Control (RBAC) มี Role ที่ติดตั้งมากับ Azure อย่างเช่น reader, contributor, owner , หรือบทบาทที่สร้างขึ้นมาเอง เป็นต้น เราจะนำ RBAC มาใช้ด้วยเหตุผลสองประการได้แก่ การระบุว่าใครสามารถจัดการเซอร์วิสได้ด้วยตนเอง (เช่น อัพเดตการตั้งค่าและคุณสมบัติของบัญชี Storage ) อีกเหตุผลหนึ่งคือการอนุญาตให้ใช้ทูลค้นหาข้อมูลที่บิ้วท์อินมาด้วย ซึ่งต้องการการอนุญาตในฐานะผู้อ่านข้อมูล (Reader)
(2) Access Control Lists (ACL) ซึ่งรายการเงื่อนไขควบคุมการเข้าถึงนี้จะใช้ระบุ Object ข้อมูลที่แน่นอนว่าผู้ใช้สามารถอ่าน, เขียน, หรือรันการทำงาน (ซึ่งการ Execute นี้จะต้องลงลึกค้นหาในโครงสร้าง Directory ด้วย) ACL นี้เป็นแบบที่สอดคล้องตามมาตรฐาน POSIX ดังนั้นจึงเหมาะกับผู้ที่คุ้นเคยกับการใช้ยูนิกซ์หรือลีนุกซ์เป็นอย่างดี
ประเด็นสำคัญ: ด้วย RBAC และ ACL จึงทำให้มีความยืดหยุ่นพอสมควรในการกำหนดความปลอดภัยสำหรับ ADLS Gen2
7. การวางแผนสำหรับ ADLS Gen2 มีเรื่องที่ต้องพิจารณาอยู่หลายระดับ
มีสิ่งที่ต้องพิจารณาอยู่หลายด้านเวลาวางแผนสำหรับ Data Lake โดยเฉพาะถ้าคุณมีรูปแบบการย่อยข้อมูล รูปแบบการใช้ข้อมูล ประเภทของผู้ใช้ และทูลหรือภาษาที่ต้องใช้อยู่จำนวนมาก บางองค์กรอาจมองการวางระบบ Data Lake ศูนย์กลางเดียวใช้งานทั่วโลก ขณะที่องค์กรอื่นอาจเลือกที่จะใช้ประโยชน์จากหลาย Data Lake (Multi-Lake) แทน
จากการเปิดตัว ADLS Gen2 จะมีอีกหนึ่งประการที่ต้องวางแผนเพิ่มเติม ที่ไม่เคยมีมาก่อนใน ADLS Gen1 ได้แก่ระบบแบบไฟล์ ซึ่งระบบตัดเก็บข้อมูลในรูปของไฟล์ใน ADLS Gen2 นี้จะมีลักษณะเหมือน Container ในเซอร์วิส Blob ซึ่งมีสิ่งต่างๆ ที่ต้องพิจารณาดังต่อไปนี้
• บัญชีผู้ใช้ (Account)
• ระบบไฟล์ในแต่ละบัญชี (File system within an account)
• โครงสร้าง Directory ภายในระบบไฟล์ (directory structure within file system)
สิ่งที่ควรสังเกตและพิจารณาเพิ่มเติมได้แก่
Region and geo-replication เป็น account-level properties ในกรณีที่มีความต้องการเกี่ยวกับ data residency และ/หรือ different geo-replication requirements นั่นจำเป็นต้องใช้ storage account หลายตัว หรือถ้าคุณมี Engine ประมวลผลบางตัว (อย่าง HDInsight หรือ Azure Databricks) ซึ่งมีให้ใช้เฉพาะในบาง Region ก็จำเป็นต้องใช้บัญชี ADLS Gen2 ที่อยู่ในภูมิภาคเดียวกันเพื่อให้ได้ประสิทธิภาพการทำงานที่มากที่สุด
• Namespace แบบ Hierarchical ก็ถูกเปิดใช้งานในระดับบัญชีผู้ใช้ด้วย ดังนั้น ถ้ากรณีที่ไม่มีความจำเป็นต้องใช้ประโยชน์จาก Namespace แบบโครงสร้างลำดับชั้นนี้แล้ว ข้อมูลดังกล่าวก็ควรนำไปเก็บในบัญชี Storage อื่นแทน
• Policy ที่ตายตัว (Immutable) และ policy ที่ควบคุมการเข้าถึงที่ใช้งานร่วมกันนั้นจะถูกตั้งค่าในระดับ Container สำหรับ Storage แบบ Blob (ดังนั้น เราจึงคาดหวังให้โพลิซีเหล่านี้บังคับใช้กับระดับของระบบไฟล์ในบัญชีที่เปิดใช้ ADLS Gen2 ได้ด้วย) ซึ่งถ้าจำเป็นที่ต้องมีโพลิซีแตกต่างกันแล้ว ก็อาจทำให้ต้องใช้คนละระบบไฟล์กันได้
• สำหรับ ACL นั้น Root ใน ADLS Gen1 จะอยู่ที่ระดับบัญชีผู้ใช้ ขณะที่ Root ใน ADLS Gen2 จะอยู่มี่ระดับระบบไฟล์
• ส่วน Power BI Dataflow ที่กล่าวถึงก่อนหน้า จำเป็นต้องใช้ระบบไฟล์ 1 ระบบหรือมากกว่าเพื่อผสานการทำงานเข้ากับ Common Data Model
ประเด็นสำคัญ: อาจจะมีบางกรณีการใช้งาน ขอบเขตการอนุญาต หรือประเด็นเรื่องค่าใช้จ่ายที่ต้องพิจารณา (ดูเพิ่มเติมในหัวข้อที่ 8) ที่ทำให้คุณต้องเลือกแยกข้อมูลออกไปจาก Data Lake เดียวกัน ส่วนระบบไฟล์ก็ถือเป็นปัจจัยใหม่ที่มีการตั้งค่าคุณสมบัติที่จำเพาะของตัวเอง ที่ควรพิจารณาร่วมด้วยในการวางแผน
8. ราคาของ ADLS Gen2 คุ้มค่าเหมือนกับ Storage แบบ Object
Storage แบบ Object อย่างเช่น Storage Azure Blob นั้นเป็นที่รู้จักกันดีในแง่ของราคาที่ประหยัดมาก ซึ่งเมื่อพิจารณาถึงค่าใช้จ่ายทางตรงของ Storage แล้ว ก็ถือว่าไมโครซอฟท์ปล่อย ADLS Gen2 ในราคาอัตราเดียวกับ Storage Azure Blob เลยทีเดียว (อย่างเช่น อัตราค่าบริการ Block Blob) คุณจะจ่ายเพียงแค่ Storage ที่คุณใช้เท่านั้น ไม่จำเป็นต้องจ่ายครอบคลุมขนาดพื้นที่ที่ต้องการล็อกไว้แต่อย่างใด อย่างไรก็ดี ค่าใช้จ่ายของการดำเนินงานที่เกี่ยวข้องนั้นค่อนข้างสูงกว่าสำหรับบัญชีผู้ใช้ที่เปิดใช้งาน Hierarchical Namespace โดยราคาของการทำธุรกรรมนั้นจะจ่ายเป็นแบบเหมารวมต่อ 10,000 ครั้ง
ประเด็นสำคัญ: ค่าใช้จ่ายในการทำงาน (Transaction) และค่า Storage ของ Metadata นั้นถือว่าแพงกว่าในกรณีที่เปิดใช้ฟีเจอร์ Hierarchical Namespace ในบัญชี Storage แม้ราคาส่วนของ Storage จะเท่ากันก็ตาม ดังนั้น เนื่องจากราคาค่าทำธุรกรรมดูเหมือนจะแพงกว่านี้ เราจึงควรเก็บโหลดงานที่ไม่น่าจะได้ใช้ประโยชน์จาก Namespace แบบโครงสร้างลำดับชั้น (HNS) ในบัฯชี Storage ที่ไม่ได้เปิดใช้งาน HNS มากกว่า
9. อนาคตของ Azure Data Lake และ U-SQL ยังไม่แน่นอน
บริการเริ่มต้นของ Azure ที่ ADLS Gen2 รองรับผ่าน Driver ABFS ได้แก่:
• Azure Databricks
• Azure HDInsight
• Azure Data Factory
• Azure SQL Data Warehouse (PolyBase)
นอกจากนี้ยังมีการสนับสนุนจากเธิร์ดปาร์ตี้ภายนอกเพิ่มเข้ามาอย่างต่อเนื่องด้วย
แต่เมื่อดูถึงฟีเจอร์ U-SQL ที่อยู่ใน Azure Data Lake Analytics (ADLA) ซึ่งไม่ใช่เซอร์วิสที่มีให้เริ่มแรกที่ได้รับการสนับสนุนจาก Driver ABFS ที่พัฒนาใหม่ จึงไม่มีใครรู้อนาคตของฟีเจอร์นี้อย่างชัดเจน ทางไมโครซอฟท์ก็ไม่ได้ประกาศโร้ดแมปในอนาคตของ ADLA ด้วย ในขณะเดียวกัน เราก็ได้เห็นเทคโนโลยีโอเพ่นซอร์สอย่าง Spark ที่ดึงดูดฐานลูกค้าได้ในวงกว้างมากกว่าเมื่อเทียบกับทูลหรือภาษาที่ผูกขาดกับผู้ผลิต ดังนั้นจึงแนะนำให้ระมัดระวังเวลาเลือกใช้ ADLS กับโปรเจ็กต์ใดๆ ในอนาคต
ประเด็นสำคัญ: ปัจจุบันยังไม่มีวิธีแบบ Serverless (จ่ายตามปริมาณการใช้จริง) ในการรันคำร้องขอข้อมูลบน ADLS Gen2 ทำให้ทั้ง Azure Databricks และ HDInsight ยังเป็นวิธีที่ได้รับความนิยมในปัจจุบันสำหรับการร้องขอข้อมูลโดยตรง
10. ADLS Gen1 จะยังได้รับการซัพพอร์ตไปอีกช่วงเวลาหนึ่ง
สัญญาณของการใช้งาน ADLS Gen1 จะยังไม่หายไปในเวลาอันใกล้ ดังนั้นถ้าคุณยังใช้ระบบ ADLS Gen1 เป็นหลักอยู่ก็ยังไม่มีอะไรที่ต้องกังวลในตอนนี้
แต่ถ้าคุณต้องการย้ายจาก ADLS Gen1 ไปใช้ ADLS Gen2 แล้ว ก็มียุทธศาสตร์การอัพเกรดอยู่หลายแนวทาง โดยมีปัจจัยสำคัญที่ควรพิจารณาดังต่อไปนี้:
• การย้ายข้อมูลผ่าน Azure Data Factory ยังถือเป็นวิธีที่ง่ายที่สุดสำหรับการย้ายข้อมูลทั้งหมดในครั้งเดียว เนื่องจากปัจจุบันยังไม่ทีทูลย้ายข้อมูลอื่นให้ใช้งาน
• ถ้าคุณมีไฟล์เก็บอยู่ใน ADLS Gen1 ที่ใหญ่กว่า 5TB ก็จำเป็นต้องแยกออกเป็นไฟล์ย่อยก่อนทำการย้าย
• การอ้างอิงใดๆ ที่ใช้ที่อยู่แบบ adl:// ก็จำเป็นต้องเปลี่ยนมาเชื่อมต่อในรูป abfs[s]:// หรือ REST API ใหม่ และ/หรือ SDK ใหม่แทน
ประเด็นสำคัญ: การย้ายระบบจาก ADLS Gen1 ไม่ได้เป็นเรื่องเร่งด่วนแต่อย่างใด แต่คุณก็ควรหาโอกาสย้ายออกมาเมื่อมีโอกาสที่เห็นว่าสมควร เนื่องจากฟีเจอร์และความสามารถใหม่ๆ มีแนวโน้มที่จะออกมาเพื่อใช้กับ ADLS Gen2 มากกว่า
ถ้าท่านใดมีข้อสงสัยและต้องการที่จะสอบถามเพิ่มเติมสามารถติดต่อ บริษัท อินแกรม ไมโคร (ประเทศไทย) จำกัด ได้ทางอีเมล์ TH-MSCSP@ingrammicro.com
