การแปลงชุดข้อมูลให้อยู่ในรูปแบบโครงสร้างข้อมูลร่วมโดยอัตโนมัติ

นอกเหนือจากการกำหนดรูปแบบโครงสร้างข้อมูลร่วมแล้ว คณะผู้จัดทำโครงการได้ออกแบบ ขั้นตอนวิธีการแปลงชุดข้อมูลที่อยู่ในรูปแบบที่เป็นที่นิยมอย่าง CSV และ XLSX ให้เป็นไปตามมาตรฐาน CMKL v1.0 เพื่อนำไปใช้กับในโครงการ แพลตฟอร์มข้อมูลเพื่องานด้านปัญญาประดิษฐ์ฯ (AI Data Platform)

เมื่อผู้ใช้งานได้อัปโหลดชุดข้อมูลต้นฉบับ (Original Data File) ขึ้นมาบนระบบ สิ่งที่เกิดขึ้นในลำดับถัดไปอาจแบ่งออกได้เป็น 2 กรณีดังนี้

กรณีต่างๆ ที่เกิดขึ้นได้บนระบบ

1. กรณีผู้ใช้อัปโหลดไฟล์ชุดข้อมูลเข้ามาใหม่ในระบบ เมื่อผู้ใช้อัปโหลดไฟล์ชุดข้อมูลเข้ามาใหม่ ระบบจะพยายามตรวจจับชนิดข้อมูลของแต่ละ key ในไฟล์นั้น และแปลงชุดข้อมูลให้เข้ากับมาตรฐาน CMKL v1.0 พร้อมสร้างไฟล์คำอธิบายโครงสร้างของชุดข้อมูล (Schema File) และเสนอชนิดของชุดข้อมูลที่ตรวจพบให้ผู้ใช้เลือกต่อไป

1. กรณีผู้ใช้ระบุชนิดข้อมูลของชุดข้อมูลผ่านแพลตฟอร์ม หลังจากที่ชุดข้อมูลอยู่บนระบบแล้ว เมื่อผู้ใช้ระบุชนิดข้อมูลของแต่ละ key ในชุดข้อมูลเรียบร้อย ระบบจะแปลงชนิดข้อมูลในไฟล์ชุดข้อมูลให้เป็นไปตามชนิดข้อมูลที่ผู้ใช้เลือกไว้ (User-Defined Schema) พร้อมทั้งอัปเดตไฟล์อธิบายโครงสร้างของชุดข้อมูลเดิมให้ตรงกับชนิดข้อมูลใหม่ที่เลือก

โดยในแต่ละกรณี จะมีขั้นตอนการประมวลผล (Process) ไฟล์ชุดข้อมูลต้นฉบับที่ถูกอัปโหลดขึ้นมาดังต่อไปนี้

ขั้นตอนการประมวลผล (Process) ชุดข้อมูล

1. การแปลงรูปแบบการจัดเก็บชุดข้อมูล (File Format)
2. การแปลง Field ในโครงสร้างข้อมูล (Data Schema) เพื่อให้อยู่ในชุดมาตรฐานโครงสร้างข้อมูลร่วม (Standardized Common Schema) และขอคำชี้แนะจากผู้ใช้งานหรือเจ้าของชุดข้อมูลเพื่อตรวจสอบความถูกต้อง
3. การดำเนินการ (Preprocess) ชุดข้อมูลเพื่อสร้าง Metadata

การแปลงรูปแบบการจัดเก็บชุดข้อมูล (File Format)

เมื่อผู้ใช้งานระบบได้อัปโหลดชุดข้อมูลขึ้นมา แพลตฟอร์มจะสแกนไฟล์ชุดข้อมูลต้นฉบับ (Original Data File) เพื่อวิเคราะห์รูปแบบการจัดเก็บ (File Format) และแปลงรูปแบบการจัดเก็บให้อยู่ในรูปของ Standardized JSON ทั้งหมด เพื่อให้เป็นมาตรฐานเดียวกัน และมีประสิทธิภาพต่อการทำ Preprocessing ในลำดับถัดไป โดยรายละเอียดการแปลงไฟล์ชุดข้อมูลต้นฉบับ ให้กลายเป็น Standardized JSON มีดังต่อไปนี้

1. กรณีที่ชุดข้อมูลต้นฉบับ (Original Data File) เป็นไฟล์ชนิด CSV ให้แปลง CSV เป็น Array ของ Object โดยให้แต่ละแถว (Row) ในไฟล์ CSV ต้นฉบับกลายเป็น Object ใน Array ส่วนคอลัมน์ (Column) ก็ให้กลายเป็น Key ของค่าใน Object นั้นๆ แทน เช่น

ไฟล์ CSV ต้นฉบับ

A,B,C

1,2,3

4,5,6

ไฟล์ JSON ที่แปลงแล้ว

[

{

"A": 1,

"B": 2,

"C": 3

},

{

"A": 4,

"B": 5,

"C": 6

}

]

2. กรณีที่ชุดข้อมูลต้นฉบับ (Original Data File) เป็นไฟล์ชนิด XLS กรณีที่ไฟล์ XLSX นั้นๆ ประกอบด้วย Sheet เพียงหน้าเดียว ให้แปลงในลักษณะเดียวกันกับ CSV ในข้อ 1. ส่วนในกรณีที่มีมากกว่า 1 Sheet ให้แยกแต่ละ Sheet เป็นคนละ Object โดยใช้ชื่อ Sheet (Sheet Name) เป็น Key ของ Object นั้นๆ ในไฟล์ JSON เสร็จแล้วให้แปลงแต่ละตารางในลักษณะเดียวกับกรณีไฟล์ชนิด CSV ตามข้อ 1. ข้างต้น เช่น

ไฟล์ XLSX ต้นฉบับ

[Sheet 1]

A,B

1,2

3,4

-----

[Sheet 2]

X, Y

9, 8

7, 6

ไฟล์ JSON ที่แปลงแล้ว

{

"Sheet 1": [

{

"A": 1,

"B": 2

},

{

"A": 3,

"B": 4

}

],

"Sheet 2": [

{

"X": 9,

"Y": 8

},

{

"X": 7,

"Y": 6

}

]

}

การแปลง Field ในโครงสร้างข้อมูล (Data Schema) เพื่อให้อยู่ในชุดมาตรฐานโครงสร้างข้อมูลร่วม (Standardized Common Schema) และขอคำชี้แนะจากผู้ใช้ หรือเจ้าของชุดข้อมูล เพื่อตรวจสอบความถูกต้อง

เมื่อชุดข้อมูลถูกแปลงให้อยู่ในรูปแบบ JSON แล้ว ลำดับต่อไปคือการแปลงโครงสร้างข้อมูล (Data Schema) ให้อยู่ในชุดมาตรฐานโครงสร้างข้อมูลร่วม (Common Schema) ใน กรณีที่ 2.1.1. เมื่อผู้ใช้แพลตฟอร์มอัปโหลดข้อมูลเข้ามาในระบบ ระบบจะตรวจจับ Keyword ในชื่อ key และสแกนข้อมูลในแต่ละ key เพื่อชี้วัดว่าจำเป็นต้องมีการแปลงชนิดข้อมูล เพื่อให้ตรงกับมาตรฐานโครงสร้างข้อมูลร่วมหรือไม่ โดยชนิดข้อมูลที่ระบบจะพยายามตรวจจับและแปลงให้อยู่ในรูปแบบมาตรฐานมีดังต่อไปนี้

ชนิดข้อมูล	Keyword ใน key ที่ระบบใช้ในการตรวจจับ	คุณลักษณะของข้อมูลในแต่ละ key ที่ระบบใช้ในการตรวจจับ
date	"date"	ข้อมูลต้องสามารถแปลงเป็นชนิด date ได้
date	"date"	ข้อมูลต้องสามารถแปลงเป็นชนิด date ได้
timestamp	“time” หรือ “timestamp” หรือ /created_?at/ หรือ /updated_?at/ หรือ /edited_?at/	ข้อมูลต้องสามารถแปลงเป็นชนิด datetime (Python) ได้
duration	“time” หรือ “timestamp”	ข้อมูลอยู่ในรูปแบบ [hh:]mm:ss[.ssss]
geolocation	“coord” หรือ “coordinates” หรือ “location” เฉพาะ ละติจูด: “latitude” หรือ “lat” เฉพาะ ลองจิจูด: “longitude” หรือ “lon” หรือ “long” หรือ “lng”	ตัวเลขต้องมีสองชุดและถูกคั่น ด้วยอักขระอื่น กรณีที่ข้อมูลต้นฉบับเก็บค่าละติจูดและลองจิจูดแยกกันคนละ key ข้อมูลในแต่ละ key นั้นจะต้องแปลงเป็นตัวเลขได้
place	“city” หรือ “county” หรือ “state” หรือ “province” หรือ “country” หรือ “region” หรือ “address”	-
file_reference	/file(_?)name/	ข้อมูลต้องอยู่ในรูปแบบ UNIX File Path
url	“link” หรือ “url”	ข้อมูลต้องอยู่ในรูปแบบ URL
email	/email(_?address)?/	ข้อมูลต้องอยู่ในรูปแบบ Email Address
key	“id” หรือ “key” หรือ “uuid”	ข้อมูลต้องไม่ซ้ำกัน
number	-	ข้อมูลต้องสามารถแปลงเป็นตัวเลขได้ทั้งหมด โดยไม่ขึ้นต้นด้วยเลข 0
boolean	-	ข้อมูลต้องมีเฉพาะคำว่า “true”/“false” “yes”/“no” “Y”/“N” “1”/“0” หรือ 1/0 (case insensitive)
string	-	-

หมายเหตุ:

• ข้อความที่อยู่ระหว่างเครื่องหมาย /.../ คือ Regular Expression
• ตรวจจับชื่อคอลัมน์แบบ case insensitive
• ข้อกำหนดในคอลัมน์ “Keyword ใน key ที่ระบบใช้ในการตรวจจับ” ยังรวมไปถึงกรณีที่มีคำอื่นนำหน้า keyword เหล่านั้นด้วย โดยจะต้องมีเครื่องหมาย “_” คั่นระหว่างคำอื่นกับ keyword ที่ระบบใช้ในการตรวจจับด้วย เช่น หากระบบใช้ keyword /(.*_)?id/ เพื่อตรวจหา “id” คำที่เข้าข่ายอาจได้แก่ “student_id” หรือ “event_id” เป็นต้น

อย่างไรก็ตาม เนื่องจากชุดข้อมูลแต่ละชุดอาจมีความต้องการและข้อจำกัดในการใช้งานที่ไม่เหมือนกัน ระบบจะเสนอทางเลือกให้ผู้ใช้สามารถตัดสินใจว่าจะยินยอมให้ระบบทำการแปลงแต่ละ Field ให้เป็นไปตามมาตรฐานโครงสร้างชุดข้อมูล (Standardized Common Schema) ที่ระบบเสนอมาหรือไม่

สำหรับ กรณีที่ 2.1.2. เมื่อผู้ใช้แพลตฟอร์มระบุชนิดข้อมูลของชุดข้อมูลผ่านแพลตฟอร์ม Goliath ผ่านหน้าจอดังภาพ ระบบจะพยายามแปลงไฟล์ชุดข้อมูลให้เป็นไปตามที่ผู้ใช้ระบุมาโดยไม่ต้องตรวจจับชนิดข้อมูลก่อน

การดำเนินการ (Preprocess) ชุดข้อมูลเพื่อสร้าง metadata

หลังจากชุดข้อมูลที่อัปโหลดเข้ามาในระบบได้ถูกแปลงให้อยู่ในรูปของ JSON และมาตรฐานรูปแบบโครงสร้างข้อมูลร่วม (Common Schema) แล้ว ลำดับต่อไปเป็นการดำเนินการ (Preprocess) เพื่อสร้าง Metadata สำหรับใช้ในการแสดงภาพรวมของชุดข้อมูลให้ผู้ใช้สามารถใช้งานได้สะดวกและมีประสิทธิภาพ

โดยข้อมูล Metadata จะถูกเติมลงใน ไฟล์คำอธิบายโครงสร้างของชุดข้อมูล (Schema File) ตามลักษณะดังนี้

// Schema File

{

...

"schema": {

...

"type": <data type name>,

// and other schema information key-values

<metadata key>: <metadata value>,

...

}

}

ข้อมูลแต่ละชนิด จะมี Metadata ที่แตกต่างกัน ซึ่ง Metadata เหล่านี้สามารถแบ่งได้เป็นสองชนิด คือ

1. Metadata ที่ระบบคำนวณได้โดยอัตโนมัติ ได้แก่

ชื่อ Key	คำอธิบาย	รูปแบบของ Metadata Value	ใช้กับข้อมูลชนิด
avg	ค่าเฉลี่ย (Average)	number	number
min	ค่าต่ำสุด (Minimum)	number	number, date, timestamp, duration
max	ค่าสูงสุด (Minimum)	number	number, date, timestamp, duration
uniqueCount	จำนวนค่าที่แตกต่างกัน	number (integer)	ทุกชนิด
missing	สัดส่วนของข้อมูลที่ขาดหายไป (0 คือข้อมูลครบทุก field, 1 คือไม่มีข้อมูลเลย)	number (in range [0,1])	ทุกชนิด
histogram	ค่าความถี่ของช่วงใน histogram ที่สร้างจากข้อมูล field นั้น (แบ่งเป็น 10 bins)	array of 10 numbers (e.g. [0.12, 0.14, 0.29, … (7 more)])	number, date, timestamp, duration
trueFreq	สัดส่วนของค่า boolean ที่มีค่าเป็น true (1 คือเป็น true ทุกค่า)	number (in range [0,1])	boolean
topValues	ค่าที่พบบ่อยที่สุด 3 อันดับแรก พร้อมความถี่ที่พบ	[ { "value": (any), "frequency": (number in range [0,1]) }, ... (2 more) ]	string, url, file_reference, email, geolocation

1. Metadata ที่ผู้ใช้กำหนด ได้แก่

ชื่อ Key	คำอธิบาย	รูปแบบของ Metadata Value	ใช้กับข้อมูลชนิด
timezone	เขตเวลา	string (in form of /(+|-)hh:mm)	timestamp
unit	หน่วยของตัวเลข	string	number