Feature Store Feast CI CD Automation Pipeline — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog
ในโลกของการพัฒนาโมเดล Machine Learning (ML) ที่ก้าวหน้าอย่างรวดเร็วในปี 2026 ความสามารถในการจัดการฟีเจอร์ (Features) ที่ป้อนเข้าสู่โมเดลได้อย่างมีประสิทธิภาพและเชื่อถือได้ ถือเป็นหัวใจสำคัญสู่ความสำเร็จ การทำ MLOps (Machine Learning Operations) ให้มีประสิทธิภาพสูงสุดไม่ได้จำกัดอยู่แค่การเทรนและ Deploy โมเดลเท่านั้น แต่ยังรวมถึงการจัดการวงจรชีวิตของฟีเจอร์ ตั้งแต่การสร้าง การจัดเก็บ การนำไปใช้ ไปจนถึงการมอนิเตอร์
บทความนี้จะพาคุณเจาะลึกถึง “Feature Store” โดยเฉพาะอย่างยิ่ง “Feast” ซึ่งเป็น Open-Source Feature Store ยอดนิยม และวิธีการผสานรวมเข้ากับ Pipeline การทำงานอัตโนมัติแบบ CI/CD (Continuous Integration/Continuous Delivery) เพื่อสร้างระบบ MLOps ที่แข็งแกร่ง ยืดหยุ่น และพร้อมรับมือกับความท้าทายของข้อมูลและโมเดลในอนาคต เราจะสำรวจตั้งแต่แนวคิดพื้นฐาน สถาปัตยกรรม ไปจนถึง Best Practices และ Use Cases ในโลกแห่งความเป็นจริง เพื่อให้คุณสามารถนำไปประยุกต์ใช้และยกระดับการทำงานด้าน ML ขององค์กรได้อย่างเต็มศักยภาพ
จินตนาการถึง “Feast” ในบริบทนี้ไม่ใช่แค่การเฉลิมฉลอง แต่เป็นการรวบรวมและจัดเตรียม “อาหาร” หรือ “ฟีเจอร์” ที่มีคุณภาพสูงสุดสำหรับโมเดล ML ของคุณ เพื่อให้พวกมัน “กินดีอยู่ดี” และทำงานได้อย่างมีประสิทธิภาพสูงสุด เหมือนกับการจัดเตรียมวัตถุดิบชั้นเลิศสำหรับเชฟมืออาชีพ เพื่อรังสรรค์เมนูที่สมบูรณ์แบบ Pipeline อัตโนมัติแบบ CI/CD จึงเปรียบเสมือนระบบครัวอัจฉริยะที่ช่วยให้การจัดเตรียมวัตถุดิบเหล่านี้เป็นไปอย่างราบรื่น รวดเร็ว และแม่นยำทุกขั้นตอน
ทำความเข้าใจ Feature Store: หัวใจสำคัญของ MLOps ยุคใหม่
ก่อนที่เราจะดำดิ่งสู่รายละเอียดของ Feast และ CI/CD เรามาทำความเข้าใจแนวคิดพื้นฐานของ Feature Store กันก่อน Feature Store คืออะไร และทำไมมันถึงกลายเป็นองค์ประกอบสำคัญที่ขาดไม่ได้ในระบบ MLOps สมัยใหม่?
Feature Store คืออะไร?
Feature Store คือพื้นที่จัดเก็บแบบรวมศูนย์ที่ทำหน้าที่เป็นแหล่งข้อมูลที่เชื่อถือได้สำหรับฟีเจอร์ที่ใช้ในการฝึกอบรม (Training) และการให้บริการ (Serving) โมเดล Machine Learning มันช่วยให้ทีม ML สามารถกำหนด จัดเก็บ ค้นหา และนำฟีเจอร์กลับมาใช้ใหม่ได้อย่างสม่ำเสมอและมีประสิทธิภาพ
ลองนึกภาพว่าฟีเจอร์ต่างๆ เช่น , , หรือ เป็นส่วนผสมสำคัญที่ใช้ในการสร้างโมเดล ML หลายตัว หากแต่ละทีมหรือแต่ละโมเดลต้องสร้างฟีเจอร์เหล่านี้ขึ้นมาใหม่ทุกครั้งจากข้อมูลดิบ จะเกิดปัญหาอะไรบ้าง?
- ความไม่สอดคล้องกัน (Inconsistency): ฟีเจอร์เดียวกันอาจถูกคำนวณต่างกัน ทำให้ผลลัพธ์ของโมเดลไม่น่าเชื่อถือ
- การทำงานซ้ำซ้อน (Duplication of Effort): ทีมต่างๆ ต้องเสียเวลาสร้างฟีเจอร์เดิมๆ ซ้ำแล้วซ้ำเล่า
- ความล่าช้าในการพัฒนา (Slow Development): การสร้างฟีเจอร์ใหม่หรือการปรับปรุงฟีเจอร์ที่มีอยู่ต้องใช้เวลานาน
- ปัญหา Training-Serving Skew: ความแตกต่างระหว่างข้อมูลที่ใช้ในการฝึกอบรมกับข้อมูลที่ใช้ในการอนุมาน (Inference) ซึ่งนำไปสู่ประสิทธิภาพของโมเดลที่ลดลง
- การจัดการที่ยุ่งยาก (Operational Overhead): การติดตามและจัดการฟีเจอร์จำนวนมากกลายเป็นเรื่องซับซ้อน
Feature Store ถูกสร้างขึ้นมาเพื่อแก้ปัญหาเหล่านี้ โดยทำหน้าที่เป็นสะพานเชื่อมระหว่าง Data Engineering และ Machine Learning Engineering ช่วยให้ฟีเจอร์ถูกสร้างขึ้นเพียงครั้งเดียว จัดเก็บอย่างเป็นระบบ และสามารถนำไปใช้ได้ทั้งในขั้นตอนการฝึกอบรม (Offline Store) และการอนุมานแบบเรียลไทม์ (Online Store) โดยรับประกันความสอดคล้องกัน
ส่วนประกอบหลักของ Feature Store
Feature Store โดยทั่วไปประกอบด้วยส่วนประกอบสำคัญหลายส่วน:
- Feature Definitions (คำจำกัดความฟีเจอร์): Metadata ที่อธิบายฟีเจอร์ เช่น ชื่อ ชนิดข้อมูล แหล่งที่มาของข้อมูลดิบ ตรรกะการคำนวณ และเอนทิตีที่เกี่ยวข้อง (เช่น , )
- Offline Store: พื้นที่จัดเก็บข้อมูลฟีเจอร์เชิงประวัติศาสตร์ (Historical Feature Data) ที่มีขนาดใหญ่ มักใช้สำหรับการฝึกอบรมโมเดล มักเป็น Data Lake หรือ Data Warehouse เช่น S3, GCS, HDFS, BigQuery, Snowflake
- Online Store: พื้นที่จัดเก็บฟีเจอร์ล่าสุด (Latest Feature Data) ที่ออกแบบมาเพื่อการเข้าถึงข้อมูลด้วยความหน่วงต่ำ (Low Latency) สำหรับการอนุมานแบบเรียลไทม์ มักเป็นฐานข้อมูล NoSQL หรือ In-memory Cache เช่น Redis, DynamoDB, Cassandra
- Feature Retrieval API: API สำหรับดึงฟีเจอร์จากทั้ง Online และ Offline Store โดยอัตโนมัติ ทำให้ผู้ใช้ไม่ต้องกังวลถึงแหล่งที่มาของข้อมูล
- Metadata Management: ระบบสำหรับการจัดการข้อมูลเกี่ยวกับฟีเจอร์ เช่น รุ่น (Version), เจ้าของ (Owner), คำอธิบาย (Description), และการตรวจสอบคุณภาพข้อมูล (Data Quality Checks)
ประโยชน์ของ Feature Store
การนำ Feature Store มาใช้ใน MLOps Pipeline มอบประโยชน์มากมาย:
- ความสอดคล้องระหว่าง Training และ Serving: นี่คือประโยชน์ที่สำคัญที่สุด Feature Store ช่วยให้มั่นใจว่าฟีเจอร์ที่โมเดลใช้ในการฝึกอบรมนั้นเหมือนกับฟีเจอร์ที่ใช้ในการอนุมานจริง ลดปัญหา Training-Serving Skew
- การนำฟีเจอร์กลับมาใช้ใหม่ (Feature Reusability): ฟีเจอร์ที่ถูกกำหนดและคำนวณแล้วสามารถนำไปใช้กับโมเดลหลายตัวหรือโปรเจกต์ต่างๆ ได้อย่างง่ายดาย ประหยัดเวลาและทรัพยากร
- การพัฒนาโมเดลที่รวดเร็วขึ้น: Data Scientists สามารถเข้าถึงฟีเจอร์ที่พร้อมใช้งานได้ทันที ไม่ต้องเสียเวลากับการเตรียมข้อมูลดิบซ้ำๆ ทำให้วงจรการพัฒนาโมเดลสั้นลง
- การกำกับดูแลข้อมูลที่ดีขึ้น (Improved Data Governance): Feature Store ทำหน้าที่เป็นแหล่งข้อมูลที่เชื่อถือได้สำหรับฟีเจอร์ ทำให้ง่ายต่อการติดตามที่มาของข้อมูล คุณภาพ และการปฏิบัติตามข้อกำหนด
- ลดภาระการดำเนินงาน (Reduced Operational Burden): การจัดการฟีเจอร์เป็นศูนย์กลางช่วยลดความซับซ้อนในการดูแลระบบและมอนิเตอร์ ทำให้ทีม Data Scientists และ ML Engineers สามารถมุ่งเน้นไปที่การสร้างมูลค่า
- การปรับขนาดได้ (Scalability): ออกแบบมาเพื่อรองรับข้อมูลจำนวนมหาศาลและการเข้าถึงฟีเจอร์ด้วยความเร็วสูง
โดยสรุป Feature Store ไม่ใช่แค่ฐานข้อมูลสำหรับฟีเจอร์ แต่เป็นแพลตฟอร์มที่ช่วยยกระดับการทำงานด้าน Machine Learning ให้มีประสิทธิภาพ เป็นระบบ สอดคล้อง และสามารถปรับขนาดได้ ช่วยให้องค์กรสามารถสร้างและนำโมเดล ML ไปใช้งานจริงได้อย่างรวดเร็วและเชื่อถือได้
เจาะลึก Feast: Open-Source Feature Store ยอดนิยม
เมื่อเราเข้าใจถึงความสำคัญของ Feature Store แล้ว ถึงเวลาที่จะเจาะลึกไปที่ Feast (Feature Store) ซึ่งเป็นหนึ่งใน Open-Source Feature Store ที่ได้รับความนิยมและมีการใช้งานอย่างกว้างขวาง
Feast คืออะไร?
Feast เป็น Open-Source Feature Store ที่พัฒนาขึ้นโดย Gojek และ Google Cloud โดยมีเป้าหมายเพื่อทำให้การค้นหา การแชร์ และการให้บริการฟีเจอร์สำหรับโมเดล ML เป็นเรื่องง่ายและมีประสิทธิภาพ Feast ได้รับการออกแบบมาเพื่อแก้ปัญหา Training-Serving Skew และเพิ่มประสิทธิภาพในการทำงานของทีม ML โดยการจัดเตรียมแหล่งข้อมูลฟีเจอร์ที่สอดคล้องกันและเชื่อถือได้
Feast ช่วยให้ทีม Data Scientists และ ML Engineers สามารถ:
- กำหนดฟีเจอร์และแหล่งข้อมูลของฟีเจอร์
- จัดเก็บฟีเจอร์ทั้งในรูปแบบ Offline (สำหรับ Training) และ Online (สำหรับ Serving)
- ดึงฟีเจอร์สำหรับ Training โดยใช้ Point-in-Time Correctness
- ดึงฟีเจอร์สำหรับ Serving ด้วยความหน่วงต่ำ
- จัดการ Metadata ของฟีเจอร์และเวอร์ชัน
แนวคิดหลักของ Feast
Feast มีแนวคิดหลักหลายประการที่สำคัญต่อการทำความเข้าใจการทำงานของมัน:
-
: เป็น Primary Key ที่ใช้ในการระบุตัวตนของเอนทิตีที่เราต้องการดึงฟีเจอร์ เช่น , , . Feast ใช้ Entity ในการเชื่อมโยงฟีเจอร์ต่างๆ เข้าด้วยกัน
-
: ระบุแหล่งที่มาของข้อมูลดิบที่ใช้ในการสร้างฟีเจอร์ เช่น ตารางใน BigQuery, ไฟล์ Parquet ใน S3, หรือ Kafka Topic. Feast รองรับ Data Sources หลากหลายประเภท
-
: เป็นการกำหนดตรรกะในการสร้างฟีเจอร์จาก ที่เฉพาะเจาะจง รวมถึงการระบุ Entity, ฟีเจอร์ที่จะดึง (Feature Columns) และช่วงเวลา (Event Timestamp) ที่เกี่ยวข้องกับฟีเจอร์นั้นๆ เป็นหัวใจสำคัญในการจัดการฟีเจอร์ใน Feast
-
: เป็นการรวมกลุ่มของ หลายๆ ตัวเข้าด้วยกันสำหรับโมเดล ML ที่เฉพาะเจาะจง ช่วยให้ Data Scientists สามารถระบุชุดฟีเจอร์ที่ต้องการสำหรับโมเดลหนึ่งๆ ได้อย่างง่ายดาย
-
: ไฟล์การกำหนดค่า () ที่ระบุการตั้งค่าพื้นฐานสำหรับ Feast repository รวมถึง Online Store, Offline Store, และ Registry Location
สถาปัตยกรรมของ Feast
สถาปัตยกรรมของ Feast ประกอบด้วยส่วนประกอบหลักดังนี้:
- Feast Core (Registry): เป็นหัวใจของ Feast ที่เก็บ Metadata ทั้งหมดเกี่ยวกับ Feature Definitions, Data Sources, Entities, FeatureViews และ FeatureServices Registry มักจะถูกจัดเก็บใน Git หรือ Cloud Storage เช่น GCS หรือ S3
- Feast SDK (Python Client): ไลบรารี Python ที่ใช้ในการกำหนดฟีเจอร์, จัดการ Registry, และดึงฟีเจอร์สำหรับ Training และ Serving
- Online Store: ฐานข้อมูลที่ใช้จัดเก็บฟีเจอร์ล่าสุดสำหรับการอนุมานแบบเรียลไทม์ Feast รองรับ Online Stores หลากหลาย เช่น Redis, DynamoDB, Google Cloud Firestore, Cassandra
- Offline Store: ฐานข้อมูลหรือระบบจัดเก็บข้อมูลที่ใช้จัดเก็บฟีเจอร์เชิงประวัติศาสตร์สำหรับการฝึกอบรมโมเดล Feast รองรับ Offline Stores เช่น BigQuery, Snowflake, S3, GCS, Redshift
- Providers: ส่วนประกอบที่ช่วยให้ Feast สามารถทำงานร่วมกับ Cloud Providers ต่างๆ ได้อย่างราบรื่น เช่น GCP Provider, AWS Provider, Azure Provider
กระบวนการทำงานโดยทั่วไปคือ Data Scientists จะกำหนด และ โดยใช้ Feast SDK จากนั้นใช้คำสั่ง เพื่อลงทะเบียนฟีเจอร์เหล่านี้ใน Feast Registry และเตรียมโครงสร้างพื้นฐานสำหรับ Online/Offline Store เมื่อฟีเจอร์ถูกลงทะเบียนแล้ว ระบบ Data Engineering จะรับผิดชอบในการนำข้อมูลเข้าสู่ Feature Store อย่างต่อเนื่อง ส่วน Data Scientists ก็สามารถดึงฟีเจอร์จาก Feast เพื่อฝึกโมเดล และ ML Engineers ก็สามารถดึงฟีเจอร์แบบเรียลไทม์เพื่อให้บริการโมเดลได้
ตัวอย่างการกำหนด Features ด้วย Feast
นี่คือตัวอย่างไฟล์ และไฟล์ Python สำหรับการกำหนดฟีเจอร์ใน Feast:
:
ในตัวอย่างนี้:
- : ชื่อโปรเจกต์ Feast
- : ตำแหน่งของ Feast Registry ซึ่งเป็น SQLite database ในเครื่อง
- : ประเภทของ Cloud Provider (ในที่นี้คือ สำหรับการทดสอบ)
- : การตั้งค่า Online Store (ในที่นี้คือ SQLite database ในเครื่อง)
:
เมื่อเราสร้างไฟล์เหล่านี้แล้ว เราสามารถใช้คำสั่ง ใน Terminal เพื่อลงทะเบียนฟีเจอร์เหล่านี้กับ Feast Registry และเตรียม Online Store ได้
คำสั่งนี้จะอ่านไฟล์ และไฟล์ Python ที่กำหนด FeatureViews เพื่อสร้างหรืออัปเดต Registry และโครงสร้าง Online Store ตามที่ระบุ
การทำความเข้าใจแนวคิดและสถาปัตยกรรมของ Feast เป็นสิ่งสำคัญในการสร้าง Pipeline MLOps ที่มีประสิทธิภาพ และเป็นรากฐานที่เราจะนำไปต่อยอดในการสร้าง CI/CD Automation Pipeline ในส่วนถัดไป
สร้างสรรค์ Pipeline อัตโนมัติด้วย CI/CD สำหรับ Feature Store
การมี Feature Store ที่ดีอย่าง Feast เป็นเพียงครึ่งหนึ่งของสมการ อีกครึ่งหนึ่งคือการทำให้การจัดการและ Deploy ฟีเจอร์เหล่านี้เป็นไปโดยอัตโนมัติและเชื่อถือได้ ซึ่งเป็นที่มาของการนำ CI/CD (Continuous Integration/Continuous Delivery) มาใช้กับ Feature Store Pipeline
ทำไมต้องมี CI/CD สำหรับ Feature Store?
ในสภาพแวดล้อม MLOps ที่ซับซ้อน การจัดการฟีเจอร์ด้วยตนเองหรือแบบ Manual Process นั้นเต็มไปด้วยความเสี่ยงและข้อจำกัด CI/CD สำหรับ Feature Store ช่วยแก้ไขปัญหาเหล่านี้:
- การควบคุมเวอร์ชันสำหรับคำจำกัดความฟีเจอร์: เหมือนกับการเขียนโค้ด การกำหนดฟีเจอร์ก็ควรถูกเก็บไว้ในระบบควบคุมเวอร์ชัน (เช่น Git) เพื่อให้สามารถติดตามการเปลี่ยนแปลง ย้อนกลับ และทำงานร่วมกันได้
- การทดสอบอัตโนมัติของ Feature Pipelines: ก่อนที่จะนำฟีเจอร์ไปใช้งานจริง ควรมีการทดสอบตรรกะการคำนวณฟีเจอร์ (Transformation Logic) และคุณภาพข้อมูล (Data Quality) โดยอัตโนมัติ เพื่อป้องกันข้อผิดพลาด
- การ Deploy ที่สอดคล้องกัน: การ Deploy คำจำกัดความฟีเจอร์และโครงสร้างพื้นฐานที่เกี่ยวข้อง (เช่น Online/Offline Store) ควรเป็นไปโดยอัตโนมัติและทำซ้ำได้ เพื่อให้มั่นใจว่าสภาพแวดล้อมต่างๆ (Dev, Staging, Prod) มีความสอดคล้องกัน
- การทำซ้ำและปรับปรุงฟีเจอร์ที่เร็วขึ้น: ด้วย CI/CD ทีมสามารถทดลอง สร้าง และ Deploy ฟีเจอร์ใหม่ๆ ได้อย่างรวดเร็ว ลดเวลาจากแนวคิดสู่การนำไปใช้งานจริง
- ลดปัญหา Training-Serving Skew: CI/CD ช่วยให้มั่นใจว่าการเปลี่ยนแปลงใดๆ ในคำจำกัดความฟีเจอร์จะถูกทดสอบและ Deploy ไปยังทั้ง Offline และ Online Store อย่างสอดคล้องกัน
ขั้นตอนสำคัญของ Feature Store CI/CD Pipeline
Feature Store CI/CD Pipeline โดยทั่วไปจะประกอบด้วยขั้นตอนหลักดังต่อไปนี้:
-
Code Commit (การยืนยันโค้ด):
- Data Scientists หรือ ML Engineers พัฒนาหรือแก้ไขคำจำกัดความฟีเจอร์ (เช่น ไฟล์ ของ Feast FeatureViews) และตรรกะการแปลงข้อมูล (Transformation Logic)
- โค้ดทั้งหมดถูก Commit และ Push ไปยัง Git Repository (เช่น GitHub, GitLab, Bitbucket, Azure Repos)
- การ Push โค้ดนี้จะ Trigger Pipeline CI/CD โดยอัตโนมัติ
-
Build/Test (การสร้างและทดสอบ):
- Linting & Syntax Checks: ตรวจสอบความถูกต้องของไวยากรณ์โค้ดและรูปแบบ
- Unit Tests: รัน Unit Tests สำหรับตรรกะการแปลงฟีเจอร์ เพื่อให้มั่นใจว่าฟีเจอร์ถูกคำนวณอย่างถูกต้อง
- Feast Validation (`feast apply –dry-run`): ใช้คำสั่ง Feast เพื่อตรวจสอบความถูกต้องของ Feature Definitions โดยไม่ทำการเปลี่ยนแปลงใดๆ กับ Registry หรือ Online Store จริง
- Data Quality Checks (แนะนำ): ตรวจสอบคุณภาพของข้อมูลดิบที่ใช้ในการสร้างฟีเจอร์ หรือข้อมูลที่ถูกแปลงแล้ว เพื่อให้มั่นใจว่าข้อมูลมีความสมบูรณ์และถูกต้อง
- Integration Tests: ทดสอบการทำงานร่วมกันของฟีเจอร์กับส่วนอื่นๆ ของระบบ (เช่น การดึงฟีเจอร์จาก Online Store)
-
Deployment (การ Deploy):
- Infrastructure Provisioning (IaC): หากมีการเปลี่ยนแปลงโครงสร้างพื้นฐานที่เกี่ยวข้อง (เช่น การตั้งค่า Online Store ใหม่, การขยายขนาด) เครื่องมือ Infrastructure as Code (IaC) เช่น Terraform หรือ CloudFormation จะถูกใช้เพื่อจัดการการเปลี่ยนแปลงเหล่านั้น
- Feast Apply (`feast apply`): คำสั่ง จะถูกรันเพื่อลงทะเบียน Feature Definitions ใหม่หรืออัปเดตที่มีอยู่ใน Feast Registry และเตรียมโครงสร้าง Online Store ตามที่กำหนด
- Deployment of Feature Ingestion Jobs: Deploy หรืออัปเดต Pipeline สำหรับการนำข้อมูลเข้าสู่ Feature Store (Feature Ingestion) ซึ่งอาจเป็น Apache Airflow DAGs, Spark Jobs, Flink Jobs หรือ Serverless Functions ที่ดึงข้อมูลดิบ แปลง และ Push ไปยัง Online/Offline Store
-
Monitoring & Alerting (การตรวจสอบและแจ้งเตือน):
- Feature Freshness: ตรวจสอบว่าฟีเจอร์ใน Online Store มีความสดใหม่ตามที่คาดหวังหรือไม่ (เช่น อัปเดตทุก 5 นาที)
- Data Quality Drift: มอนิเตอร์การเปลี่ยนแปลงของคุณภาพข้อมูลฟีเจอร์เมื่อเวลาผ่านไป (เช่น ค่าเฉลี่ย, ค่าเบี่ยงเบนมาตรฐาน)
- Service Uptime & Latency: ตรวจสอบความพร้อมใช้งานและความหน่วงของการดึงฟีเจอร์จาก Online Store
- Alerting: ตั้งค่าการแจ้งเตือนเมื่อพบความผิดปกติ (เช่น ฟีเจอร์ไม่อัปเดต, คุณภาพข้อมูลลดลง)
เครื่องมือสำหรับ CI/CD Automation
มีเครื่องมือมากมายที่สามารถนำมาใช้สร้าง CI/CD Pipeline สำหรับ Feature Store ได้:
- Version Control: Git (GitHub, GitLab, Bitbucket, Azure Repos)
- CI/CD Platforms:
- GitHub Actions
- GitLab CI/CD
- Jenkins
- Azure DevOps Pipelines
- AWS CodePipeline/CodeBuild
- Google Cloud Build
- Orchestration (สำหรับ Feature Ingestion):
- Apache Airflow
- Prefect
- Dagster
- AWS Step Functions
- Google Cloud Composer
- Infrastructure as Code (IaC):
- Terraform
- CloudFormation (AWS)
- Deployment Manager (GCP)
- Data Quality:
- Great Expectations
- Deequ
ตัวอย่าง: GitHub Actions สำหรับ Feast CI/CD
นี่คือตัวอย่าง GitHub Actions Workflow สำหรับการตรวจสอบและ Deploy Feature Definitions ของ Feast:
:
name: Feast CI/CD Pipeline
on:
push:
branches:
- main
paths:
- 'feature_repo/**' # Trigger เมื่อมีการเปลี่ยนแปลงในโฟลเดอร์ feature_repo
pull_request:
branches:
- main
paths:
- 'feature_repo/**'
jobs:
build_and_test_features:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Set up Python
uses: actions/setup-python@v4
with:
python-version: '3.9'
- name: Install Feast
run: |
pip install "feast[gcp]" # หรือ "feast[aws]" ตาม Cloud Provider ที่ใช้
pip install -r feature_repo/requirements.txt # ถ้ามี dependencies เพิ่มเติม
- name: Validate Feast definitions (Dry Run)
working-directory: ./feature_repo
run: |
feast apply --dry-run # ตรวจสอบความถูกต้องโดยไม่ Deploy จริง
- name: Run unit tests for feature transformations
working-directory: ./feature_repo
run: |
# สมมติว่ามีไฟล์ test_features.py ที่มี unit tests
python -m pytest tests/unit/test_features.py
deploy_features_to
