Use cases AI/ML แบบเรียลไทม์ เช่น ป้องกันฉ้อโกง (fraud prevention) และการแนะนำ (recommendation) กำลังเพิ่มขึ้น และ feature stores เล่นบทบาทสำคัญในการนำไปสู่ production ให้สำเร็จ ตาม Feast feature store open source ยอดนิยม คำถามที่พบบ่อยที่สุดในชุมชน Slack คือ: feature store มี scalable/performant แค่ไหน? เพราะลักษณะสำคัญที่สุดของ feature store สำหรับ real-time AI/ML คือความเร็วในการ serve features จาก online store ไปยัง ML model สำหรับ online predictions หรือ scoring Feature stores ที่ประสบความสำเร็จต้องตอบสนอง latency requirements ที่เข้มงวด (วัดเป็นมิลลิวินาที) อย่างต่อเนื่อง (think p99) และในระยะ scale (ถึง millions of queries per second, ด้วยขนาดข้อมูล gigabytes ถึง terabytes) พร้อมรักษา total cost of ownership ต่ำและ accuracy สูง
как мы увидим в этом посте, выбор онлайн feature store, а также архитектура feature store, играют важную роль в определении того, насколько производительной и рентабельной она является. Неудивительно, что компании часто проводят тщательный бенчмаркинг перед выбором онлайн feature store, чтобы узнать, какой выбор архитектуры или онлайн feature store является наиболее производительным и рентабельным. В этом посте мы рассмотрим архитектуры и бенчмарки как от DIY feature stores, созданных компаниями, успешно внедряющими реальные AI/ML use cases, так и от open source и коммерческих feature stores. Давайте начнем.
1. Open Source Feast
มาดู benchmarking data และ data architecture ของ Feast open source feature store Feast ทำ benchmark เพื่อเปรียบเทียบ feature serving latency เมื่อใช้ online stores ต่างๆ (Redis vs Google Cloud DataStore vs AWS DynamoDB) และเปรียบเทียบความเร็วของกลไกต่างๆ ในการ extract features (เช่น Java gRPC server, Python HTTP server, lambda function, ฯลฯ) ดูรายละเอียด benchmark setup และผลลัพธ์เต็มได้ที่บล็อกโพสต์นี้ สรุปคือ Feast พบว่ามีประสิทธิภาพสูงสุดโดยใช้ Java gRPC server และ Redis เป็น online store
ใน diagram ด้านบนเห็นตัวอย่างว่า Better.com (บริษัท mortgage ออนไลน์) implement lead scoring ranking system ด้วย Feast open-source feature store ตามที่ Vitaly Sergey Senior Software Engineer ที่ Better.com นำเสนอ features ถูก materialized จาก offline stores (S3, Snowflake, Redshift) ไป online store (Redis) นอกจากนี้ features ยัง ingest เข้า online store จาก streaming sources (Kafka topics) Feast เพิ่งเพิ่มรองรับ streaming data sources (นอกจาก batch data sources) ซึ่งปัจจุบันรองรับเฉพาะ Redis การรองรับ streaming data sources สำคัญมากสำหรับ real-time AI/ML use cases เพราะ use cases เหล่านี้พึ่งพาข้อมูลสด (fresh live data)
ตัวอย่าง use case lead scoring ของ Better.com: new leads ingest ตลอดวัน features มาจากหลายแหล่ง ตั้งแต่ entities (leads) และ features ที่ใช้ scoring ได้รับการ update ตลอดเวลา leads จึงได้รับการ rank และ re-rank ทันทีที่มี new lead จะ ingest และ scored โดย model พร้อมกันที่ ingest เข้า online store อาจต้องการ re-rank เร็วๆ นี้ Leads ของ Better.com หมดอายุหลัง 48 ชั่วโมง implement ใน Redis online store โดยตั้ง time to live (TTL) 48 ชั่วโมง เพื่อ expire entity (lead) และ feature vectors ที่เกี่ยวข้องหลัง 48 ชั่วโมง Feature store จึงทำความสะอาดตัวเองอัตโนมัติ ไม่มี stale entities หรือ features ใช้พื้นที่ online storage เหลือเปล่า
อีกการ implement Feast ที่น่าสนใจคือ Microsoft Azure Feature Store ดูสถาปัตยกรรมได้ที่นี่ รันบน Azure cloud ปรับให้เหมาะกับ low latency real-time AI/ML use cases รองรับ batch และ streaming sources และ integration เข้ากับ Azure Data & AI ecosystem Features ingest เข้า online store จาก batch sources (Azure Synapse Serverless SQL, Azure Storage / ADLS) และ streaming sources (Azure Event Hub) หากคุณ deploy บน Azure หรือคุ้นเคยกับ Azure ecosystem แล้ว feature store นี้อาจเหมาะกับคุณ สำหรับ online store ใช้ Azure Cache for Redis และด้วย Enterprise Tiers ของ Azure Redis รวม Active-Active Geo-Duplication สร้าง globally distributed caches ด้วย availability ถึง 99.999% นอกจากนี้ ลดต้นทุนเพิ่มเติมได้ด้วย Enterprise Flash tier รัน Redis บน tiered memory architecture ใช้ both in-memory (DRAM) และ Flash memory (NVMe หรือ SSD) จัดเก็บข้อมูล
2. Wix DIY feature store – จารีตของ MLOps platform
ด้านล่างเป็นสถาปัตยกรรมอีกแบบสำหรับ real-time AI/ML use cases เป็น feature store architecture ของ Wix แพลตฟอร์มสร้างเว็บไซต์ยอดนิยม ใช้สำหรับ real-time use cases เช่น recommendations, churn และ premium predictions, ranking, และ spam classifiers Wix ให้บริการผู้ใช้ลงทะเบียน 200 ล้านคน ซึ่งเพียงส่วนน้อยเป็น 'active users' ในเวลาใดเวลาหนึ่ง สิ่งนี้ส่งผลใหญ่ต่อการ implement feature store มาดูกัน
ข้อมูลด้านล่างอิงจาก TechTalk presentation โดย Ran Romano เมื่อเขาเป็นหัวหน้า ML Engineering ที่ Wix มากกว่า 90% ของข้อมูลใน Wix feature store เป็น clickstreams และ ML models ถูก trigger ต่อ website หรือต่อ user Ran อธิบายว่าสำหรับ real-time use cases latency เป็นปัญหาใหญ่ และบาง production use cases ต้อง extract feature vectors ภายในมิลลิวินาที
Raw data จัดเก็บใน Parquet files บน AWS S3 bucket แบ่ง partition ตาม business units (เช่น 'editors', 'restaurants', 'bookings', ฯลฯ) และตาม date เป็นส่วนหนึ่งของ Wix data platform ที่ data analysts ใช้ ซึ่งมีมาก่อน Wix ML Platform หลายปี ในกระบวนการ daily build batch ใช้ Spark, SQL (ใช้เวลานาทีถึงชั่วโมง) history features ของผู้ใช้ทั้งหมดถูก extract จาก S3, pivoted และ aggregated โดย user และ ingest เข้า offline store (Apache Hbase) ให้การ lookup 'by user' ที่เร็วกว่ามาก เมื่อ system ตรวจจับว่า user active อยู่ กระบวนการ 'warmup' จะถูก trigger และ features ของ user นั้นโหลดเข้า online store (Redis) ซึ่งเล็กกว่า offline store เพราะเก็บแค่ user history ของ active users กระบวนการ 'warmup' นี้ใช้เวลาหลายวินาที และสุดท้าย features ใน online feature store ถูก update ต่อเนื่องด้วย fresh live real-time data โดยตรงจาก streaming sources ต่อ event ที่มาจาก user (ใช้ Apache Storm)
สถาปัตยกรรมแบบนี้มีอัตราส่วน writes ต่อ reads ต่ำกว่า Feast architecture ซึ่งมีประสิทธิภาพด้าน materialization และ online storage เพราะเก็บ features แค่ active users ใน online store ไม่ใช่ทุก user เนื่องจาก active users เป็นส่วนน้อยของ registered users ทั้งหมดใน Wix จึงประหยัดมาก แต่มี trade-off: แม้การ retrieve features จาก online store เร็วมาก (ภายในมิลลิวินาที) แต่ก็ต่อเมื่อ features อยู่ใน online store แล้ว เนื่องจาก race conditions เนื่องจาก warmup process ใช้เวลาหลายวินาที จึงไม่พอโหลด features ที่เกี่ยวข้องทันเมื่อ user กลายเป็น active ดังนั้น scoring หรือ prediction สำหรับ user นั้นจะ fail นี่ OK ถ้า use case ไม่ใช่ critical flow หรือ mission-critical เช่น approve transactions หรือ prevent fraud สถาปัตยกรรมนี้เฉพาะเจาะจงกับ Wix ที่มี active users เพียงส่วนน้อย
3. Commercial Feature Store Tecton
มาดูสถาปัตยกรรมของ commercial enterprise feature store Tecton ตาม diagram ด้านล่าง นอกจาก batch data sources และ streaming data sources Tecton ยังรองรับ 'out-of-the-box' real-time data sources เรียกอีกอย่างว่า real-time features หรือ 'real-time' transformations Real-time features คำนวณได้เฉพาะตอน inference request เช่น ความต่างระหว่างขนาด transaction ที่น่าสงสัยกับขนาด transaction ก่อนหน้า ในกรณี Better.com ด้วย Feast open source Better.com พัฒนารองรับ real-time features เอง แต่กับ Tecton feature store ทำได้ง่ายกว่า เพราะรองรับ native โดย feature store เหมือน Feast และ Wix, Tecton ก็ define features ใน registry เพื่อให้ logical definition ถูก define ครั้งเดียวสำหรับ offline และ online stores ทั้งคู่ ลด training-serving skew อย่างมาก ให้ accuracy สูงของ ML model ใน production ด้วย
เกี่ยวกับการเลือก offline store, online store และ benchmarking สำหรับ offline feature store Tecton รองรับ S3 สำหรับ online store Tecton ให้ลูกค้าเลือกระหว่าง DynamoDB และ Redis Enterprise Cloud ใน presentation ล่าสุด Tecton CTO Kevin Stumpf ให้ tips เลือก online feature store จาก benchmarks ที่บริษัททำ นอกจาก benchmark latency และ throughput Tecton ยัง benchmark cost ของ online store ทำไมสำคัญ? สำหรับ high throughput หรือ low latency use cases ต้นทุน online store อาจเป็นส่วนใหญ่และสำคัญของ total cost of ownership ของ MLOps platform ทั้งหมด การประหยัดต้นทุนจึงสำคัญมาก
สรุป benchmarking ของ Tecton: สำหรับ high throughput use cases ที่ typical สำหรับผู้ใช้ Tecton, Redis Enterprise เร็วกว่า 3x และถูกกว่า 14x เทียบกับ DynamoDB
Catch คืออะไร? หากคุณมีเพียง 1 use case และไม่มี high หรือ consistent throughput และไม่มี strict latency requirements ก็อาจใช้ DynamoDB ได้ ดูรายละเอียดและผลลัพธ์ benchmark เต็มของ Tecton ที่นี่
4. Lightricks ใช้ Commercial Feature Store Qwak
ด้านล่างเป็นตัวอย่าง feature store architecture อีกแบบ ใช้โดย Lightricks บน commercial feature store Qwak Lightricks เป็น unicorn company พัฒนา mobile apps edit วิดีโอและรูปภาพ รู้จักกันดีใน selfie-editing app Facetune ใช้ feature store สำหรับ recommendation system
ตาม diagram ด้านบน คล้าย Tecton, Qwak feature store รองรับ 3 ประเภท feature sources – batch, streaming, และ real-time features
สำคัญ: กับ Qwak feature store materialization ของ features เข้า feature store ทำโดยตรงจาก raw data sources สำหรับ offline store (Parquet files on S3) และ online store (Redis) ต่างจาก feature stores ตัวอย่าง Wix, Feast, Tecton ที่ materialization ของ online store ทำจาก offline store ไป online store สำหรับ batch sources นี่มีข้อได้เปรียบที่ไม่แค่ transformation logic ของ feature ถูก unified ระหว่าง training และ serving flows (เหมือน feature stores Feast, Wix, Tecton) แต่ actual transformation หรือ feature computation ทำ unified ด้วย ลด training-serving skew เพิ่มเติม การมี unified data pipeline สำหรับ offline และ online โดยตรงจาก raw data มีศักยภาพให้ accuracy สูงขึ้นใน production ดูข้อมูลเพิ่มเติมเกี่ยวกับ Qwak feature store architecture และ components ใน presentation นี้
สรุป
ในบทความนี้เรารีวิว highlights ของ benchmarks และ architectures ของ feature stores หลายตัวสำหรับ real-time AI/ML ตัวแรก Open Source Feast ตัวที่สอง DIY Wix feature store ตัวที่สาม Tecton และตัวที่สี่ Qwak เรายังรีวิว highlights ของ benchmarks ที่บริษัทเหล่านี้ทำ เพื่อดูว่า online store ไหน performant และ cost-effective ที่สุด เรายังสำรวจ mechanism หรือ feature server ไหนเหมาะสำหรับ extract features จาก online store เราเห็นว่ามีความแตกต่างอย่างมากใน performance และ cost ของ feature stores ขึ้นอยู่กับ architecture, ประเภท features ที่รองรับ และ components ที่เลือก
ตีพิมพ์ครั้งแรกใน KDnuggets.
