Query เร็วขึ้น เมื่อทำ “Design by Analytics” บน Hadoop
การทำ Big Data ต้องอาศัย Big Data Technology อย่างเช่น Hadoop มาบริหารจัดการข้อมูล ทั้งในการเก็บข้อมูลและประมวลผลข้อมูล … การเก็บข้อมูลใน Hadoop มีคนอธิบายไว้เยอะแล้ว แต่การประมวลผลข้อมูลบน Data Center ของเราให้เร็วถึงระดับที่เทียบได้กับ Platform เจ้าใหญ่ๆ เช่น Google Cloud Platform นั้นควรทำอย่างไร …
วิธีการหนึ่งที่น่าสนใจคือ การออกแบบสถาปัตยกรรมทางเทคโนโลยีให้เหมาะสมกับการวิเคราะห์ข้อมูล ซึ่งผมขอเรียกว่า “Design by Analytics” ที่ไม่ใช่ยก Template ของ Vendors มาทำ Sizing Hardware Spec. เป็นหลัก หรือไปคัดลอกการทำ Deploy services ต่างๆ จาก Successor มาตรงๆ แต่ต้องเข้าใจ Requirements ของการทำ Big Data Analytics อย่างชัดเจนแบบลงรายละเอียดถึง Use Cases ต่างๆ แล้วจึงมาดูว่า เพื่อจะให้เป็นไปตาม Requirement เหล่านั้น เราต้อง Run services/software อะไรในเครื่องไหน … Service นั้นมีการทำงานอย่างไร … เป็น Distributed Computing หรือไม่ …กิน Resources อะไรแค่ไหน (CPU/RAM) มีข้อมูลที่จะนำมาจัดเก็บและประมวลผลประมาณเท่าใด รวมถึงต้องประมาณการเกี่ยวกับ Concurrent Jobs ที่จะต้อง Run ใน Platform ด้วย… เมื่อทราบทั้งหมดดังนี้แล้ว จึงจะทำการ Design เป็นขั้นตอนถัดไป
ยกตัวอย่างโจทย์เช่น ลูกค้าต้องการ Dashboard ที่แสดงผลข้อมูลเป็นกราฟเชิงสรุปข้อมูลในมุมมองต่างๆ ตั้งแต่ มิ.ย.2555 จนถึง มิ.ย.2563 โดยให้ใช้ Big Data Tech. บน on-Premises
ถอดจากโจทย์มาเป็น Analytics Requirements ซึ่งกรณีนี้ก็คือ Batch Analytics ที่เป็นเพียง Descriptive Analytics แล้วนำผลลัพธ์ไปสร้าง Graph … ซอฟต์แวร์ที่ทำ Descriptive Analytics ได้เร็วที่สุดตอนนี้บน on-Premises ผมนึกถึง Impala … Impala เป็น SQL Engine ที่ต้องทำงานร่วมกับ Hive, HDFS หรือ HBase นั่นแสดงว่า ถ้าคิดจะใช้ Impala แล้ว ต้องพาเพื่อนมันมาด้วย เช่น Hive + HDFS … สรุปคือซอฟต์แวร์ที่จะใช้วิเคราะห์ข้อมูล ประกอบด้วย Hive และ Impala และมีการเก็บข้อมูลไว้ใน HDFS
จาก Analytics Requirements การ Sizing Hardware และการวางแผน Software Deployment ต้องทำควบคู่กันไป ดังนี้
1. Impala เป็น in-Memory Computing ที่มีการ Caching ผลลัพธ์และ Metadata ไว้ที่ RAM และเป็น Distributed Computing ที่มีการประมวลผลข้อมูลในสไตล์ของ Data Locality … การ Caching และ Computing ดังกล่าวเป็นความสามารถของ Service หนึ่งของ Impala ชื่อ “Impala Daemon” ด้วยเหตุนี้ Node ที่จะ Run Impala Daemon ต้องมี CPU Cores และ RAM เยอะๆ หน่อย หรือเยอะกว่า Slave Node ทุกเครื่องใน Cluster ซึ่งจาก Document ของ Cloudera [1] ระบุให้ใช้ RAM ขั้นต่ำ 32 GB และ Recommended ที่ 128 GB เลยทีเดียว!!! … นอกจากนี้ Impala Daemon กับ DataNode ควรจะ co-Deployment ไปด้วยกัน ซึ่งหมายความว่าเครื่องไหนมี Impala Daemon เครื่องนั้นก็ควรต้องมี DataNode ของ HDFS ทำงานอยู่ด้วย เพื่อลด Data Movement ในขณะประมวลผลข้อมูล
2. Hive เป็น Data Warehouse ของ Hadoop ที่มีการเก็บโครงสร้างของ Table ไว้ใน MetaStore ซึ่ง Impala ต้องอาศัย MetaStore ของ Hive ในการประมวลผลข้อมูล ส่วนข้อมูลจะอยู่ใน HDFS. แม้ว่า Hive จะมี Service ชื่อ HiveServer ซึ่งทำหน้าที่หลักๆ คือ แปลง ANSI SQL ที่ User สั่งงาน ไปเป็น Java MapReduce Job ที่จะถูกดูแลการประมวลผลด้วย YARN ต่อไป แต่ประเด็นสำคัญคือ เราไม่ได้ใช้ Hive ในการประมวลผลตามโจทย์ของลูกค้า เราใช้ Impala ประมวลผล ดังนั้น YARN ซึ่งเป็น Job Scheduling ของ Hadoop จึงถูกลดบทบาทลงไปและส่งผลให้ Node ต่างๆ มัน Lightweight มากขึ้น. ด้วยเหตุนี้ Node ที่จะ Run HiveServer อาจเป็นเครื่องที่มี CPU Cores และ RAM น้อยกว่าเครื่องที่ Run Impala Daemon ก็ได้
3. YARN มี NodeManager ทำหน้าที่สร้าง Container ขึ้นมา เพื่อ Run JAVA MapReduce Job โดยใน Container นั้นมีการถือครอง Resources ต่างๆ เช่น CPU, RAM, Disk Capacities อื่นๆ ไว้ใช้สำหรับการ Run Job นั้น เมื่อเสร็จสิ้นการ Run Job แล้ว NodeManager จะคืน resources ให้กับระบบ เพื่อให้ YARN สามารถนำไปบริหารจัดการได้ต่อไป. เนื่องจากตั้งแต่ต้นจนจบในการประมวลผลแต่ละ Job นั้น จะต้องใช้ Containers จำนวนมากมายใกล้เคียงกับจำนวน HDFS Data Blocks ที่จะถูกประมวลผลใน Job นั้นๆ แต่ Resources ของระบบมีจำกัดทำให้ไม่สามารถ Run Containers จำนวนมากมายเหล่านั้นขึ้นมาพร้อมๆ กันได้ ด้วยเหตุนี้ YARN จึงต้องจัดตารางงานของ Containers เพื่อให้ทยอยกันเข้าใช้ Resources (Job Scheduling). เมื่อ Container หนึ่งประมวลผล Task เสร็จแล้ว ก็จะคืน Resource ให้ YARN เพื่อให้ YARN ส่งให้ Container ถัดไปได้ใช้ ดังนั้นกลไกการถือครองและคืน Resources ให้ระบบจึงเกิดขึ้นอย่างต่อเนื่องและจัดว่าเป็น Overhead ในบริหารจัดการ Containers ที่เกิดขึ้นกับระบบโดยรวมอย่างมหาศาล!!!...
โชคดีที่ Impala Job ไม่ใช่ JAVA MapReduce Job จึงไม่จำเป็นต้องใช้ Container ของ YARN ในการ Run job และไม่มีเหตุผลใดที่จะ Deploy NodeManager ไปไว้เครื่องเดียวกับ Impala Daemon ส่งผลดีให้ Impala Daemon ได้ใช้ Resources บน Slave Node ได้อย่างเต็มที่โดยไม่ถูก Allocate resource ไปให้ Container และไม่มี Overhead จากการทำงานของ YARN อีกด้วย (รูปที่ 1)
ที่ผ่านมาผมได้ทำ Design by Analytics ตามแนวทางที่อธิบายมาข้างต้นโดยตลอด. ใน Site งานที่เป็น Descriptive Analytics พบว่า การประมวลผลข้อมูลของ Hadoop และ Impala มีความเร็วถึงระดับที่เทียบได้กับ Platform ที่ใช้ทำ Data Warehouse ของเจ้าใหญ่ๆ เช่น Google BigQuery. สิ่งที่น่าสนใจคือ ผมยังไม่เคยทราบเลยว่า ความเร็วระดับ 1–10 วินาทีของ BigQuery บน Query ที่ใช้ Group By with Aggregation Function กับข้อมูล 1.x Billion Records ในขนาด 5xx GB นั้น Google เค้าใช้เครื่องใหญ่แค่ไหน มี CPU Core และ RAM เท่าไหร่ และที่สำคัญคือผมไม่รู้เลยว่า ข้อมูลวิ่งไปไหนมาไหนบน Host มากมายของ Google ที่มีอยู่ในเกือบทุกทวีปบนโลกไปนี้เลย. เมื่อเปรียบเทียบกับการใช้ Impala และ Hadoop บน on-Premises เราใช้คอมพิวเตอร์ในแบบ Commodity Hardware เพียงแค่ 6 เครื่องด้วยสเปคที่ดูใหญ่สักหน่อยแต่ก็พบได้ทั่วไปใน Data Center ของไทย สามารถทำเวลาได้ 7 นาทีกว่าๆ ในรอบแรกบนข้อมูลเดียวกันและ Query เดียวกันกับ BigQuery … สำหรับในรอบถัดไป Impala และ Hadoop ใช้เวลาประมวลผลน้อยลงอย่างมาก คือใช้เพียงแค่ 1 นาทีเศษเท่านั้น
สรุปส่งท้าย
ความเร็วของการ Query ที่ได้รับจากการทำ “Design by Analytics” มาจากการเลือกทำ Hadoop Services Deployment ที่เหมาะสม ซึ่งช่วยลด Overhead มากมายที่อาจเกิดขึ้นใน Hadoop Cluster โดยไม่จำเป็น และนอกจากเหนือจาก Benefits ในด้านความเร็วแล้ว “Design by Analytics” ยังช่วยให้องค์กรได้รับประโยชน์ในด้านการลงทุนทำ Platform เท่าที่จำเป็นกับการใช้งานจริงอีกด้วย.
Reference
