Data Lakehouse & Pipeline
Data Lakehouse & Pipeline คือแพลตฟอร์มคลังข้อมูลกลางสำหรับรวมข้อมูลจากระบบ ERP/MES ฐานข้อมูลเดิม ไฟล์ และอุปกรณ์ IoT ไว้ในที่เดียว ออกแบบให้ติดตั้งบนเซิร์ฟเวอร์ในองค์กร (On-Premise) จัดข้อมูลเป็น 3 ชั้น (Bronze–Silver–Gold) คุมสิทธิ์ได้ถึงระดับแถวและคอลัมน์ และเก็บในรูปแบบเปิดที่ไม่ผูกกับผู้ขายรายใด

สำรวจการใช้งานและรายละเอียด
- จัดข้อมูลเป็น 3 ชั้น Bronze–Silver–Gold (Medallion Architecture) บน Apache Iceberg
- รับข้อมูลทั้งแบบเป็นรอบ (Batch) และแบบต่อเนื่อง (Streaming) รวมถึงดึงเฉพาะส่วนที่เปลี่ยน (CDC) จากฐานข้อมูลเดิม
- คุมสิทธิ์ได้ถึงระดับแถวและคอลัมน์ ใช้บัญชี Active Directory / LDAP เดิมขององค์กร
ดูคุณสมบัติเพิ่มเติม
- ตรวจย้อนกลับได้ว่าตัวเลขในรายงานมาจากแหล่งใด (Data Lineage ระดับคอลัมน์)
- ซอฟต์แวร์ชั้นข้อมูลเป็น Open Source และเก็บข้อมูลในรูปแบบเปิด ส่วน nimitFlow คิดสิทธิ์ใช้งานตามใบเสนอราคา
เหมาะกับงานของคุณหรือไม่?
เหมาะกับใคร
ทีมไอทีและทีมข้อมูลที่ต้องรวมข้อมูลจากหลายระบบ
เตรียมข้อมูลก่อนคุย
รายชื่อระบบต้นทาง รูปแบบข้อมูล และสิทธิ์การเข้าถึงที่ต้องใช้
สรุปสั้น
- Data Lakehouse & Pipeline รวมข้อมูลที่แยกอยู่หลายระบบ (Data Silos) ไว้ในคลังกลางเดียว โดยไม่ต้องเปลี่ยนระบบ ERP/MES ที่ใช้อยู่
- ข้อมูลผ่าน 3 ชั้น: Bronze เก็บข้อมูลดิบ, Silver ตรวจและทำความสะอาด, Gold พร้อมใช้ทำรายงาน งานวิเคราะห์ และ AI
- ซอฟต์แวร์ชั้นข้อมูลเป็น Open Source เช่น Apache Iceberg, Spark, Kafka, Airflow, Trino และ MinIO และเก็บข้อมูลเป็นไฟล์รูปแบบเปิด (Parquet / Iceberg)
- ความปลอดภัยออกแบบไว้ตั้งแต่ต้น: Single Sign-On (ล็อกอินครั้งเดียวใช้ได้หลายแอป), สิทธิ์ระดับแถวและคอลัมน์, ปิดบังข้อมูลส่วนบุคคล, เข้ารหัส AES-256 และบันทึกการเข้าถึง (Audit Log)
- เราเสนอ Data Lakehouse เป็นโครงการตามขอบเขตงาน ราคาขึ้นกับจำนวนแหล่งข้อมูล ปริมาณข้อมูล และฮาร์ดแวร์
Data Lakehouse คืออะไร และแก้ปัญหาอะไร
Data Lakehouse คือคลังข้อมูลที่เก็บทั้งข้อมูลดิบและข้อมูลพร้อมวิเคราะห์ไว้ในระบบเดียว Data Lakehouse & Pipeline ของเรารวมข้อมูลจากระบบเดิมขององค์กร ไฟล์ และอุปกรณ์ที่เก็บข้อมูลอยู่แล้ว เข้าคลังกลางนี้ ข้อมูลผ่านการตรวจคุณภาพเป็นชั้น คุมสิทธิ์ได้ และตรวจย้อนกลับได้ว่ามาจากแหล่งใด จากนั้นข้อมูลชุดเดียวกันใช้ได้ทั้งรายงาน งานวิเคราะห์ และ AI เช่น Predictive Analytics และ Enterprise KM Chatbot
หลายองค์กรเก็บข้อมูลไว้คนละที่ ทั้งฐานข้อมูลของระบบ ERP/MES ไฟล์ Excel เครื่อง NAS และข้อมูลจากอุปกรณ์ในไลน์ผลิต การรวมข้อมูลมักใช้สคริปต์ตั้งเวลาที่ดูแลยาก รายงานจึงช้า และตรวจที่มาของตัวเลขได้ยาก เมื่อจะเริ่มงาน AI ก็ต้องรวบรวมและทำความสะอาดข้อมูลใหม่ทุกครั้ง
Data Lakehouse ต่างจาก Data Lake และ Data Warehouse อย่างไร
Data Lakehouse รวมข้อดีของ Data Lake (เก็บข้อมูลดิบได้ทุกรูปแบบในราคาต่อพื้นที่ต่ำ) กับ Data Warehouse (ตารางที่มีโครงสร้าง ค้นด้วย SQL ได้เร็ว) ไว้ในระบบเดียว ข้อมูลเก็บเป็นไฟล์รูปแบบเปิด (Parquet และ Apache Iceberg) บนพื้นที่เก็บข้อมูลแบบ S3 (มาตรฐานพื้นที่เก็บข้อมูลแบบออบเจกต์) จึงไม่ผูกกับผู้ขายรายใด
แบบเดิม
- สคริปต์ตั้งเวลา (Crontab / Shell Script) ดึงข้อมูลทีละระบบ
- ข้อมูลอ้างอิงอยู่ในไฟล์ Excel และเอกสารกระจัดกระจาย
- เก็บข้อมูลไว้บนเซิร์ฟเวอร์ภายในหรือ NAS
- ออกรายงานเป็นไฟล์ CSV/Excel ด้วยเครื่องมือ BI รุ่นเก่า
Data Lakehouse
- รับข้อมูลผ่าน Airflow (เป็นรอบ) และ Kafka (ต่อเนื่อง)
- จัดข้อมูลเป็นชั้น Bronze–Silver–Gold บน Apache Iceberg
- มี Data Catalog และ Lineage บอกที่มาของข้อมูล
- ค้นด้วย SQL ผ่าน Trino / Dremio ต่อ Tableau, Power BI และ Jupyter
สรุป: ข้อมูลชุดเดียวกันใช้ได้ทั้งรายงาน งานวิเคราะห์ และ AI
- รวมข้อมูลไว้ที่เดียว — เชื่อมข้อมูลจากอุปกรณ์ในโรงงาน แอปของ Inspektion ที่ส่งข้อมูลผ่าน nimitFlow และระบบ ERP/MES เดิม เข้าคลังกลางเดียว
- ลด Data Silos — เปลี่ยนข้อมูลที่แยกอยู่หลายระบบให้เป็นชุดเดียวที่ผ่านการตรวจคุณภาพแล้ว
- เป็นฐานให้ระบบอื่น — ส่งข้อมูลชั้น Gold ให้ Predictive Analytics, Enterprise KM Chatbot และเครื่องมือ BI ดึงไปใช้
Data Lakehouse ทำงานอย่างไร
Data Lakehouse & Pipeline ทำงานเป็น 5 ขั้น คือ เชื่อมแหล่งข้อมูล เก็บข้อมูลดิบ ตรวจและทำความสะอาด จัดข้อมูลพร้อมใช้ และเปิดให้ผู้ใช้ค้นข้อมูล ซอฟต์แวร์ในชั้นข้อมูลเป็น Open Source ส่วนการติดตามระบบใช้ nimitFlow ร่วมกับ Prometheus/Grafana
- 1
เชื่อมต่อแหล่งข้อมูล
รับข้อมูลจากฐานข้อมูล SQL (เช่น Oracle, PostgreSQL, MS SQL) API ไฟล์ Google Sheets และอุปกรณ์ IoT ด้วย Apache Airflow สำหรับงานเป็นรอบ และ Apache Kafka สำหรับข้อมูลต่อเนื่องหรือดึงเฉพาะส่วนที่เปลี่ยน (CDC)
- 2
Bronze — เก็บข้อมูลดิบ
เก็บข้อมูลตามรูปแบบต้นทางไว้ก่อน (Schema-on-read) จึงย้อนกลับมาประมวลผลใหม่ได้เมื่อกติกาเปลี่ยน
- 3
Silver — ตรวจและทำความสะอาด
Apache Spark ตรวจความถูกต้อง ทำความสะอาด และตัดข้อมูลซ้ำ ตามกฎคุณภาพข้อมูล (Data Quality Rule) แล้วเก็บเป็นตาราง Iceberg
- 4
Gold — ข้อมูลพร้อมใช้
สรุปและเสริมข้อมูลตามมุมมองธุรกิจ พร้อมสำหรับรายงาน BI งานวิเคราะห์ และ AI/ML
- 5
ใช้งานและติดตามระบบ
ผู้ใช้ค้นข้อมูลด้วย SQL ผ่าน Trino / Dremio ต่อ Tableau, Power BI หรือ Jupyter Notebook ส่วนฝ่ายไอทีเห็นสถานะทุกชั้นในจอเดียวผ่าน nimitFlow ร่วมกับ Prometheus/Grafana และรับแจ้งเตือนทาง LINE หรืออีเมล
ชั้นเก็บข้อมูล (Storage) แยกจากชั้นประมวลผล (Compute) คุณจึงเพิ่มพื้นที่หรือเพิ่มเครื่องประมวลผลแยกกันได้ตามปริมาณงาน โดยไม่ต้องหยุดระบบ ตาราง Iceberg รองรับการแก้ไขข้อมูลแบบ ACID (แต่ละครั้งบันทึกสำเร็จครบ หรือไม่บันทึกเลย) ย้อนดูข้อมูล ณ เวลาก่อนหน้า (Time Travel) และปรับโครงสร้างตารางได้โดยไม่ต้องสร้างใหม่
ข้อมูลเก็บที่ไหน และใครเข้าถึงได้บ้าง
ในสถาปัตยกรรมนี้ ข้อมูลเก็บบนเซิร์ฟเวอร์ในองค์กรของคุณ (On-Premise) และผู้ใช้เข้าถึงได้ตามสิทธิ์ของบทบาทเท่านั้น ข้อมูลที่รวมไว้ที่เดียวต้องคุมการเข้าถึงให้รัดกุมกว่าเดิม เราจึงออกแบบการยืนยันตัวตน การคุมสิทธิ์ การเข้ารหัส และการบันทึกการเข้าถึงไว้ตั้งแต่ต้น ตามรายการด้านล่าง
- ยืนยันตัวตน — Keycloak เชื่อมบัญชีผู้ใช้จาก Active Directory / LDAP แล้วทำ Single Sign-On ให้แอปด้วย OIDC/SAML (มาตรฐานการล็อกอินร่วม) ขององค์กร รองรับการยืนยันตัวตนหลายขั้น (MFA)
- คุมสิทธิ์ — Apache Ranger กำหนดสิทธิ์จากศูนย์กลางได้ถึงระดับฐานข้อมูล ตาราง คอลัมน์ และแถว ตามบทบาทของผู้ใช้ (RBAC หรือสิทธิ์ตามบทบาท)
- ปิดบังข้อมูลอ่อนไหว — ปิดบังหรือแทนค่า (Masking / Tokenization) ข้อมูลส่วนบุคคลระดับคอลัมน์
- เข้ารหัส — ข้อมูลที่เก็บเข้ารหัสแบบ AES-256 และการรับส่งข้อมูลใช้ TLS 1.2 ขึ้นไป
- ตรวจสอบย้อนหลัง — เก็บ Audit Log ทุกการเข้าถึงและการเปลี่ยนสิทธิ์ ส่งต่อระบบเฝ้าระวังความปลอดภัย (SIEM) ขององค์กรได้
- บอกที่มาของข้อมูล — OpenMetadata ทำสารบบข้อมูล (Data Catalog) อภิธานศัพท์ธุรกิจ (Business Glossary) และเส้นทางที่มาของข้อมูล (Data Lineage) ระดับคอลัมน์
ตัวอย่างการแบ่งสิทธิ์ตามบทบาท (ปรับร่วมกับคุณในขั้นออกแบบ)
| บทบาท | Bronze | Silver | Gold |
|---|---|---|---|
| Data Engineer | อ่าน/เขียน | อ่าน/เขียน | เขียนผ่าน Pipeline |
| Data Analyst / BI | ไม่มีสิทธิ์ | อ่านเฉพาะส่วนงาน | อ่าน |
| Data Scientist | อ่าน (ข้อมูลส่วนบุคคลถูกปิดบัง) | อ่าน | อ่าน |
| Auditor / Compliance | อ่าน Audit Log | อ่าน Audit Log | อ่าน + Lineage |
Data Lakehouse เหมาะกับงานไหน และไม่เหมาะกับงานไหน
Data Lakehouse เหมาะกับองค์กรที่มีข้อมูลอยู่หลายระบบ ต้องการรายงานจากข้อมูลชุดเดียวกัน และต้องเก็บข้อมูลไว้ในองค์กร Data Lakehouse ไม่เหมาะกับองค์กรที่ข้อมูลยังน้อยหรือมาจากไม่กี่แหล่ง เพราะฐานข้อมูลกลางหรือ nimitFlow อาจพอสำหรับเริ่มต้น ถ้าเครื่องจักรยังไม่มีระบบเก็บข้อมูล ต้องมีอุปกรณ์เก็บข้อมูลหรือระบบต้นทางก่อน เช่น อุปกรณ์เก็บข้อมูลจากเซนเซอร์ InSensor เราประเมินจากปริมาณข้อมูลและจำนวนระบบต้นทางก่อนเสนอแนวทาง
งานที่เหมาะและไม่เหมาะกับ Data Lakehouse
| งาน | เหมาะกับ Data Lakehouse ไหม | เหตุผลหรือสิ่งที่ต้องทำ |
|---|---|---|
| ข้อมูลอยู่หลายระบบ (ERP, MES, ฐานข้อมูล, ไฟล์) และต้องการรายงานจากข้อมูลชุดเดียวกัน | เหมาะ | รวมเข้าคลังกลางและตรวจคุณภาพเป็นชั้นก่อนออกรายงาน |
| ต้องเก็บข้อมูลไว้ในองค์กร คุมสิทธิ์ละเอียด และตรวจการเข้าถึงย้อนหลัง | เหมาะ | ติดตั้ง On-Premise คุมสิทธิ์ด้วย Ranger และเก็บ Audit Log |
| เตรียมข้อมูลการผลิต เครื่องจักร และคุณภาพ ให้ Predictive Analytics หรือ AI | เหมาะ | งาน AI ดึงข้อมูลชั้น Gold ที่ผ่านการตรวจแล้วไปใช้ |
| ฝ่ายไอทีต้องการระบบมาตรฐานเปิด ไม่ผูกกับผู้ขายรายเดียว | เหมาะ | ข้อมูลเก็บเป็น Parquet / Iceberg บนมาตรฐาน S3 API |
| ข้อมูลยังน้อยหรือมาจากไม่กี่แหล่ง | อาจยังไม่จำเป็น | เริ่มจากฐานข้อมูลกลางหรือ nimitFlow ก่อน แล้วค่อยขยาย |
| นโยบายข้อมูลกำหนดให้ใช้ Cloud | ประเมินเป็นรายโครงการ | สถาปัตยกรรมนี้ออกแบบสำหรับเซิร์ฟเวอร์ในองค์กร |
| เครื่องจักรยังไม่มีระบบเก็บข้อมูล | ต้องมีอุปกรณ์เก็บข้อมูลหรือระบบต้นทางก่อน | Data Lakehouse รับข้อมูลจากระบบหรืออุปกรณ์ที่มีอยู่ ไม่ได้อ่านสัญญาณจากเครื่องจักรเอง |
เราเคยทำงานข้อมูลแบบไหน และเรียนรู้อะไร
เราเคยรวมข้อมูลการผลิตและข้อมูลบริหารให้ผู้ผลิตชิ้นส่วนยานยนต์ในไทย และเคยเตรียมข้อมูลธุรกรรมเพื่อสอนโมเดล Machine Learning ให้องค์กรในภาคการเงินของไทย Data Lakehouse ตามสถาปัตยกรรมในหน้านี้ยังไม่มีโครงการที่ส่งมอบแล้ว สถาปัตยกรรมนี้มาจากข้อเสนอโครงการล่าสุดของเรา งานด้านล่างจึงเป็นงานข้อมูลที่ใกล้เคียงที่สุด ไม่ใช่โครงการ Data Lakehouse
- ปี 2565–2566 เราย้ายเว็บข้อมูลการผลิตของ 11 ไลน์ผลิตขึ้นเซิร์ฟเวอร์กลาง VMware ของโรงงาน ให้ผู้ผลิตชิ้นส่วนยานยนต์ในไทย เพราะฝ่ายไอทีของโรงงานแยกเครือข่ายสำนักงานออกจากเครือข่ายไลน์ผลิตตามนโยบายความปลอดภัย งานบนเซิร์ฟเวอร์ทำร่วมกับฝ่ายไอทีของลูกค้า ซึ่งเป็นผู้กำหนด IP พอร์ต และสิทธิ์การติดตั้ง
- ปี 2566–2567 เราพัฒนาเว็บแอปฐานข้อมูลกลางบน Google Cloud ให้ผู้ผลิตชิ้นส่วนยานยนต์รายเดียวกัน รวม KPI ความสูญเสียภายใน ของเสีย ผลผลิต ยอดขาย และกำไร จากไฟล์รายงานหลายชุดไว้ในเว็บเดียว ระบบเฟสแรกลงนามตรวจรับในปี 2566 ส่วนโมดูลเคลมลูกค้ายังอยู่ในรอบปรับแก้และตรวจความถูกต้องของข้อมูลต่อในต้นปี 2567
- ปี 2564–2566 เราพัฒนาระบบ Machine Learning ให้องค์กรในภาคการเงินของไทย ระบบนำข้อมูลธุรกรรมการชำระเงินมาทำความสะอาด แล้วสอนโมเดลให้พยากรณ์ความผิดปกติของเวลาตอบสนองล่วงหน้า 5 และ 10 นาที ระบบติดตั้งบนเซิร์ฟเวอร์ของลูกค้าแยกจากระบบรับส่งรายการ เราจัดทำเอกสารปิดโครงการในปี 2565 แล้วโครงการเข้าสู่ช่วงบำรุงรักษาตามสัญญา
อ่านเคสงานข้อมูลที่เราทำ
สิ่งที่เราเรียนรู้
นโยบายความปลอดภัยของฝ่ายไอทีเป็นตัวกำหนดว่าข้อมูลวางที่ไหน และเปิดให้เข้าถึงจากเครือข่ายใดได้ ในงานรวมข้อมูลทั้งสองงานของผู้ผลิตชิ้นส่วนยานยนต์ ฝ่ายไอทีของลูกค้าเป็นผู้กำหนดเครือข่าย สิทธิ์การติดตั้ง และแบบตรวจความปลอดภัยของระบบบนคลาวด์ การออกแบบจึงต้องทำร่วมกับฝ่ายไอทีตั้งแต่ต้น
ตัวเลขจากไฟล์รายงานเดิมต้องตรวจเทียบกับรายงานต้นฉบับก่อนให้ผู้ใช้ใช้ตัดสินใจ งานตรวจความถูกต้องของข้อมูลและปรับตามความเห็นของผู้ใช้ดำเนินต่อหลังส่งมอบเฟสแรก จึงต้องวางไว้ในแผนตั้งแต่ต้น ส่วนงาน AI ต้องเริ่มจากทำความสะอาดข้อมูลก่อนสอนโมเดล และควรแยกระบบใหม่ออกจากระบบงานหลัก เพื่อไม่กระทบการให้บริการ
แปลว่าอะไรสำหรับคุณ
โครงการ Data Lakehouse ของคุณจึงเริ่มจากสำรวจระบบต้นทางและนโยบายความปลอดภัยร่วมกับฝ่ายไอทีของคุณ แล้วสร้างเส้นทางส่งข้อมูลจาก Bronze ถึง Gold กับข้อมูลชุดนำร่องก่อน คุณตรวจตัวเลขในชั้น Gold เทียบกับรายงานเดิมที่ใช้อยู่ เมื่อตัวเลขตรงกันจึงขยายไปแหล่งข้อมูลอื่น
ขั้นตอนโครงการและสิ่งที่ส่งมอบ
เราวางโครงการ Data Lakehouse เป็น 5 ขั้น ได้แก่ ออกแบบรายละเอียด ติดตั้งเซิร์ฟเวอร์และแพลตฟอร์ม เชื่อมข้อมูลและตั้งค่าความปลอดภัย ทดสอบและเริ่มใช้งาน และดูแลหลังเริ่มใช้งานพร้อมถ่ายทอดความรู้ ช่วงดูแลเข้มข้นหลังเริ่มใช้งาน (Hypercare) และการถ่ายทอดความรู้ กำหนดไว้ในขอบเขตงานได้ เพื่อให้ฝ่ายไอทีของคุณดูแลระบบต่อเอง
- 1
ออกแบบรายละเอียด
ยืนยันความต้องการ ออกแบบระบบภาพรวมและรายละเอียด (HLD/LLD) ตารางสิทธิ์ นโยบายอายุข้อมูล และแผนทดสอบ
- 2
ติดตั้งเซิร์ฟเวอร์และแพลตฟอร์ม
ติดตั้งเครื่อง ระบบปฏิบัติการ Linux ตั้งค่าความปลอดภัยตาม CIS Benchmark แล้วติดตั้งองค์ประกอบของแพลตฟอร์ม
- 3
เชื่อมข้อมูลและตั้งค่าความปลอดภัย
สร้างเส้นทางส่งข้อมูล (Pipeline) จาก Bronze ถึง Gold กับข้อมูลชุดนำร่อง เชื่อม SSO ตั้งสิทธิ์ การเข้ารหัส และ Audit
- 4
ทดสอบและเริ่มใช้งาน
ทดสอบร่วมกับผู้ใช้ (UAT) แก้ข้อบกพร่อง แล้วย้ายขึ้นใช้งานจริง
- 5
ดูแลหลังเริ่มใช้งานและถ่ายทอดความรู้
กำหนดช่วงดูแลหลังเริ่มใช้งานและ Workshop ของแต่ละทีมไว้ในขอบเขตงานที่ตกลง
เอกสารส่งมอบทำเป็นภาษาไทย (คงศัพท์เทคนิคภาษาอังกฤษ) ได้แก่ เอกสารออกแบบระบบ คู่มือติดตั้ง คู่มือบริหารระบบ คู่มือปฏิบัติการประจำวัน คู่มือติดตามระบบ เอกสารตั้งค่าการแจ้งเตือน คู่มือแก้ปัญหา เอกสาร UAT เอกสารระบบตามที่ติดตั้งจริง (As-Built) และเอกสารอบรม
ตัวอย่างระยะเวลา
แผนงานในข้อเสนอโครงการล่าสุดของเราระบุแผนประมาณ 22 สัปดาห์ และช่วง Hypercare 60 วันหลังเริ่มใช้งานที่อาจต่อเนื่องเกินแผนดังกล่าว และถ่ายทอดความรู้ไม่น้อยกว่า 30 ชั่วโมง ระยะเวลาจริงขึ้นกับจำนวนแหล่งข้อมูลและความพร้อมของระบบต้นทาง
สเปคทางเทคนิค
| ชื่อแพลตฟอร์ม | Enterprise Data Lakehouse Platform (ไม่มีรหัสรุ่น — จัดชุดตามโครงการ) |
|---|---|
| สถาปัตยกรรม | Open Data Lakehouse แบบ Medallion (Bronze–Silver–Gold) แยก Storage กับ Compute |
| รูปแบบตาราง / ไฟล์ | Apache Iceberg (ACID, Time Travel, Schema Evolution) · Parquet |
| พื้นที่เก็บข้อมูล | MinIO (S3-Compatible) พร้อม Erasure Coding และ Object Versioning |
| รับข้อมูล (Ingestion) | Apache Airflow (Batch: JDBC / API / ไฟล์) · Apache Kafka (Streaming, CDC) |
| ประมวลผล | Apache Spark พร้อม Data Quality Framework |
| ค้นข้อมูล (Query) | Trino / Dremio — SQL สำหรับ BI และงานวิเคราะห์ |
| Catalog / Lineage | OpenMetadata — Data Catalog, Business Glossary, Lineage ระดับคอลัมน์ |
| ความปลอดภัย | Apache Ranger (RBAC ถึงแถว/คอลัมน์, Masking) · Keycloak (SSO, MFA) |
| การเข้ารหัส | AES-256 ขณะจัดเก็บ · TLS 1.2 ขึ้นไประหว่างรับส่ง |
| ติดตามระบบ | nimitFlow + Prometheus / Grafana — แจ้งเตือนทาง LINE / อีเมล |
| รูปแบบติดตั้ง | On-Premise บนเซิร์ฟเวอร์ Linux ขององค์กร |
องค์ประกอบตามสถาปัตยกรรมที่ Inspektion เสนอในโครงการล่าสุด (ก.ค. 2569) — ขนาดเครื่องและองค์ประกอบปรับตามปริมาณข้อมูลและขอบเขตงานของแต่ละองค์กร
สถาปัตยกรรมและการเชื่อมต่อ
ระบบที่เชื่อมต่อได้
- ฐานข้อมูล SQL — Oracle, PostgreSQL, MS SQL (JDBC)
- REST API และไฟล์ (Excel, CSV, Google Sheets)
- ข้อมูลต่อเนื่องผ่าน Apache Kafka และ CDC จากฐานข้อมูลต้นทาง
- ระบบ ERP/MES เดิมขององค์กร ผ่านฐานข้อมูลหรือ API
- อุปกรณ์ IoT และแอป Inspektion ผ่าน nimitFlow
- Tableau / Power BI / Jupyter Notebook
- Active Directory / LDAP (ผ่าน Keycloak)
- ระบบ SIEM สำหรับ Audit Log
- Predictive Analytics
- Enterprise KM Chatbot
ความต้องการระบบ
- เซิร์ฟเวอร์ในองค์กรแยกเป็นเครื่องประมวลผล (Compute Node) และเครื่องเก็บข้อมูล (Storage Node) — เพิ่มเครื่องภายหลังได้โดยไม่หยุดระบบ
- ระบบปฏิบัติการ Linux สำหรับเซิร์ฟเวอร์ (ข้อเสนอล่าสุดใช้ Red Hat Enterprise Linux 9) ตั้งค่าความปลอดภัยตาม CIS Benchmark
- เครือข่ายความเร็วสูงระหว่างเซิร์ฟเวอร์แบบรวมลิงก์ (LACP) และเส้นทางเชื่อมไปยังระบบต้นทาง
- ขนาดเครื่องคำนวณจากปริมาณข้อมูลเข้าต่อวัน ระยะเวลาที่ต้องเก็บข้อมูล และนโยบายเก็บรักษาข้อมูล — ทีมงานประเมินให้ก่อนเสนอราคา
- Active Directory / LDAP ขององค์กร หากต้องการ Single Sign-On
- หากนโยบายข้อมูลต้องการติดตั้งบน Cloud ทีมงานประเมินความเหมาะสมเป็นรายโครงการ
รูปแบบลิขสิทธิ์
ประเมินราคาตามขอบเขตงาน
ซอฟต์แวร์ชั้นข้อมูลเป็น Open Source ส่วน nimitFlow มีสิทธิ์ใช้งานตามใบเสนอราคา ค่าใช้จ่ายรวมฮาร์ดแวร์ ระบบปฏิบัติการ งานติดตั้ง เชื่อมข้อมูล และบริการดูแลตามขอบเขตงาน
- เสนอราคาเป็นโครงการ ตามจำนวนแหล่งข้อมูล ปริมาณข้อมูล และระยะเวลาดูแลที่ต้องการ
- ระบบปฏิบัติการสำหรับเซิร์ฟเวอร์ (เช่น Red Hat Enterprise Linux) มีค่า Subscription ตามผู้ผลิต
- ข้อมูลเก็บในรูปแบบเปิด (Parquet / Iceberg บนมาตรฐาน S3 API) ย้ายหรือต่อยอดด้วยเครื่องมืออื่นได้
เริ่มต้นอย่างไร
เริ่มจากนัดคุยโจทย์กับเรา เราสำรวจระบบต้นทาง รูปแบบข้อมูล และนโยบายความปลอดภัยขององค์กรคุณ แล้วประเมินขนาดระบบจากปริมาณข้อมูล จากนั้นเสนอขอบเขตงานพร้อมใบเสนอราคา
เตรียมอะไรมาบ้าง
- รายชื่อระบบต้นทาง (ERP, MES, ฐานข้อมูล, ไฟล์, อุปกรณ์) และรูปแบบข้อมูลของแต่ละระบบ
- ปริมาณข้อมูลเข้าต่อวันโดยประมาณ และระยะเวลาที่ต้องเก็บข้อมูล
- สิทธิ์การเข้าถึงที่ต้องใช้ และนโยบายความปลอดภัยข้อมูลขององค์กร (เช่น ใช้ Active Directory หรือไม่)
- รายงานหรืองานวิเคราะห์ที่อยากได้เป็นอันดับแรก และเครื่องมือ BI ที่ใช้อยู่
คำถามที่พบบ่อย
ต้องเปลี่ยนระบบ ERP/MES เดิมไหม?
ไม่ต้อง Data Lakehouse ดึงข้อมูลจากระบบเดิมผ่านฐานข้อมูล (JDBC) API ไฟล์ หรือ CDC ระบบ ERP/MES ที่คุณใช้อยู่จึงทำงานต่อได้ตามเดิม
ต้องเสียค่า License รายปีไหม?
ไม่มีค่า License รายปีของซอฟต์แวร์ชั้นข้อมูล เพราะเป็น Open Source ส่วน nimitFlow ที่ใช้ติดตามระบบเป็นซอฟต์แวร์ของ Inspektion และคิดตามใบเสนอราคา ค่าใช้จ่ายหลักคือฮาร์ดแวร์ ระบบปฏิบัติการ สิทธิ์ใช้ nimitFlow งานติดตั้งและเชื่อมข้อมูล และบริการดูแลระบบ
ข้อมูลต้องออกนอกองค์กรไหม?
ข้อมูลไม่ต้องออกนอกองค์กร เพราะสถาปัตยกรรมนี้ออกแบบให้ติดตั้งบนเซิร์ฟเวอร์ในองค์กร (On-Premise) หากนโยบายข้อมูลต้องการใช้ Cloud เราประเมินความเหมาะสมเป็นรายโครงการตามนโยบายและงบประมาณขององค์กร
ควบคุมสิทธิ์การเข้าถึงข้อมูลได้ละเอียดแค่ไหน?
ละเอียดถึงระดับแถว Apache Ranger กำหนดสิทธิ์ได้ถึงระดับตาราง คอลัมน์ และแถว ปิดบังข้อมูลส่วนบุคคลระดับคอลัมน์ได้ และทุกการเข้าถึงถูกบันทึกเป็น Audit Log
ฝ่ายไอทีในองค์กรดูแลระบบเองได้ไหม?
ได้ ซอฟต์แวร์ชั้นข้อมูลเป็น Open Source และข้อมูลเก็บในรูปแบบเปิด คุณกำหนด Workshop ถ่ายทอดความรู้ตามบทบาทพร้อมคู่มือภาษาไทยไว้ในขอบเขตงานได้ เมื่อผ่านการถ่ายทอดความรู้แล้ว ฝ่ายไอทีของคุณบริหารและต่อยอดระบบได้เอง
ราคาและระยะเวลาเท่าไร?
ขึ้นกับจำนวนแหล่งข้อมูล ปริมาณข้อมูล และฮาร์ดแวร์ที่ต้องใช้ ติดต่อทีมงานเพื่อประเมินขอบเขตงานและขอใบเสนอราคา ตัวอย่างข้อเสนอล่าสุดวางแผนประมาณ 22 สัปดาห์ โดยช่วงดูแลหลังเริ่มใช้งานอาจต่อเนื่องเกินแผนดังกล่าว




