«Трансформация надстройки происходит значительно медленнее, чем трансформация  основания, поэтому потребовалось более полувека, чтобы изменения условий производства нашли отражение во всех областях культуры. Только сегодня мы можем оценить, какая форма была принята»

Беньямин Вальтер. Произведение искусства в эпоху его технической воспроизводимости, 1936

В то время, как Вальтер фактически жаловался на на развитие медиатехнологий для использования в неофашистской пропаганде, он также описывал критические моменты, когда техническая эволюция порождает радикальные культурные изменения, такие как происходящие сегодня с бессерверными вычислениями и облачными сервисами.

Хотя «бессерверные вычисления» не заняли полвека, любой, кто работает в этой отрасли в течение последнего десятилетия, наблюдал устойчивое развитие от виртуализации до бессерверной архитектуры. Добавьте к этому технологию конвергентной обработки и хранения данных, и вы получите мощную комбинацию  экономически эффективных и удобных для всех технологий.  Все лучшие облачные провайдеры имеют продуманные предложения по платформе и программному обеспечению, способные устранить, или, по крайней мере, сильно сократить необходимость концентрации на инфраструктуре, позволяя любым  предприятиям сосредоточиться на обеспечении ценности, а не поддержке технологии.

В первой из трех частей этой серии мы расскажем о том, какие новейшие серверные и современные облачные сервисы могут предоставлять аналитические платформы данных и посоветуем, как сделать выбор технологий.

При рассмотрении любой платформы данных конечный результат, который мы будем называть продуктом данных, должен быть ключевым мотиватором всех решений. Когда мы говорим о продуктах данных, мы подразумеваем регулярную аналитическую отчетность, автоматизированное принятие решений посредством машинного обучения или конкретно определяемых бизнес-решениях, поддерживаемых специальным анализом данных. Чтобы понять, о каких технологиях мы говорим, ознакомьтесь с приведенным ниже техническим стеком кандидатов, представляющих  услуги от трех наиболее известных поставщиков облачных вычислений.

Бессерверные опции в облаке

Общие компоненты архитектуры в техническом стеке. Несмотря на то, что, несомненно, функциональность и завершенность перечисленных облачных сервисов будет различаться, для рассматриваемых нами вариантов использования они функционально эквивалентны.

Конвейер данных (Data Pipeline):

Интеграция с поглощением (Ingestion Integration)

Этот компонент отвечает за сбор данных из множества источников, продвигая их к очереди событий и / или на уровень облачного хранилища. Он представляет собой связующее звено для остальной части предприятия или других внешних источников данных. Хотя существуют и другие варианты облачных сервисов, это решение по-прежнему превосходит их в общей структуре поглощения.  Стоит отметить, что решение еще не усвоено облачной службой, поэтому для него требуется развертывание в контейнерах Docker в службах управления контейнерами, доступное для всех 3 перечисленных облачных провайдеров.S

Поглощение и очередь событий (Ingest & Event Queue)

Это механизм распределенной очереди, который представляет собой сердцевину платформы данных, управляемой событиями. Что отличает эти сервисы от обычных очередей, так это то, что они распределены, и они способны обслуживать множество одновременных потребителей, используя один и тот же поток. Эти службы функционально эквивалентны Apache Kafka, но являются ”платформой как услуга” (PaaS), устраняющей необходимость управления ОС Linux и  Kafka daemons. Все облачные сервисы имеют отличную интеграцию с потоковыми и облачными компонентами, что делает интеграцию чрезвычайно простой.

Общее хранилище (Common Storage)

Это высокодоступное и масштабируемое хранилище облачных объектов, из которых самый популярный пример AWS S3 (несмотря на файловую систему Google, вышедшую на несколько лет раньше S3). В облачной архитектуре оно функционально эквивалентно файловой системе HDFS от Hadoop и используется вместо нее в этой архитектуре. Оно служит для хранения файлов почти для всех компонентов облачного сервиса.

Обработка событий (Event Processing)

Отрабатывая Ingest & Event Queue, обработка событий является основой конвейера данных. Она включает в себя (но не ограничивается) очистку данных, создание объектов / прогнозов и агрегации. Поскольку многие, если не большинство, из этих операций, как правило, являются атомарными (одна операция на одно событие данных), для обеспечения высокой эффективности используются бессерверные функции облака. Облачные функции - это просто фрагменты кода, выполняемые для каждой записи, считанной из очереди событий. Не нужно беспокоиться о запуске кластеров серверов для обработки рабочей нагрузки - все это осуществляется самим облачным сервисом.

Обработка информационных массивов (Bulk Processing)

Как правило, это более традиционная пакетная обработка нескольких записей из Ingest & Event Queue или непосредственно из Common Storage. Эта технологическая услуга, -  как правило, представлена в виде любимого многими распределенного программного обеспечения для обработки данных Apache Spark. Spark может использоваться в пакетной потоковой обработке, а также содержит приличную библиотеку машинного обучения. Лучшим способом использования Spark в архитектуре облачного сервера является динамическое создание кластеров, когда данные доступны для обработки данных, а затем автоматически сбрасывают кластер. Это гарантирует отсутствие чрезмерных расходов от простоя кластера.

Так как облачные сервисы должны созреть до полностью бессерверными (с точки зрения пользователя), мы все с замиранием сердца ждем реализации  Apache Spark, где нет необходимости управлять кластером. Таким образом, мы рекомендуем использовать облачные функции, если нет крайней необходимости в Apache Spark.

Аналитические услуги:

Машинное обучение (Machine Learning)

тот уровень может казаться загадочным и сложным для некоторых, но на самом деле в конечном итоге он представляет собой умеренно сложный набор конвейеров данных со специализированными функциями. Фактически, большая часть предварительной работы по подготовке данных для машинного обучения будет происходить в ранее упомянутых компонентах Event and Bulk Processing. Машинное обучение рассматривается отдельно от обработки событий, поскольку многие специализированные функции доступны как облачные сервисы, а также инструменты разработки для создания и модификации моделей машинного обучения. Поскольку это глубокая тема, мы изучим ее подробнее в более поздних блогах, но пока достаточно упомянуть, что

облачные сервисы заботятся о большой инфраструктуре и процессе разработки, где ваши ученые по данным или инженеры по машинному обучению не сильны.  Конечной целью большинства услуг машинного обучения является создание понимания для самостоятельного использования автоматизированными решениями и (или) для улучшения отчетности Business Intelligence.

Система обработки запросов (Query Engine)

Это общая реляционная база данных SQL, оптимизированная для масштаба данных, требуемых для наших аналитических прецедентами. В большинстве облачных сервисов это полностью совместимый с SQL сервис с незаметно работающим колоночным механизмом хранения.  В большинстве облачных сервисов доступно множество вариантов, включая службы, совместимые с MySQL или SQL Server с масштабируемыми архитектурами. Эта общая стартовая точка позволяет использовать множество инструментов в базе данных, предоставляемой в качестве услуги. Данные поступают сюда с помощью движков Event или Bulk Processing.

Business Intelligence

Обычно этот компонент представляет инструменты для создания отчетов и данных, основанные на хранилищах данных SQL. Хотя мы указали лишь традиционные инструменты BI, доступные в облаке, вы можете использовать многие другие платформы для визуализации или поиска данных. После того, как данные попадают в базу данных и проходят подсчет, открывается целый легион инструментов, доступных поставщикам облачных вычислений или другим поставщикам SaaS.

Как выглядит беcсерверный конвейер?

Он охватывает множество технологий. Для примера давайте посмотрим, какой поток данных понадобится в гипотетическом интернет-магазине. В этом случае мы будем использовать компоненты Google Cloud Platform для создания платформы, поддерживающей как хранилище данных, так и панель мониторинга near-realtime. В этом упрощенном примере используются три источника данных:

1. Просмотр продукта пользователем интернет-магазина
2. Заказы из онлайн-системы управления розничными заказами
3. Информация об обновлении каталога продукта из загрузок файлов

Вот что происходит в этом примере:

1. Приложение Online Retailer Website отправляет данные о событиях непосредственно в очередь Google Cloud Pub / Sub через клиента, встроенного в приложение.
2. Приложение  Order Management System отправляет данные о событиях непосредственно в очередь Google Cloud Pub / Sub.
3. Apache NiFi автоматически загружает файлы каталога продуктов (Product Catalog) из каталога в облачном хранилище Google.
4. Apache NiFi анализирует файлы обновления Product Catalog в событиях и помещает их в очередь Google Cloud Pub / Sub.
5. Облачные функции (Cloud Functions) используются для очистки, фильтрации, преобразования данных. Они записываются обратно в другую очередь Cloud Pub / Sub для последующего потребления.
6. Поддержка панели мониторинга near-realtime  потоковое задание Cloud Dataflow объединяет продажи за день и сохраняет результаты в простой базе данных Cloud SQL.
7. По завершению использования панели near-realtime простое веб-приложение периодически запрашивает базу данных Cloud SQL, чтобы обновить панель мониторинга.
8. Поддерживая Data Mart (и, возможно, другие варианты использования), все данные из обработанных очередей Cloud Pub / Sub в # 5 записываются в Cloud Storage.
9. Набор работ Cloud Dataproc объединяет, агрегирует, фильтрует и преобразует объединенные данные в подходящий для Data Mart формат.
10. BigQuery производит чтение непосредственно из файлов, подготовленных заданиями Dataproc, что позволяет выполнять аналитические задания SQL с помощью инструментов Business Intelligence, таких как Data Studio. Data Studio может использоваться для составления и регулярного запроса из Bigquery для всех случаев использования хранилища данных. В этом примере Data Studio также предоставляет функции визуализации данных.

Зачем нам бессерверная технология?

Итак, что заставило бы вас построить продукт данных с вышеупомянутыми технологиями? Давайте рассмотрим возможности, которые предоставляет платформа такого рода, и почему она отличается от того, что было раньше. Вот наш «Tight 5»:

• Информационная инженерия и кодирование машинного обучения будут значительно сокращены, что позволит увеличить время разработки инновационных продуктов.
• У ваших команд будет более легкий доступ к облачным сервисам, которого не было раньше. Если команде срочно требуется программное обеспечение, время реализации будет составлять минуты или часы, а не дни или недели. Необходимо осуществлять исследование данных в среде для ноутбуков? Раскрутите облачную службу или конкурирующий продукт SaaS над готовыми наборами данных.
• Бессерверная обработка на основе событий сокращает развертывание, тестирование и обслуживание инфраструктуры до нескольких строк кода автоматизации. Это позволяет резко упростить получение рабочей платформы данных.
• Гибкость и отсутствие капиталовложений. Пользуясь услугами ведущих провайдеров. вы вносите плату за мегабайт / событие / секунду. Теперь вы можете самостоятельно контролировать вашу среду. Если вам необходимо внести какие-то изменения в бизнес, то они полностью будут под вашим контролем. Создавайте новые продукты и избавляйтесь от старых так же быстро, как ваши команды способны с этим справиться
• Вспомогательные услуги, такие как наблюдение, оркестровка, авторизация / аутентификация, идентификация / каталог, PCI-DSS, сетевая безопасность, активное или неактивное шифрование, уже встроены в платформу. Эти дополнительные услуги часто игнорируются до реализации, но с их помощью можно выполнять или прерывать реализации. Стоит отметить, что поставщик облачных услуг обычно предоставляет эти услуги для многих клиентов, поэтому все, что уже встроено в систему, автоматически было спроектировано и протестировано большим числом организаций.      

Обратите внимание, что мы не упоминали о сбережениях затрат: основное внимание уделяется разработке продуктов данных. Причины создания эффективной платформы данных многообразны в большинстве организаций, но для того, чтобы оправдать переход на новую платформу данных, мы предположим, что ваш случай (случаи) использования:

а) предоставляет значительное конкурентное преимущество через аналитику или

б) обеспечивает доход поток прямо или косвенно из ваших продуктов данных.

Экономия затрат может фактически быть побочным эффектом перехода на облачную платформу данных, но редко бывает достаточной мотивацией для перемещения. Следовательно, мы рассматриваем функциональные преимущества, а не полагаемся на прямое сравнение затрат.            

Кому подходит бессерверная технология?                   

Первоначальные сценарии для организаций, использующих облачную архитектуру,таковы:

1. Нет существующей платформы данных, поэтому нет никакой стоимости преобразования. связанных с внедрением новейших технологий. Это характерно для стартапов или тех редких организаций, которые никогда не пытались извлечь из своих данных выгоду. Такой сценарий с названием «greenfield» также распространен, когда вы строите платформу данных, чтобы использовать данные, но не понимаете, как извлечь выгоду из данных вашей организации.            
2. Это лидеры продуктов или технологий в крупной организации с уже существующим хранилищем данных, которые не могут обеспечить возможности для новых продуктов данных или просто не могут идти в ногу с текущими потребностями бизнеса. В этом случае мы предполагаем, что отдельная команда стремится извлечь данные своей организации в параллельную платформу данных, чтобы как можно быстрее извлечь ценность и шагнуть вперед.    
3. Это организации с существующими инвестициями в кластеры Hadoop или Spark в локальных или даже облачных серверных экземплярах. Как правило, эти организации стремятся сократить время, затрачиваемое на обслуживание платформы, и стремятся использовать аналитические сервисы, тесно интегрируемые с облаком.         

В первом сценарии у вас есть большая свобода принимать новые технологии, не беспокоясь о работе с устаревшими технологиями. Кроме того, не будет потайных затрат, касающихся имеющихся основных ресурсов, таких как имеющийся кластер, который не даст вам полностью использовать бессерверный подход.  Единственный недостаток в этом сценарии заключается в том, что в вашей организации может не быть кадров с необходимыми навыками для первоначального решения проблемы планирования и реализации. Если вашей организации нужна помощь, разумно искать соответствующих экспертов для оказания помощи для вашей новой архитектуры.

Во втором сценарии у вас, вероятно, будет намного больше осложнений, связанных с поглощением устаревших источников данных. Для простоты и скорости лучше избегать попытки интеграции с любыми другими компонентами вашей существующей архитектуры, отличной от источника данных. Решения, описанные ранее, такие как Apache NiFi, лучше всего использовать для запроса указанных каталогов для файлов, где более старые механизмы доставки не могут быть интегрированы. При этом вы обнаружите, что Apache NiFi поддерживает множество стандартных протоколов, таких как HL7, FTP, MQTT, SNMP, JMS, многие современные облачные сервисы, и может быть легко расширен по мере необходимости. Весьма вероятно, что это удовлетворит все ваши потребности интеграции на уровне «Поглощение».

В завидном случае, когда ваша компания уже имеет платформу данных в облаке, как в сценарии 3, ваша миграция в архитектуру облачных сервисов может быть более постепенной. Например, если у вас есть действующий резидентный кластер Hadoop и (или) кластер Kafka, поддерживающий успешную архитектуру поглощения, вы можете выбрать гибридный подход и реализовать только обработку данных и аналитические службы в своей архитектуре. Вообще, поглощение, как правило, сложнее перестроить, поэтому ваша команда может выбрать гибридный подход, чтобы сократить время доставки ваших продуктов данных.                     

В будущих статьях мы рассмотрим более глубокое погружение в примеры архитектуры. Во второй части этой серии из 3 частей мы рассмотрим схему типичного конвейера данных. Мы изучим пример рабочего потока конвейера данных на основе управляемых событиями бессерверных функций и  их возможностей упрощения задачи обработки данных. Затем, в части 3, мы будем следить за разработкой и реализацией для аналитической службы архитектуры. В частности, мы рассмотрим механизм сбора данных и автоматизированный механизм принятия решений с использованием библиотеки обучения облачным машинам.                       

No Comments