หมวดหมู่: Big Data

ดร.จิรพันธ์ แดงเดช ของกลุ่ม Thailand SPIN ชวนผมไปบรรยายงาน “AI/Big Data เรื่องบ่น และหนทางออก” ในวันที่ 22 พฤศจิกายนนี้ ที่อาคาร Software Park ผมก็ไม่แน่ใจว่าผู้จัดเห็นผมเป็นคนชอบบ่นมากๆหรือเปล่า เลยให้ผมขึ้นบรรยายเป็นคนแรก จริงๆแล้วผมสัมผัสกับงานทางด้าน Big Data มาหลากหลายด้านทั้งงานสอน อบรม ให้คำปรึกษา ขึ้นเวทีบรรยาย ติดตั้งระบบ และเจอลูกค้ามากมาย รวมถึงมีบทบาทในฐานะของบอร์ดและผู้บริหารของหน่วยงานทั้งภาครัฐและเอกชนหลายแห่ง ก็เลยมีเรื่องบ่นมากมายอย่างที่ผู้จัดเชิญผมนั้นละ แต่บ่นแล้วจะมีหนทางออกไหมนั้นก็คงต้องให้วิทยากรท่านอื่นๆและผู้ฟังทุกท่านช่วยกันแลกเปลี่ยนความคิดเห็นร่วมกัน ทั้งนี้ในด้านของ Big Data ผมเห็นประเด็นต่างๆที่น่าบ่นดังนี้

• เพ้อเจ้อ: ผมขึ้นมาอย่างนี้หลายท่านอาจตกใจ แต่จริงครับเรื่องที่น่าบ่นที่สุดคือการขาดความรู้ความเข้าใจเรื่อง Big Dataโดยเฉพาะผู้บริหารที่ต้องการทำโปรเจ็คด้านนี้ บางครั้งอยากทำเพราะตามกระแส แต่ก็ไม่ทราบว่าคืออะไร มอบหมายให้ฝ่ายไอทีไปจัดการบ้าง ลงทุนหาเครื่องมือมาทำบ้าง คิดว่าเริ่มต้นคือไปกำหนดทำ Data Catalog หรือ Data Warehouse แต่ไม่ได้มีกลยุทธ์ที่จะเข้ามาแก้ไขปัญหาอะไรที่ชัดเจน ที่หนักกว่าคือไม่มีข้อมูลจริงๆ และบ่อยครั้งก็ชอบโม้ไปว่าหน่วยงานได้ทำ Big Data เสร็จแล้ว ซึ่งจุดนี้น่ากลัวที่สุดเพราะแทบยังไม่ได้ทำอะไรแต่คิดว่าทำเสร็จแล้ว แต่โชคดีที่หลังๆก็เริ่มเห็นหลายหน่วยงานที่ผู้บริหารมีความรู้ความเข้าใจมี่ดีขึ้นมากแล้ว ทำให้เห็นทิศทางที่ดีขึ้นและเริ่มมีการนำ  Big Data มาใช้ได้จริง
• ไม่มีข้อมูล: ปัญหานี้เจอมาในหน่วยงานหลายแห่ง ที่มีข้อมูลน้อยมากระดับแสนเรคอร์ด และขาดข้อมูลที่เข้ามาอย่างต่อเนื่อง สุดท้ายก็ไม่สามารถไปวิเคราะห์อะไรได้ โดยส่วนมากจะเจอปัญหาดังนี้
  • มีข้อมูลเพียงเล็กน้อย: นอกจากนี้อาจมีปัญหาที่ตามมาก็คือข้อมูลไม่อัพเดท เพราะข้อมูลแทบไม่มีการเคลื่อนไหวอะไรเลย ส่วนใหญ่ก็จะสามารถทำได้เพียงรวบรวมข้อมูลมาแสดง Dashboard อาจไม่สามารถไปทำ Prediction อะไรมากมายนัก
  • มีข้อมูลกระจัดกระจายแต่ยังไม่สามารถรวบรวมข้อมูลได้: ปัญหาแบบนี้ยังพอแก้ไขได้ โดยการพยายามรวบรวมข้อมูลที่เป็น Silo เหล่านี้เข้าสู่ DataLake
  • มีข้อมูลกระจัดกระจายแต่ไม่สามารถขอมารวบรวมได้: ส่วนใหญ่เราจะเจอปัญหาของการหวงข้อมูลของหน่วยงานต่างๆทั้งภายในและภายนอก ถ้าจะเปิดให้ใช้ก็อาจแค่ให้ดีงข้อมูลแบบ API เป็นรายเรคอร์ดไม่สามารถเอาข้อมูลทั้งหมดมาวิเคราะห์ได้ ซึ่งทำให้ยากต่อการวิเคราะห์ข้อมูลโดยการใช้ Big Data สุดท้ายก็ทำได้แค่ทำรายงานสรุป Dashboard เป็นเรื่องๆไป
• ขาดบุคลากร: เรื่องของ Big Data มีแนวคิดที่แตกต่างจากการทำ Database หรือ Data warehouse  แบบเดิมๆ จะต้องเรืยนรู้หลักการใหม่ๆเช่นการทำ DataLake  หลักการของ ELT  แทนที่ ETL แบบเดิม การพัฒนาโปรแกรมโดยใช้ Python, R, Hadoop หรือ Spark ตลอดจนเครื่องมือรูปแบบใหม่อื่นๆ รวมถึงการทำ Data Science
• ขาดเครื่องมือ: เมื่อพูดถึงการทำโปรเจ็ค Big Data ถ้าจะต้องลงมือทำจริงในองค์กรและมีข้อมูลขนาดใหญ่ อาจต้องติดตั้งที่ใช้งบประมาณนับสิบล้านบาท  ยกเว้นจะใช้ Public Cloud ที่ค่าใช้จ่ายเริ่มต้นอาจถูกกว่า แต่องค์กรส่วนใหญ่ก็ไม่ได้จัดสรรงบประมาณมากนัก และไม่อยากนำข้อมูลขึ้น Public cloud ทำให้ไม่สามารถทำโครงการได้อย่างแท้จริง
• ไม่มีการนำมาใช้งานจริง: เมื่อมีการทำ Dashboard หรือการวิเคราะห์ต่างๆแล้ว บ่อยครั้งจะพบว่า ผู้ใช้ก็ยังเป็นทีมไอทีที่ทำโปรเจ็ค องค์กรไม่ได้มีวัฒนธรรมในการใช้ข้อมูลในทุกภาคส่วน ซึ่งอันนี้ก็อาจเป็นเพราะคนในบ้านเราไม่ได้คุ้นเคยกับการใช้ข้อมูลมากนัก เราไม่ค่อยใช้ตัวเลขในการตัดสินใจ ดังนั้นจึงจำเป็นต้องสร้างวัฒนธรรมองค์กรให้ใช้ข้อมูลมาในการตัดสินใจ มิฉะนั้นแล้วสิ่งที่ทำมาก็ไม่ได้เกิดการใช้งานจริง

จากที่เล่ามาทั้งหมดนี่ คือตัวอย่างที่จะบ่นให้ฟังในงานวันที่ 22 พฤศจิกายนนี้ ถ้าท่านใดสนใจจะฟังผมบ่นเพิ่มหรือฟังวิทยากรท่านอื่นๆบ่น ก็สามารถลงทะเบียนได้ที่  >> Eventbrite  โดยไม่มีค่าใช้จ่ายใดๆ

ธนชาติ นุ่มนนท์

IMC Institute

ผมมักจะเจอคำถามบ่อยๆว่าจะทำโปรเจ็ค Big Data  ควรจะใช้เทคโนโลยีอะไรดี เลือกซื้อจากรายไหนดี จริงๆแล้วการจะตอบคำถามนี้คงจะต้องพิจารณาจากหลายปัจจัยตั้งแต่คำถามว่า

1. ต้องการนำมาใช้ในโครงการใด Use Caseใด ซึ่งคำตอบนี้จะมีผลต่อสถาปัตยกรรมที่ต้องมาพิจารณาในการออกแบบ ตัวอย่างเช่น
   • ข้อมูลมี Volume มากเพียงใด เพราะหากมีขนาดมากกว่า 100 TB ก็อาจเป็นปัญหา
   • ข้อมูลมี Velocity ที่จะเข้าเท่าไร เพราะถ้ามีขนาดต่ำกว่า 100 K ต่อวินาทีก็อาจรองรับไหว
   • ข้อมูลมี Variety เพียงใด มีทั้ง Structure หรือมี semi-structured และ Unstructured ด้วย
   • ต้องการประมวลผลแบบใด Batch หรือ Realtime
2. เราต้องการจะออกติดตั้ง Big Data Platform ที่ใด
   • Cloud หรือ  Data Center
3. เราจะเลือกสถาปัตยกรรมแบบใด
   • ติดตั้งเอง หรือ PaaS  ที่เป็น Big Data as a Service
   • ค่าจ่ายแบบ Pay as you go หรือ Fix
   • ระบบแบบ Couple หรือ Decouple
4. เราได้สื่อสารแผนงานของเราชัดเจนเพียงใด
5. เราได้วิเคราะห์อุปสรรคต่างๆได้ดีเพียงพอแค่ไหน

รูปที่ 1 องค์ประกอบของสถาปัตยกรรมระบบ Big Data

สถาปัตยกรรมระบบ Big Data ส่วนใหญ่ก็จะประกอบไปด้วยองค์ประกอบ 4 อย่างก็คือ

• Ingestion คือส่วนที่นำข้อมูลเข้าที่อาจเป็นแบบ Batch หรือ Streaming
• Storage คือส่วนที่เก็บข้อมูลทั้งนี้คืออยู่กับขนาดและชนิดของข้อมูลที่ต้องการเก็บ
• Processing คือส่วนในการประมวลผลต่างๆทั้งการทำ Data Cleanising, การทำ Modelling  หรือ การทำ Data Science ซึ่งการประมวลผลมีทั้งแบบ Batch หรือRealtime
• Visualisation คือส่วนในการแสดงผลข้อมูล

ในปัจจุบันก็มีเทคโนโลยีด้าน Big Data หลากหลายที่สามารถนำมาใช้ได้ (ดังแสดงในรูปที่ 2) แต่ละเทคโนโลยีมีความเหมาะสมที่แตกต่างกันทั้งนี้ขึ้นกับ Use Case ของโครงการที่ Big Data จะนำไปใช้ โดยต้องวิเคราะห์ถึงขนาดของข้อมูล ความถี่ของข้อมูล ความต้องการประมวลผล ความปลอดภัยของข้อมูล และงบประมาณ

รูปที่ 2 ตัวอย่างเทคโนโลยีด้าน Big Data

ทั้งนี้การเลือกใช้เทคโนโลยี Big Data มีหลักการที่สำคัญสองประเด็น

• ควรจะสร้างระบบที่แยก (Decoupled) กันระหว่างระบบ Storage และ Processing ซึ่งอาจต้องใช้เครื่อง Server Cluster ที่ต่างกัน
• การเลือกใช้เทคโนโลยี Big Data ถ้าต้องติดตั้งใน Data Center เองก็ไม่ควรเกิน 4 เทคโนโลยี แต่ถ้าเป็นบริการบน Cloud ก็ไม่ควรเกิน 7 เทคโนโลยีทั้งนี้ก็เพื่อง่ายต่อการบำรุงรักษา และลดความซับซ้อนของระบบ

เพื่อให้เห็นวิธีการเลือกสถาปัตยกรรม ผมขอยกตัวอย่างกรณีศึกษาของลูกค้ารายหนึ่งที่ทางทีมงานของ IMC Institute เข้าไปดำเนินการให้ โดยมีวิธีคิดดังนี้

Business Use Case มีข้อกำหนดต่างๆดังนี้

• ลูกค้าต้องการรวบรวมข้อมูลจากแผนกและหน่วยงานต่างๆที่มีมาตั้งแต่ปี 2553  ที่ปัจจุบันเป็นแบบ Siloให้อยู่ในรูปแบบของ Data Lake เพื่อใช้ในการวิเคราะห์ข้อมูลทั้งแบบ Descriptive และ Predictive
• Volume: ข้อมูลมีขนาดประมาณ 1 TB และมีจำนวนประมาณ 1,000 ล้านเรคอร์ด
• Velocity: จะมีข้อมูลที่นำเข้าใหม่ในเพียงเดือนละครั้งจำนวนประมาณ 5 ล้านเรคอร์ด
• Variety: ข้อมูลมีหลากหลายรูปแบบทั้งที่เป็น Database, CSV, SPSS หรือ ข้อความ
• Processing: ข้อกำหนดในการประมวลผลไม่ได้เป็นแบบ Realtime แต่ขอให้สามารถแสดงผลข้อมูลหลายร้อยล้านเรคอร์ดได้ภายในไม่เกินหนึ่งนาที
• งบประมาณ:  ลูกค้ามีงบประมาณจำกัดต่ำกว่า 8 ล้านบาท

Technology:  ทีมงานได้ตัดสินใจเลือกตามเงื่อนไขต่างๆดังนี้

• Infrastructure:  เมื่อเปรียบเทียบระหว่างการทำระบบ On-Premise หรือ Private Cloud บน Data Center กับการใช้  Big Data as a Service ของ Public Cloud รายต่างๆแล้ว ทีมงานเลือกใช้ Google Cloud Platform (GCP) ด้วยเหตุผลเรื่องค่าใช้จ่ายที่ถูกกว่า ความคุ้นเคยของทีมงาน ความง่ายต่อการใช้งาน และสามารถเริ่มทำได้ทันทีเพราะค่าใช้จ่ายเริ่มต้นต่ำ
• Ingestion: เนื่องจากการนำเข้าข้อมูลเป็นแบบ Batch ข้อมูลมีขนาดเล็กและไม่มีความซับซ้อนมากนัก ทีมงานก็เลยเลือกที่จะใช้วิธี Upload ผ่าน Command Line  ของ GCP
• Storage:  ทีมงานเลือกใช้ Google Cloud Storage แบบ Multi-Regional ในการเก็บข้อมูลที่หลากหลาย เนื่องจากราคาถูกและสามารถ Scale ได้ง่าย โดยจะแบ่งข้อมูลออกเป็นสามโซนคือ Raw Zone, Trusted Zone และ Refined Zone นอกจากนี้ยังใช้ Google BigQuery ในการเก็บข้อมูล Structure ที่ผ่านการ Cleansing จาก Raw Zone มาแล้วเพื่อความรวดเร็วในการประมวลผล
• Processing: ทีมงานเลือกใช้ Google DataProc ที่เป็น Hadoop as a Service มาใช้ในการประมวลผล โดยจะสร้าง Cluster เมื่อมีการประมวลผล และค่าใช้จ่ายจะเป็นแบบ Pay as you go ทำให้ประหยัดค่าใช้จ่าย โดยใช้เทคโนโลยีต่างๆในการประมวลผลดังนี้
  • Data Cleansing: การประมวลผลข้อมูลใน Raw Zone เลือกใช้ Spark จาก DataProc โดยเลือกเขียนโปรแกรมเป็นภาษา Python
  • Data Transformation: การแปลงข้อมูลหรือการสร้าง Table ใหม่ ทีมงานเลือกใช้ Hive และ Spark จาก DataProc
  • Machine Learning: ในการทำ Predictive Analytics ทีมงานเลือกใช้ Spark MLlib
  • Query: สำหรับการ Query ข้อมูลขนาดหลายร้อยเรคอร์ดและเชื่อมโยงกับ Visualisation Tool ทีมงานเลือกใช้ Google BigQuery ที่มีความรวดเร็วในการประมวลผล
• Visualisation: ทีมงานเลือกใช้ Power BI ด้วยเหตุผลเรื่องงบประมาณและความสวยงามของกราฟที่ได้

จากตัวอย่างที่ยกมาจะพบว่าการออกแบบ Big Data Archicture และการเลือกใช้เทคโนโลยี ความสำคัญอยู่ที่ต้องเริ่มต้นจาก Business Use Case ไม่ใช่เริ่มจากเทคโนโลยี

ธนชาติ นุ่มนนท์

IMC Institute

เอกสารอ้างอิง

1.) AWS Big Data Demystified #1.2 | Big Data architecture lessons learned

วันก่อนเขียนเรื่องการทำ Big Data Platform บน Hybrid/Multi Cloud หลายๆท่านก็อาจสนใจต่อว่า แล้วเราควรเลือกโซลูชั่นของรายไหน จริงๆผมเองก็ไม่มีคำตอบที่ชัดเจน แต่หากเราแบ่งกลุ่มกันก็จะเห็นว่า มีรายที่ทำ On-Premise คือ  Oracle, IBM, SAP, Cloudera, Hortonworks, MapR, Huawei เป็นหลัก แต่กลุ่มเหล่านี้ก็มุ่งที่จะพัฒนาโซลูชั่น On-Cloud เสริมมา เพื่อสร้างเป็น Hybrid/Multi Cloud  ส่วนรายที่เป็นระบบ On-Cloud อย่าง AWS, Google, Azure หรือ Alibaba ก็พยายามทำให้โซลูชั่นของตัวเองทำงานร่วมกับระบบ On-Premise หรือ Cloud Provider รายอื่นได้

รูปที่ 1 Magic Quadrant for Data Management Solutions for Analytics ของ Gartner

หากจะเปรียบเทียบ Big Data Solution ต่างๆ ผมแนะนำให้ไปดูรายงาน Gartner เรื่อง Magic Quadrant for Data Management Solutions for Analytics ที่ออกมาเมื่อเดือนมกราคม 2519 ซึ่งได้ทำการเปรียบเทียบโซลูชั่นต่างๆจำนวนมาก และสรุปเป็น Magic Quadrant ดังรูปที่ 1 ทั้งนี้ผมได้ทำตารางสรุปข้อมูลที่ Gartner รายงานไว้ว่าแต่ละรายมีโซลูชั่นใดบ้าง และมีจุดแข็งและข้อพึงระวังอย่างไร ดังตารางข้างล่างนี้

ธนชาติ นุ่มนนท์

IMC Institute

วันก่อนไปบรรยายมีคนถามผมว่าจะติดตั้งระบบ Big Data ในองค์กร ใช้โซลูชั่นของใครดี จะทำเป็นระบบ On-Premise หรือควรใช้ Public Cloud

คงต้องอธิบายว่าระบบ  Big Data จะประกอบไปด้วยเทคโนโลยีอยู่ 4 ด้านคือ  Data Ingestion/Collection, Data Storage, Data Processing และ Data Visualisation และหลักการทำ  Big Data คือเน้นการสร้าง Data Lake ที่เราจะต้องนำข้อมูลดิบที่มีปริมาณมหาศาลมาเก็บไว้ในระยะยาว ซึ่งอาจเป็นข้อมูลธุรกรรมต่างๆ ข้อมูล IoT ซึ่งข้อมูลเหล่านี้มีปริมาณเห็นหลายสิบล้าน หรือจำนวนหลาย TeraByte ทั้งนี้ขึ้นอยู่กับประเภทธุรกิจ บางธุรกิจเช่น Telecom อาจมีบริมาณเป็นหลาย TB ต่อวัน หรือธนาคารก็อาจเป็นจำนวนพันล้านเรคอร์ดต่อปี

การที่ต้องเก็บข้อมูลจำนวนมากและการเก็บข้อมูลต้องพร้อมที่จะประมวลผลในเวลารวดเร็ว จึงเป็นความท้าทายที่ต้องหา Storage ขนาดใหญ่ ซึ่งต้องขยายได้อย่างรวดเร็ว มีราคาถูก และมีความเสถียร ก็เลยเป็นไปได้ยากที่เราจะพัฒนาระบบ Hadoop แบบ On-Premise แล้วในอนาคตต้องขยายระบบไปเรื่อยๆเพื่อจะเก็บข้อมูลทั้งหมด ดังนั้นแนวทางที่ดีคือการเก็บข้อมูลขนาดใหญ่ไว้บน  Public Cloud Storage ที่จะตอบโจทย์เหลือราคาความเสถียรและขนาดการเก็บได้ดีกว่า เช่นการใช้ Amazon S3, Azure Data Lake Storage (ADLS) และ Google Cloud Storage เป็นต้น  แล้วก็นำข้อมูลที่จะเป็นที่อาจมีความสำคัญอย่างมากที่ไม่อยากนำไปเก็บออกนอกองค์กรมาใส่ไว้ใน Storage ของ Hadoop HDFS ที่เราอาจติดตั้งระบบ Cluster ขนาดเหมาะสมไว้ในองค์กร (On-Premise) แต่ไม่จำเป็นต้องเป็นระบบที่ใหญ่มากนัก

ในแง่ของการประมวลผลข้อมูล (Data Processing) เราสามารถที่จะใช้ Hadoop On-Premise มาทำการประมวลโดยผ่านเทคโนโลยีอย่าง Spark, Hive หรือเครื่องมืออื่นๆ แต่ความท้าทายก็อาจจะอยู่ที่เมื่อต้องการประมวลผลข้อมูลที่ใหญ่มากๆเช่น การทำ Machine Learning กับข้อมูลเป็นสิบหรือร้อยล้านเรคอร์ด กรณีนี้เราจำเป็นต้องการระบบ Cluster ที่มี CPU จำนวนมากซึ่งระบบ On-Premise ไม่สามารถจะรองรับได้ จึงอาจต้องใช้ Services ของ Public Cloud เช่น  AWS EMR, Google DataProc, Azure HDinsight ที่เราสามารถกำหนด CPU จำนวนมากได้ หรือบางครั้งก็อาจใช้บริการประมวลผลอื่นๆที่มีอยู่บน Public cloud ซึ่งสามารถช่วยในการประมวลผลอย่างรวดเร็วได้อย่างเช่น Google BigQuery, Azure ML, AWS Athena ก็จะยิ่งทำให้ได้ประสิทธิภาพดีขึ้น ข้อสำคัญการประมวลผลแบบนี้ราคาขึ้นอยู่กับการเวลาในการใช้งานซึ่งถูกกว่าติดตั้งระบบ On-Premise ขนาดใหญ่มากๆ

ในด้านการดึงข้อมูลเข้า Storage  (Data Ingestion) ก็คงจะต้องพิจารณาว่าต้นทางของข้อมูลอยู่ที่ใดและ Storage อยู่ที่ใด ถ้าข้อมูลที่จะดึงเข้าจำนวนมากอยู่ในองค์กรก็ควรที่จะตั้งระบบแบบ On-Premise หรือ ถ้าอยู่ภายนอกก็อาจใช้ Public cloud service ส่วนการเลือกใช้เครื่องมือด้าน Visualisation ที่อาจต้องมีทั้งสองระบบ โดยระบบ On-Premise ใช้กับการแสดงข้อมูลภายในองค์กรผ่าน Desktop ส่วนกรณีแสดงผลผ่านเว็บหรืออินเตอร์เน็ตอาจพิจารณาใช้ Public cloud โดยรูปที่ 1 ได้สรุปแนวทางการทำ Big Data Platform โดยทาง Hybrid/Multi Cloud ตามที่อธิบายไว้ข้างต้น

รูปที่ 1 ตัวอย่างระบบ Big Data  บน Hybrid/Multi Cloud

แนวทางการติดตั้งระบบ  Big Data ที่ดีควรเริ่มจากการทำบน Public Cloud เพื่อความรวดเร็วในการดำเนินงานและลดค่าใช้จ่าย เมื่อเริ่มเห็นผลก็อาจมีการติดตั้งระบบ On-Premise ที่มีขนาดเหมาะสม แล้วมีการ Transfer ข้อมูลไปมากันทั้งสองระบบ โดยเน้นให้ Public cloud เก็บข้อมูลขนาดใหญ่และประมวลผลขนาดใหญ่ ส่วน Hadoop On-Premise เน้นข้อมูลที่สำคัญและต้องการประมวลผลในองค์กร ซึ่งแนวโน้มของผู้ผลิตในระบบ On-Premise ต่างๆเช่น Cloudera หรือ Hortonworks ก็เน้นไปสู่ Hybrid/Multi Cloud ดังแสดงตัวอย่างดังรูปที่ 2

รูปที่ 2 ตัวอย่างโซลูชั่นของ Hortonworks ทีเน้น Multi-Cloud

สุดท้ายผมได้ทำตารางข้างล่างมาเปรียบเทียบระหว่างระบบ On-Premise กับ Public Cloud Service ต่างๆมาให้เพื่อพิจารณาเลือกใช้บริการต่อไป

ธนชาติ นุ่มนนท์

IMC Institute

ครั้งก่อนผมเขียนบทความเรื่อง AI คือหัวใจสำคัญของการทำ Digital Transform และข้อมูลคือองค์ประกอบหลักของ AI   พร้อมทิ้งท้ายไว้ว่าจะเขียนเพิ่มเติมในตอนถัดไปว่าเราจะเอาข้อมูลมาจากไหน ซึ่งถ้าเราจะพิจารณาถึงนิยามของ Big Data ว่ามี 4 V คือ Volume, Variety, Velocity และ Veracity ประกอบกับพิจารณาการเปลี่ยนแปลงของสรรพสิ่งต่างๆที่จะต้องมีการเคลื่อนไหวตลอดเวลา การเคลื่อนที่ การงาน การศึกษา สุขภาพ หรือ การทำธุรกรรม แลัวเราจะเห็นได้ว่า Big Data ถ้ามีเพียงแต่ข้อมูลขนาดใหญ่ (Volume) ก็อาจจะไม่เพียงพอต่อการวิเคราะห์พฤติกรรมหรือเข้าใจในสถานการณ์ปัจจุบัน เพราะองค์ประกอบที่สำคัญสุดประการหนึ่งของ Big Data กลับกลายเป็นเรื่องของ Velocity ที่เราจะต้องมีข้อมูลที่เข้ามาอย่างต่อเนื่อง ตัวอย่างเช่นเราต้องมีข้อมูลที่เข้ามาอย่าต่อเนื่องเพื่อทราบ

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

ซึ่งหากเราจะพิจารณาเทคโนโลยีที่จะได้มาซึ่งองค์ประกอบด้าน Velocity ของ Big Data เราอาจเห็นอยู่สี่ประเภทคือ

• Social media ก็คือการที่ผู้คนเข้าไปโพสต์ข้อมูลต่างๆ เข้าไปค้นหาข้อมูล หรือสื่อสารกันออนไลน์
• Mobile ก็คือการที่ผู้คนเข้าไปใช้โทรศัพท์เคลื่อนที่ และมีการส่งข้อมูลมายังผู้ให้บริการ (Telecom operator) อย่างต่อเนื่อง
• Internet of things คือการที่สรรพสิ่งต่างๆเชื่อมต่ออยู่กับระบบอินเตอร์เน็ต และมีการส่งข้อมูลเข้ามายัง IoT Platform อย่างอัตโนมัติ เช่น  wearable device หรือ smart device sensor
• Transaction คือข้อมูลที่มีการทำธุรกรรมแล้วถูกบันทึกในรูปดิจิทัล เช่นข้อมูลจาก Point of Sales (POS)  ของร้านค้า, ข้อมูล CRM, ข้อมูล ERP หรือข้อมูลธุรกรรมการเงินที่มีการบันทึกอย่างต่อเนื่อง

รูปที่ 1 ข้อมูลทีมีองค์ประกอบ Velocity สำหรับการสร้าง Big Data

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

รูปที่ 2  วัฎจักรของข้อมูล AI และรายได้ [จาก AI Frontiers : The Era of Artificial Intelligence, Kai-Fu Lee]

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

• บริษัทด้านอินเตอร์เน็ตขนาดใหญ่ อย่าง Facebook, Google, Instagram, Twitter บริษัทเหล่านี้มีข้อมูลที่มี Velocity จำนวนมหาศาลที่ถูกป้อนเข้ามาอย่างต่อเนื่องตลอดเวลาโดยผู้ใช้ แต่ข้อมูลเหล่านี้ส่วนใหญ่เป็นของบริษัทต่างชาติ
• บริษัทผู้ให้บริการโทรศัพท์เคลื่อนที่ อย่าง AIS, DTAC หรือ True น่าจะจะเป็นกลุ่มอุตสาหกรรมที่มีข้อมูลใหญ่ที่สุดในประเทศไทย ซึ่งมีข้อมูลจากการใช้งานของลูกค้า 30-40 ล้านคนต่อบริษัทโดยเป็นข้อมูล  CDR (Call Detail Record) หลายหมื่นล้านเรคคอร์ดหรือหลาย Terabyte ต่อวัน ยังไม่รวมถึงข้อมูล Billing หรือ CRM จุดเด่นของอุตสาหกรรมนี้คือมีข้อมูลตำแหน่งของลูกค้า และพฤติกรรมการใช้โทรศัพท์ของลูกค้า
• อุตสาหกรรมค้าปลีก เช่น 7-11 จะมีข้อมูลขนาดใหญ่ที่มีการจากการซื้อสินค้า จะเห็นพฤติกรรมของผู้บริโภค เข้าใจลักษณะสินค้าที่ขาย แต่บางครั้งอาจไม่ทราบว่าลูกค้าคือใคร เว้นแต่จะมีบัตรสมาชิกและเก็บช้อมูลสมาชิกอย่าง Starbucks ที่สามารถทราบว่าลูกค้าแต่ละรายไปทานอะไร สาขาไหน เวลาไหน และถ้าอุตสาหกรรมทำ E-commerce ก็ทราบ Log การเข้าใช้งานของลูกค้า เช่นการเข้ามาดูเว็บ การกดเข้าดูสินค้า ทำให้เข้าใจผู้บริโภคได้มากขึ้น
• กลุ่มการเงินการธนาคาร จะมีข้อมูลธุรกรรมการเงิน ข้อมูลการเงินของลูกค้า แต่ลูกค้าทั่วไปอาจไปทำธุรกรรมที่ไม่บ่อยนัก อาจเป็นรายการขนาดใหญ่ แต่การเข้ามาของ  Mobile/Internet Banking และe-Payment ก็จะทำให้ธนาคารมีปริมาณธุรกรรมของลูกค้ามากขึ้น มี Log การเข้ามาใช้ของลูกค้า
• กลุ่มธุรกิจประกันภัย กลุ่มเหล่านี้จะไม่ได้มีข้อมูลของลูกค้าแต่ละรายที่เข้ามาต่อเนื่องมากนัก เพราะลูกค้าจะมาทำธุรกรรมไม่กี่ครั้งต่อปี ดังนั้นจุดเปลี่ยนของธุรกิจนี้อยู่ที่การใช้ IoT เข้ามาเพื่อให้ได้ข้อมูลของลูกค้ามากขึ้นเช่นการใช้ wearable device, Telematic  หรือ  smart home sensor
• อุตสาหกรรมการท่องเที่ยว กลุ่มนี้จะมีธุรกรรมค่อนข้างมากเช่น การเดินทาง การจองที่พัก เพียงแต่ข้อมูลในแต่ละรายอาจไม่มากนัก ยกเว้นเป็นบริษัทขนาดใหญ่เช่น สายการบิน หรือหน่วยงานอย่าง การท่าอากาศยาน
• โรงพยาบาลและสาธารณสุข จะเป็นหน่วยงานที่มีขนาดใหญ่ และจำนวนธุรกรรมค่อนข้างมาก และมีข้อมูลหลากหลายทั้งใน รูปแบบของรูปภาพ บันทึกทางการแพทย์ แต่ปัญหาโดยมากคือขาดการจัดเก็บข้อมูลที่เป็นระบบ และข้อมูลมีขนาดใหญ่มากยากต่อการเก็บและวิเคราะห์
• กลุ่มสื่อและธุรกิจบันเทิง จะเป็นอุตสาหกรรมที่มีข้อมูลที่เป็นเนื้อหา (content) แต่อาจขาดข้อมูลที่ทราบถึงการบริโภคของลูกค้าโดยตรง ยกเว้นทำเป็นสื่อออนไลน์เช่น  เว็บข่าวที่อาจเห็น Log  ของลูกค้า หรือ  Streaming TV อย่าง  NetFlix หรือ  AIS Play  ที่จะทราบได้ว่าลูกค้าเข้ามาดูรายการใดอย่างไร
• กลุ่มภาคการศึกษา จะมีข้อมูลที่ค่อนข้างน้อยเว้นแต่จะปรับเป็นเนื้อหาออนไลน์ ที่อาจทำให้เข้าใจพฤติกรรมของผู้เรียน มีตะแนนการวัดผลที่เก็บไว้ จะทำให้วัดผลมีประสิทธิภาพมากขึ้น
• กลุ่มสาธารณูปโภค เช่น การไฟฟ้า การประปา กลุ่มเหล่านี้ก็อาจมีข้อมูลการใช้จากมิเตอร์ต่างๆ
• หน่วยงานภาครัฐ โดยมากข้อมูลจะขาด Velocity ทำให้ไม่มีข้อมูลที่ดีพอในการนำวิเคราะห์รายคน แต่ก็มีหน่วยงานอย่างของกระทรวงการคลังที่อาจมีปริมาณธุรกรรมเยอะเช่น กรมสรรพากร กรมศุลกากร หรือหน่วยงานอย่าง กรมการกงศุล หรือประกันสังคม ที่อาจมีข้อมูลเข้ามาต่อเนื่องเยอะ แต่ปัญหาที่มักพบคือข้อมูลเหล่านี้มักไม่ถูกจัดเก็บในรูปแบบที่ไปวิเคราะห์ Big Data ได้ และขาดการเชื่อมโยงข้อมูลกับหน่วยงานรัฐด้วยกัน

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

ธนชาติ นุ่มนนท์

IMC Institute

ผมเคยเขียนบทความหลายๆครั้งชี้ให้เห็นว่าการทำ Big Data จำเป็นที่จะต้องมี Data Lake  ที่ทำงานร่วมกับ Database/Data warehouse และต้องมี Data Processing Tool และ Data Visualisation Tool ดังตัวอย่างสถาปัตยกรรมโดยย่อในรูปที่ 1  ทั้งนี้ Hadoop จะเป็นเทคโนโลยีที่หน่วยงานส่วนใหญ่จะลงทุนในการทำ Data Lake เพราะมีราคาในเก็บข้อมูลที่ต่ำเมื่อเทียบกับเทคโนโลยี On-Premise อื่นๆ และก็มีระบบนิเวศน์ที่มีซอฟต์แวร์อื่นๆอาทิเช่นการดึงข้อมูลหรือการประมวลผลข้อมูล

รูปที่ 1 สถาปัตยกรรมเทคโนโลยี Big Data แบบย่อ

เพื่อให้เห็นภาพการออกแบบสถาปัตยกรรม Big Data โดยใช้เทคโนโลยี Hadoop ผมขอยกตัวอย่างระบบสถาปัตยกรรมข้อมูลแบบดังเดิม ( Traditional data architecture) ในรูปที่ 2 ซึ่งหน่วยงานอาจมีระบบฐานข้อมูลที่หลากหลายท้ง RDBMS และ NoSQL โดยอาจมี Data warehouse ที่จะทำหน้าที่รวบรวมข้อมูลแล้วแสดงผลผ่านมายัง Visualisation Tools  ต่างๆ ซึ่งหากเราจะพัฒนาระบบนี้ให้เป็นสถาปัตยกรรม Big Data แบบ On-Premise โดยใช้ Hadoop เป็น Data Lake เราก็อาจได้ระบบต่างๆดังรูปที่ 3 โดยรายละเอียดของการทำงานซอฟต์แวร์แต่ละตัว (Hadoop HDFS, Spark, Kafka และอื่นๆ) ผมขอไม่กล่าวซ้ำ เพราะได้เคยเขียนไว้หลายครั้งในบล็อก thanachart.org

รูปที่ 2 ตัวอย่างสถาปัตยกรรมข้อมูลแบบดังเดิม

รูปที่ 3 ตัวอย่างสถาปัตยกรรม Big Data แบบ On-Premise โดยใช้ Hadoop 

แต่การจะลงทุนระบบ On-Premise โดยใช้เทคโนโลยี Hadoop และซอฟต์แวร์ต่างๆในรูปที่ 3 จะมีต้นทุนที่ค่อนข้างสูงมาก ผมเคยเขียนบทความแนะนำให้ไปเริ่มต้นโดยใช้ Public cloud ที่ราคาจะถูกกว่ากันมาก (อ่านบทความเรื่องนี้เพิ่มเติมได้ที่ Big Data as a Service แนวทางการทำโครงการ Big Data ที่ไม่ต้องลงทุนโครงสร้างพื้นฐาน) ซึ่งในบทความนี้ผมเลยตั้งที่จะทำตารางสรุปเปรียบเทียบการใช้บริการ Public Cloud รายใหญ่ต่างๆ กับเทคโนโลยีที่เป็น On-Premise โดยแสดงให้เห็นว่าบริการอะไรที่จะเข้าทดแทนระบบแบบ On-Premise ตามตารางที่ 1 และรูปที่ 4-6 ก็จะสรุปเป็นภาพบริการของ Cloud Provider ทั้งสามราย ซึ่งรายละเอียดของบริการแต่ละอย่างขอให้ไปศึกษาเพิ่มเติมจากผู้ให้บริการหรือหลักสูตรต่างๆทั้งใน YouTube หรือของ IMC Institute

ธนชาติ นุ่มนนท์

IMC Institute

ตารางที่ 1 เปรียบเทียบเทคโนโลยี On-Promise กับบริการต่างๆของ Public Cloud

รูปที่ 4 ตัวอย่างสถาปัตยกรรม Big Data โดยใช้ AWS แทนที่ระบบ On-Premise

รูปที่ 5 ตัวอย่างสถาปัตยกรรม Big Data โดยใช้ Google Cloud Platform แทนที่ระบบ On-Premise

รูปที่ 6 ตัวอย่างสถาปัตยกรรม Big Data โดยใช้ Microsoft Azureแทนที่ระบบ On-Premise