DataOps Unleashed — конференция, на которой обсуждают DataOps, CloudOps и AIOps, лекторы рассказывают об актуальных тенденциях и передовых методах запуска, управления и мониторинга пайплайнов данных и аналитических рабочих нагрузках. 

Команда VK Cloud Solutions перевела конспект выступлений, которые показались полезны автору статьи. DataOps-специалисты ведущих ИТ-компаний объясняли, как они устанавливают предсказуемость данных, повышают достоверность и снижают расходы на работу с пайплайнами.

Вступительная лекция


Видеозапись выступления

Сейчас все работают с данными, поэтому DataOps переживает взрывной рост. Как командам идти в ногу с возрастающим спросом на данные? Кунал Агарвал, соучредитель и президент компании Unravel Data, рассказал о трех «К», мешающих эффективной работе команд по обработке данных:

  1. Крайняя сложность. Возникает из-за пайпланов и стеков данных. Чтобы сформировать современный стек, компании компонуют от 6 до 20 систем.
  2. Координация. Координация — это совместная работа дата-инженеров, специалистов по операциям с данными, дата-архитекторов и руководителей структурных подразделений. В работе этих специалистов недостаточно хорошо отлажены повторяющиеся стабильные процессы.
  3. Команда. В отрасли наблюдается сильный кадровый дефицит.

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

У DataOps-сообщества есть инструменты и процессы для решения этих проблем:

  1. Крайняя сложность. Благодаря наблюдаемости в full stack DataOps может упростить процессы управления, оптимизировать потоки, повысить надежность, качество и производительность приложений, работающих с данными. У специалистов появляется единый надежный источник истины, на который они могут положиться.
  2. Координация. DataOps может автоматизировать задачи, для решения которых раньше приходилось обращаться к экспертам, и значительно ускорить их масштабирование.
  3. Команда. Благодаря надежности и повторяемости процессов DataOps может ускорить взаимодействие между членами команды.
  4. Облако. DataOps создает интеллектуальное управление, позволяющее использовать все преимущества облачных решений и обойти стороной их недостатки.

Цикл операционной аналитики


Видеозапись выступления

Практики для работы с ПО пожирают бизнес, и работа с данными — не исключение. DataOps направляет компании в сторону повторяемости, гибкости и высокой скорости обработки данных. Но пока все равно с трудом удается преодолеть разрыв между экспертами, полагающимися на данные, и специалистами по подготовке данных. Boris Jabes, президент компании Census, ставшей пионером операционной аналитики и подхода reverse ETL, рассказал, как окончательно преодолеть этот разрыв с помощью операционной аналитики и подняться до золотого стандарта DevOps-принципов: непрерывного цикла данных.

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

А есть ли аналогичный цикл в DataOps? Команды по обработке данных часто попадают в ловушку «отправить запрос и подождать». Цикл обратной связи между командой по обработке данных и бизнес- или продакт-командами в большей степени зависит от конкретных обстоятельств. 

Инструменты Reverse ETL, как у компании Census, открывают дорогу операционной аналитике, которая берет данные из хранилища и создает CI/CD-пайплайн для деплоймента аналитики в реальном времени прямо в операционных инструментах. Вот как выглядит цикл операционной аналитики.

  1. Берем необработанные данные из источников данных и создаем модели, чтобы извлечь из них ценную для бизнеса информацию.
  2. Возвращаем ценные сведения в операционные приложения, чтобы автоматизировать бизнес-операции.
  3. Переносим новые данные из приложения в источники — цикл завершен.



Применяя такой цикл, можно внедрить подход Data-as-a-Product: артефакты данных напрямую связаны с бизнесом и помогают принимать решения. Раньше команда по обработке данных предоставляла услуги и принимала заказы. Теперь она становится критически важным звеном, поддерживающим гибкость бизнеса.

Прощайте, неработающие пайплайны и задержки релизов!


Видеозапись выступления

Достичь наблюдаемости пайплайнов данных в сложной среде становится все труднее. Компании выделяют дополнительные средства и тратят сотни человеко-часов на анализ влияния, который приходится выполнять вручную. Joseph Chmielewski, старший инженер в компании Manta, утверждает, что это можно исправить. В своем выступлении он рассказывает, как внедрить DataOps в рабочую среду, наладить автоматический мониторинг и тестирование и избавить ваших сотрудников от утомительной «ручной» работы.

В одной недавно вышедшей статье говорится, что в DataOps довольно трудно оркестрировать код и данные в разных инструментах и мониторить комплексную среду. Опрос о «наиболее серьезных технических трудностях DataOps, с которыми сегодня сталкиваются корпоративные команды по обработке данных», показал, что с проблемами оркестрации сталкивают 44% специалистов.

Чем сложнее среда данных, тем чаще «мертвые зоны» вызывают ошибки и инциденты. Исправить их не так-то просто, если наблюдаемость пайплайна данных ограничена. Эти мертвые зоны возникают из-за «неизвестных неизвестных» — данных, которые пользователь не учел или о которых ничего не знал. В сложной системе непросто рассмотреть детали: разные наборы данных имеют разную логику или структуру. И мертвые зоны возникают, когда у пользователя нет полного обзора.

Вот некоторые признаки невыявленных мертвых зон:

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

Йозеф приводит реальный пример влияния таких мертвых зон на работу предприятия:

Крупной автомобильной компании нужно было разобраться в экосистеме данных, чтобы ускорить управление изменениями и профилактику инцидентов. DataOps-команда безуспешно пыталась построить график зависимостей вручную. Команда дата-инженеров тратила 30–40% рабочего времени на отслеживание зависимостей и потоков данных. DataOps-команде удалось выявить в потоках данных мертвые зоны, которые нужно было устранить, — это были области на пересечении с работой других отделов. Ручная работа занимала слишком много времени, приводила к ошибкам и не давала устойчивых результатов в долгосрочной перспективе.

Автоматическое data lineage — хорошее решение, позволяющее устранить мертвые зоны и обеспечить наглядность в пайплайнах для всех пользователей данных. Это достигается благодаря анализу метаданных, подробному документированию потоков данных и воспроизводимым, проверяемым или справочным результатам анализа за весь период времени.

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

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

Благодаря решениям вроде Manta все пользователи получают полный обзор пайплайна. Такая организация работы:

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

Облачное Data Lakehouse невозможно без открытых технологий


Видеозапись выступления

Torsten Steinbach, ведущий архитектор в IBM, подробно рассказал о том, как его команда взрастила и встроила open-tech-решения в современную платформу Data Lakehouse. В своем выступлении он остановился на анализе табличных форматов с точки зрения согласованности данных, удобстве использования мета-хранилищ и каталогов, шифровании для защиты, индексах пропуска данных для повышения производительности и фреймворках пайплайнов.

Эволюция Big Data-систем прошла четыре этапа:

  1. В 90-х корпоративные хранилища данных были хорошо интегрированными и оптимизированными системами.
  2. В 2000-х благодаря озерам данных Hadoop и стекам ELK появилась возможность использовать на недорогом типовом оборудовании открытые форматы данных и настраиваемое масштабирование.
  3. В 2015 году популярность обрели облачные озера данных, эластичные и со схемой работы use/pay per job, объектными хранилищами и дезагрегированной архитектурой.
  4. Сегодня мейнстримом стали Data Lakehouses — благодаря целостности, безопасности данных, высокой производительности и масштабируемости, а также функциям работы в реальном времени.



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

Традиционно, чтобы добиться высокого качества и заявленного в SLA времени реагирования, система больших данных должна включать и облачное озеро данных, и хранилище.
Data Lakehouse — это озеро данных с качеством обслуживания на уровне хранилища. В нем можно:

  • работать с дезагрегированными данными в объектном хранилище;
  • принимать и обрабатывать эластичные и разнородные данные;
  • использовать механизмы обработки запросов. 

В нем поддерживаются открытые форматы, файловые и табличные. Кроме того, Data Lakehouse может предоставляться как услуга.

Торстен подробно останавливается на шести признаках Lakehouse, типичных для качества обслуживания на уровне хранилищ данных:

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

В Lakehouse соответствие требованиям ACID достигается использованием табличных форматов для фиксации истории версий метаданных, которые хранятся вместе с данными.

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

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

3. Табличный каталог. Hive Metastore остается золотым стандартом табличных каталогов с эпохи Hadoop. Но в его работе возникают сложности, если количество файлов измеряется шести-семизначными числами или разделы перечислены иерархически.

В Lakehouse реализовано следующее решение: информация о списках файлов децентрализуется с помощью файлов метаданных. Для кросс-табличных транзакций и истории версий используются новые табличные каталоги поверх табличных форматов (Nessie, LakeFS). Следующий рубеж — это объединить табличные каталоги с метаданными в реальном времени: Kafka Schema Registry (Confluent) и Apicurio Registry.

Наиболее популярные Open Source-проекты табличных форматов, созданные между 2017 и 2019 — Apache Iceberg (Netflix), Delta Lake (Databricks) и Apache Hudi (Uber).

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

4. Производительность и масштабируемость. Форматы файлов — ключевой фактор, связанный с производительностью и масштабируемостью. Распространенные форматы, такие как Parquet и ORC, содержат определенную статистику, например, минимальные и максимальные значения и фильтры Блума. Во многих модулях их можно использовать, чтобы пропускать файлы при оптимизации. К сожалению, им все еще приходится читать «подвалы» файлов Parquet/ORC. При этом они не охватывают все индексирование хранилищ данных SOTA, например, кластеризованные индексы со столбцами include.

В Lakehouse реализована поддержка специальных Open Source-фреймворков для индексации, например, XSkipper от IBM и Hyperspace от Microsoft. Данные индекса хранятся в специальных файлах Parquet в объектном хранилище, так что Lakehouse может индексировать файлы любого формата кроме Parquet и ORC.

5. Защита данных. В традиционных хранилищах данных используют механизм Access Control Lists (ACLs) с детализацией на уровне бакета или объекта. Таким образом, невозможно решить задачу подробных ACLs, например, на уровне столбца. Принудительное применение подробного доступа в модулях запросов нежизнеспособно: это убило бы понятие открытости и разнородности в Lakehouse. Далее в традиционных хранилищах строгие требования к безопасности предъявляются только к провайдерам и операторам объектных хранилищ.

Lakehouse нужно подробное принудительное применение доступа и шифрование данных внутри файлов. Комбинированное решение представляет собой Apache Parquet Encryption, которое не зависит от хранилища и транспортируемых доверенных данных. В нем есть поддержка ключей шифрования на уровне столбцов и «подвалов», а еще ACLs для столбцов посредством ACLs на базе ключей (в службе управления ключами).

6. Автоматизация пайплайнов. ETL-пайплайны, которые работают с данными в движении в реальном времени, используют коннекторы Spark или Flink. Они нужны для чтения или записи данных в тему Kafka, с абстракцией, дополнительно реализуемой через Apache Beam. Такие пайплайны размещают потоковые данные в объектном хранилище, например Iceberg, и поддерживают потоковые преобразования topic-2-topic.

Пакетные ETL-пайплайны для данных со Spark используют коннекторы в открытых фреймворках рабочих потоков (MLFlow, Luigi, Kubeflow, Argo, Airflow), а также бессерверные триггеры и последовательности встроенных событий, предоставляемые по принципу FaaS.



На схеме выше показана бессерверная платформа данных, реализованная IBM по принципу lake-as-a-service на основе открытых технологий:

  • Центральная служба — SQL Query, которая в бессерверном режиме выполняет прием данных, их пакетную ETL-обработку, каталогизацию и запросы к ним. Решение полностью основано на Spark.
  • Cloud Object Storage полностью S3-совместимо с использованием разных открытых форматов.
  • Event Streams — это управляемый сервис Kafka с реестром схем, в котором данные в реальном времени подключаются к Cloud Object Storage.
  • Watson Studio — это сервис оркестрации на основе Kubeflow для автоматизации заданий пайпланов.
  • Интеграция службы Cloud Functions/Code Engine с бессерверными и FaaS-функциями выполняется с помощью триггеров событий и последовательностей.
  • Эту платформу можно подключить к приложению с помощью Python, JDBC, REST API и других коннекторов, таких как Dremio.



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

Открытые сервисы, такие как Spark, PrestoDB, Dremio и Trino, можно интегрировать в платформу Lakehouse IBM, чтобы воспользоваться ее преимуществами.

Происхождение, цель и методы реализации наблюдаемости данных


Видеозапись выступления

Наблюдаемость данных (Data Observability, DO) — пока еще новое понятие. С ее помощью компании могут выявлять, разрешать и предотвращать проблемы с качеством данных. Для этого необходим непрерывный мониторинг их состояния с течением времени. Kevin Hu, соучредитель компании Metaplane, глубоко погрузился в тему наблюдаемости данных. В своем выступлении он рассказал о ее происхождении, определил сферу применения и компоненты наблюдаемости и поделился действенными советами о внедрении наблюдаемости на практике.

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

С появлением «современного стека» все больше данных централизованно размещают в одном месте, после чего используют для критически важных приложений: в области операционной аналитики, обучения ML-моделей и изучения удобства использования ИТ-продукта. Мы можем менять данные даже после размещения их в хранилище: то, что раньше было неизменным, стало гибким. Это увеличило объемы данных, их важность и фрагментацию поставщиков.

Команды по обработке данных могут многому научиться у разработчиков ПО. С инструментами наблюдаемости ПО, такими как Datadog, Grafana и New Relic, каждая команда разработчиков научилась быстро собирать метрики из всех систем и моментально получать аналитические сведения об их работоспособности. Они трансформировали мир программного обеспечения: витиеватая низкоинформационная среда, в которой невозможно было получить подробные данные, превратилась в прозрачную и наблюдаемую.

Три столпа наблюдаемости программного обеспечения — это метрики, отслеживание и логи:

  1. Метрики — цифровые значения, которые описывают компоненты программной системы на протяжении определенного времени. Например, использование ресурсов процессора микросервисами, время отклика конечной точки API или размер кэш-памяти в базе данных.
  2. Трассировки — описывают зависимости между элементами инфраструктуры. Например, жизненный цикл запроса приложения от конечной точки API к серверу и потом к базе данных.
  3. Логи — самый низкоуровневый элемент информации. Описывает и состояние элемента инфраструктуры, и его взаимодействие с внешним миром.

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



Отталкиваясь от вышеперечисленных основ, Кевин пришел к четырем основам наблюдаемости данных:

  1. Метрики. Если данные числовые,  у них есть статистика распределения показателей: среднее, стандартное отклонение и коэффициент асимметрии распределения. Если мы имеем дело с категориями, сводная статистика распределения представляет собой количество групп и их уникальность. Для всех типов данных можно рассчитать такие метрики, как полнота, наличие или отсутствие конфиденциальной информации, точность.
  2. Метаданные. Метаданные включают такие свойства, как объем, схема и свежесть данных — все это можно масштабировать независимо, сохраняя при этом статистические характеристики.
  3. Lineage. Data lineage определяет двунаправленные зависимости между датасетами, которые различаются по уровню абстракции от lineage целых систем, таблиц, столбцов и значений.
  4. Логи. В логах регистрируется, как данные взаимодействуют с внешним миром. Их можно классифицировать как взаимодействие «машина-машина» (перемещения, трансформации) и «машина-человек» (создание новых моделей данных, работа с дашбордами, построение ML-моделей).

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

Как можно измерить прогресс? Кевин привел несколько примеров метрик для двух целей:

  1. Чтобы сэкономить время разработчиков, посмотрите на количество проблем с качеством данных, длительность их выявления и устранения.
  2. Если вы хотите сохранить доверие, отслеживайте качественные опросы стейкхолдеров (например, NPS), количество входящих тикетов и цели и условия соглашений об уровне обслуживания.

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



Чтобы обеспечить высокую эффективность наблюдаемости, нужно выстроить процессы:

  • Профилактику — условия контрактов, Agile, модульное тестирование.
  • Активную наблюдаемость — CI/CD hook.
  • Пассивную наблюдаемость — непрерывный мониторинг.
  • Набор методов по устранению инцидентов (PICERL). 

Для настройки этих процессов существует множество инструментов: можно пробовать Open Source-проекты, создавать проприетарные или приобретать коммерческие решения.

Создание отказоустойчивой системы. Как Wistia обеспечила взаимодействие и наблюдаемость в пайплайнах данных


Видеозапись выступления

Есть ощущение, что специалисты по обработке данных часами играют в детективов, выслеживая, где же случился сбой в пайплайне. Donny Flynn, архитектор пользовательских данных в компании Census, продвигающей подход Reverse ETL, и Chris Bertrand, дата-сайентист в компании Wistia, подробно рассказали о важности взаимодействия и наблюдаемости при создании отказоустойчивых систем по работе с данными. Они также объяснили, как Reverse ETL помогает превратиться из сыщика в героя.

Census — это центральный элемент современного стека данных, инструмент Reverse ETL по операционной аналитике. Snowflake — это облачное хранилище данных, которое выступает единым источником истины для бизнеса. У вас есть разные источники данных в виде бизнес-приложений и SaaS-инструментов. У вас есть трансформации (dbt), которые происходят в хранилище данных, и аналитические данные для инструментов бизнес-аналитики (Looker). Вполне возможно, ваше хранилище принимает события из Segment. Census синхронизирует данные из хранилища и инструментов бизнес-аналитики с операционными инструментами.



Census совместима с экосистемой пайплайнов данных. Это могут быть решения для потоковой передачи событий, например, Snowplow, Kafka или Fivetran, которые переносят данные в ваш датахаб. Или оркестраторы заданий вроде Airflow, Prefect или Dagster.



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

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

Как Wistia использует Census для внедрения наблюдаемости? Исходная архитектура данных выглядит так:



  • Пользователи Wistia, работающие с компьютеров и смартфонов, взаимодействовали с приложением, написанным на Rails, и использовали MariaDB. Их специалисты по продажам и работе с клиентами используют Salesforce, так что для них важно получать информацию об использовании Wistia из основного приложения. Поэтому они выполнили пользовательскую интеграцию, с помощью которой API обращается с вызовом к Salesforce.
  • В то же время они использовали Fivetran, чтобы реплицировать экземпляры MariaDB в хранилище Amazon Redshift.

Почему в Wistia решили изменить эту архитектуру? При пользовательской интеграции с Salesforce возникает пять проблем:

  1. Из-за изменений в хранилище данных потребовалась ревизия кода на уровне приложения, а это весьма обременительная задача.
  2. Из-за изменений в хранилище данных нужно было работать с базой кода Rails (Ruby) — для нетехнических специалистов это сложно.
  3. Есть доступ только к данным приложения.
  4. Архитектура была кастомизирована для CRM-схемы Wistia.
  5. Любые системные сбои отправлялись в экземпляр Bugsnag как мусор, так что они реагировали на эти ошибки.

В итоге в Wistia переработали архитектуру:



Теперь в парк их ИТ-продуктов попадает Census. Они работают с API Census, использующим скрипты Python, чтобы управлять синхронизацией данных между Redshift и Salesforce. В результате им больше не нужно отправлять данные из Rails в Salesforce. Вот к каким улучшениям это привело:

  1. Для внесения изменений в хранилище данных теперь нужно проходить тесты dbt.
  2. Для внесения изменений в хранилище данных нужно работать с более знакомым языком — SQL.
  3. Есть доступ ко всем данным в хранилище.
  4. Архитектура все еще кастомизирована для CRM-схемы Wistia.
  5. В случае системного сбоя по электронной почте отправляются оповещения, а мониторинг встроен во внутренние системы.

Команда VK Cloud Solutions тоже развивает экосистему для построения Big Data-решений. Вы можете ее протестировать — для этого мы начисляем новым пользователям 3 000 бонусных рублей.

Что почитать по теме:

Комментарии (0)