Защо вашият тръбопровод за машинно обучение (ML) няма да изглежда по никакъв начин както миналата година

Архитектурните предположения, които оформиха повечето канали за данни за машинно обучение в предприятията между 2019 и 2024 г., бяха изградени около специфичен набор от ограничения: трансформация, обвързана с процесора, пакетно-ориентиран ETL и системи за съхранение, проектирани за аналитични заявки, а не за работни натоварвания, обслужващи модели. Тези ограничения се разсейват по-бързо, отколкото повечето пътни карти за инфраструктура отчитат. Конвергенцията на обработката на данни, базирана на графични процесори, двигателите за заявки с милисекундна латентност и метаданните на обектно ниво в мащаб S3 не е постепенна еволюция на съществуващите модели. Тя изисква отказ от фундаментални дизайнерски решения, а не тяхното коригиране.

Предположението за ETL, ориентирано към процесора, се проваля

През по-голямата част от последното десетилетие стандартният конвейер за данни от машинно обучение (ML) премества данните през поредица от етапи на трансформация, обвързани с процесора: приемане, почистване, добавяне на функции, съхранение, обслужване. Това имаше смисъл, когато пречката беше I/O за съхранение и когато обучението на модели се случваше достатъчно рядко, така че латентността на конвейера беше приемлива. Проблемът е, че нито едно от условията не е валидно за обемите на натоварване, които характеризират производствените системи с изкуствен интелект през 2025 и 2026 г. Обучителните изпълнения сега консумират терабайти предварително обработени данни на час, а слоят за трансформация на процесора се е превърнал в стъпката, ограничаваща скоростта в пропускателната способност на конвейера, а не клъстерът от графични процесори, който той захранва.

Механизмът е ясен. Когато обучителна задача с 512 графични процесора чака зареждащ механизъм за данни, който сериализира предварителната обработка в процесорни нишки, използването на графичния процесор пада под 40 процента по време на фазите с интензивно използване на данни. Това не е проблем с настройката. Става въпрос за структурно несъответствие между процесорната единица, за която е проектиран трансформационният слой, и степента на потребление на изчисленията надолу по веригата. Екосистемата RAPIDS на NVIDIA и по-широкият преход към операции с DataFrame, ускорени от графични процесори, с cuDF, решават този проблем, като преместват трансформационните натоварвания в същата йерархия на паметта като процеса на обучение, елиминирайки PCIe трансферните разходи, които предварителната обработка на процесора въвежда.

Какво всъщност променя обработката на данни, базирана на графични процесори

Практическото значение на предварителната обработка, базирана на графичния процесор (GPU), не е просто по-бързи конвейери. Тя променя кои трансформации са икономически изгодни по време на обучение спрямо това, което трябва да бъде предварително изчислено и материализирано. С ETL, свързан с процесора, екипите рутинно предварително изчисляват и съхраняват производни функции, тъй като трансформацията в движение по време на обучение е била непосилно бавна. Обработката, базирана на графичния процесор, променя този компромис: сложните допълнения, токенизацията в голям мащаб и генерирането на вграждане вече могат да се случват в рамките на цикъла на обучение, без да се намалява използването на графичния процесор (GPU), което означава, че слоят за съхранение на функции става по-малко необходим за клас натоварвания, където преди това е служил като компенсатор на производителността.

Това има пряко отражение върху разходите. Хранилището с функции носят нетривиални оперативни разходи: управление на схеми, гаранции за актуалност, задачи за запълване и време за инженеринг, необходимо за поддържане на съгласуваност между офлайн и онлайн дефинициите на функции. Когато предварителната обработка, базирана на графичния процесор (GPU), може да замести предварително изчислената материализация на функции, тези разходи изчезват. Компромисът е цената на изчисленията за всяко обучение, която се увеличава, но за екипите, които плащат за резервиран капацитет на графичния процесор, това често е за предпочитане пред поддържането на паралелен инфраструктурен слой.

Обслужване на езерни къщи в реално време и краят на ламбда архитектурата

Архитектурата Lambda, която поддържа отделни пакетни и стрийминг конвейери за обслужване както на исторически, така и на данни в реално време, беше разумен отговор на ограниченията на първото поколение двигатели за заявки към езера данни. Латентността на заявките в стил Hive направи непрактична за обслужване на характеристики на модела директно от езерна къща по време на извод, така че екипите изградиха слоеве за обслужване на Redis или DynamoDB отгоре. Apache Iceberg, Delta Lake и Apache Hudi, комбинирани с двигатели за заявки като Apache Arrow Flight SQL и DuckDB, работещи с колонно обектно хранилище, намалиха латентността на точкови заявки в таблици от езерни къщи до ниски милисекунди при подходящи стратегии за разделяне.

Търговското значение е, че оперативната сложност на Lambda архитектурата вече не е оправдана за нарастващ дял от работните натоварвания, свързани с машинно обучение (ML). Поддържането на два кодови пътя, два модела за консистентност и два набора от SLA за свежест удвоява площта за повреди по отношение на качеството на данните по време на извод. Когато пакетният слой и обслужващият слой се разминават, което се случва при всеки нетривиален обем на запис, входните данни на модела по време на извод се различават от разпределението, върху което е обучен моделът. Свиването до един обслужващ слой тип „езерна къща“ с приемане в реално време чрез Apache Kafka или AWS Kinesis, захранвани директно с таблици на Iceberg, премахва това разминаване структурно, вместо да се опитва да го управлява оперативно.

Федерирани слоеве на заявки и достъп до функции между домейни

Корпоративните машинни обучения (ML) все по-често се нуждаят от функции, които превишават организационните граници: модел за измами, който се нуждае от данни за транзакции от плащания, телеметрия на устройства от системата за сигурност и история на акаунти от CRM. Конвенционалният подход насочва всичко това през централизирана ETL задача, което създава както проблем със забавянето, така и проблем с управлението. Преместването на данни през границите на домейните води до задължения за местоживеене на данните, сложност на контрола на достъпа и политически търкания, свързани с централизираната собственост върху данните.

Федерираните механизми за заявки, по-специално Trino, Starburst и нововъзникващият клас инструменти за семантичен слой, изградени върху тях, позволяват сглобяване на функции по време на заявка, без физическо преместване на данни между домейни. Планировчикът на заявки изпраща предикати до вградения механизъм за съхранение на всеки домейн и сглобява набора от резултати в координатора на заявки. Това е важно за ML конвейерите, защото означава, че логиката за инженерство на функции може да препраща към данни от активни домейни, без да е необходимо централизирано хранилище за данни, което да служи като посредник. За организации, работещи съгласно GDPR или специфични за сектора изисквания за местоживеене на данни, федерацията също така намалява регулаторната площ на конвейера за функции, като съхранява данните в неговата първоначална юрисдикция до момента на използване.

Метаданни на обектно ниво в S3 мащаб и какво позволяват те за агентни работни процеси

AWS S3 Express One Zone и по-широкият преход към хранилища за обекти с богати, заявки за метаданни представляват по-малко обсъждана, но структурно значима промяна за агентните AI натоварвания. Ограничението, което исторически е ограничавало това, което един агент може да прави със суровите данни в хранилището за обекти, е откриването: намирането на правилните обекти в контейнер, съдържащ стотици милиони файлове, изисква или предварително изграден каталог, или пълно изброяване на контейнери, като и двете въвеждат латентност и оперативни зависимости, които правят агентния достъп до данни в реално време непрактичен.

Маркирането на метаданни на ниво обект, комбинирано с S3 Metadata (в момента в предварителен преглед) и интеграция с AWS Glue Data Catalog, позволява на агентите да издават структурирани заявки към метаданните на обекти, без да четат съдържанието на обектите. Агентът може да идентифицира десетте най-скорошни контролни точки на модела за конкретен експеримент, да филтрира обучителните шардове по произход на източника на данни или да локализира всички регистрационни файлове за извод за дадена версия на модела за по-малко от секунда, без отделна каталожна услуга в критичния път. За агентски конвейери, които трябва да вземат решения за извличане на данни динамично, това променя архитектурата от такава, при която агентът извиква каталожен API, на такава, при която агентът прави заявки директно към хранилището, премахвайки оперативната зависимост и намалявайки броя на режимите на отказ.

Проблемът с родословието на метаданните в голям мащаб

Нито едно от тези архитектурни подобрения не решава основния проблем с произхода на данните, който става все по-остър с нарастването на динамиката на конвейерите. Когато предварителната обработка, базирана на графични процесори, трансформира данните в рамките на цикъла на обучение, когато таблиците тип „lakehouse“ получават непрекъснати актуализации и когато федеративните заявки сглобяват функции по време на заявката, веригата на произход от суровия източник до входните данни на модела става по-трудна за реконструкция. Това е важно за регулираните индустрии, където изискванията за одит изискват съставът на данните за обучение на модела да бъде възпроизводим, и е важно за отстраняване на грешки, където регресията на производителността на модела може да се проследи до промяна в схемата във федерален източник, която никоя система надолу по веригата не е открила.

Apache OpenLineage, вече част от Linux Foundation, предоставя неутрална от производителя спецификация за излъчване на lineage събития от рамки за обработка на данни, включително Spark, Airflow, dbt и Flink. Инструментирането на целия конвейер със събития на OpenLineage и съхраняването им в lineage backend, като Marquez, дава на инженерните екипи граф от зависимости от данни, към който може да се правят заявки, обхващащ целия конвейер, включително федеративни съединения и трансформации от страна на графичния процесор, ако рамката за обучение излъчва събития. Без това, архитектурната гъвкавост, получена от описаните по-горе модели, идва за сметка на наблюдаемостта.

Последователност на инвестициите в инфраструктура

Въпросът за лидерите в инженерството не е дали да възприемат тези модели, а в какъв ред, като се има предвид, че всеки от тях носи разходи за миграция и оперативен риск. Най-често срещаната грешка в последователността, която наблюдаваме, е третирането на миграцията на предварителна обработка, базирана на графичния процесор, като предпоставка за всичко останало. Това не е така. Консолидацията на обслужващите „lakehouse“ системи и федеративният слой за заявки са до голяма степен независими от стека за предварителна обработка и често осигуряват по-бърза възвръщаемост на инвестициите, защото намаляват оперативните разходи незабавно, вместо да изискват повторно изграждане на обучителен канал.

Практическото секвениране започва със слоя за обслужване: мигриране на обслужването на функции от специално хранилище за ключ-стойност към таблица Iceberg в реално време, подкрепена от двигател за заявки с ниска латентност, валидиране на SLA за латентност при шаблони на производствени заявки и след това разширяване на тази инфраструктура, за да покрие пътя на функциите за пакетно обучение. След като „lakehouse“ (езерната къща) е единственият източник на истина както за функциите за обучение, така и за функциите за обслужване, аргументите за предварителна обработка с помощта на GPU стават по-лесни за оценка поотделно, тъй като договорът за данни между слоя за предварителна обработка и заданието за обучение вече е стабилен.