สวัสดีครับ กลับมาพบกันอีกครั้งกับบทความยาวๆ แบบที่อ่านจบรู้เล่าเอาไปโม้ต่อได้เลย วันนี้ผมจะมาแนะนำให้รู้จักกับสายอาชีพวิศวกรข้อมูล หรือ Data Engineer กัน แต่เราจะไปไกลกันมากกว่านั้น ผมจะพาไปรู้จักกับที่มาที่ไปของสายอาชีพนี้ด้วยว่ามันเกิดขึ้นมาได้อย่างไร งานปรกติทำอะไรกัน มีเครื่องมืออะไรต้องรู้จักบ้าง และปิดท้ายที่ตัวอย่างโจทย์ทางฝั่ง Data Engineer จากบริษัท Credit OK ที่ผมทำงานอยู่
บทความนี้อาจจะยาวๆ หน่อย เพราะเขียนขึ้นมาเพื่อตกผลึกความคิดสำหรับไปบรรยายให้นักศึกษามหาวิทยาลัยเทคโนโลยีพระจอมเกล้าธนบุรีฟังในหัวข้อ Introduction to Data Engineer and Data Pipeline at Credit OK และงาน CodeMania 1010 ในหัวข้อ Serverless Big Data Architecture with Google Cloud Platform ท่านผู้อ่านสามารถเข้าไปดู Slides ได้จากลิงค์นะครับ อ่อ แล้วก็มี Video ด้วยนะ เข้าไปดูได้ที่นี่ครับถ้าสนใจ https://www.youtube.com/watch?v=BAeo0FcF6f8 ขอขอบคุณอาจารย์และทีมงานผู้จัดงานดังกล่าวที่ให้โอกาสผมให้ได้สร้างผลงานนี้ออกมาด้วยครับ
คำเตือน บทความนี้จะเริ่มจากปูความรู้พื้นๆ แล้วค่อยลึกขึ้นเรื่อยๆ โดยเฉพาะในฝั่ง Technical เพราะการตกผลึกความรู้ที่เกิดจากการใช้งานจริง ผมต้องกราบขออภัยท่านผู้อ่านที่พื้นฐานไม่แข็งแรงด้วยนะครับ ผมไม่สามารถลงลึกเล่าในทุกๆ ประเด็นได้จริงๆ เพราะเท่านี้ก็ยืดยาวมากแล้ว แต่ก็อยากให้ลองอ่านกันก่อนนะ อย่าเพิ่งรีบปิดหนีไปกันซะก่อน 555
เอาล่ะ เราอย่ามัวรีรอกันอยู่เลย มาเข้าเรื่องกันดีกว่าครับ 🙂
Big Data คืออะไร แล้วทำไม Data ถึงได้ใหญ่นัก?
ก่อนจะไปคุยกันเรื่อง Data Engineer เรามาคุยเรื่อง Data กันก่อนดีกว่าครับ
Data หรือ ข้อมูล ที่เรากำลังจะพูดถึงนี้ คือสิ่งที่ถูกเก็บเอาไว้บนคอมพิวเตอร์ที่อยู่ใน Digital Form เรียบร้อยแล้ว สามารถดึงออกมาใช้งานได้ ข้อมูลคือทุกอย่างที่ถูกสร้างขึ้นและถูกบันทึกเก็บเอาไว้ แต่ลำพังข้อมูลเองไม่ได้มีประโยชน์เท่าไหร่ จนกระทั่งมีการเอามันมาประมวลผล เอามันออกมาใช้งาน
ข้อมูลที่ถูกประมวลผลแล้วเราเรียกมันว่า Informaion หรือสารสนเทศ สามารถเอาไปใช้ประกอบการตัดสินใจต่างๆ ได้ และนี่คือคุณค่าของการเอาคอมพิวเตอร์เข้ามาใช้เก็บข้อมูล เพราะมันเก่งเรื่องการจำและการดึงข้อมูลออกมาให้มนุษย์ใช้ตัดสินใจเสียเหลือเกิน
จนมาถึงปัจจุบันนี้การเกิดขึ้นของ Artificial Intelligence (AI), Machine Learning (ML) ยิ่งทำให้ทางฝั่งการวิเคราะห์ข้อมูลขนาดใหญ่ยิ่งดู Sexy ขึ้นไปอีก เพราะว่ามันเป็นการประยุกต์ใช้ศาสตร์วิชาสถิติในการหาความสัมพันธ์ของข้อมูลจากหลายมิติ เป็นการปลดล็อคศักยภาพในการวิเคราะห์ข้อมูลในระดับที่คนมองด้วยตาก็คงทำไม่ได้อีกต่อไป
จะว่าไปแล้วข้อมูลมันมาจากไหนกันมากมาย แล้ว Big Data มันโผล่มาได้ยังไง เรามาต่อกันเลยดีกว่า
การกำเนิดขึ้นของข้อมูล
การนำคอมพิวเตอร์มาใช้ช่วยทำงาน
คอมพิวเตอร์ในช่วงต้นความจริงก็แค่อุปกรณ์ที่เอาไว้ช่วยจำช่วยประมวลผลข้อมูลต่างๆ คอมพิวเตอร์ถูกเอามาใช้ในภาคธุรกิจเพื่อเป็นผู้ช่วยในการบันทึกข้อมูล ส่งข้อมูลหากัน เพื่อลดต้นทุนและเพิ่มประสิทธิภาพในการทำงาน
การนำคอมพิวเตอร์มาบันทึกข้อมูล จึงเกิดข้อมูลขึ้นบนโลกคอมพิวเตอร์อีกมากมาย แถมข้อมูลตรงนี้ยังมีประโยชน์ตรงไปตรงมาด้วย เพราะมันเป็นข้อมูลที่เกิดขึ้นจากการทำงาน จึงสามารถเอามีวิเคราะห์การทำงานได้โดยตรง
โดยทั่วไปแล้วข้อมูลทางภาคธุรกิจนี้จะใช้งานกันภายในองค์กร แต่ความจริงเป็นแล้วปริมาณนั้นมหาศาลมาก และความเป็นจริงอาจถูกสร้างขึ้นในระบบโดยอัตโนมัติ จากห่วงโซ่การทำงานบ้าง จากอุปกรณ์ต่างๆ บ้าง (ตัวอย่างเช่นเครื่องแสกนนิ้วเข้างาน) ธุรกิจต่างๆ จึงมองหาช่องทางในการเอาข้อมูลเหล่านี้ไปสร้างมูลค่า
การเกิดขึ้นของอินเทอร์เน็ต
สมัยก่อนคอมพิวเตอร์ทำงานแบบตัวใครตัวมัน แต่ละเครื่องก็เก็บข้อมูลของตัวเองไป มีการ Copy ข้ามไปข้ามมาไม่มากนัก ส่วนใหญ่ก็เอาไว้เก็บในเรื่องของงานเป็นหลัก แต่ด้วยการพัฒนาของโลกคอมพิวเตอร์ที่เร็วจนน่าเหลือเชื่อ เราเชื่อมคอมพิวเตอร์เข้าหากัน จากในบ้าน สู่นอกบ้าน สู่ระดับโลก
อินเทอร์เน็ตจึงถือกำเนิดขึ้น มาเป็นเครือข่ายที่เชื่อมคอมพิวเตอร์ทั้งโลกเข้าด้วยกัน เริ่มเกิดเว็บไซต์ เกิดโปรแกรมสำหรับแลกเปลี่ยนข้อมูลกันระหว่างคอมพิวเตอร์จากทุกหนแห่ง
ส่งผลให้เกิดการแลกเปลี่ยนข้อมูลจำนวนมหาศาล ตามมาด้วยเทคโนโลยีสำหรับการเก็บข้อมูลเหล่านั้น และเทคนิคในการดึงออกมาใช้ประโยชน์ ตัวอย่างของผู้ที่ประสบความสำเร็จที่เห็นได้ชัดก็เหล่าบริษัท Search Engine ต่างๆ Social Network ต่างๆ กลุ่มนี้เป็นกลุ่มที่ถือข้อมูลเอาไว้เยอะมากๆ โดยอาศัยการมีอยู่ของอินเทอร์เน็ต
ผู้คนเข้าไปใช้งาน ช่วยกันสร้างข้อมูลขึ้นมา ไปเก็บไว้กับผู้ให้บริการ ให้ผู้บริการก็ได้เอาข้อมูลไปวิเคราะห์ใช้งาน เอาของกลับมาขายผู้ใช้บริการ เกิดเป็นวงธุรกิจโฆษณาออนไลน์ขนาดยักษ์ขึ้นมา
ข้อมูลจากคอมพิวเตอร์เองโดยโปรแกรมที่ทำงานโดยอัตโนมัติ
มนุษย์ไม่ได้เป็นผู้สร้างข้อมูลแต่เพียงผู้เดียว ความจริงเป็นเพียงส่วนเล็กๆ เสียด้วยซ้ำ ผู้ที่สร้างข้อมูลเยอะจริงๆ คือคอมพิวเตอร์กันเองเนี่ยล่ะ
คนเขียนโปรแกรมให้คอมพิวเตอร์ทำงานต่อยอดไปเรื่อยๆ เกิดข้อมูลขึ้นมาบนโลกอินเทอร์เน็ตขึ้นมหาศาล ตัวอย่างชัดๆ ก็เช่นการ Log จากการใช้งานโปรแกรม ผู้ใช้เข้าใช้งานที่ไหน กดปุ่มอะไร มีการดึงข้อมูลอย่างไร มี Error อะไรเกิดขึ้นจากระบบ ทุกการกระทำเหล่านี้ล้วนเป็นข้อมูลที่เกิดขึ้นอัตโนมัติโดยคอมพิวเตอร์ทั้งสิ้น
อีกตัวอย่างก็เช่นการปล่อย Bot Crawler ของเหล่า Search Engine ให้วิ่งไปตามลิงค์บนอินเทอร์เน็ต เก็บข้อมูลเว็บต่างๆ มารวมเอาไว้ แล้วเอามาใช้ค้นหา โปรแกรมเหล่านั้นวิ่งบนอินเทอร์เน็ต เวลาเปิดเว็บไหน ก็กลายเป็นการสร้างข้อมูลขึ้นทุกครั้ง ข้อมูลจึงเกิดขึ้นเยอะมากๆ ผ่านทางโปรแกรมพวกนี้
นี่ยังไม่นับพวกข้อมูลที่เกิดจากการวิเคราะห์ข้อมูล ข้อมูลที่ได้จากอุปกรณ์ทางการแพทย์ ไปจนถึงข้อมูลจาก Malware, Botnet ที่ผมว่าความจริงอาจจะเป็นผู้ผลิตข้อมูลเยอะกว่าใครเสียด้วยซ้ำ ด้านมืดของอินเทอร์เน็ตนั้นมีพื้นที่กว้างใหญ่นัก
การจัดการบริหาร Big Data
หลังจากที่ข้อมูลถูกสร้างขึ้นมาแล้ว ก็ต้องมีการจัดเก็บและบริหารข้อมูล
การเก็บข้อมูลที่เรียบง่ายและพื้นฐานที่สุดก็คือเก็บเป็นไฟล์ ได้อะไรก็เซฟลงไป เปิดขึ้นมาเห็นเลยว่าเก็บอะไรไว้ในนั้น เวลาเขียนโปรแกรมก็ตั้งชื่อให้มี Pattern หน่อย ก็สามารถเรียกข้อมูลออกมาใช้ได้อย่างแม่นยำ แต่หากมีไฟล์จำนวนมากๆ ต้องการวิเคราะห์ข้อมูลจากหลายๆ ไฟล์ ก็ต้องเปิดขึ้นมาทั้งหมด ทีนี้ก็เริ่มไม่ดีละ แทนที่เราจะเซฟทุกอย่างบนไฟล์ ฐานข้อมูลจึงถือกำเนิดขึ้นมา
ระบบฐานข้อมูลเป็นเทคโนโลยีที่เกิดจากการรวมร่างของวิชา Data Structure และ Algorithm ที่ว่ากันถึงเรื่องจะเก็บข้อมูลยังไงให้มีประสิทธิภาพ ทำยังไงให้สามารถดึงข้อมูลที่ต้องการออกมาใช้งานได้อย่างรวดเร็ว จึงเกิดเป็น DBMS (Database Management System) ให้เราใช้กันอย่างทุกวันนี้ ซึ่งในช่วงต้นเรามักจะนำมาใช้กับโปรแกรมทั่วไป อย่างเช่นระบบพนักงาน ระบบสมาชิก ต่างๆ ซึ่งงานเหล่านี้เหมาะสมกับ DB ประเภท RDBMS (Relational Database Management System) ที่เก็บข้อมูลลงบนหลายๆ ตารางแล้วมีความเชื่อมโยงกัน แต่ปัญหาคือ พอข้อมูลมันใหญ่เข้าๆ แล้ว RDBMS มันเอาไม่อยู่ จึงต้องมองหาทางออกอื่น เปลี่ยนโครงสร้างการเก็บข้อมูลใหม่ให้เหมาะสมมากขึ้น จึงเกิดเป็น NoSQL ขึ้นมา
ความจริงมีข้อมูลก็ไม่จำเป็นต้องเก็บแบบเป็น Table แล้วเรียกออกมาใช้งานด้วย SQL นี่ ก็เลยเกิดฐานข้อมูลที่ Optimize เพื่อเก็บข้อมูลและดึงข้อมูลให้มีประสิทธิภาพมากขึ้น ซึ่งก็มีหลายประเภทมาก แต่ละประเภทก็เหมาะกับงานที่แตกต่างกัน หนึ่งในคุณสมบัติที่กินขาด RDBMS เลยก็คือการแยกกันเก็บข้อมูลบนหลายๆ เครื่องพิวเตอร์ได้ แล้วมันก็ช่วยกันทำงาน ช่วยกันดึงข้อมูล มาถึงตอนนี้เราสามารถโหลด Big Data ระดับ TB ขึ้นมาใช้งานกันได้แบบสบายๆ แล้ว
แต่การจะต้องเปิด Server มาเตรียมพร้อมโหลดข้อมูลขนาดใหญ่ตลอดเวลา เอาทุกอย่างมาไว้ใน RAM ก็เป็นเรื่องสิ้นเปลืองไปจนถึงขึ้นเป็นไปไม่ได้ ข้อมูลบางอย่างมีปริมาณมาก นานๆ ใช้ที แต่ใช้ทีละเยอะๆ การเก็บแบบไฟล์ลง Disk แล้วเอาคอมพิวเตอร์หลายๆ ตัวเข้าไปช่วยกันโหลดขึ้นมาประมวลผลจึงเกิดขึ้นมา ช้าหน่อย แต่อย่างน้อยมันก็ทำงานได้ ทำให้สามารถจัดการข้อมูลใหญ่ขึ้นไปถึงระดับ PB ก็ยังได้ ระบบที่ว่านี้คือ Data Warehouse นั่นเอง ซึ่งก็มีให้บริการอยู่หลายยี่ห้อ ส่วนใหญ่จะอยู่บน Public Cloud เจ้าใหญ่ๆ
เทคโนโลยีการเก็บข้อมูลมีความซับซ้อนขึ้นเรื่อยๆ Dataset แต่ละชุดที่มีพฤติกรรมทางข้อมูลที่แตกต่างกัน ก็อาจจะควรเก็บด้วย Database คนละแบบกัน แล้วใครล่ะที่จะเลือก ที่จะโหลดข้อมูลเข้าฐานข้อมูล ที่จะดูแลความเป็นอยู่ของฐานข้อมูลเหล่านี้ คนนั้นก็คือ Data Archtect และ Data Engineer นั่นเอง
ใคร ผู้ใด คือ Data Engineer?
แน่นอน ผมเชื่อว่าคนส่วนใหญ่น่าจะรู้จัก Data Scientist อยู่แล้ว แต่ความจริงทางฝั่ง Data นี้มีผู้เล่นหลักๆ อยู่ 3 คนนะ ได้แต่ Data Engineer, Data Scientist, Data Analyst ความจริงมี Data Archtect อีกคน แต่มักจะทำงานร่วมกับ Data Engineer เนี่ยล่ะ
ก่อนจะไปลงลึกกันด้าน Data Engineering ผมขอเล่าให้ฟังถึงหน้าที่ของแต่ละคนที่กล่าวถึงให้ฟังก่อน โดยขอใช้ Journey ของข้อมูลเป็นตัวเล่าเรื่อง ทั้งสามคนนี้ล้วนมีบทบาทสำคัญทั้งสิ้น แต่ในที่นี้เราคงจะเน้นที่ทางฝั่ง Data Engineer กันหน่อยนะครับ (ขอขอบคุณภาพจาก Coraline ทำอธิบายได้ครบถ้วนดีมาก)
Raw Data
ข้อมูลเริ่มจากการเป็นข้อมูลดิบ ถูกส่งเข้ามาในระบบ (โดยมากมักจะเรียก Storage ถังแรกนี้ว่า Data Lake) ไม่ว่าจะมาเป็นไฟล์สวยๆ หรือจะมาเป็นไฟล์เน่าๆ สุดท้ายก็ต้องโหลดเข้ามาทำความสะอาดกันอยู่ดี Data Engineer จะต้องทำการศึกษาหน้าตาของข้อมูลดิบเหล่านี้ ทำความเข้าใจว่า จะโหลดเข้ามาท่าไหนเพื่อจะได้เอามาใช้งานต่อได้
Data Processing
จาก Raw Data ก็จะต้องมีการทำความสะอาดข้อมูลให้อยู่ในรูปแบบที่เอาไปใช้งานได้ Data Engineer จะเป็นคน Setup ทดลองเล่นกับข้อมูลตรงนี้คนแรก จับ Process ไปใส่ถังข้อมูล โดยการทำงานจะทำงานเป็น Batch หรือ Streaming จะต้องเซทระบบให้เหมาะสมกับลักษณะของข้อมูล หลังจากครั้งแรกใช้งานได้แล้ว ก็เริ่มเขียน Job ให้มันทำงานโดยอัตโนมัติ เกิดเป็นสิ่งที่เรียกว่า Data Pipeline ทีนี้ข้อมูลก็จะไหลเข้าระบบและถูกทำความสะอาดโดยอัตโนมัติ
Data Storage
หลังจากจัดการกับข้อมูลเรียบร้อยแล้ว ก็ต้องจัดเก็บลง Database หรือ Data Warehouse ขึ้นอยู่กับสถาการณ์และทรักยากรที่มีให้ใช้ เตรียมพร้อมสำหรับนำไปใช้งาน จะเลือกใช้ระบบเก็บข้อมูลแบบไหน ต้องสร้าง Column ออกแบบตารางยังไงให้พร้อมสำหรับการ Query ไปใช้ งานนี้ทุกคนในทีม Data จะต้องทำงานร่วมกัน
Data Modeling
มาถึงจุดของการเอาข้อมูลไปหามูลค่าเพิ่ม การนำข้อมูลที่จัดการทำความสะอาดเบื้องต้นแล้วไปใช้ต่อสำหรับการทำ Model งานนี้เป็นหน้าที่ของ Data Scientist จะเอาไปหมุนยังไง จะเลือกแบ่ง Training/testing set จำนวนเท่าไหร่ จะเลือก Algorithm อะไรมาใช้เพื่อทำ Model ของข้อมูล ก็ทำการทดลองกันไป จนกระทั่งได้ Final Model ที่จะเอามาใช้กับงานจริง จึงจะส่งกลับมาให้ทีมงานไปใช้งานกัน
Data Model Deployment in Production
หลังจาก Data Scientist สร้าง Data Model สำเร็จแล้ว จะต้องเอามันไปใช้งานจริงบน Production บอลก็จะถูกส่งกลับมาที่ Data Engineer ที่จะสร้างระบบเพื่อรัน Model ที่สร้างขึ้นมาให้ได้ และจับมันไปใส่เป็นส่วนหนึ่งใน Data Pipeline เพื่อให้มันรันได้โดยอัตโนมัติได้ด้วย ผลลัพธ์ที่ได้จาก Model ก็จะถูกเก็บเอาไว้พร้อมสำหรับการนำไปใช้งาน
Data Visualization & Report
สุดท้ายปลายทางของการใช้ข้อมูลคือการส่งผลลัพธ์จากข้อมูลออกไปใช้งาน ไม่ว่าจะเอาไปต่อกับ Application เพื่อให้ผู้ใช้ได้ใช้งานกันโดยตรง หรือจะเอามาทำเป็นรายงาน ใส่กราฟสวยๆ ให้อ่านง่ายเข้าใจง่าย หา Insight ต่างๆ เพื่อไปประยุกต์ใช้กับฝั่งธุรกิจ และการนำไปสร้างคำแนะนำสำหรับการปฏิบัติงานจริง เหล่านี้เป็นงานของ Data Analyst และ Data Scientist ครับ
ทั้งหมดที่กล่าวไปข้างบนนั้นก็คือ Data ที่ไหลอยู่ในระบบที่มีการวิเคราะห์ข้อมูลกันอย่างเป็นเรื่องเป็นราว สังเกตว่า Data Engineer เล่นบทใหญ่ในภาพเลย เพราะเขาคือคนที่ทำให้ Data มันไหลไปมาอยู่ในระบบได้อย่างราบรื่น อำนวยความสะดวกให้ทีมอื่นสามารถนำข้อมูลออกไปใช้ได้อย่างสะดวกสบาย
Fundamental Skills for Data Engineers
เรื่องต่อมาที่จะพูดถึงกันเป็นเรื่องของทักษะที่ Data Engineer ควรมี แน่นอน ส่วนใหญ่ก็เกี่ยวข้องกับ Data เนี่ยล่ะ แต่ในโพสนี้ เราจะลงไปถึงฝั่ง Data Architecture & Infrastructure ด้วย
ใครที่ชอบสะสมข้อมูล ชอบวางระบบคอมพิวเตอร์ ชอบเอาเครื่องมือมาต่อกัน เป็น Technology Geek อยู่แล้ว ก็น่าจะเข้าทางอยู่
Data Architecture
สถาปัตยกรรมข้อมูล เป็นศาสตร์ที่พูดถึงการออกแบบระบบสำหรับใช้ในการจัดการกับข้อมูล อย่างที่ได้กล่าวไปคร่าวๆ แล้วว่า การเก็บข้อมูลนั้นมีหลายรูปแบบ ทีนี้ล่ะเราจะลงมาดูกันว่า มีอะไรบ้าง แล้วแต่ละรูปแบบแตกต่างกันอย่างไร เมื่อไหร่ควรใช้อะไร
File Storage Architecture
เรามาเริ่มจากการเก็บไฟล์กันก่อน โดยรูปแบบการเก็บไฟล์บน Cloud เท่าที่ใช้กันก็มีอยู่ 3 ประเภท ดังนี้
Local Disks
อันนี้คือการเก็บลง Disk ของเครื่อง VM ที่รันโปรแกรมนั่นเอง วิธีการเก็บแบบนี้ไม่ยั่งยืน เพราะเครื่องสมัยนี้เขา Auto Scale เปิดๆ ปิดๆ กันโดยอัตโนมัติ เวลาเครื่องมันปิดไปมันกลับมาใหม่ ไฟล์ที่เคยเก็บมันหายไปหมด จึงไม่เหมาะกับการเอาไปเก็บไฟล์ที่ต้องการใช้นานๆ ในโจทย์ที่เรากำลังจะพูดถึงอยู่ อย่างไรก็ดี
ข้อดีของการเก็บไฟล์แบบนี้คือมันทำงานเร็วมาก เนื่องจากมันอยู่บนเครื่องเดียวกันเลย ดังนั้นงานที่ต้องถือไฟล์เอาไว้ Process ชั่วคราว ต้องโหลดขึ้นมาใช้บ่อยๆ การเก็บไฟล์ในรูปแบบนี้ก็เหมาะกับงานประเภทนี้อยู่นะ
ดังนั้นเวลาจะใช้งาน เราก็มักจะโหลดไฟล์ออกมาจาก Storage ประเภทอื่น (โดยเฉพาะ Object Storage) เอามาฝากไว้ก่อนในเครื่อง แล้วก็ค่อย Process จากในนั้น พอได้ผมลัพธ์ก็ค่อนเขียนไปเก็บเอาไว้ที่อื่น
Network Disks
เก่งขึ้นมาจาก Local Storage หน่อยก็คือ เอา Disk มาต่อทาง Network ภาษา Cloud เราเรียกกันว่า Persistent Storage การเก็บไฟล์ในรูปแบบนี้คือการจอง Disk จากภายนอก แล้วเชื่อมเข้ากับเครื่องที่ต้องการใช้งานผ่านทาง Network นอกจากนั้นบางกรณียังสามารถเชื่อม Disk หนึ่งตัว ลงไปในหลายๆ เครื่องคอมพิวเตอร์ได้ด้วย ทำให้หลายคอมพิวเตอร์สามารถติดต่อสื่อสานผ่านทางไฟล์กันได้เลย (แต่ก็จะเสี่ยงปัญหา race condition เด้อ)
การเก็บข้อมูลแบบนี้นิยมใช้กับโปรแกรมที่จำเป็นต้องเขียนไฟล์จริงๆ เพื่อให้เครื่อง VM ที่ใช้งานอยู่เป็นอิสระ มันจะเกิดแก่เจ็บตายไม่เดือดร้อนไปถึงข้อมูล เพราะเราได้แยกส่วนของ Storage ออกมาอยู่ในที่ปลอดภัยเรียบร้อยแล้ว
ส่วนปัญหาของ Storage ประเภทนี้ก็คือ แน่นอน มันไม่เร็วอย่าง Local Storage อยู่แล้ว และอีกเรื่องก็คือ ส่วนใหญ่เวลาใช้งานจริงเราจะ Mount แบบ File System ซึ่งมันจะใช้ได้ 1 Disk ต่อ 1 เครื่อง เท่านั้น ที่ว่าต่อหลายๆ Disk เข้าไปหนึ่งเครื่อง จะได้เป็น Storage Protocol แบบพิเศษที่ใช้ผ่านทาง Network ได้ เช่น SMB หรือ NSF อะไรพวกนี้ ซึ่งเหล่านั้นก็ไม่ได้นิยมมาใช้งานกับ Big Data อยู่ดี
Object Storage
Object Storage คือรูปแบบการเก็บไฟล์ที่ได้รับความนิยมสูงโคตรๆ หลังจากเข้าสู่ยุค Cloud เพราะอย่างที่บอกว่าพอเราจะ Scale เครื่องขึ้นมาเยอะๆ เราก็ต้องแยกส่วนของ Compute กับ Storage ออกจากกัน แล้วก็มีเจ้า Object Storage เนี่ยล่ะที่เป็นช่องทางหลักในการเก็บข้อมูล แบ่งปันข้อมูลแก่ระบบ
การทำงานของมันแทนที่จะต้องมี Disk มี Server มาจัดการไฟล์ ทีนี้ไม่ต้องแล้ว เหล่า Cloud Provider ทำ Protocol สำหรับเซฟไฟล์ สำหรับโหลดไฟล์ขึ้นมาให้ใช้งาน ข้อมูลจะไปเก็บบนเครื่องไหน ตอนนี้เราไม่สนใจ เราสนแค่ข้อมูลยังอยู่ แล้วจะดึงกลับมาใช้งานทีหลังได้อย่างไร (ใครยังไม่เห็นภาพให้จินตนาการถึงบริการฝากไฟล์อย่าง Dropbox, OneDriver, Google Drive อารมณ์คล้ายๆ กันนั่นล่ะ) เวลาคิดเงินเอาตาม Storage ที่ใช้งานเลย แล้วก็ดึงข้อมูลเข้าๆ ออกๆ บ่อยขนาดไหน
นอกจากไม่ต้องมาดูแลให้วุ่นวายแล้ว เขายังทำ Relica สำเนาข้อมูลของเราเอาไว้บนหลายๆ เครื่องคอมพิวเตอร์ ทีนี้เวลาเรามีคอมพิวเตอร์หลายๆ ตัว โหลดข้อมูลเดียวกันขึ้นมาใช้ มันจะแบ่งกันโหลดจากหลายๆ Storage Location โดยอัตโนมัติ ทำให้การส่งข้อมูลทำได้อย่างไว คือนอกจากฝั่ง Compute แยกช่วยกันทำงานแล้ว ฝั่ง Storage ก็ไม่น้อยหน้าช่วยกันทำงานด้วยเช่นกัน (งานหนักจึงตกไปอยู่กับฝั่ง Network 555)
ล้ำไปกว่านั้นอีกคือ ด้วยความรุ่งเรืองของยุค Big Data & Data Pipeline เหล่า Storage พวกนี้มี Interface ให้เราสามารถตั้งให้มันไป Trigger ให้ไปรันโปรแกรมจาก Service ต่างๆ ต่อไปโดยอัตโนมัติ เช่น เมื่อมีไฟล์ใหม่ลงไปวางแล้ว ให้เอาไฟล์นี้ไปโหลดเขาเข้าไปรันที่ Function X โดยอัตโนมัติ แล้วเมื่อ Function X เมื่อทำงานเสร็จก็เซฟผลลัพธ์เอาไว้อีกที่นึงสำหรับไว้ใช้งานต่อ พอมันอัตโนมัติแบบนี้แล้วก็เลยเกิดเป็น Data Pipeline ขึ้นนั่นเอง คือนี่มันสะดวกสุดๆ ไปเลย
ตัวอย่างบริการที่น่าจะคุ้นเคยกันก็เช่น AWS S3, Google Cloud Storage และจากค่ายอื่นๆ ที่ส่วนใหญ่จะเรียกกันว่า Object Storage
Databases Architecture
ทักษะต่อมาเป็นเรื่องการรู้จักเลือกใช้ และจัดวาง Database ให้เหมาะสม Data Engineer เป็นผู้ที่ต้องรู้และเข้าใจเรื่อง Database ดียิ่งกว่าใคร แล้วก็ต้องใช้งานเป็นอย่างเชี่ยวชาญด้วย จะต้องรู้ว่าข้อมูลแบบไหน ควรจะเก็บใน Database ประเภทใดจึงจะเหมาะสม นั่นล่ะครับคือสิ่งที่สำคัญมากๆ จะให้ดีควรจะศึกษาการทำงานของ Database แต่ละประเภทให้เข้าไปถึงไส้ในของมันเลย จึงจะสามารถมาจับงานตรงนี้ได้ดี
ถ้าจะให้เล่าปูพื้นเรื่องฐานข้อมูลซะหน่อยก็จะประมาณว่า คือเวลาเราเก็บข้อมูลเป็นไฟล์เนี่ย จะใช้งานก็ต้องเปิดไฟล์ขึ้นมา เกิดไฟล์ใหญ่ๆ กว่าจะรันโปรแกรมไปหา Record ที่เราต้องการก็ต้อง Scan มันทั้งไฟล์ มันเปลือง ก็เลยมีการดึงเจ้าไฟล์นั่นมาจัดโครงสร้างให้ดี สร้าง column ของข้อมูลขึ้นมา ปรับขนาดให้เหมาะสมและเท่าๆ กัน ทำให้แต่ละ record มีขนาดเท่ากันตายตัว สามารถกระโดดเข้าไปเรียก record ที่ลำดับใดๆ ก็ได้ในทันทีจากการคูณกันของขนาดของแต่ละ record กับตำแหน่งของ record ที่ต้องการ เหนือไปกว่านั้นอีกคือ มีการทำโครงสร้างข้อมูลแบบพิเศษให้สามารถค้นหาได้เร็วขึ้น เมื่อต้องการค้นหาข้อมูลจาก Column ใดๆ เป็นพิเศษ ก็ทำการ Index มันซะ เจ้า Database Engine เนี่ย เวลา Insert ข้อมูลลงไป มันก็จะปรับข้อมูลให้เข้ากับ Data Structure นี้ แล้วโหลดไปใส่ไว้ใน RAM เลยจ้า เวลาค้นหาก็จะเจออย่างเร็วเลยว่า ข้อมูลที่ต้องการอยู่ลำดับที่เท่าไหร่ใน Table
ที่เล่ามานี่ยัง Basic สุดๆ ความจริงมันมีการทำงานที่ซับซ้อนอีกหลายอย่างมาก คำถามก็คือ แล้วใครล่ะเป็นผู้จัดการงานพวกนี้ให้ เราเรียกโปรแกรมนั้นว่า Database Management System (DBMS) มันก็คือโปรแกรมตัวหนึ่งที่คอยดูแลข้อมูลของเรา พร้อมให้เราเขียนคำสั่งเข้าไปค้นหาข้อมูล และพ่นข้อมูลที่เราต้องการออกมาให้นั่นเอง (ความจริงแล้ว File เนี่ยมันก็คือ Database ชนิดหนึ่งที่ OS เป็นคนจัดการให้ผ่านทาง File System สารพัดแบบ)
เอาล่ะ ทีนี้มันก็มี Database หลายประเภทเหลือเกิน ผมจะขอเล่าคร่าวๆ เกี่ยวกับ Database ประเภทหลักๆ ที่เราควรจะต้องรู้จัดกันเอาไว้บ้าง ดังนี้
RDBMS (Relational DB) (SQL)
ส่วนใหญ่โจทย์ที่เรามักจะเอาคอมพิวเตอร์มาช่วยแก้ปัญหา สามารถแบ่งข้อมูลแต่ละประเภทเป็นส่วนๆ เพื่อประหยัดทรัพยากรและความง่ายในการจัดการ แล้วค่อยจับมันมีสร้างความเชื่อมโยงกันในตอนที่จะใช้งาน ด้วยเหตุนี้จึงเกิดเป็น RDBMS ขึ้นมา (บางคนเรียก SQL Database) ที่จัดเก็บข้อมูลแบบเดียวกันบน Table เดียวกัน แล้วสามารถสร้างความสัมพันธ์กันระหว่าง Table ได้ โดยใช้ภาษา SQL ในการเรียกหาข้อมูลที่ต้องการ
สำหรับเจ้าที่เป็นที่นิยมใช้งานกันก็เช่น MySQL, PostgreSQL, MS SQL, Oracle ซึ่งน่าจะเคยผ่านหูผ่านตากันมาบ้างเนอะ (ถ้ายังไม่เคยเห็นก็ดูรูปข้างบนนะ)
อย่างไรก็ดี เมื่อ Big Data มาถึงใหม่ๆ เกิด Hype ว่า RDBMS เอาไม่อยู่แล้ว Performance ไม่พอ ซึ่งมันก็จริง RDBMS เก็บข้อมูลบนคอมพิวเตอร์เครื่องเดียวเป็นหลัก พอข้อมูลใหญ่ขึ้นก็ต้องขยายเครื่องไปเรื่อยๆ แล้วมันมีจุดสิ้นสุดไง
เด็กใหม่เพิ่งหัดแว้นหลายคนก็เลยย้ายจาก SQL ไปใช้ NoSQL (ที่เดี๋ยวจะเล่าต่อไป) กันซะเยอะ ซึ่งสุดท้ายเห็นว่าตัดสินใจผิดไปกันไปเยอะอยู่ เพราะงานหลายอย่างเหมาะสมกับการใช้งานแบบ SQL มากกว่า
เอาจริงๆ ผมมองว่างานพัฒนาโปรแกรมส่วนใหญ่ก็ใช้ SQL มันเนี่ยล่ะ สะดวกที่สุดแล้ว นอกจากนั้นงานที่ทำก็ไม่ได้ Scale ใหญ่ขนาดจะต้องไปใช้ NoSQL ด้วย บางทีกลายเป็นทำให้ชีวิตยากขึ้นโดยไม่จำเป็น
ยิ่งไปกว่านั้น SQL DB สมัยนี้มันเก็บโครงสร้างข้อมูลแบบ NoSQL ก็ได้อีกต่างหาก ถ้าจะเอาจริงๆ จึงอยากบอกว่าอย่าเพิ่งเบนหน้าหนี SQL DB กันนะครับ นอกเสียจากว่าโจทย์ที่กำลังทำอยู่มัน Scale ใหญ่จริง หรือข้อมูลมันไม่ได้ซับซ้อนเป็นหลาย Table ถ้ามันสะดวก เครื่องมีพร้อมขนาดนั้น ค่อยมาพิจารณาเลือกใช้ NoSQL
NoSQL
เขียน SQL ไม่เป็นหรอ มาใช้ NoSQL ซิ จะได้ไม่ต้องเขียน SQL บร้าาา ไม่ใช่ละ!!!
NoSQL คือ Database ที่ไม่ได้เป็นแบบ RDBMS ไม่ได้เป็น Table มา Join กันเวลาจะใช้งาน ซึ่งโดยมากก็ออกแบบมาเพื่อแก้ปัญหาการเก็บและดึงข้อมูลที่แตกต่างกันออกไป คือข้อมูลบนโลกนี้มันไม่ได้ต้องเก็บแบบ Table มี Relationship กันทั้งหมดก็ได้ปะ ข้อมูล Logging ระบบงี้ มันไม่ได้มีความสัมพันธ์กัน บางทีเราแก้วางโครงสร้างการเก็บใหม่ วางวิธีการดึงข้อมูลแบบใหม่ มันสามารถรีดประสิทธิภาพ Database ออกมาได้อีกอย่างมหาศาล ความเด็ดอีกอย่างคือส่วนใหญ่สามารถแบ่งเครื่องหลายๆ เครื่องช่วยกันทำงานได้ด้วย ยิ่งทำให้มันทำงานเร็วขึ้นไปได้อีก ด้วยเหตุนี้ NoSQL จึงถูกเอามาใช้กับงาน Big Data กัน
หลักๆ แล้ว NoSQL Databases ถูกแบ่งออกเป็น 4 ประเภท ดังนี้
Document-oriented Database
จะดีขนาดไหนถ้าข้อมูลของเราไม่ต้องถูกบังคับด้วย Schema ของ Table เกิดข้อมูล User มีฟิลด์ที่ Flexible มากๆ เพิ่มๆ ลดๆ อยู่เรื่อย จะทำอย่างไร? ถ้าใช้ RDBMS เจอปัญหานี้เข้าไปบอกเลยว่าเหนื่อยแน่ แต่ถ้าเราเก็บข้อมูลในรูปแบบ JSON ได้ล่ะ แล้วก็มี DB ที่เก็บข้อมูลแบบนี้ให้ใช้งานด้วย มันคือ Document DB ที่กำลังพูดถึงอยู่นี่ล่ะ
ความสามารถพิเศษที่เพิ่มเข้ามาจากการเก็บแบบ Object หรือที่นิยมใช้กันที่สุดก็คือในรูปแบบ JSON นี่ล่ะ นอกจากนั้นเรายังสามารถเลือกให้มันทำ Index กับ Field ที่เราต้องการได้ เพื่อให้สามารถทำการค้นหาข้อมูลที่ต้องการออกมาได้อย่างรวดเร็ว
อย่างไรก็ดี มันไม่ได้ถนัดเรื่อง Relationship อย่าง RDBMS การ Join อะไรต้องทำเอง ดังนั้นเวลาออกแบบต้องพยายามดูข้อมูลที่เกี่ยวข้องกับ Record นั้นๆ เอามาไว้ด้วยกันใน Document เดียว เวลาดึงออกมาก็จะได้พร้อมสำหรับการใช้งานเลย
อีกอย่างคือ การที่บอกว่า ไม่มี Schema ไม่ได้แปลว่าจะเก็บอะไรก็ได้ ไม่อย่างนั้นก็ไม่รู้เลยซิว่าแต่ละ Record มีอะไรเก็บเอาไว้บ้าง เพียงแต่ว่า Schema มัน Flexible ด้วยตัว DB แต่คนเขียนโปรแกรมก็ยังจำเป็นต้องมีการออกแบบ Schema ที่จะใช้ในโปรแกรมแหละ ซึ่งผมมองว่ามันยิ่ง Serious มากกว่าไอ้การที่มี Schema เป็นกรอบให้เราเดินตามเสียอีก
DB ประเภทนี้ดูแล้วมีความใกล้เคียงกับ RDBMS มากที่สุดละ แล้วมัน Flexible เอามากๆ เลยด้วย สามารถย้ายมาใช้ได้ไม่ยาก ถ้างานของเราต้องการ Performance ดีประมาณหนึ่ง แล้วข้อมูลไม่ได้มีความเชื่อมโยงหากันมากนัก นี่ก็เป็นตัวเลือกที่น่าสนใจเลยทีเดียว
ตัวที่นิยมใช้กันมากที่สุดก็คือ MongoDB ชื่อดังนั่นเอง
Columnar Database
DB ตัวต่อมาที่จะขอแนะนำ เป็น DB ที่เกิดขึ้นมาเพื่อ Big Data อย่างแท้จริง มันคือ Columnar DB หนึ่งในนั้นก็คือ Big Table ของ Google Search Engine นั่นเอง (ใหญ่ขนาดไหนก็ดูจำนวนเว็บที่เราค้นได้ใน Google เอาก็ละกัน)
Concept โดยคร่าวของ Columnar DB ก็คือ เราเก็บข้อมูลตามแนว Column เป็นหลักแทนที่จะเก็บเป็น Row ลองนึกถึง RDBMS เวลาเรา Insert ข้อมูลลงไป ที่มันจะแบ่งพื้นที่ของแต่ละ Row ไว้เท่าๆ กัน เพื่อให้เวลากระโดดไปเปิดข้อมูลที่ Row ที่เท่าไหร่ก็จะสามารถคำนวณ Address ได้ แต่ทีนี้เราแยกส่วนเป็นหลายๆ Column แทน แต่ละ Column มีไฟล์ของตัวเอง เป็นอิสระของมันเอง เวลาจะค้นก็เปิดไฟล์ของ Column นั้นๆ เอาได้เลย
แล้วถ้าเกิดข้อมูลเราเป็นแบบ Sparse Matrix (แปลเป็นไทยว่าเมทริกซ์หลอมแหลม) ล่ะ ข้อมูลประเภทที่หลวม มีข้อมูลว่างเยอะมากๆ ควรจะจัดการอย่างไร ตัวอย่างโจทย์ประเภทนี้ก็เช่น การเก็บข้อมูลของ Search Engine เวลาเราเอาแกนสองแกนมาพล็อค Cross กัน เราเอาหัวแกน x เป็น keyword ส่วนหัวแกน y เป็น document_id (URL ของเว็บ) ถ้า document_id ไหนมีคำที่ตรงกับ keyword ก็จะมีค่าความสัมพันธ์ของ document และ keyword นั้นๆ ซึ่งจำนวน Keyword ในโลกนี้มีเยอะมาก และ document_id เองก็มีเยอะมากๆ เช่นกัน แต่ว่าแต่ละ document มี keywords เพียงไม่กี่คำ ดังนั้นข้อมูล 1 แถว (document_id นี้มี keywords อะไรบ้าง) จึงมี data น้อยมาก เมื่อจับมา Cross กัน จึงไม่คุ้มค่าเลยที่จะเก็บค่า NULL ลงไปด้วย ทางที่ดีไม่ต้องเก็บไปเลยเสียยังดีกว่า ลองพิจารณาภาพข้างล่างเป็นตัวอย่าง จะเห็นว่าเราเก็บข้อมูลบนเฉพาะตัวที่มีค่าก็พอ ที่เหลือถ้าหาไม่เจอก็ Default เป็น 0 ไป รู้ๆ กัน
ทีนี้จะทำยังไงกับมันดี เรียงข้อมูลใหม่ซิ เราเลือกให้เก็บ 1 ไฟล์ 1 column แทน คืองี้ Column A แต่ละ Row มีอะไรบ้าง เก็บข้อมูลพร้อมทำการ Index ตัว Adress เอาไว้ว่าเป็น Record ที่เท่าไหร่ลงไป 1 ไฟล์ ทำแบบนี้กับ Column B, C, D ไปเหมือนๆ กัน ทีนี้เวลาจะค้นหาข้อมูลจาก Column ใดๆ เราก็เปิดไฟล์ค้นหาข้อมูลที่ต้องการจากไฟล์เพียงไฟล์เดียวได้อย่างรวดเร็ว ถ้าเจอแล้วก็ค่อยเอา Address ที่ได้ไปดึงข้อมูลที่เกี่ยวข้องจาก Column อื่นๆ ออกมาด้วย ถ้า Column ไหนไม่มีก็ไม่ต้องดึงข้อมูลออกมา พอเป็นแบบนี้ การเก็บข้อมูลก็จะประหยัดพื้นที่ สามารถดึงข้อมูลออกมาได้อย่างรวดเร็ว นอกจากนั้นสามารถทำ Partition ได้ง่ายมากๆ เพราะเราสามารถเก็บข้อมูลในระดับ Column ที่ใช้ทรัพยากรน้อยกว่า แยกเป็นหลายๆ ไฟล์ได้ เวลาค้นก็ทำได้ไวกว่าแบบ Row นอกจากนั้นยังสามารถสร้าง Column ไปได้เรื่อยๆ ได้อีกด้วย เพราะมันก็เหมือนแค่การสร้างไฟล์ใหม่ แล้ว Column ที่เพิ่มขึ้นมาก็สามารถ Index แยกไม่ต้องไปรวมกับชาวบ้านได้เลย เหล่านี้คือคุณสมบัติที่ดีของ Columnar DB
ฟังดูดีไปหมด แต่ใช่ว่ามันจะเหมาะกับทุกงานที่ไหนกันเล่า ปัญหาคือถ้าจะทำ Compound Index (ค้นหาด้วย Condition ที่ใช้มากกว่า 1 column) จะทำยังไง คำตอบก็คือ ทำไม่ได้ครับ สมมุติจะค้นด้วย where A and B แบบนี้ ถ้าไม่ทำ Compound Index เอาไว้ก็จะค้นไม่ได้ เราจะต้องสร้าง Column ขึ้นมาใหม่ที่เกิดจากการร่วมร่างของ Columns ที่จะ Search แล้ว Index จึงจะค้นได้ ดังนั้นเราต้องรู้โครงสร้างที่ชัดเจนของข้อมูลก่อนจะออกแบบการเก็บ ไม่งั้นงานจะบึ้มเอาง่ายๆ นอกจากนั้น Column ที่สร้างไปแล้วอยากจะเปลี่ยนแปลงก็ทำได้ยากมากไปจนถึงเป็นไปไม่ได้ เรียกว่าเพิ่ม Column ใหม่ขึ้นมาใช้งานเลยยังจะดีกว่าให้ต้องแก้ไข รวมๆ แล้วจุดอ่อนของมันก็คือความไม่ยืดหยุ่นในการแก้ไขนั่นเอง
อย่างไรก็ตาม การเก็บแบบ Columnar DB นั้น เหมาะกับโจทย์ Map Reduce มาก มันคือการกระจายโหลดไปบนคอมพิวเตอร์หลายๆ เครื่องให้เช่นกันทำงาน แล้วรวมผลลัพธ์กลับมาให้ มันจึงเหมาะอย่างมากสำหรับการประมวลผลกับข้อมูลขนาดใหญ่ที่ต้องการ Performance สูง
Graph Database
Graph DB เป็นฐานข้อมูลที่ออกแบบมาเพื่อเก็บข้อมูลที่มีความเชื่อมโยงกันสูง โดยเชื่อมโยงกันอยู่ในรูปของกราฟที่จะเชื่อมโยงต่อกันไปเรื่อยๆ แล้วก็สามารถ Query หาข้อมูลที่ต้องการออกจากความสัมพันธ์ได้ พร้อมกับสารพัดตัวช่วยในการประมวลผลแบบกราฟ หาเส้นที่สั้นที่สุดเอย หาความสัมพันธ์รวมเอย ใช้งานกันได้โดยง่ายไม่ต้อง Implement อะไรเพิ่มเลย
อย่างไรก็ดี ส่วนตัวผมยังไม่มีประสบการณ์ใช้งาน DB ประเภทนี้เพราะยังไม่เจอโจทย์ที่ซับซ้อนพอ จึงขออนุญาตข้ามนะ 555
Key-value Database
สุดท้ายกลับสู่โลกที่แสนเรียบง่าย คือ Key-value Database (KVDB) เป็น Database ที่ทำหน้าที่เก็บข้อมูลเพียงมิติเดียวแบบ Key (ชื่อตัวชี้) และ Value (ข้อมูล) อารมณ์เหมือน Dictionary หรือ Associative array ในภาษา Programming ต่างๆ เลย
อาจฟังดูตลก ง่ายแบบนี้ Implement เองก็ได้ปะ ก็ใช่นะ แต่ความจริงแล้ว DB ประเภทนี้ถูกใช้งานเยอะมาก เพราะโจทย์สำคัญของ KV ก็คืองาน Caching นั่นเอง โปรแกรมที่ Performance ดี รับโหลด User ได้มากๆ ไม่ได้เกิดจากเวทย์มนต์ แต่มักจะเกิดจากการทำระบบ Caching ที่ดี
แล้วโลกเราทุกวันนี้ก็มักจะ Scale เครื่องในแนวนอน วิธีการจะทำให้ทุกเครื่องเห็นข้อมูลตรงกันได้ก็ต้องมี DB Server ตรงกลางแชร์ข้อมูลร่วมกันใช่ไหมล่ะ ไม่ว่าจะเป็น session ของ user ข้อมูล cache ต่างๆ ที่ผลิตขึ้นมา ต้องแชร์ถึงทุกเครื่องที่ Spawn ขึ้นมา นึกดูว่ามันจะต้อง Performance ดีขนาดไหนถึงจะ Serve ทุกเครื่องได้ คนอื่นเขาช่วยกันทำงาน แต่เจ้าไปเก่งมาจากไหนให้บริการทุกคนได้ 555 และนี่ล่ะคือหัวใจของ KV DB ก็คือเรื่องของ Performance นั่นเอง
ยี่ห้อดังที่ส่วนใหญ่ใช้กันก็จะมี Redis และ Memcache เจ้า DB พวกนี้เป็น In-memory Database คือทำงานบน Memory ล้วนๆ (แต่ก็มีการเขียนลง Disk อยู่เรื่อยๆ นะ ดังนั้นไฟดับก็ยังเอาอยู่) ด้วยเหตุนี้มันจึงทำงานได้เร็ว เร็วจัด เร็วสุดๆ
อย่างไรก็ดี แต่นี่ไม่ใช่ DB ที่เหมาะกับการเอามาทำ Big Data มันเป็นเพียง NoSQL ตัวหนึ่งที่ควรรู้จักเอาไว้ ผมจึงขอข้ามไม่ลงรายละเอียดมากนัก เอาไว้มีโอกาสจะกลับมาเล่าให้ฟังในภายหลัง เจ้าตัวนี้เล่นสนุก เหมาะกับโจทย์สำหรับการพัฒนาโปรแกรมมากๆ 😀
The Hybrid Database Architecture
แล้วทำไมจะต้องเลือก DB ขึ้นมาใช้งานแค่ตัวใดตัวหนึ่ง ในเมื่อข้อมูลแต่ละประเภทเหมาะกับการเก็บบน DB คนละแบบกัน ดังนั้นจึงจะได้เห็นการใช้ DB ผสมผสานกันเป็นเรื่องธรรมดา โดยเฉพาะ KV นี่แทบจะเห็นในทุกระบบ ส่วนทางฝั่ง Big Data ก็ต้องพิจารณาถึงขนาดข้อมูล ความบ่อยในการเรียกใช้ ความ Real-time เครื่องที่จะต้องเอามาใช้ ซึ่งไม่มีสูตรตายตัว ขึ้นอยู่กับธรรมชาติของข้อมูลแต่ละงานเลยจริงๆ และอย่าลืมศึกษาจุดแข็งจุดอ่อนของ DB แต่ละตัวกันด้วย โดยใช้ CAP Theorem เป็นพื้นฐานในการเลือกก็น่าจะพอใช้ได้อยู่
Data Warehouse
อะไรกัน ยังมีอีกหรอ ใช่! เพราะ Data Warehouse มันไม่เหมือน DB ปรกติ
จะว่าไปจริงๆ Data Warehouse มันก็คล้ายๆ กับ Database นั่นล่ะ แต่ที่มันจะต่างกันก็ตรงที่ Data Warehouse เหมือนเป็นถังเก็บข้อมูลที่เน้นเก็บข้อมู,ในระดับที่ใหญ่มากๆ ข้อมูลแบบยัดๆ ลงไปเถอะ เน้นเก็บข้อมูลขนาดใหญ่ แต่ไม่เน้นเรื่องเวลาในการดึงข้อมูลออกมาใช้งาน พูดอีกนัยคือคงจะเน้นเรื่องเขียนมากกว่าอ่านก็อาจจะไม่ผิดไปมากนัก
มันจึงเป็นการรวมร่างระหว่าง File Storage (เก็บข้อมูลราคาถูก) กับ Database (ดึงข้อมูลท่ายากได้) นั่นเอง กลายเป็น สามารถเก็บข้อมูลในราคาถูก แล้วยังสามารถดึงข้อมูลท่ายากได้ (แต่ไม่ Real-time ขนาด DBMS)
วิธีการทำงานมันเป็นอย่างนี้ แทนที่เราจะเก็บข้อมูลทิ้งๆ ขว้างๆ แบบเขียนลงไปในไฟล์รัวๆ (การเก็บแบบนั้นเราเรียกว่า Data Lake อะไรก็เก็บๆ ลงไปก่อน ไม่ต้องคิดมาก) เรามากำหนด Schema ของข้อมูลมาสักหน่อยไหมล่ะ อย่างน้อยก็รู้ว่ามี Field อะไรบ้างที่ใช้งานได้ เพื่อจะได้เอาไว้ใช้ในการ Query ด้วยภาษา SQL ได้โดยง่าย
แต่แทนที่เราจะมีทำ Index ยัดลง RAM ให้ซับซ้อนอย่าง Database ทั่วไป เราอาศัยการเก็บด้วยไฟล์เนี่ยล่ะ ราคาถูกดี แล้วก็ทำ Partition ทำ Replication เอาไว้บนหลายๆ เครื่องเอาแทน ทีนี้เวลาจะใช้งานก็แปลง Code SQL ให้เป็นคำสั่งในการเรียกข้อมูล แล้วให้เครื่องหลายๆ เครื่อง ช่วยกันเปิดไฟล์ แบ่งกันโหลดคนละนิดคนละหน่อย ช่วยกันประมวลผลเพื่อความเร็วในการทำงาน แล้วก็รวมผลลัพธ์ออกมาให้ผู้ใช้
ดังนั้นส่วนใหญ่โครงสร้างด้านล่างของ Data Warehouse มันก็คือ Object Storage นั่นเอง และประมวลผลด้วยการทำ Map Reduce เนี่ยล่ะ แล้วก็เพิ่มความสามารถให้ใช้ SQL Query ได้อย่างที่ได้กล่าวไปข้างต้น
ที่บริษัท Credit OK ของเราใช้ Big Query เป็นหลัก ราคาค่าเก็บข้อมูลถูกมาก เท่ากับ Object Storage ทั่วไป แล้วคิดเงินแพงเอาตอนดึงข้อมูลออกมาประมวลผล กด Query รัวๆ กับข้อมูลใหญ่ๆ ก็อาจจะกระเป๋ารั่วกันได้ง่ายๆ Hadoop ก็จัดอยู่ในกลุ่มนี้ได้เช่นกัน และ Cloud Provider เจ้าอื่นก็มี Data Warehouse ให้ใช้ด้วยกันทั้งสิ้น แต่ผมไม่มีประสบการณ์นัก ก็จะขอจบเอาไว้แต่เพียงตรงนี้สำหรับเรื่อง Data Storage
Cloud Computing and Infrastructure
นอกจากเรื่อง Data Storage แล้ว Data Engineer ก็ต้องมีความเข้าใจเรื่องการวาง Infrastructure ของ Cloud ด้วย เพราะเขาจะต้องเป็นคนเลือกเครื่องมือและทำ Data Pipeline
คำถามที่จะต้องตอบให้ได้ก็คือ Cloud เจ้าที่ใช้อยู่ มีเครื่องมืออะไรให้ใช้บ้าง แต่ละเครื่องมือเหมาะกับงานแบบไหน มีข้อจำกัดอะไรบ้าง และที่สำคัญคือคิดราคายังไง หลังจากดูประเภทของงานที่เราจะทำว่าเหมาะกับ Cloud เจ้าไหนได้แล้ว จึงค่อยเลือก Cloud ที่จะฝากชีวิต แล้วจึงลงเจาะลึกลงไปใช้เครื่องมือที่ต้องการ
สำหรับหัวข้อนี้ผมเคยเล่าเอาไว้แล้วใน Serverless Big Data Architecture on Google Cloud Platform @ Credit OK EP 2 สามารถไปติดตามอ่านกันได้ครับ
Programming on Data Manipulation
ทักษะสุดท้ายที่จะเน้น และเป็นทักษะที่สำคัญที่สุดเลย ก็คือคุณต้องเขียนโปรแกรมเป็น ไม่งั้นคงไม่เรียกว่า Engineer โดยหลักๆ แล้วก็ใช้งานกันอยู่ 2 ภาษา ได้แก่ SQL และ Python อาจจะดูน้อย แต่ 2 ภาษานี้จะต้องรู้และเข้าใจอย่างลึกซึ่ง เพื่อมาแก้งานที่ต้องทำกันหลักๆ ประมาณนี้
Data Ingestion
บางที Data Engineer อาจต้องสร้าง Server ขึ้น หรือไม่ก็ใช้ Service บน Cloud ตั้งขึ้นมาเพื่อรับข้อมูล Data จากลูกค้าเข้ามาสู่ระบบ แล้วก็ต้องไปเขียน Job ให้ทางฝั่งนั้นส่งข้อมูลมาให้ถึงระบบของเราด้วย ซึ่งงานส่วนนี้ใช้ Python ก็สามารถครอบคลุมจัดการได้แทบทั้งหมด
Data Cleaning
หลังจากได้ข้อมูลมาถึง Server แล้ว ก็ต้องเอามาทำความสะอาดกันก่อน ถ้าอยู่ในรูปแบบที่ไม่ดี ก็ต้องทำความสะอาดใหญ่ อาจต้องเอา Python ลงมาช่วย Process ก่อน
แต่ถ้าโชคดี ข้อมูลอยู่ในรูปแบบที่ไม่แย่มาก อาจจะโหลดเข้า Data Warehouse แล้วใช้ SQL ทำความสะอาดเอาเลยก็ได้ วิธีการใช้ SQL ทำความสะอาดนี่มักจะเขียนได้ยากกว่า แต่ใช้งานได้ง่ายกว่าเพราะมันต่อกับ Data Warehouse ได้เลย
Data Manipulation & Data Pipeline
หลังจากได้ข้อมูลที่สะอาดมาแล้วก็ต้องเอามาหมุนๆๆ แล้วก็หมุน จนกว่าจะได้ข้อมูลในแบบที่เราต้องการ
แต่เนื่องจากข้อมูลมักจะใหญ่ เวลาทำก็ต้องเขียนโปรแกรมเอา โดยทั่วไปมักจะใช้ SQL Query เอาเลยเนี่ยล่ะ แต่ถ้าเป็นงานแบบ Streaming ก็อาจจะใช้ Python เป็นตัวหมุนข้อมูลก่อนจับใส่ Data Warehouse
พอ Data ทำความสะอาดมาบ้างแล้ว ส่งเข้ามาถึง Data Warehouse แล้ว ทีนี้ก็มักจะใช้ SQL จัดการได้เลย เราอาจจะสร้าง SQL หลายอัน แต่ละอันจะตั้ง Table ขึ้นมาใหม่เป็นแต่ละ Step เรารัน SQL ที่ว่านี้ต่อกันไปเรื่อยก็จะได้ข้อมูลที่ Table ปลายทางที่พร้อมสำหรับการใช้งาน การรัน SQL ที่ต่อๆ กันนี้ก็คือหนึ่งในการทำ Data Pipeline นั่นเอง
Crontab (Task Scheduler)
สุดท้ายหลังจากเราทำ Data Manipulation จนเป็นที่ต้องการใช้ ก็ต้องกำหนดสร้างเป็นกระบวนการที่แน่นอน เพื่อให้มันทำโดยอัตโนมัติตลอดไป เกิดเป็น Data Pipeline ขึ้นมา
โดยข้อมูลที่ต้องทำ Batch Processing แบบที่ต้องมากดรันเองทั้งก้อน แทนที่จะมารันเอง เราตั้งเวลาให้คอมรันให้เอง สิ่งนี้บน Linux เราเรียกกันว่า Crontab หรือบน Windows เรียกว่า Task Scheduler ความจริงมันเรียบง่ายมาก มันก็คือตั้งเวลาว่า ถ้าถึงเวลานี้แล้ว ให้ไปสั่งให้ใครทำอะไร ถ้า Data Pipeline เรามีหลายขั้นตอนต้องรัน ก็จะต้องตั้งเวลาให้ต่อๆ กันไป
ที่บอกว่า Crontab มันเป็น Skill นั้น ก็เพราะว่าเราก็ต้องรู้ว่าเราจะรันอะไร เมื่อไหร่ แล้ว Format การตั้งเวลานี่อย่างกับภาษาต่างดาว ซึ่งจริงๆ แล้วไม่ยากหรอก อย่างไรก็ดี เพื่อความชัวร์ หรือเวลาจะตั้งเวลาที่ซับซ้อน ผมขอแนะนำเว็บ https://crontab.guru มาเป็นผู้ช่วย
What is Data Pipeline?
ต่อมาเรามาลงลึกกันเรื่อง Data Pipeline กันให้มากขึ้น ผมขออธิบายแยกคำดังนี้ Data ก็คือข้อมูล ส่วน Pipeline คือเส้นทางของการส่งสิ่งของอะไรบางอย่าง ซึ่งในวงการคอมพิวเตอร์ก็คือการทำให้มัน Process ต่อไปเองโดยอัตโนมัติ
ดังนั้นรวมกันแล้ว Data Pipeline คือกระบวนการเขียนโปรแกรม หรือเอาเครื่องมือมาต่อกัน แล้วสร้างเป็น Workflow กระบวนการ Process Data ตั้งแต่ข้อมูลเข้ามา ไปจนสิ้นสุดกระบวนการ โดยอัตโนมัติ จินตนาการเหมือนเครื่องทำลูกอมที่เราใส่น้ำตาลและกลิ่นลงไป แล้วก็ได้ออกมาเป็นลูกอมพร้อมรับประทาน
มีอีกคำศัพท์ที่น่าจะต้องรู้จักกันคือคำว่า ETL (extract, transform, load) ศัพท์คำนี้มีมานานมากแล้วล่ะ เพราะมันคือการจัดการกับ Data ที่ทางฝั่งธุรกิจต้องทำมานานแล้ว (ความจริงจะให้พิจารณาไปคอมพิวเตอร์มันก็คือโลกของ Processing กับ Data ดีๆ นี่เอง) ธุรกิจที่มาเชื่อมต่อกัน ก็ต้องมีกระบวนการแลกเปลี่ยนข้อมูลซึ่งกันและกัน ส่งข้อมูลมาหากัน (Extract) และเมื่อคนละธุรกิจอยู่คนละที่กัน ใช้ฐานข้อมูลคนละอย่างกัน เวลาจะส่งข้อมูลกันก็เลยต้องมีการเขียนโปรแกรมมาแปลงข้อมูลให้อยู่ในรูปแบบที่ตนเองเก็บ (Transform) จากนั้นจึงจะสามารถเอามาเก็บในฐานข้อมูลหลักและใช้งานได้ (Load) กระบวนการที่ว่านี้ก็เป็นหนึ่งในการทำ Data Pipeline ที่มีมานานมากแล้วนั่นเอง แล้วทุกวันนี้เราก็ยังใช้งานกันอยู่
สุดท้ายคือเรื่อง Batch กับ Steaming ที่ต้องมาทำความเข้าใจกัน เรื่องนี้ฟังดูเหมือนไม่มีอะไรมากแต่มันทำให้เครื่องมือเราเปลี่ยนไปอย่างสิ้นเชิงเลยทีเดียว ผมขอลงลึกหน่อยสำหรับสองเรื่องนี้
Batch Data Processing
การประมวลผลแบบ Batch คือการที่เรามีข้อมูลอยู่ ไม่ว่าจะอยู่ในรูปแบบของ File หรือจะถูก Structure สวยงามแล้วอยู่ใน Database แล้วเราไปรัน Script ให้มัน Process เป็นครั้งๆ ไป ส่วนมากพอ Process เสร็จแล้ว เราจะส่งต่อไปเก็บเอาไว้อีกที่เพื่อนำไปใช้งานต่อไป
ทีนี้เวลาจะทำ Data Pipeline เราก็จะเขียนโปรแกรมเป็น Script พร้อมรันเก็บเอาไว้ แล้วสั่ง Cron ให้มันมารัน Script นี้ทุกๆ ช่วงเวลาที่กำหนด มีตั้งแต่ระดับเดือนละครั้ง สัปดาห์ละครั้ง วันละครั้ง รายชั่วโมง รายนาที ขึ้นอยู่กับว่าต้องการความสดใหม่ของข้อมูลขนาดไหน
นั่นหมายความว่า ถ้า Script รันไม่บ่อย ข้อมูลก็จะค้างอยู่ที่ช่วงเวลาดังกล่าวเป็นเวลานาน แต่ถ้ารันบ่อยหน่อย ข้อมูลก็จะสดใหม่กว่าแน่นอน ซึ่งเป็นเรื่องดีกว่าอยู่แล้ว แต่ถ้ารันบ่อย ก็ต้องพิจารณาเรื่อง 2 เรื่อง
เรื่องแรก คือ Script เรารันนานขนาดไหน ถ้า Script รัน 10 นาที ไปตั้งเวลาให้รันทุกนาที ทีนี้ได้เห็น Process ทำงานซ้อนกัน เกิด Race Condition กระจาย เราก็จะเก็บข้อมูลผิดๆ ลงฐานข้อมูล
เรื่องที่สอง ทุกการ Process มีราคา มันคือการที่คุณเปิดคอมพิวเตอร์ขึ้นมาทำอะไรบางอย่าง Computing Power โดยภาพรวมของระบบก็จะถูกเอามาใช้งานที่ตรงส่วนตรงนี้ ถ้าใช้ Cloud มีงานเยอะๆ ก็อาจทำให้คุณต้องตั้งเครื่องเพิ่ม หรือถ้าเป็นพวกคิดเงินตามจำนวน Data ที่ Process พวกนี้ยิ่งชัดเลย ยิ่งรันบ่อยก็ยิ่งต้องจ่ายเงินมาก หรือถ้าสุดท้ายข้อมูลมันน้อยนิดแทบไม่มีราคาที่จะมารัน ก็ต้องพิจารณาว่า ถ้ารันไปแล้วนานมากจะมีคนเข้ามาใช้สักที จะเป็นไปได้ไหมที่เราจะค่อยให้มันรันต่อ User เปิด แล้ว User ก็รอสักหน่อยละกัน เปลี่ยนจากการทำ Pipeline มาเป็นการทำ Caching แทน
ที่เล่ามานั่นคือการทำงานแบบ Batch Processing ที่รันเป็นครั้งๆ จบไปเป็นครั้งๆ ส่วนใหญ่การทำงานพวกนี้เราจะทำกับข้อมูลขนาดใหญ่โตหรือที่ไม่ต้องการความ Real-time มากนัก
Stream/Real-time Data Processing
อีกประเภทของการ Process ข้อมูลคือแบบ Streaming หลายๆ คนอาจนึกถึงคำว่าว่า Real-time เอาไว้ในการ Process ข้อมูลแบบนี้ ซึ่งก็ถูกแหละ แต่มันก็ไม่จำเป็นจะต้อง Real-time เสมอไป เราอาจจะ Stream ข้อมูลเข้ามาแล้วเอาไว้ก่อนก่อน รอ Batch มาทำงานต่อก็เป็นไปได้ แต่ที่ทำเป็น Stream เพราะข้อมูลมันมาหน้าตาแบบนั้นไง ข้อมูล Stream ที่ผมพูดถึงนี้มักจะถูกส่งมาเป็นราย Record ทีละอันๆ เลย ต่างจาก Batch ที่จะส่งมาเป็นไฟล์เป็นก้อนใหญ่ๆ
ตัวอย่างที่ชัดเจนมากของการทำ Stream Processing ก็คือข้อมูล Log ของโปรแกรมนั่นเอง คือโปรแกรมของเราเนี่ย ถ้าเขียนให้ดี เราจะต้องให้มันจะพ่น Log ออกมาอยู่เรื่อยๆ เวลามันมีปัญหาเราจะได้มีหลักฐาน นอกจากเอาไว้ปรับปรุงโปรแกรมแล้ว เรายังสามารถใช้ Log ในการดูความเคลื่อนไหวของ User ได้ด้วย
คำถามคือเราจะเอามาแสดงบน Dashboard สวยๆ ให้เห็นแบบ Real-time ได้อย่างไร เราก็ต้องสร้าง Data Pipeline ให้มันส่งข้อมูลจาก Log เข้ามาในโปรแกรมสำหรับแสดงผลบนกราฟสวยๆ ของเรา กรณีแบบนี้ล่ะที่เราจะต้องทำ Data Streaming
กับข้อมูลอีกแบบก็เช่น เรา Stream ข้อมูล Transaction จากเครื่องคิดเงิน Cashier (POS) ของลูกค้า ข้อมูลเข้ามาทันที แต่ข้อมูลตรงนั้นเราไม่ได้จำเป็นต้องเอามาใช้ประมวลผลทันที เราอาจจะ Stream ทำความสะอาดให้เรียบร้อย แล้วโหลดเข้ามาเก็บไว้ใน Data Warehouse แยกเป็นวันๆ เอาไว้ แล้วตอนกลางคืนค่อยมารัน Batch เพื่อประมวลผลหายอดรวม หาความถี่ของการขายของในแต่ละช่วงเวลา
ทำไมยังต้องกลับมาทำแบบ Batch อีก ในเมื่อ Streaming มัน Real-time ได้?
นั่นเป็นเพราะว่า Streaming มันไม่เห็นภาพรวมไงล่ะ หนึ่งวันมี Transactions วิ่งเข้ามากี่รายการ ย้อนหลังกลับไปวันก่อนๆ การประมวลผลแบบนี้การทำ Streaming มันทำไม่ได้ไง เราจับ Stream เข้ามาก่อน จะเอาไปใช้ Real-time ก็แยกไปใช้งานก่อนเลย อีกฝั่งนึงก็เก็บรวมๆ เอาไว้ แล้วถ้าจะมี Dashboard แบบ Overview เราค่อยเอาข้อมูลที่ประมวลผลแบบ Batch เรียบร้อยแล้วมารันแล้วแสดงผลอีกที
มาถึงตรงนี้ก็น่าจะครบแล้วสำหรับพื้นฐานเรื่อง Data Pipeline ก่อนที่เราจะเข้าไปดูการทำงานของจริงกัน ซึ่งจะต้องมีการเอาเครื่องมือหมายตัวมาทำงานต่อๆ กัน ซึ่งจะต้องมีเครื่องมืออะไรบ้าง จะต้องต่อกันด้วยท่าไหน ไปเจอกันในหัวข้อต่อไปได้เลย!
Data Pipeline at Credit OK
ในบทนี้ผมจะมาเล่าถึง Data Pipeline ของบริษัท Credit OK ให้ฟังกันสักโจทย์ แต่ก่อนจะเริ่มต้นผมขอเล่าเรื่องเกี่ยวโจทย์ที่บริษัทของเราทำให้ฟังกันก่อน
รู้จักกับ Credit OK
Credit OK เราก่อตั้งขึ้นมาเพื่อแก้ปัญหาการเข้าถึงสินเชื่อของผู้คน โดยเฉพาะสินเชื่อเพื่อการทำมาหากินหรือ Working Capital เพราะการได้รับสินเชื่อเพื่อนำเงินไปต่อยอด เป็นเหมือนน้ำมันที่ช่วยธุรกิจเกิดการขยายตัว เพิ่มศักยภาพในการแข่งขัน และเป็นสิ่งที่ดีต่อทุกคนในระบบตั้งแต่ลูกค้า ผู้กู้ ผู้ให้กู้ ไปจนถึงระบบเศรษฐกิจของประเทศ
ปัญหามีอยู่ว่า การจะปล่อยกู้จะต้องมั่นใจให้ได้ว่า เงินที่ปล่อยไปจะถูกใช้อย่างถูกจุดประสงค์และได้คืนด้วย ไม่กลายเป็นหนี้เสีย ซึ่งปัจจุบันสถาบันการเงินในประเทศไทยใช้ข้อมูลเงินเดือน เครดิตบูโร เป็นแหล่งข้อมูลหลักในพิจารณาสินเชื่อ
คำถามคือ แล้วถ้าเป็นช่างรับเหมา เป็นแม่ค้า เป็นฟรีแล้นซ์ ไม่มีเงินเดือน ไม่เคยกู้สถาบันการเงิน แล้วไปขอจะได้หรือ คำตอบก็คือ ไม่ได้ เขาไม่มีข้อมูลมาประเมินความเสี่ยง มันไม่ผ่านนโยบายของการปล่อยสินเชื่อ คนกลุ่มนี้เมื่อต้องการเงินด่วน จึงต้องไปหาสถาบันการเงินประเภทอื่นที่ต้องเอาของไปค้ำ บ้านบ้าง รถบ้าง หรือถ้าไม่มีอะไรเลยก็ไปกู้หนี้นอกระบบที่ดอกเบี้ยสูงลิ่ว หาเงินมาเท่าไหร่ก็ไม่พอ วิ่งวันยิ่งเพิ่มพูน ต้องไปยืมที่ใหม่มาคืนที่เก่า ทำให้หลายๆ คนที่ตั้งใจทำงานขยันขันแข็งควรค่าแก่การได้มีชีวิตที่ดีไม่สามารถหลุดพ้นขึ้นจากหลุดจากวงจรนี้ได้
ความจริงโลกนี้ดีขึ้นทุกวัน โชคดีที่ความก้าวล้ำทางเทคโนโลยีสามารถเข้ามาแก้ปัญหาตรงนี้ได้บ้างแล้ว เพราะการประเมินสินเชื่อสามารถทำได้จากข้อมูลอื่นๆ ได้ด้วย ข้อมูลการซื้อขายสินค้า ข้อมูลการทำธุรกิจ และข้อมูลอื่นๆ อีกมากมายที่หามาได้จากแหล่งต่างๆ เชื่อมโยงเข้ากับการทำ Big Data และ Machine Learning เกิดขึ้นมาเป็น Credit Scoring แบบใหม่ที่ทำงานได้อย่างรวดเร็วและอัตโนมัติ
การทำเรื่องเช่นนี้ได้ เราจำเป็นต้องอาศัย Infrastructure สำหรับเก็บข้อมูลที่มีประสิทธิภาพ ปลอดภัย และเชื่อถือได้ นอกจากนั้นยังมีส่วนของโปรแกรมที่จะนำมารัน ทั้งการทำ Credit Scoring ไปจนถึง API และ Web Application ที่ให้ผู้ใช้บริการของเราเข้ามาใช้งาน จะต้องทำงานประสานกันได้อย่างยอดเยี่ยม
แต่ในทางตรงกันข้ามด้วยความที่เรายังเป็น Startup เกิดใหม่ แล้วต้องไปเจอกับสภาพการขาดตลาดของแรงงานบุคลากรทางด้านไอทีที่มีคุณภาพของประเทศไทย เราจึงเลือกเส้นทางการใช้คนให้น้อยที่สุด ทำ Automation ให้มากที่สุด อะไรต้องทำซ้ำๆ ทำบ่อยๆ ถ้าใช้คอมพิวเตอร์ทำได้ เราจะไม่รีรอรีบทำให้มันอัตโนมัติขึ้นมาอย่างไว แล้วโยกคนออกไปทำงานอื่นที่คอมทำไม่ได้
ตัวอย่างจริง Data Pipeline ที่ Credit OK
แน่นอนด้วยความที่เราเป็น Startup ที่มีความเชี่ยวชาญด้าน Data Analytics เราจึงมีข้อมูลไหลเข้ามาจากหลายแหล่งข้อมูล ด้วยเหตุนี้จึงต้องมีการโหลดข้อมูลเข้ามาสู่ Big Data Infrastructure ของเราบน Google Cloud Platform (GCP) ก่อน ซึ่ง GCP ก็มีเครื่องมือพร้อมมากสำหรับการทำ Big Data คือ Stack ฝั่ง Data ของเราไม่มีความจำเป็นต้องตั้งเครื่อง VM แม้แต่ตัวเดียว
Requirements & Solutions & Data Pipeline
ก่อนจะไปกันต่อ ผู้อ่านท่านใดถ้าไม่เคยใช้ Google Cloud Platform หรือไม่เคยอ่าน Post เก่าๆ ที่ผมแนะนำเครื่องมือมาก่อน ผมแนะนำให้ไปอ่านกันก่อนนะครับ ไม่งั้นเดี๋ยวจะมึน ตามไปอ่านกันได้ที่นี่เลยจ้า Serverless Big Data Architecture on Google Cloud Platform @ Credit OK EP 2
ลูกค้าของเราเป็น On-premise มีเครื่องฐานข้อมูลเก็บแยกตามสาขาอยู่ทั่วประเทศ แต่เราใช้ GCP
ข้อมูลที่จะต้องโหลดเข้ามานั้นอยู่แยกกันในแต่ละร้านค้า ไม่ได้ถูกรวมกันเอาไว้บน Cloud เราจึงต้องเขียนโปรแกรมเพื่อโหลดข้อมูลขึ้นมาบน Cloud ให้ได้
ทางแก้ปัญหาก็คือ เราตั้ง Server สำหรับรับอัพโหลดไฟล์แล้วค่อยมา Process ต่อด้านบน
ส่วนทางฝั่งลูกค้า เขียนโปรแกรมที่ทำการ Export ข้อมูลเป็น CSV ทำการ Zip แล้วก็อัพโหลดขึ้นมาที่ Path ดังกล่าว แล้วตั้งให้โปรแกรม Export + Upload นี้ทำงานโดยอัตโนมัติผ่านทาง Task Scheduler ของแต่ละร้านค้า
สรุปแล้วก็คือ ทุกๆ วัน ที่เวลาเดียวกัน ไฟล์จะถูกอัพโหลดขึ้นมาจากเครื่อง Server ของลูกค้าที่กระจายอยู่ทั่วประเทศ
เราไม่มีทีมลงไปติดตั้งโปรแกรมให้ลูกค้า ต้องอาศัยเจ้าหน้าที่ Partners ของเรา
เนื่องจากเราเข้าไปเป็น Vendor เข้าไปทำงานดังกล่าว หน้าที่การติดตั้งโปรแกรมจึงต้องเป็นของทีมของลูกค้าเองที่เขาคอยวิ่งดูแลกันอยู่แล้ว
อย่างไรก็ดี ฝั่งเราเองก็ต้องเขียนโปรแกรมให้ติดตั้งง่ายที่สุด ซึ่งด้วยเหตุนั้นจึงต้องเขียนโปรแกรมที่รันบน Windows Server ได้ คิดอยู่นาน สุดท้ายเลือกใช้ Go เพราะสามารถ Compile ไปลงบน Platform ไหนก็ได้ ซึ่งในทีนี้ก็คือ Windows แล้วเอาไปแค่ไฟล์ exe ไปลงก็พอ
จากนั้นเวลาติดตั้งก็เขียน Script ตั้งค่า Task Scheduler ให้เรียบร้อยเลย จะได้ง่ายๆ เวลาใช้งานก็กด Setup Next Next แล้วก็จบละ
Data Ingestion Server ต้องรับโหลดพร้อมกันจากลูกค้ามีร้านค้าทั่วประเทศ ผ่านช่องทางที่ปลอดภัย
ลูกค้าของเราทั้งหมดแล้วมีหลายร้อยร้านค้าทั่วประเทศ แล้วด้วยความที่ Script มันติดตั้งเหมือนๆ กัน เวลาที่รัน Scheduler ก็เลยเหมือนกัน นั่นแปลว่าลูกค้าหลายร้อยเจ้าจะ Upload ไฟล์ขึ้นมาที่ Server พร้อมกัน!
วิธีการจัดการก็ไม่ยาก แทนที่จะต้องตั้ง VM มารับไฟล์ เราก็หลบไปใช้ Serverless Service แทน ซึ่ง Solution ที่ใช้ก็คือ Google Cloud Functions ที่รับ HTTPS Request เวลามี Request เข้ามา มันจะ Spawn Workers ขึ้นมาทำงานให้เราโดยอัตโนมัติ
กล่าวคือ เวลามี Request เข้ามา ถ้าไม่มี Instance เปิดเอาไว้ มันจะถูก Hold เอาไว้ก่อนแปบนึง รอจนกระทั่งมีเครื่องขึ้นมาพร้อมรับโหลดแล้ว จึงปล่อยให้ Request วิ่งเข้าไป Process ต่อ ทีนี้ก็ไม่ต้องห่วงเรื่องโหลดเลย เพราะใช้งาน Serverless บน GCP เราสามารถ Spawn เครื่องขึ้นมาได้แบบแทบจะไม่จำกัด ส่วนไฟล์ที่ได้รับมีก็เขียนลงไปบน GCS ไปได้เลย
Data ที่ได้รับมีจะถูกโหลดต่อเข้า BigQuery โดยอัตโนมัติ
หลังจากได้ไฟล์มาลง GCS แล้ว เราจะต้องทำความสะอาดเบื้องต้นโดยอัตโนมัติด้วย Google Cloud Functions เช่นเคย
ขั้นตอนก็คือ เราตั้งให้ GCS Trigger ว่า เวลามีไฟล์ลงมาใส่ ให้ทำการส่งไฟล์ต่อไปทำงานบน Google Cloud Functions อีกตัวหนึ่ง ที่ทำหน้าที่ในการแตก Zip ทำความสะอาดข้อมูลเบื้องต้นให้อยู่ในรูปแบบที่ถูกต้องสำหรับการโหลดเข้า BigQuery แล้วก็เซฟลงไปใน Bucket ปลายทาง
เมื่อไฟล์ของเราพร้อมสำหรับโหลดเข้า BigQuery แล้ว เราก็จะตั้ง Job ของ BigQuery ให้มันโหลดข้อมูลดังกล่าวเข้าไปใน Table Raw Data ทุกวัน ซึ่งตารางนี้จะแสนเรียบง่าย เก็บทุก Column เป็น String เพื่อให้ง่ายต่อการนำเข้าข้อมูล แล้วเราค่อยไปทำความสะอาดกันต่อภายในหลัง
ในท้ายที่สุดของขั้นตอนนี้ เราก็จะได้ข้อมูลประจำของแต่ละวันเข้าไปใน Data Warehouse ของเราเรียบร้อย
Data Processing ถูกรันโดยอัตโนมัติทุกคืน
หลังจากข้อมูลของแต่ละวันถูกส่งเข้ามาใน Big Query แล้ว ทีนี้กระบวนการ Data Pipeline ที่ซับซ้อนสำหรับการนำ Data ไปสร้าง Model จึงจะเริ่มขึ้น
ในขั้นตอนแรกเลยก็คือการ Clean Data ให้อยู่ใน Schema ที่มันควรจะเป็น เนื่องจาก Table ที่ข้อมูลมาลงเอาไว้ตอนต้นเราตั้ง Column เป็น String ทั้งหมด แต่การจะเอามาใช้งานต่อได้ เราต้อง Cast Format ให้ถูกต้องเสียก่อน อะไรเป็น String Datetime Decimal เขียน SQL สำหรับแปลงข้อมูลให้เรียบร้อย พอแปลงเรียบร้อยแล้วก็จับไปใส่รวมไว้ใน Table ข้อมูลที่สวยงามของเรา เตรียมพร้อมสำหรับการนำไป Process ต่อ
แต่ขั้นตอนใช่ว่าจบแค่ตรงนี้ที่ไหนกัน ที่ได้มาก่อนหน้าคือข้อมูลสวยๆ เป็นราย Record ต่อมาเราต้องจัดการ Aggregate ข้อมูลให้อยู่ในรูปแบบของการนำไปใช้เข้า Model ทีนี้ก็เขียน SQL กันไปยาวๆ จาก Table ต่อ Table ไปเรื่อยๆ จนถึง Table ปลายทาง
จาก Table ปลายทาง ทีนี้ก็พร้อมแล้วสำหรับการนำไปใช้งาน ฝั่ง Data Engineer ก็จะนำ Code Model จาก Data Scientist ในทีมมาใช้งานใน Production เราก็ฝังมันเข้าไปเป็น Service ให้ Web Application ของเราเอาไปเรียกใช้งาน
เป็นอันสิ้นสุดการทำ Data Pipeline ของโจทย์นี้ เพราะผลลัพธ์ถูกส่งไปถึงลูกค้าเป็นอันเรียบร้อย 🙂
จบแล้วจ้าาา
ในที่สุดก็อ่านมาจนถึงช่วงสุดท้ายของบทความแล้ว (ใครแอบ Scroll ลงมาโดยไม่ได้อ่านบ้าง 555)
ผมหวังว่าบทความนี้เนื้อหาก็น่าจะครอบคลุมพอสมควรสำหรับการปูพื้นให้กับคนที่สนใจอยากทำความรู้จักกับสายอาชีพ Data Engineer นอกจากนั้นเรายังเจาะลงไปถึงเนื้อหาในเทคโนโลยีต่างๆ ที่ควรจะต้องรู้จัก แล้วยังแถมโจทย์จริงๆ ในการทำ Data Pipeline บน Google Cloud Platform ให้เป็นเคสตัวอย่างสำหรับศึกษากันไว้ด้วย
ทางบริษัทของเราก็มีการขยายทีมงานอยู่ตลอดเวลา ถ้าใครสนใจร่วมงานกันก็สามารถติดต่อเข้ามาได้นะครับ สามารถดูประกาศรับสมัครทีมงานได้ที่นี่ https://jobs.blognone.com/company/creditok หรือถ้ามีความสามารถพิเศษ สนใจทางด้านใดเป็นพิเศษ อยากร่วมงานกัน ก็ติดต่อตรงมาที่อีเมล์ [email protected] ได้เช่นกัน (ไม่ต้องดูประกาศหรอกความจริง ไม่ค่อยได้เข้าไปอัพเดทกันสักเท่าไหร่ 555)
สำหรับท่านใดที่มีคำถาม มีข้อเสนอแนะ เห็นพิมพ์คำผิด (ที่น่าจะมีเยอะมาก) ก็สามารถ Comment พูดคุยกันได้ที่กล่องข้างล่างนะครับสบายๆ หรือถ้าอยากติดตามผลงานก็กดปุ่ม Like Fanpage ที่หัวเว็บได้เลยครับ มีอะไรเล่าให้ฟังอีกเยอะ 555
สำหรับบทความนี้ ก็ขอจบเอาไว้แต่เพียงเท่านี้ สวัสดี และขอทุกท่านได้มีความสุขกับการทำ Automation นะครับ 🙂
