# Data ELT กระบวนการเตรียมข้อมูลให้พร้อมสำหรับงาน Data Analytics

ในแต่ละองค์กรย่อมมี[ข้อมูลหลากหลายเรื่อง](https://blog.sidata.plus/siriraj-data-timeline#heading-data-areas) จากแหล่งข้อมูลต่าง ๆ จำนวนมาก ถ้าถามว่า "สามารถนำข้อมูลจากแหล่งต้นทางเหล่านี้มาใช้สำหรับงานวิเคราะห์ตรง ๆ เลยจะได้ไหม" ก็ต้องตอบว่า "ได้ ...แต่ไม่มีประสิทธิภาพ" เพราะจะเจอกับประเด็นต่าง ๆ เช่น

1. ต้องมาอัพเดทข้อมูลให้เป็นปัจจุบันเอง (ถ้าต้องการข้อมูลเพื่อตอบปัญหาครั้งเดียวจบ ก็จะไม่มีปัญหานี้)

2. ข้อมูลแต่ละระบบเก็บไม่เหมือนกัน เช่น ข้อมูลเดียวกันแต่ชื่อ column/field ไม่เหมือนกัน (ตัวอย่าง รหัสบุคลากรอาจจะเก็บเป็น EmployeeID, empID, employee_no) หรือ ชื่อ column/field เดียวกันแต่เนื้อข้อมูลต่างกัน (ตัวอย่าง employee_type อาจหมายถึง ประเภทการจ้างงาน, ประเภทบุคลากร, ประเภทเงินเดือน เป็นต้น)

3. ข้อมูลที่เก็บที่ต้นทาง หรือ application database มักจะถูก design มาสำหรับการใช้งานในรูปแบบ transaction ซึ่งมีความต้องการแตกต่างจากการวิเคราะห์ analytics ที่อาจจะต้องมีการคำนวน และการเชื่อมโยงกับข้อมูลอื่น ๆ เพิ่มเติม

4. การตรวจสอบความถูกต้องของข้อมูล จะทำให้ผู้ใช้งานข้อมูลเชื่อมั่นได้อย่างไรว่า ข้อมูลมีความถูกต้อง เป็นปัจจุบัน ไม่หาย ไม่ซ้ำ

5. การรักษาความปลอดภัย (security) และความเป็นส่วนตัว (privacy) ของข้อมูลที่กระจัดกระจายอยู่ จะทำให้ควบคุมการใช้งานได้ยาก และเมื่อมีกฎหมายทั้ง พ.ร.บ. Cybersecurity และ PDPA ต้องยิ่งควบคุมให้ดี มิเช่นนั้นก็จะมีบทลงโทษต่อองค์กร

จากตัวอย่างประเด็นข้างต้น กระบวนการ ELT จะเข้ามาช่วยคลี่คลายประเด็นเหล่านี้ และช่วยให้การจัดการ Data มีประสิทธิภาพมากยิ่งขึ้น

![Data ELT](https://cdn.hashnode.com/res/hashnode/image/upload/v1650868511591/RgKYhWXfG.png)


### Source

ในศิริราช มีข้อมูลอยู่ 3 แหล่งหลัก ๆ 

1. Databases ที่เก็บข้อมูลจากระบบในโรงพยาบาลต่าง ๆ เช่น OPD, IPD, Lab, Pharmacy, Finance, HR และอื่น ๆ

2. Spreadsheets ข้อมูลที่เก็บในไฟล์เป็นตาราง เช่น ตัวชี้วัด KPIs จากหน่วยงานต่าง ๆ, ระบบเก็บข้อมูลที่ไม่ใช่ Database เป็นต้น

3. APIs ที่คืนค่ามาเป็น JSON ผ่านระบบ Data Service Layer (DSL) ซึ่งเป็น integration gateway กลาง เชื่อมโยงข้อมูลจากระบบต่าง ๆ มาส่งให้ เช่น Data Registry เป็นต้น

กรณี Databases (NoSQL), Spreadsheets, APIs จะมีการแปลงข้อมูล (Transformation) ให้อยู่ในรูปแบบ Tabular relations (SQL-compatible)

> แต่ละ source เปรียบเสมือน ปลา แต่ละชนิด ใน 1 แม่น้ำ



### Data Lake

นำข้อมูลออกมาจาก source ต่าง ๆ (Extract) มารวมกันในแหล่งเดียว เพื่อให้ง่ายต่อการจัดการ และเมื่อแยกส่วนออกจาก Application Database การทำงานใน Data Lake ก็จะไม่ไปกระทบกับ Database ต้นทาง

> เปรียบเสมือน ปลาหลายชนิด จาก หลายแม่น้ำ ไหลมารวมกัน (Extract & Load) ในทะเลสาบ (Lake) 


### Data Warehouse

นำข้อมูลจาก Lake มาจัดระเบียบและแปลงโครงสร้าง (Transformation) ให้อยู่ในรูปแบบที่สามารถนำข้อมูลไปใช้ต่อได้ง่ายขึ้น เช่น Unified Star Schema, OMOP CDM เป็นต้น โดยอาจมีการนำ Data จากหลาย table มาเชื่อมโยงกัน (Join) เพื่อเติมข้อมูลให้สมบูรณ์ขึ้น และจัดวางบน shelf ชั้นวางในคลังข้อมูลให้เรียบร้อย

ในขั้นนี้สามารถเริ่มนำ Data ไปใช้งานต่าง ๆ เช่น การทำ Dashboard, การทำ ML & AI เป็นต้น ได้บ้างแล้ว แต่ยังต้องอาศัยผู้ที่มีความเข้าใจข้อมูลพอสมควรในการใช้งาน เช่น การ Join, Group By, Pivot เป็นต้น 

> เปรียบเสมือน ทีม Data specialists ที่มีความรู้ในการตกปลา (Transformation) ไปจับปลาชนิดที่ต้องการ มาเก็บไว้ในคลัง 



### Data Mart


นำข้อมูลจาก Data Warehouse มาปรับโครงสร้าง ให้พร้อมใช้งานได้มากที่สุด โดยที่ผู้ใช้งานที่ได้รับอนุญาตสามารถหยิบข้อมูลควบคู่กับคำอธิบายไปใช้ได้โดยง่าย

> เปรียบเสมือน ทีม Data specialists แล่ปลา (Transformation) ให้พร้อมไปวางขายใน supermarket ทำให้ผู้ใช้งานข้อมูล (Data users) สามารถซื้อไปปรุงอาหารต่อได้ง่าย (Data products) โดยที่ไม่ต้องตกปลาหรือแล่ปลาเป็น




---
แนะนำแหล่งศึกษาเพิ่มเติม
- [The Informed Company by Dave Fowler and Matthew C. David](https://theinformedcompany.com/)
- [Unified Star Schema by Francesco Puppini](https://technicspub.com/uss/)
- [Fundamentals of Data Engineering by Joe Reis & Matt Housley](https://learning.oreilly.com/library/view/fundamentals-of-data/9781098108298/)