หมวดหมู่: Articles

ผมได้เขียนบทความ Big Data Architecture มาทั้งหมด 6 ตอนเพื่อให้ได้อ่านกัน จะได้เข้าใจได้ว่า การออกแบบสถาปัตยกรรม Big Data ควรต้องใช้เทคโนโลยีอย่างไรบ้าง โดยผมมองระบบ Big Data เหมือนระบบไอทีทั้วไปที่จะต้องมี

• Input ซึ่งในที่นี้คือ Big Data ที่มีคุณลักษณะ 4V คือ Volume, Velocity, Variety และ Veracity
• Process/System ซึ่งในที่นี้คือ Big Data Pipeline หรือ Big Data Architecture
• Output ซึ่งในที่นี้ก็คือผลลัพธ์ที่ได้จากการวิเคราะห์ Big Data ซึ่งอาจเป็นแบบ Business Intelligence หรือ Data Science

ทั้งนี้ Architecture อาจจะเปลี่ยนแปลงไปขึ้นอยู่กับคุณลักษณะของข้อมูลและผลลัพธ์ที่ต้องการ บทความที่ผมเขียนต้องการสรุปให้ทุกคนเข้าใจและตอบคำถามต่างๆได้อาทิเช่น

• อะไรคือความแตกต่างระหว่าง Data Warehouse และ Data Lake
• การออกแบบ Big Data Architecture จำเป็นต้องการ Hadoop หรือไม่
• การออกแบบสถาปัตยกรรมโดยใช้ Public Cloud Services ต้องใช้บริการอะไรบ้าง
• สถาปัตยกรรมในการวิเคราะห์ข้อมูลแบบ Streaming เป็นอย่างไร

ซึ่งบทความของผมมีทั้งหมด 6 ตอนโดยมีหัวข้อต่างๆดังนี้

• ตอนที่ 1 : Big Data Pipeline ทำไมไม่ใช่ Data Warehouse
• ตอนที่ 2 : สถาปัตยกรรมบน Data Lake
• ตอนที่ 3 : จาก Hadoop แบบ On-Premise สู่การใช้บริการบน Public cloud
• ตอนที่ 4 : สถาปัตยกรรม Data platform บน Public cloud
• ตอนที่ 5 : สถาปัตยกรรม Data platform สำหรับประมวลผลข้อมูลแบบ Streaming
• ตอนที่ 6 : สถาปัตยกรรม Cloud Data platform สำหรับประมวลผลข้อมูลทั้งแบบ Batch และ Streaming

ส่วนผู้ที่สนใจอยากศึกษาเพิ่มเติมทสง IMC Institute ก็มีบันทึกวิดีโอรายการย้อนหลังรายตอนที่เกี่ยวข้องกับ Big Data architecture โดยเผยแพร่ไว้ที่ YouTube channel ของ IMC Institiute

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

IMC Institute

ในตอนที่แล้วผมได้เขียนบทความให้เห็นว่าหากเราต้องการทำการประมวลผลข้อมูลแบบ Streaming เราอาจต้องปรับสถาปัตยกรรม Big data ให้เป็นแบบ Lambda หรือ Kappa และถ้าจะทำบนระบบ On-premise เราอาจต้องใช้เทคโนโลยีอย่าง Apache Kafka ที่มีทั้งการทำ Ingestion, Fast storage และ Real-time processing

และเมื่อพิจารณาถึงการทำสถาปัตยกรรมบน Cloud เราอาจจะเห็นได้ว่าขั้นตอน Big Data Pipeline ที่เคยระบุว่ามี 5 อย่างคือ Ingestion, Storage, Processing, Analytics และ Visualisation เมื่อต้องการออกแบบให้ประมวลผลทั้งแบบ Bacth และ Streaming จะมีความซับซ้อนขึ้น โดยอาจต้องมี Storage, Processing และ Analytics ที่ใช้กับข้อมูลทั้งสองแบบคือ Batch และ Streaming รวมถึงอาจต้องมี Pipeline ที่ใช้ในการเก็บข้อมูลสำหรับ Serving layer โดยจะมีสถาปัตยกรรมดังรูปที่ 1 ที่มีองค์ประกอบต่างๆดังนี้

• Ingestion ที่จะนำข้อมูลเข้ามาทั้งแบบ Batch และ Streaming
• Storage ในการเก็บข้อมูลที่อาจแบ่งเป็น Fast storage สำหรับข้อมูลแบบ Streaming และ Data Lake สำหรับข้อมูลแบบ Batch
• Processing/Analytics ในการประมวลและวิเคราะห์ข้อมูลที่อาจแบ่งเป็น Batch Processing/Analytics และ Real-time Processing/Analytics
• Serving layer ที่อาจเป็น Data Warehouse หรือ No SQL ที่จะทำหน้าที่เก็บผลลัพธ์ของการประมวลผลข้อมูลทั้งสองแบบ
• Visualisation ส่วนที่เป็นการแสดงผลที่อาจจะดึงมาจาก Serving layer

จากสถาปัตยกรรมข้างต้นนี้ หากไปเปรียบเทียบกับสถาปัตยกรรม Data Platform เดิมที่อยู่บน Cloud ซึ่งผมเคยได้สรุปไว้ในบทความ Big Data Architecture #4: สถาปัตยกรรม Data platform บน Public cloud จะพบว่ามีบริการที่อาจต้องนำเพิ่มขึ้นมาดังนี้

• Fast storage อย่าง อย่าง Azure Event Hub, Google Cloud Pub/Sub หรือ AWS Kinesis เพื่อทำหน้าที่เป็น Storage หลักในการเก็บข้อมูล Streaming
• Real-time processing อย่าง Azure Stream Analytics, Google Cloud DataFlow หรือ AWS Kinesis Stream Analytics

โดย Cloud Data Platgorm สำหรับผู้ให้บริการ Cloud สามรายหลักคือ Microsoft Azure, Google Cloud Platform และ AWS จะได้ได้ Block diagram ดังรูปที่ 2 – 4

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

IMC Institute

การออกแบบสถาปัตยกรรม Big Data บน Public cloud อาจแตกต่างกับการออกแบบบนระบบ On-premise ที่ผมเคยเขียนไว้ในตอนที่ 1 ว่าไม่ควรเน้นที่จะเป็น Data warehouse (อ่านเพิ่มเติมได้จาก Big Data Architecture #1: Big Data Pipeline ทำไมไม่ใช่ Data Warehouse) ทั้งนี้เนื่องจากเทคโนโลยี Data Warehouse ไม่ได้เหมาะสมกับคุณลักษณะของ Big Dataในเรื่องของ 4V ทำให้การเก็บข้อมูลขนาดใหญ่จะมีราคาแพง และจะเน้นได้เฉพาะข้อมูลแบบ Structure หรือ Semi-structure

แต่ในกรณีของผู้ให้บริการ Public cloud จะมีบริการ Data Warehouse ทีสามารถรองรับข้อมูลขนาดใหญ่ได้ในราคาที่ถูกกว่า ทำให้ในบางกรณีเราสามารถที่จะออกแบบสถาปัตยกรรม Big Data โดยใช้ Data Warehouse as a Service อย่าง Google BigQuery หรือ Azure Synapse ได้ ดังตัวอย่างในรูปที่ 1

กรณีนี้เราจะเห็นการใช้บริการบน Public Cloud สองอย่างหลักๆคือ

1. Fully managed ETL service อย่าง Azure Data Factory หรือ Google Cloud DataFusion ที่จะทำหน้าที่ดึงข้อมูลจากแหล่งต่างๆเข่น RDBMS อย่าง MySQL ซึ่งอาจจะอยู่บนระบบ On-Premise หรือ Public Cloud แล้วทำการแปลงข้อมูลให้อยู่ใน Format ที่ต้องการก่อนโหลดเข้า Data Warehouse
2. Fully managed data warehouse service อย่าง Azure Synapse หรือ Google BigQuery ซึ่งเป็นบริการแบบ PaaS ที่สามารถรองรับการเก็บข้อมูลขนาดใหญ่ โดยผู้ใช้บริการไม่ต้องไปกังวลเรื่องการดูแลระบบ

การใช้สถาปัตยกรรม Big Data ที่เน้นเฉพาะ Data Warehouse จะเหมาะกับกรณีของ Big data ที่มีเฉพาะที่มาจากแหล่งข้อมูลแบบ Relational มีรูปแบบข้อมูล (Schema) ที่แน่นอน ไม่ได้มาจากหลายแหล่งข้อมูลนัก และเน้นเฉพาะการทำ Business Intelligence (BI) หรือต้องการสืบค้นข้อมูลในรูปแบบของ SQL แต่หากมีแหล่งข้อมูลจำนวนมากและมีหลากหลายชนิด รวมถึงต้องการทำการวิเคราะห์เชิง Predictive โดยใช้ Machine Learning เราควรที่จะเน้นสถาปัตยกรรมแบบ Data Platform ที่ใช้ทั้ง Data Lake และ Data Warehouse เหมือนกรณีที่ผมเขียนอธิบายไว้ในตอนที่ 2 (อ่านเพิ่มเติมได้จาก Big Data Architecture #2: สถาปัตยกรรมบน Data Lake) ที่มี Block diagram ดังแสดงในรูปที่ 2

ในกรณีการออกแบบสถาปัตยกรรมแบบ Data Platform เราจะเห็นการใช้บริการต่างๆบน Public cloud ดังนี้

1. Fully managed ETL service อย่าง Azure Data Factory, Google Cloud Data Fusion หรือ AWS Glue
2. Cloud storage อย่าง Azure Data Lake Storage, Google Cloud Storage หรือ AWS S3 เพื่อทำหน้าที่เป็น Storage หลักในการเก็บ Big data
3. Fully managed data warehouse service อย่าง Azure Synapse, Google BigQuery หรือ AWS Redshift
4. Fully managed Hadoop/Spark service อย่าง Azure HDInsight, Google DataProc หรือ AWS EMR เพื่อที่จะทำหน้าที่ในการทำ Data preparation หรือการทำ Data Analytics อย่าง Machine Learning โดยใช้เทคโนโลยี Hive หรือ Spark
5. Ingestion service อย่าง Azure Event Hub, Google Cloud Pub/Sub หรือ AWS Kinesis ที่ทำหน้าที่ในการนำข้อมูลแบบ Streaming เข้าสู่ Cloud Storage

เพื่อให้เห็นสถาปัตยกรรม Big data แบบ Data Platform บน Public cloud services สามรายหลักคือ Microsoft Azure, Google Cloud Platform และ AWS ผมได้วาด Block diagram มาแสดงเปรียบเทียบกับระบบ On-premise ดังรูปที่ 3 – 6

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

IMC Institute

ในตอนที่แล้วผมได้ระบุว่าการทำ Big Data ควรที่จะต้องออกแบบสถาปัตยกรรมโดยใช้ Data Lake เป็น Storage หลัก และเทคโนโลยีที่เหมาะกับการทำ Data Lake มากที่สุดก็คือ Hadoop แต่อย่างไรการจะติดตั้งระบบ Hadoop แบบ On-premise ยังมีข้อที่ควรจะพิจารณาอีกในหลายด้านดังนี้

• ระบบมีค่าใช้จ่ายด้าน Hadware และ Software เริ่มต้นที่ค่อนข้างสูง ซึ่งหากต้องการเก็บข้อมูลเป็นหลักสิบ Terabyte ค่าใช้จ่ายก็อาจเริ่มจากเป็นหลักสิบล้านบาท
• ระบบ Hadoop มีความซับซ้อนในการติดตั้ง และบำรุงรักษา
• ระบบ Hadoop จะไม่ได้แยกส่วนที่เป็น Storage และ Processing ออกจากกัน กล่าวคือระบบ Hardware เดียวกันจะถูกนำมาใช้งานในทั้งสองด้าน ทำให้ขาดความยืดหยุ่นและการลงทุนอาจไม่ได้ประสิทธิภาพนัก
• การจะขยายระบบ Hadoop จะไม่สามารถทำได้ทันทีทันใดเพราะจะมีขั้นตอนในการจัดหา Hardware เพิ่มเติม
• ระบบ Hadoop มีเทคโนโลยีในการประมวลผลที่ซับซ้อน และมีความหลากหลายทำให้นักพัฒนาต้องเรียนรู้หลากหลายระบบ และแม้แต่เพียงแค่การจะเข้าดูข้อมูลที่เก็บไว้ในระบบก็ไม่ง่ายนัก

จากข้อจำกัดข้างต้นทำให้หลายๆองค์กรหันมาสนใจสถาปัตยกรรม Big data แบบที่ใช้บริการต่างๆของ Public cloud ค่ายดังๆอาทิเช่น Amazon Web Services (AWS), Microsoft Azure หรือ Google Cloud Platform (GCP) เป็นต้น เนื่องจาก Public cloud เหล่านี้มีบริการที่เกี่ยวข้องกับ Big Data มากมาย อาทิเช่น

• Cloud storage service อย่าง AWS S3, Azure data lake Storage หรือ Google cloud storage
• Database service อย่าง RDS ของ AWS, Azure SQL หรือ Cloud SQL ของ GCP
• Data warehouse service อย่าง Redshift ของ AWS, Azure Synapse หรือ Google BigQuery
• Hadoop/Spark service อย่าง EMR ของ AWS, HDInsight หรือ Databrick ของ Azure, DataProc ของ GCP

ผมได้เขียนสรุปตัวอย่างบริการต่างๆที่ Public cloud ทั้งสามรายนี้มีเมื่อเทียบกับระบบ Big data แบบ On-premise ดังตารางข้างล่างนี้

จุดเด่นของการออกแบบสถาปัตยกรรม Big Data บน Public cloud เมื่อเทียบกับระบบ On-premise มีดังนี้

• มีทรัพยากรที่ยืดหยุ่นกว่า (Elastic resources) กล่าวคือบริการต่างๆบน Cloud สามารถจะลดหรือขยายได้อย่างรวดเร็ว เช่นการเพิ่มขนาดการเก็บข้อมูล หรือเพิ่มจำนวน Server
• Modularity กล่าวคือบริการแต่ละตัวเป็นอิสระต่อกัน ดังนั้นจึงมีการแยกระบบ Storage และ Processing โดยไม่ได้ผูกไว้กับระบบ Hardware ชุดเดียวกันเหมือน Hadoop แบบ On-premise
• ค่าใช้จ่ายขึ้นอยู่กับการใช้งาน และไม่ต้องเสียค่าลงทุนเริ่มต้นสูงนัก
• สามารถเริ่มทำโครงการได้อย่างรวดเร็ว เพราะบริการต่างๆบน Public cloud มีอยู่แล้ว สามารถเริ่มต้นโครงการได้ทันที
• การใช้บริการ Cloud เริ่มเป็น New normal สำหรับการทำระบบไอที และมีบริการใหม่ๆทางด้าน Big data และ AI ที่สามารถทำให้เราสร้างนวัตกรรมในเรื่องต่างๆได้ง่ายขึ้น

แต่การจะใช้บริการบน Public cloud จำเป็นจะต้องออกแบบสถาปัตยกรรมให้ถูกต้องและเลือกบริการให้เหมาะสม ซึ่งผมจะเขียนอธิบายในตอนต่อไป

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

IMC Institute

เมื่อวันก่อนผมได้อ่านหนังสือเล่มหนึ่งชื่อ The Economics of Data, Analytics, and Digital Transformation ที่เขียนโดย Kirk Borne และ Bill Schmarzo ซึ่งเพิ่งตีพิมพ์เมื่อปลายปีที่แล้ว ผมว่าเป็นหนังสือที่อธิบายเรื่องเกี่ยวกับการวิเคราะห์คุณค่าของข้อมูลและการทำ Data analytics ในมุมมองทางเศรษฐศาสตร์ได้ดีมาก แต่สิ่งที่ผมอย่างกล่าวถึงในที่นี้คือเรื่องของระดับการวัดความสามารถในการนำ Big Data ไปใช้ในองค์กรหรือ Big Data Business Model Maturity Index (BDBMMI) ที่เขียนไว้ในบทแรกของหนังสือเล่มนี้

BDBMMI ที่กล่าวมานี้อาจไม่ใช่เรื่องใหม่ ผมเองก็เคยนำเรื่องนี้มาเขียนในบทความเรื่อง ระดับการวัดความสามารถในการนำ Big Data ไปใช้ในองค์กร ซึ่งระดับความสามารถของการนำ Big Data ไปใช้ในองค์กร (Big Data Matuarity Model) มีอยู่ 5 ระดับ คือ 1) Business Monitoring 2) Business Insights 3) Business Optimization 4) Data Monetization และ 5) Business Metamorphosis แต่หนังสือเล่มนี้อาจเปลี่ยนชื่อระดับที่ 4 และ 5 เป็น Insights Monetization และ Digital Transformation ตามระดับ โดยได้ให้คำอธิบายแต่ละขั้นตอนที่ชัดเจนขึ้นดังนี้

1. Business Monitoring ในระดับนี้องค์กรได้ทำ Business Intelligence และ Data Warehouse ซึ่งเป็นขั้นตอนที่เราจะแสดงข้อมูลหรือทำรายงานต่างๆขององค์กรในลักษณะของ Descriptive Analytic ที่เราจะดูข้อมูลในอดีตเพื่อให้ทราบว่า What’s happened? แต่การทำขั้นทำขั้นตอนยังเป็นเพียงการนำข้อมูลมาวัดความสำเร็จที่ผ่านมา และยังขาดการวิเคราะห์สิ่งที่จะเกิดขึ้นหรือการทำ predictive analytics และ prescriptive analytics ที่องค์กรควรจะก้าวไปถึงระดับนี้ให้ได้ เพื่อจะทำให้กลายเป็นองค์กรที่ขับเคลื่อนด้วยข้อมูล ซึ่งจะต้องคิดในการนำข้อมูลมาวิเคราะห์ในเชิงธุรกิจมากขึ้น มีการทำด้าน Data science มากขึ้น และมีการสร้างวัฒนธรรมในการใช้ข้อมูลมากขึ้น
2. Business Insights ในระดับนี้องค์กรมีการเริ่มต้นตั้งคำถามเพื่อให้ทราบว่า What is likely to happen next? กล่าวคือคาดการณ์ว่าน่าจะเกิดอะไรขึ้นกับ ตลาด กลุ่มลูกค้า สินค้า และบริการต่างๆ เป็นค้นหาข้อมูลเชิงลึก (Insights) ของลูกค้า สินค้า และบริการต่างๆ ขั้นตอนนี้องค์กรจะมีการรวบรวมข้อมูลจากหลายๆแหล่งทั้งภายนอกและภายในองค์กร มีการทำ Data Lake และเห็นการทำงานร่วมกันระหว่างฝั่งธุรกิจแผนกต่างๆ กับทีมงานนักวิทยาศาสตร์ข้อมูลมากขึ้น
3. Business Optimizationในระดับนี้องค์กรจะมีการทำ predictive analytics และ prescriptive analytics โดยใช้ Machine Learning มากขึ้น จะมีข้อแนะนำในขั้นสิ่งต่างๆทีทำในขั้นตอนปฎิบัติงาน กล่าวคืออาจมี Recommendation system สำหรับลูกค้าแต่ละคน หรือสินค้าในแต่ละอย่าง ซึ่งเป็นผลลัพธ์ที่ได้มาจากการทำ Data science เพื่อคาดการณ์สิ่งที่ดีที่สุดสำหรับองค์กร
4. Insights Monetization ในระดับนี้ไม่ได้หมายความว่าองค์กรจะนำข้อมูลที่มีอยู่ไปขายเพื่อหารายได้ แต่เป็นการนำข้อมูลไปสร้างคุณค่าเพิ่ม ที่อาจทำให้ได้ช่องทางการตลาดใหม่ๆ กลุ่มลูกค้าใหม่ๆ สินค้าและบริการใหม่ๆ ตลอดจนการหาพันธมิตรทางธุรกิจใหม่ๆ
5. Digital Transformation ในระดับนี้องค์กรจะมีวัฒนธรรม (Culture) ในการใช้ข้อมูล การวืเคราะห์ข้อมูล เพื่อจะนำมาใช้ให้เกิดประโยชน์ทางธุรกิจอยู่ตลอดเวลา

ในครั้งหน้าผมจะลองมาสรุปให้เห็นว่าการที่จะทำให้องค์กรสามารถเข้าไปสู่ในแต่ละขั้นตอนของ

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

IMC Institute

เมื่อวันก่อนตอนผมบรรยายในงาน Webinar ครั้งที่ 45 ของสถาบันไอเอ็มซี ในหัวข้อ Data Engineering Technologies & Trends 2021 มีผู้ฟังท่านหนึ่งถามมาว่า “เราจะทราบได้อย่างไรว่า ข้อมูลของเราเป็น Fake data”

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

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

กระบวนการที่จะช่วยทำให้ลดความผิดพลาดของข้อมูลส่วนหนึ่งคือ การทำ Data preperation ซึ่งเป็นหน้าที่ของ Data engineerในการจะต้องนำข้อมูลดิบ (Raw data) มาแปลง มาตรวจสอบความถูกต้องเสียก่อน เช่นหา Missing data หรือ Outlier กล่าวคือหาข้อมูลที่ดูแล้วผิดปกติแล้วทำการแก้ไข เช่นบางครั้งข้อมูลลบการเงินของบริษัทอาจมีจำนวนสูงผิดปกติ จำนวนพน้กงานมากผิดปกติ ข้อมูลส่วนตัว อายุ น้ำหนัก ดูสูงผิดปกติ หรือข้อมูนำเข้าส่งออกอาจใช้สกุลเงินต่างกัน ข้อมูลเหล่านี้ Data engineer จะช่วยทำการ Data Cleansing ให้ได้ เช่นอาจปรับหาค่าที่เหมาะสมมาใส่ หรือตัดออก และแปลงข้อมูลดิบให้กลายเป็นข้อมูลที่น่าเชื่อถือ (Trusted data) เพื่อให้ Data analyst หรือ Data scientist นำไปทำการวิเคราะห์ข้อมูลและแสดงผลต่อไป

แต่อย่างไรก็ตามแม้ Data engineer จะสร้าง Trusted data ให้แล้ว ก็ใช่ว่าข้อมูลนั้นจะถูกต้อง 100% แหล่งข้อมูลที่เข้ามาก็อาจจะเกิดการผิดพลาดแต่วิธีการด้าน Data engineering ก็ยังไม่สามารถแก้ไขได้ จากสารพัดสาเหตุ อาทิเช่น นำข้อมูลเข้ามาไม่ครบ ได้ข้อมูลผิดๆแต่ต้น หรือแม้แต่ข้อมูลถูกต้องแล้ว แต่ Data analyst ไม่เข้าใจข้อมูลดีพอ เลยทำการวิเคราะห์ที่ผิดแล้วแสดงผลผิดพลาดก็เป็นไปได้

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

ดังนั้นการที่จะทราบได้อย่างไรว่า ข้อมูลของเราเป็น Fake data คำตอบผมคือ กระบวนงานของ Data engineering และประสบการณ์ของ Domain expert เป็นเรื่องสำคัญสุด

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

IMC Institute

เมื่อตอนที่แล้วผมเขียนถึงประเภทงานด้านต่างๆที่เกี่ยวข้องกับการวิเคราะห์และบริหารจัดการข้อมูล (งาน Data Engineer มีความสำคัญมากพอๆกับงานของ Data Scientist (ตอนที่ 1)) และชี้ให้เห็นว่างานของวิศวกรข้อมูล (Data emgineer) มีความสำคัญพอๆกับงานของนักวิทยาศาสตร์ข้อมูล (Data Scientist) และบางครั้งอาจมีความสำคัญมากกว่าเสียด้วยซ้ำไป

สำหรับเหตุผลต่างๆขออธิบายดังนี้

1. การทำงานด้านข้อมูลจะเริ่มต้นจากกระบวนการทางวิศวกรรมข้อมูล ซึ่งเป็นหน้าที่ของ Data engineer ที่จะต้องนำเข้าข้อมูล จัดการแปลงข้อมูล ปรับข้อมูลให้มีความถูกต้อง รวมถึงการตัดข้อมูลที่ผิดพลาดออก ก่อนที่จะส่งงานนี้ไปให้ Data Scientist หรือ Data analyst ไปทำการพยากรณ์หรือวิเคราะห์ข้อมูลต่อ ดังนั้นถ้าวิศวกรข้อมูลส่งข้อมูลมาผิดพลาด ไม่สมบูรณ์ ก็จะมีผลทำให้การวิเคราะห์หรือการพยากรณ์ข้อมูลต่างๆผิดพลาดไปด้วย ดังที่กล่าวว่า garbage in garbage out
2. เมื่อวิเคราะห์ถึง Data analytic life cycle ตามมาตรฐานของ CRISP-DM(Cross-industry standard process for data mining) จะเห็นได้ว่ามีอยู่ 6 ขั้นตอน เริ่มจาก การทำความเข้าใจธุรกิจ (Business Understanding) ไปจนถึงการนำไปใช้งาน (deployment) ซึ่งเราจะพบว่างานส่วนใหญ่เกือบ 70-80% จะใช้เวลาไปกับขั้นตอนของ Data preparation กล่าวคือการเตรียมข้อมูลที่เป็นงานของ Data engineer ขณะที่งานของ Data scientist อย่างขั้นตอนการสร้างแบบจำลอง (Modeling) และ การประเมินผล (Evaluation) จะใช้เวลาไม่นานนัก

3. งานการวิเคราะห์ข้อมูลขนาดใหญ่ (Big data)ที่พบในทางปฎิบัติจริงโดยมากจะเป็นงานการวิเคราะห์ข้อมูลทั่วไปที่ใช้หลักการของ Business Intelligence (BI) โดยเป็นหน้าที่ของนักวิเคราะห์ด้านข้อมูล (Data analyst) แล้วอาจนำผลไปทำ Dashboard โดยใช้เครื่องมือด้าน Visualization ซึ่งงานเหล่านั้นพบมากกว่างานด้านการพยากรณ์ข้อมูล (Predictive analytic) ที่ต้องทำโดย Data scientist ด้วยซ้ำไป เพราะหน่วยงานต่างๆจะเริ่มต้นจากการทำ BI ก่อน
4. งานด้านการพยากรณ์ข้อมูล (Predictive analytic) ที่ทำโดยมากมักจะเป็นงานในการพัฒนาโมเดลพื้นฐานที่มีอยู่ทั่วไป และอาจต้องการนักวิทยาศาสตร์ข้อมูลที่เน้นการพัฒนาโปรแกรม หรือ Citizen Data Scientist ในการทำมากกว่าต้องการ นักวิทยาศาสตร์ข้อมูลขั้นสูง ซึ่งเราจะพบว่าสามารถนำงานเหล่านั้นให้ Data engineer มาศึกษาการเขียนโปรแกรมการพยากรณ์ข้อมูลได้ และบางครั้งอาจจะง่ายกว่าการที่จะเอานักวิทยาศาสตร์ข้อมูลขั้นสูงมาฝึกเป็น Data engineer เสียด้วยซ้ำไป กล่าวคือเราอาจให้ Data engineer มาทำหน้าที่ Data scientist ได้ในงานที่ไม่ซับซ้อน
5. ข้อมูลจาก The 2021 Data Science Interview Report ระบุว่าตำแหน่งงานทางด้าน Data scientist เริ่มมีการเติบโตน้อยลงจากที่เคยเพิ่มปีละ 80% เหลือเพียงโตขึ้น 10% จากปี 2020 เมื่อเทียบกับปี 2019 ขณะที่งานด้าน Data engineer กลับโตขึ้นถึง 40% นอกจากนี้ยังมีการศึกษาโดย Mihail Eric ที่ลงบทความใน https://www.kdnuggets.com/ พบว่างานทางด้าน Data engineer มีความต้องการสูงกว่างานด้าน Data science ถึง 70%

6. สุดท้ายมีบทความเรื่อง Data Engineer VS Data Scientist ที่รายงานการสำรวจเงินเดือนเฉลี่ยระหว่าง Data engineer กับ Data Scientist ในปี 2018 พบว่าเงินเดือนของ Data engineer เฉลี่ยอยู่ที่  $151K ต่อปี ส่วน Data Scientist $139K ต่อปี

ทั้งหมดนี้คือสิ่งทีอยากชี้ให้เห็นว่างานของวิศวกรข้อมูล (Data engineer) มีความสำคัญมากและอาจเป็นหนึ่งในอาชีพที่น่าสนใจที่สุดสำหรับคนที่ต้องการทำงานด้านข้อมูล

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

IMC Institute