Instaclustr спонсировал этот пост.
Слон в инженерной комнате сейчас заключается в том, что большинство ошибок ИИ связаны не с точностью модели или даже с качеством ваших обучающих данных. Вместо этого многие организации не получают от ИИ того, чего хотят (или ожидают), потому что они пытаются предоставлять прогнозы в реальном времени из конвейера пакетной обработки данных.
Я имею практический опыт работы со многими предприятиями, которые создали впечатляющие модели машинного обучения (ML), обеспечивающие время вывода менее секунды… а затем передающие им данные, которым уже несколько часов. Двигатель Ferrari имеет квадратные колеса.
Архитектурный пробел, требующий внимания
Производственный ИИ следует предсказуемой схеме: модели, которые преуспевают в тестировании, попадают в производство и сразу же сталкиваются с ночными заданиями ETL (извлечение, преобразование, загрузка), болотами данных, маскирующимися под озера, и хранилищами функций, у которых нет особой надежды успевать за трафиком. Затем мошенники обнаруживают подозрительные транзакции с опозданием на шесть часов, ваша система рекомендаций предлагает уже устаревшие сигналы о намерениях прошлой недели, а ваше «динамическое» ценообразование работает на статических данных.
Именно здесь Apache Kafka (и, чтобы быть ясным, я имею в виду Apache Kafka с полностью открытым исходным кодом) фундаментально меняет игру. В то время как все одержимы моделями преобразователей и нейронными архитектурами, команды, которые действительно преуспевают в промышленном искусственном интеллекте, незаметно решили проблему построения конвейеров потоковой передачи данных, которые полностью устраняют проблему устаревания.
Почему Kafka работает там, где не работает пакетная обработка
Рабочие нагрузки ИИ предъявляют особые требования, которым пакетная обработка не соответствует и не может удовлетворить. Когда вы обрабатываете миллионы прогнозов в секунду, каждая миллисекунда устаревания данных приводит к проблемам для клиентов. Способность Kafka доставлять сообщения с задержкой в 2 мс становится решающим фактором между обнаружением мошенничества и объяснением убытков аудиторам.
Традиционные очереди сообщений становятся узкими местами в масштабах ИИ, поскольку они не рассчитаны на объем и скорость рабочих нагрузок машинного обучения. Модель секционирования Kafka позволяет распараллеливать как прием данных, так и обслуживание моделей без узких мест координатора. Архитектура идеально соответствует поразительно параллельному характеру рабочих нагрузок вывода: один раздел на экземпляр модели, автоматическое распределение нагрузки и плавное горизонтальное масштабирование.
Большинство предприятий не готовы к внедрению искусственного интеллекта в реальном времени, поскольку их инфраструктура данных застряла в эпоху пакетной обработки.
Однако настоящее волшебство происходит при потоковой обработке с сохранением состояния. С помощью Kafka Streams вы не просто перемещаете данные между системами, но и преобразуете их в процессе работы. Разработка функций происходит в потоке, а не в пакетных заданиях. Агрегации постоянно обновляются. Ваши модели всегда видят текущие векторы признаков, поскольку сами признаки вычисляются в реальном времени.
Команды, добившиеся успеха при таком подходе, следуют узнаваемой схеме, согласно которой:
- Необработанные события перетекают в темы Kafka из приложений.
- Kafka Streams выполняет оконные агрегаты, которые отслеживают поведение пользователей за последние пять минут, час и день.
- Векторы признаков обновляются мгновенно по мере поступления новых данных.
- Модели используют расширенные темы, наполненные заранее рассчитанными функциями.
- Прогнозы возвращаются в Kafka, снабжая последующие системы, которые немедленно реагируют на них.
Конечным результатом является архитектура, которая постоянно синхронизируется с реальностью. Никаких задержек или узких мест в пакетных операциях нет, только непрерывная передача данных от источника к модели и к приложению.
Детали реализации имеют значение
Развертывание кластера Kafka и надежда на лучшее — это не стратегия. Успешная ли у вас реализация или что-то еще зависит от понимания этих критических шаблонов.
Ваша стратегия разделения определяет все последующие этапы. Случайное распределение кажется самым простым, но оно разрушает локальность данных. Вместо этого разделите их по объектам, таким как user_id, session_id или device_id. Это гарантирует, что связанные события попадут в один и тот же раздел, что, в свою очередь, позволит осуществлять обработку с отслеживанием состояния без распределенных транзакций.
Затем, когда вашей модели рекомендаций нужны все события для пользователя, они уже размещены вместе. Или, когда вашей системе обнаружения мошенничества требуется история транзакций, она легко доступна без межраздельных объединений.
Эволюция схемы также может улучшить или разрушить ваше развертывание. Ваши модели ИИ будут развиваться быстрее, чем ваши контракты данных, я гарантирую это. Используйте Avro или Protobuf с реестром схем с первого дня. Поначалу JSON может показаться проще, но данные без схемы в производственных конвейерах ИИ приводят к скрытым сбоям, повреждению данных и моделям, делающим прогнозы на основе неверных входных данных. Двоичные форматы также уменьшают размеры сообщений (часто значительно) по сравнению с JSON, что снижает затраты на инфраструктуру и уменьшает задержку.
В финансовых или медицинских системах искусственного интеллекта семантика «точно один раз» является решающей. Настройте производителей так, чтобы они могли безопасно повторять попытки, а потребителей — чтобы они были полностью транзакционными. Да, вы потеряете около 20% пропускной способности, но это небольшая цена за целостность (и гораздо дешевле, чем устранение дублирующих обвинений или защита плохих медицинских прогнозов перед регулирующими органами).
Те, кто сейчас преуспевает в использовании ИИ, — это не те, у кого лучшие модели, а те, у кого лучшая инфраструктура данных.
Обучающие данные требуют постоянного хранения, но хранение всего в горячем хранилище Kafka разрушает экономику. Внедрите многоуровневое хранилище в выбранное вами хранилище объектов, сохраняя при этом 24–48 часов горячего хранения для обработки в реальном времени и автоматически переводя все остальное в холодное хранилище. Ваши конвейеры обучения по-прежнему смогут получать доступ к историческим данным, не платя за дорогое SSD-хранилище.
Если есть одна сверхспособность Kafka, которую, как я вижу, командам по-прежнему не хватает, так это сжатие журналов для хранилищ функций. При сжатии журнала сохраняются только самые последние значения для каждого ключа, сохраняя при этом структуру темы. Он идеально подходит для хранилищ функций, где вам нужно текущее состояние без всей истории. Ваша модель всегда получает последний профиль пользователя, текущий баланс счета и самое последнее взаимодействие, и все это без запроса к базе данных или поддержания сложных уровней кэширования.
Создание архитектуры потокового ИИ
Начните с одного варианта использования, связанного с задержкой данных. Возможно, ваша система рекомендаций выдает устаревшие результаты или система мониторинга предупреждает вас на 30 минут позже. Создайте доказательство концепции, демонстрирующей преимущества потоковой передачи.
Передавайте события приложения напрямую в Kafka, минуя промежуточное хранилище. Оттуда:
- Вычисляйте функции в Kafka Streams вместо предварительной обработки в пакетном режиме.
- Пусть модели используют темы Kafka вместо запроса к базам данных.
- Передавайте прогнозы обратно через Kafka в последующие системы.
- Неукоснительно следите за задержкой P99.
- В тот момент, когда актуальность данных падает ниже уровня соглашения об уровне обслуживания (SLA), это и есть триггер масштабирования.
- Добавляйте разделы до того, как они вам понадобятся.
- Увеличьте репликацию до того, как вы увидите сбои.
Стоимость избыточной подготовки Kafka минимальна по сравнению со стоимостью обслуживания устаревших прогнозов.
Конец неприятной правды
Большинство предприятий не готовы к внедрению искусственного интеллекта в реальном времени, поскольку их инфраструктура данных застряла в эпоху пакетной обработки. Они вложили миллионы в озера и хранилища данных, оптимизированные для исторического анализа, но не для разведки в реальном времени. Они сформировали команды, ориентированные на оркестровку пакетных заданий, а не на потоковую обработку, и создали архитектуры, предполагающие, что данные находятся в состоянии покоя, а не данных в движении.
Kafka — это больше, чем выбор технологии. Платформа с открытым исходным кодом — это архитектурная философия, согласно которой данные должны непрерывно передаваться от источника к потребителю. Используя Kafka, вы обязуетесь устранить искусственные задержки, которые возникают при пакетной обработке, и признаете, что в современных системах искусственного интеллекта свежие данные каждый раз превосходят сложные модели.
Те, кто сейчас преуспевает в использовании ИИ, — это не те, у кого лучшие модели, а те, у кого лучшая инфраструктура данных. Эта инфраструктура все чаще строится на основе потоковой передачи, которая устраняет устаревшие данные в источнике. Пакетная обработка — это конкурентный недостаток, который вы больше не можете себе позволить.
Instaclustr обеспечивает надежность в любом масштабе благодаря интегрированной платформе данных с технологиями с открытым исходным кодом, такими как Apache Cassandra®, Apache Kafka®, Apache SparkTM, ElasticsearchTM, RedisTM, Apache ZooKeeperTM и PostgreSQL®. Узнайте больше Последние новости от Instaclustr ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Анил Инамдар — глобальный руководитель службы обработки данных в компании NetApp Instaclustr, которая предоставляет управляемую платформу на базе технологий данных с открытым исходным кодом, включая Cassandra, Kafka, Postgres, ClickHouse и OpenSearch. Анил имеет более чем 20-летний опыт работы в области данных и… Подробнее от Анила Инамдара
