Как бывший администратор сетей и систем хранения данных, я с удивлением наблюдаю, как облако абстрагируется от сложности инфраструктуры, пишет на портале BigDATAwire Джозеф Мораис, технический лидер и эксперт компании Confluent в области потоковой обработки данных.
Сегодня управляемые сервисы позволяют предприятиям масштабировать системы без необходимости вникать в низкоуровневую структуру сетей, систем хранения и данных, как это было раньше. Именно поэтому я восхищен широким распространением архитектур периферийных вычислений. Благодаря этому рынку (объем которого, по данным IDC, к 2028 г. составит 378 млрд. долл.) предприятия начинают решать самые сложные задачи распределенных вычислений: ограниченные сети, сложные сценарии отказов и требования к потоковым данным, которые разрушают представление многих инженеров о данных как о чем-то статичном, хранящемся в базе данных.
Давайте рассмотрим подробнее, почему периферийные вычисления так сложны, как они противоречат традиционным представлениям платформенных команд о данных и почему ставки так высоки для правильной реализации этой важной и быстро развивающейся архитектуры.
От IIoT к основным корпоративным приложениям
Первые примеры использования периферийных вычислений появились в промышленном Интернете вещей (IIoT), где сетевое подключение неравномерно и важны миллисекунды. На заводах периферийные системы предиктивного обслуживания играют важную операционную роль, например, вовремя отключают перегретое оборудование, чтобы избежать катастрофы. Этим системам требуется сверхмалая задержка, локализованная обработка и возможности обработки обрывов связи.
Однако периферийные вычисления выходят далеко за пределы промышленных предприятий.
Сегодня предприятия алгоритмически обрабатывают каждую точку данных для принятия решений. Правильная организация периферийных вычислений подразумевает определение того, как обрабатывать данные, генерируемые на конечных точках за пределами централизованной инфраструктуры, делая их воспроизводимыми, устойчивыми и высокодоступными. К таким конечным точкам можно отнести смарт-устройства, мобильные телефоны или подключенные автомобили. Эта проблема стоит перед любой компанией с удаленными объектами, парком устройств, которым нужно «звонить домой», или любым сценарием использования, когда происходит обучение или формирование выводов искусственного интеллекта. Периферийные вычисления — это маршрутизация данных и извлечение ценности как можно ближе к реальному времени, когда эта ценность оказывается максимальной.
Архитектура для ненадежных сетей и неизбежных сбоев данных
Периферийные среды часто характеризуются нестабильными сетевыми соединениями. Устройства отключаются. Линии в сельской местности обрываются. Время безотказной работы крайне непостоянно. Первый принцип проектирования периферийных вычислений: убедитесь, что конечные точки могут восстанавливаться после сбоев и передавать данные после восстановления соединения.
Задержка — еще одна область отказов, которая критически важна в архитектурах периферийных вычислений. Если промышленные машины достигают определенных пороговых значений давления или температуры, то задержка реакции на команду в доли секунды, вызванная, например, перегрузкой полосы пропускания, может привести к катастрофическим последствиям. Хорошей сети недостаточно, если скачок задержки не позволяет критически важным данным достичь места назначения.
Суверенитет данных и локальность добавляют еще один уровень сложности на периферии. Например, компании, предоставляющие финансовые услуги, сталкиваются с законами о защите персональных данных потребителей, которые ограничивают их возможности по обработке и анализу данных. Во многих случаях для обеспечения комплаенса и защиты клиентов требуется санитизация данных до того, как они покинут регион.
Восприятие данных как событий: новый архитектурный подход
Существует два распространенных, но ошибочных подхода, которые мешают предприятиям, стремящимся решить эти проблемы с периферийными вычислениями.
Первый: связать все периферийные сайты с центральным узлом и запускать там службы. Это увеличивает задержки, усложняет суверенитет и создает центральную точку отказа.
Второй: рассматривать периферийные данные в традиционных терминах баз данных. Исторически сложилось так, что данные представляют собой нечто статичное — они организуются в схемы и извлекаются для последующего анализа. Такая модель «данных в состоянии покоя» рассматривает постоянство как первоклассную характеристику дизайна, а события — как второстепенные.
Потоковые данные переворачивают эту модель. Вместо того чтобы хранить данные для последующей работы с ними, приоритет отдается действиям в реальном времени по мере возникновения событий. Такой подход акцентирует внимание на «происходящем», позволяя системам непрерывно обрабатывать и реагировать на события, в том числе восстанавливаться после сбоев. Это очень важно на периферии, где требования к задержкам и суверенитету часто предполагают, что обработка должна происходить ближе к источнику.
Почему потоковая обработка данных идеально подходит для сложных периферийных архитектур
Потоковая обработка обеспечивает гибкую и надежную подложку для данных, которая позволяет манипулировать ими «на лету».
Наиболее распространенным фреймворком для потоковой обработки данных является Apache Kafka, который построен на неизменяемом журнале, предназначенном только для добавления, что обеспечивает долговечность и воспроизводимость. Kafka — это распределенная технология, обеспечивающая масштабируемость и высокую доступность даже на периферии. Если что-то выходит из строя, Kafka позволяет потребительским приложениям воспроизводить события из журнала — данные не теряются. Kafka поддерживает семантику exactly-once (каждое сообщение будет обработано один и только один раз), транзакционную обработку и асинхронную репликацию (например, объединение кластеров), помогая системам восстанавливаться после проблем со связью и сохранять согласованность. Это делает его отличным решением для сред с нестабильной связью или требованиями высокой доступности.
Apache Flink дополняет Kafka обработкой потоков с учетом состояния. Его отказоустойчивость основана на использовании контрольных точек и снимков состояния — периодическом сохранении состояния приложения в долговременном хранилище. В случае сбоя Flink восстанавливается с последней контрольной точки, минимизируя сбои и избегая несоответствий. Flink также обрабатывает потоки практически в реальном времени, позволяя использовать такие периферийные сценарии, как санитизация, агрегация и обогащение данных, и при этом сохранять устойчивость.
Kafka и Flink — это лучшая отправная точка для создания инфраструктуры данных, управляемых событиями, которая хорошо совместима с периферийными архитектурами.
Высокое вознаграждение за правильную настройку периферии и потоков
Большой победой облачных вычислений стало то, что инфраструктура стала гораздо более удобной для использования по умолчанию. Обещание дать инженерам возможность сосредоточиться на создании ценности, а не на управлении инфраструктурой, стало настолько верным, что превратилось в клише.
Что делает периферию интересной, так это то, что она относительно сложна и все еще развивается, предлагая огромные технологические и бизнес-преимущества тем компаниям, которые правильно ее используют. Быть хорошим специалистом в области периферийных вычислений сегодня — все равно что быть хорошим специалистом в области веб-приложений в конце
Для платформенных команд, уже работающих с многопользовательскими системами, борьба с отказами в массово распределенных, эфемерных средах не является новой проблемой. Но для предприятий, все еще придерживающихся концепции «данные в состоянии покоя», стоимость выхода на периферию заключается в принятии потоковых архитектур, управляемых событиями.
Но отдача того стоит. Потоковая обработка открывает доступ к потоку данных реального времени и инсайтам реального времени и поддерживает культуру, готовую мгновенно реагировать на изменения в мире.
