กรณีการใช้งานปัญญาประดิษฐ์ / การเรียนรู้ของเครื่อง (AI/ML) แบบเรียลไทม์ เช่น การป้องกันการฉ้อโกงและการแนะนำ กำลังเพิ่มขึ้น และร้านค้าฟีเจอร์มีบทบาทสำคัญในการทำให้ใช้งานได้สำเร็จในการผลิต ตาม Feast ของร้านฟีเจอร์โอเพนซอร์สยอดนิยม หนึ่งในคำถามที่พบบ่อยที่สุดที่ผู้ใช้ถามในชุมชน Slack คือ:อย่างไร ปรับขนาดได้/มีประสิทธิภาพ คืองานฉลอง? เนื่องจากคุณลักษณะที่สำคัญที่สุดของที่เก็บฟีเจอร์สำหรับ AI/ML แบบเรียลไทม์คือความเร็วในการให้บริการฟีเจอร์จากร้านค้าออนไลน์ไปยังโมเดล ML สำหรับการคาดคะเนหรือการให้คะแนนออนไลน์ การจัดเก็บคุณสมบัติที่ประสบความสำเร็จสามารถตอบสนองความต้องการเวลาแฝงที่เข้มงวด (วัดเป็นมิลลิวินาที) สม่ำเสมอ (คิด p99) และในขนาด (มากถึงการสืบค้นหลายล้านรายการต่อวินาที ด้วยชุดข้อมูลขนาดกิกะไบต์ถึงเทราไบต์) ในขณะเดียวกันก็รักษาต้นทุนรวมที่ต่ำ ความเป็นเจ้าของและความแม่นยำสูง
ตามที่เราจะเห็นในโพสต์นี้ การเลือกร้านค้าคุณสมบัติออนไลน์ ตลอดจนสถาปัตยกรรมของที่เก็บคุณสมบัติ มีบทบาทสำคัญในการพิจารณาว่ามีประสิทธิภาพและคุ้มค่าเพียงใด ไม่น่าแปลกใจเลยที่บริษัทต่างๆ มักจะทำการเปรียบเทียบอย่างละเอียดก่อนเลือกร้านค้าคุณสมบัติออนไลน์ เพื่อดูว่าสถาปัตยกรรมหรือร้านค้าคุณสมบัติออนไลน์ใดมีประสิทธิภาพและคุ้มทุนมากที่สุด ในโพสต์นี้ เราจะตรวจสอบสถาปัตยกรรมและการวัดประสิทธิภาพจากทั้งร้านค้าฟีเจอร์ DIY ที่สร้างโดยบริษัทต่างๆ ที่ประสบความสำเร็จในการปรับใช้กรณีการใช้งาน AI/ML แบบเรียลไทม์ รวมถึงโอเพ่นซอร์สและร้านค้าฟีเจอร์เชิงพาณิชย์ เริ่มกันเลย
1. เทศกาลโอเพ่นซอร์ส
อันดับแรก มาดูการเปรียบเทียบข้อมูลและสถาปัตยกรรมข้อมูลของที่เก็บฟีเจอร์โอเพนซอร์สของ Feast กันก่อน เมื่อเร็ว ๆ นี้ Feast ได้ทำเกณฑ์มาตรฐานเพื่อเปรียบเทียบคุณสมบัติในการให้บริการเวลาแฝงเมื่อใช้ร้านค้าออนไลน์ต่างๆ (Redis กับ Google Cloud DataStore กับ AWS DynamoDB) นอกจากนี้ยังเปรียบเทียบความเร็วของการใช้กลไกต่างๆ ในการดึงข้อมูลคุณลักษณะต่างๆ (เช่น เซิร์ฟเวอร์ Java gRPC, เซิร์ฟเวอร์ Python HTTP, ฟังก์ชันแลมบ์ดา เป็นต้น) คุณสามารถดูการตั้งค่าเกณฑ์มาตรฐานฉบับสมบูรณ์และผลลัพธ์ได้ในโพสต์บล็อกนี้ บรรทัดล่าง:งานฉลองพบว่ามีประสิทธิภาพมากที่สุดโดยใช้เซิร์ฟเวอร์ Java gRPC และมี Redis เป็นร้านค้าออนไลน์
ในแผนภาพด้านบน คุณจะเห็นตัวอย่างวิธีที่บริษัทจำนองออนไลน์ Better.com ใช้ระบบการจัดอันดับลูกค้าเป้าหมายโดยใช้ที่เก็บฟีเจอร์ Feast แบบโอเพนซอร์ส ตามที่ Vitaly Sergey วิศวกรซอฟต์แวร์อาวุโสของ Better.com นำเสนอ คุณลักษณะดังกล่าวได้รับการเผยแพร่จากร้านค้าออฟไลน์ (S3, Snowflake และ Redshift) ไปยังร้านค้าออนไลน์ (Redis) นอกจากนั้น ฟีเจอร์ต่างๆ จะถูกนำเข้าไปยังร้านค้าออนไลน์จากแหล่งสตรีมมิ่ง (หัวข้อ Kafka) เมื่อเร็ว ๆ นี้ Feast ได้เพิ่มการรองรับแหล่งข้อมูลการสตรีม (นอกเหนือจากแหล่งข้อมูลแบบกลุ่ม) ซึ่งปัจจุบันรองรับเฉพาะ Redis เท่านั้น การสนับสนุนแหล่งข้อมูลการสตรีมมีความสำคัญมากสำหรับกรณีการใช้งาน AI/ML แบบเรียลไทม์ เนื่องจากกรณีการใช้งานเหล่านี้อาศัยข้อมูลสดที่สดใหม่
ตัวอย่างเช่น ในกรณีการใช้งานการให้คะแนนลูกค้าเป้าหมายสำหรับ Better.com ลูกค้าเป้าหมายใหม่จะถูกนำเข้าอย่างต่อเนื่องตลอดทั้งวัน คุณลักษณะต่างๆ มาจากแหล่งที่มาต่างๆ มากมาย และทั้งเอนทิตี (ลูกค้าเป้าหมาย) และคุณลักษณะที่ใช้ในการให้คะแนนจะได้รับการอัปเดตตลอดเวลา ดังนั้น ผู้มุ่งหวังจะได้รับการจัดอันดับและจัดอันดับใหม่ ทันทีที่มีโอกาสในการขายใหม่ ตัวแบบจะนำเข้าและให้คะแนน ในเวลาเดียวกันกับที่มีการนำเข้าในร้านค้าออนไลน์ เราอาจต้องการจัดอันดับใหม่ในไม่ช้าหลังจากนั้น โอกาสในการขาย Better.com จะหมดอายุหลังจาก 48 ชั่วโมง และการดำเนินการนี้จะถูกนำไปใช้ในร้านค้าออนไลน์ของ Redis โดยเพียงแค่ตั้งค่า time to live (TTL) เป็น 48 ชั่วโมง เพื่อหมดอายุเอนทิตี (ลูกค้าเป้าหมาย) และเชื่อมโยงคุณสมบัติเวกเตอร์หลังจาก 48 ชั่วโมง ดังนั้นที่จัดเก็บคุณลักษณะจะทำความสะอาดตัวเองโดยอัตโนมัติ และไม่มีเอนทิตีหรือคุณลักษณะที่ล้าสมัยที่ใช้พื้นที่เก็บข้อมูลออนไลน์อันมีค่า
การใช้งาน Feast ที่น่าสนใจอีกอย่างหนึ่งคือ Microsoft Azure Feature Store คุณสามารถดูสถาปัตยกรรมได้ที่นี่ มันทำงานบน Azure cloud ที่ปรับให้เหมาะสมสำหรับกรณีการใช้งาน AI/ML แบบเรียลไทม์ที่มีเวลาแฝงต่ำ รองรับทั้งแหล่งที่มาแบบแบตช์และสตรีม รวมถึงการผสานเข้ากับระบบนิเวศ Azure Data &AI คุณลักษณะนี้นำเข้าในร้านค้าออนไลน์จากแหล่งที่มาของชุดงานทั้งสอง (Azure Synapse Serverless SQL, Azure Storage / ADLS) และจากแหล่งการสตรีม (Azure Event Hub) หากคุณใช้งาน Azure อยู่แล้วหรือคุ้นเคยกับระบบนิเวศของ Azure ที่เก็บคุณลักษณะนี้อาจเหมาะสำหรับคุณ สำหรับร้านค้าออนไลน์นั้นใช้ Azure Cache สำหรับ Redis และระดับองค์กรของ Azure Redis จะรวม Active-Active Geo-Duplication เพื่อสร้างแคชแบบกระจายทั่วโลกที่มีความพร้อมใช้งานสูงถึง 99.999% นอกจากนี้ ยังสามารถลดต้นทุนได้อีกโดยใช้ระดับ Enterprise Flash เพื่อเรียกใช้ Redis บนสถาปัตยกรรมหน่วยความจำแบบแบ่งชั้นที่ใช้ทั้งหน่วยความจำในหน่วยความจำ (DRAM) และหน่วยความจำแฟลช (NVMe หรือ SSD) เพื่อจัดเก็บข้อมูล
2. Wix DIY feature store – รากฐานที่สำคัญของแพลตฟอร์ม MLOps
ด้านล่างนี้เป็นสถาปัตยกรรมที่แตกต่างกันสำหรับการนำกรณีการใช้งาน AI/ML ไปใช้แบบเรียลไทม์ เป็นสถาปัตยกรรมร้านค้าคุณสมบัติของ Wix แพลตฟอร์มการสร้างเว็บไซต์ยอดนิยม ใช้สำหรับกรณีการใช้งานแบบเรียลไทม์ เช่น คำแนะนำ การคาดการณ์แบบแยกส่วนและแบบพรีเมียม การจัดอันดับ และตัวแยกประเภทสแปม Wix ให้บริการผู้ใช้ที่ลงทะเบียนแล้วกว่า 200 ล้านคน ซึ่งมีเพียงส่วนน้อยเท่านั้นที่เป็น 'ผู้ใช้ที่ใช้งานอยู่' ในเวลาใดก็ตาม สิ่งนี้มีอิทธิพลอย่างมากต่อวิธีการใช้งานที่เก็บคุณสมบัติ ลองดูที่มัน
ข้อมูลด้านล่างนี้อ้างอิงจากการนำเสนอของ TechTalk ที่ Ran Romano นำเสนอเมื่อเขาเป็นหัวหน้าฝ่ายวิศวกรรม ML ที่ Wix ข้อมูลกว่า 90% ที่จัดเก็บในที่เก็บฟีเจอร์ของ Wix เป็นคลิกสตรีมและโมเดล ML จะถูกเรียกใช้ตามเว็บไซต์หรือต่อผู้ใช้ Ran อธิบายว่าสำหรับกรณีการใช้งานแบบเรียลไทม์ เวลาแฝงเป็นปัญหาใหญ่ นอกจากนี้ สำหรับกรณีการใช้งานจริงบางกรณี พวกเขาจำเป็นต้องแยกเวกเตอร์คุณลักษณะภายในมิลลิวินาที
ข้อมูลดิบถูกจัดเก็บไว้ในไฟล์ Parquet บน AWS ในบัคเก็ต S3 และแบ่งพาร์ติชั่นตามหน่วยธุรกิจ (เช่น "ผู้แก้ไข" "ร้านอาหาร" "การจอง" ฯลฯ) และตามวันที่ เป็นส่วนหนึ่งของแพลตฟอร์มข้อมูลของ Wix ที่ใช้โดยนักวิเคราะห์ข้อมูลซึ่งมีมาก่อนแพลตฟอร์ม Wix ML เมื่อหลายปีก่อน ใน บิลด์รายวัน กระบวนการแบทช์โดยใช้ Spark, SQL (ซึ่งใช้เวลาเป็นนาทีถึงชั่วโมง) คุณลักษณะประวัติผู้ใช้ทั้งหมดจะถูกแยกจาก S3, หมุนและรวบรวมโดยผู้ใช้ และนำเข้าไปยังร้านค้าออฟไลน์ (Apache Hbase) วิธีนี้ช่วยให้ค้นหาประวัติผู้ใช้ได้รวดเร็วยิ่งขึ้นโดย 'ผู้ใช้' เมื่อระบบตรวจพบว่าผู้ใช้กำลังใช้งานอยู่ 'วอร์มอัพ' กระบวนการถูกเรียกใช้และคุณลักษณะของผู้ใช้นั้นถูกโหลดลงในร้านค้าออนไลน์ (Redis) ซึ่งมีขนาดเล็กกว่าร้านค้าออฟไลน์มาก เนื่องจากเก็บเฉพาะประวัติผู้ใช้ของผู้ใช้ที่ใช้งานอยู่ กระบวนการ 'อุ่นเครื่อง' นี้อาจใช้เวลาหลายวินาที และสุดท้าย ฟีเจอร์ในร้านค้าฟีเจอร์ออนไลน์จะได้รับการอัปเดตอย่างต่อเนื่องโดยใช้ข้อมูลสดแบบเรียลไทม์สดโดยตรงจากแหล่งการสตรีมสำหรับแต่ละเหตุการณ์ที่มาจากผู้ใช้ (โดยใช้ Apache Storm)
สถาปัตยกรรมประเภทนี้มีอัตราส่วนการเขียนต่อการอ่านที่ต่ำกว่าเมื่อเทียบกับสถาปัตยกรรม Feast ซึ่งมีประสิทธิภาพมากในแง่ของการทำให้เป็นจริงและการจัดเก็บออนไลน์ เนื่องจากจะเก็บเฉพาะคุณลักษณะสำหรับผู้ใช้ที่ใช้งานอยู่ในร้านค้าออนไลน์มากกว่าที่เก็บสำหรับผู้ใช้ทั้งหมด เนื่องจากผู้ใช้ที่ใช้งานอยู่เป็นส่วนเล็ก ๆ ของผู้ใช้ที่ลงทะเบียนทั้งหมดภายใน Wix สิ่งนี้แสดงถึงการประหยัดอย่างมาก อย่างไรก็ตามนี้มาในราคา แม้ว่าการเรียกคุณลักษณะจากร้านค้าออนไลน์จะรวดเร็วมาก ภายในเสี้ยววินาที ก็ต่อเมื่อคุณลักษณะนั้นมีอยู่แล้วในร้านค้าออนไลน์ เนื่องจากสภาวะการแข่งขัน เนื่องจากกระบวนการวอร์มอัพใช้เวลาหลายวินาที จึงไม่เร็วพอที่จะโหลดคุณสมบัติที่เกี่ยวข้องเมื่อผู้ใช้เริ่มใช้งาน ดังนั้นการให้คะแนนหรือการทำนายสำหรับผู้ใช้รายนั้นจะล้มเหลว ซึ่งเป็นเรื่องปกติตราบใดที่กรณีการใช้งานไม่ได้เป็นส่วนหนึ่งของขั้นตอนที่สำคัญหรือสำหรับกรณีการใช้งานที่สำคัญต่อภารกิจ เช่น การอนุมัติธุรกรรมหรือการป้องกันการฉ้อโกง สถาปัตยกรรมประเภทนี้มีความเฉพาะเจาะจงมากสำหรับ Wix ซึ่งมีผู้ใช้เพียงส่วนน้อยเท่านั้นที่เป็นผู้ใช้ที่ใช้งานอยู่ในเวลาใดก็ตาม
3. ร้านค้าคุณลักษณะเชิงพาณิชย์ เทคตัน
มาดูสถาปัตยกรรมของ Tecton ที่เก็บฟีเจอร์องค์กรเชิงพาณิชย์กัน ดังที่เราเห็นในไดอะแกรมด้านล่าง นอกเหนือจากแหล่งข้อมูลแบทช์และแหล่งข้อมูลการสตรีมแล้ว Tecton ยังสนับสนุนแหล่งข้อมูลแบบเรียลไทม์ 'นอกกรอบ' สิ่งเหล่านี้เรียกอีกอย่างว่า 'คุณลักษณะแบบเรียลไทม์ ' หรือการแปลงแบบ 'เรียลไทม์' คุณสมบัติเรียลไทม์สามารถคำนวณได้เฉพาะในคำขออนุมานเท่านั้น ตัวอย่างเช่น ความแตกต่างระหว่างขนาดของรายการที่น่าสงสัยและขนาดของรายการล่าสุด ดังนั้น ในกรณีของ Better.com ที่มีโอเพ่นซอร์ส Feast ด้านบน Better.com ได้พัฒนาการสนับสนุนคุณสมบัติตามเวลาจริงด้วยตัวมันเอง ด้วยที่เก็บฟีเจอร์ Tecton สิ่งนี้ง่ายต่อการใช้งาน เนื่องจากได้รับการสนับสนุนจากที่เก็บฟีเจอร์อยู่แล้ว เช่นเดียวกับ Feast และที่เก็บฟีเจอร์ของ Wix Tecton ยังกำหนดคุณสมบัติในรีจิสทรีเพื่อให้คำจำกัดความเชิงตรรกะถูกกำหนดครั้งเดียวสำหรับร้านค้าออฟไลน์และออนไลน์ ซึ่งช่วยลดความเบ้ของการให้บริการฝึกอบรมได้อย่างมากเพื่อให้มั่นใจว่าโมเดล ML อยู่ระหว่างการผลิตมีความแม่นยำสูงด้วย
ในแง่ของตัวเลือกร้านค้าออฟไลน์ ร้านค้าออนไลน์ และการเปรียบเทียบ สำหรับร้านค้าคุณสมบัติออฟไลน์ Tecton รองรับ S3 สำหรับร้านค้าออนไลน์ Tecton เสนอทางเลือกให้ลูกค้าระหว่าง DynamoDB และ Redis Enterprise Cloud ในการนำเสนอเมื่อเร็วๆ นี้ Tecton CTO Kevin Stumpf ได้ให้คำแนะนำเกี่ยวกับวิธีเลือกที่เก็บคุณสมบัติออนไลน์ของคุณ โดยอิงตามเกณฑ์มาตรฐานที่บริษัทดำเนินการเมื่อเร็วๆ นี้ นอกเหนือจากการเปรียบเทียบเวลาแฝงและปริมาณงานแล้ว Tecton ยังเปรียบเทียบต้นทุนของร้านค้าออนไลน์อีกด้วย ทำไมสิ่งนี้จึงสำคัญ? สำหรับปริมาณงานสูงหรือกรณีการใช้งานที่มีเวลาแฝงต่ำ ต้นทุนของร้านค้าออนไลน์อาจมีขนาดใหญ่และเป็นส่วนสำคัญของต้นทุนรวมในการเป็นเจ้าของแพลตฟอร์ม MLOps ทั้งหมด ดังนั้นการประหยัดต้นทุนใดๆ ก็สามารถช่วยได้มาก
บรรทัดล่างของการเปรียบเทียบของ Tecton คือสำหรับกรณีการใช้งานที่มีปริมาณงานสูงโดยทั่วไปสำหรับผู้ใช้ของ Tecton Redis Enterprise นั้นเร็วกว่า 3 เท่า และในขณะเดียวกันก็มีราคาถูกกว่า DynamoDB ถึง 14 เท่า
สิ่งที่คุณอาจถามคืออะไร? หากคุณมีกรณีการใช้งานเพียงกรณีเดียว และไม่มีปริมาณงานสูงหรือสม่ำเสมอ และไม่มีข้อกำหนดเวลาในการตอบสนองที่เข้มงวด คุณก็สามารถใช้ DynamoDB ได้ คุณสามารถดูรายละเอียดทั้งหมดและผลการทดสอบของ Tecton ได้ที่นี่
4. Lightricks ใช้ Commercial Feature Store Qwak
ด้านล่างนี้เป็นอีกตัวอย่างหนึ่งของสถาปัตยกรรมที่เก็บคุณลักษณะ อันนี้ใช้โดย Lightricks ซึ่งอิงจากร้านค้าเชิงพาณิชย์ Qwak Lightricks เป็นบริษัทยูนิคอร์นที่พัฒนาแอปมือถือสำหรับตัดต่อวิดีโอและรูปภาพ โดยเฉพาะอย่างยิ่ง Facetune ซึ่งเป็นแอปตัดต่อภาพเซลฟี่ ใช้ที่เก็บคุณลักษณะสำหรับระบบการแนะนำ
ดังที่แสดงในไดอะแกรมด้านบน เช่น Tecton ที่เก็บฟีเจอร์ Qwak รองรับแหล่งที่มาของฟีเจอร์สามประเภท ได้แก่ แบทช์ การสตรีม และฟีเจอร์แบบเรียลไทม์
เป็นสิ่งสำคัญที่จะต้องทราบว่าด้วยที่เก็บฟีเจอร์ Qwak การทำให้ฟีเจอร์เป็นจริงในที่เก็บฟีเจอร์นั้นทำได้โดยตรงจากแหล่งข้อมูลดิบสำหรับทั้งร้านค้าออฟไลน์ (โดยใช้ไฟล์ Parquet บน S3) และร้านค้าออนไลน์ (โดยใช้ Redis) สิ่งนี้แตกต่างไปจากตัวอย่างที่เก็บคุณลักษณะจาก Wix, Feast หรือ Tecton ซึ่งการทำให้เป็นรูปเป็นร่างของร้านค้าออนไลน์จากร้านค้าออฟไลน์ไปยังร้านค้าออนไลน์สำหรับแหล่งที่มาของชุดงาน สิ่งนี้มีข้อได้เปรียบที่ไม่เพียงแต่ลอจิกการเปลี่ยนแปลงของคุณลักษณะเท่านั้นที่รวมเป็นหนึ่งเดียวในการฝึกอบรมและขั้นตอนการให้บริการ (เช่นเดียวกับที่เก็บคุณลักษณะของ Feast, Wix และ Tecton ด้านบน) แต่ยังรวมถึงการแปลงจริงหรือการคำนวณคุณลักษณะที่ทำอย่างสม่ำเสมอ ลดลงอีก เอียงให้บริการฝึกอบรม การมีไปป์ไลน์ข้อมูลแบบครบวงจรสำหรับออฟไลน์และออนไลน์โดยตรงจากข้อมูลดิบมีศักยภาพที่จะรับรองความถูกต้องแม่นยำยิ่งขึ้นในระหว่างการผลิต ดูข้อมูลเพิ่มเติมเกี่ยวกับสถาปัตยกรรมและส่วนประกอบที่เก็บฟีเจอร์ของ Qwak ได้ในงานนำเสนอนี้
สรุป
ในโพสต์นี้ เราได้ตรวจสอบไฮไลท์สำคัญของการวัดประสิทธิภาพและสถาปัตยกรรมของร้านค้าคุณสมบัติหลายแห่งสำหรับ AI/ML แบบเรียลไทม์ ร้านแรกคือ Open Source Feast ร้านฟีเจอร์ DIY Wix แห่งที่สอง ร้านที่สามจาก Tecton และร้านที่สี่โดย Qwak นอกจากนี้เรายังตรวจสอบไฮไลท์ของเกณฑ์มาตรฐานบางอย่างที่บริษัทเหล่านี้ดำเนินการเพื่อดูว่าร้านค้าออนไลน์ใดมีประสิทธิภาพมากที่สุดและคุ้มค่าที่สุด เรายังสำรวจกลไกหรือเซิร์ฟเวอร์คุณลักษณะที่จะใช้ในการดึงคุณลักษณะจากร้านค้าออนไลน์ เราเห็นว่าประสิทธิภาพและต้นทุนของที่เก็บฟีเจอร์มีความแตกต่างกันอย่างมาก ขึ้นอยู่กับสถาปัตยกรรม ประเภทฟีเจอร์ที่รองรับ และส่วนประกอบที่เลือก
เผยแพร่ครั้งแรกใน KDnuggets
