Арена дата что это
Ещё один шаг в сторону open source: как и почему мы внедрили Arenadata DB
Привет, Хабр! Меня зовут Станислав Маскайкин, я архитектор аналитических систем ВТБ. Сегодня я расскажу о том, почему мы перевели нашу систему подготовки отчётности с Oracle SuperCluster на российскую Arenadata DB. Как мы выбирали решение, почему не взяли чистый опенсорс, а также о некоторых результатах такой миграции — под катом.
Зачем нужен был переход?
Несколько лет назад банк ВТБ объединился с Банком Москвы и ВТБ 24. Каждый из банков имел собственную ИТ-инфраструктуру с отдельным аналитическим контуром. После объединения получилось, что в банке одновременно существуют три разных ИТ ландшафта.
Само по себе владение тремя разными системами – это тройные затраты на инфраструктуру, поддержку и развитие. Но в нашем случае было ещё несколько факторов.
С точки зрения законодательства любой банк должен регулярно сдавать отчётность проверяющим органам. После объединения эту отчётность мы должны были сдавать уже по единому ВТБ. Имея три разрозненные системы, решать эту задачу можно было разве что вручную.
Исторически ВТБ24 был ориентирован на работу с физическими лицами, ВТБ – на работу с юридическими лицами, а Банк Москвы – на работу и с первыми, и со вторыми.
На момент объединения этих банков обязательная отчётность формировалась в следующих системах:
Единое хранилище данных (ЕХД) – хранилище данных Банка Москвы, реализованное на SuperCluster M8 и ETL-инструменте Informatica Power Center.
Система подготовки отчётности – хранилище данных ВТБ24, реализованное на Oracle SuperCluster M8 с программным обеспечением Diasoft Flextera BI. Данные для этой системы готовились в другом хранилище – корпоративном хранилище данных (КХД), реализованном на СУБД Teradata и ETL-инструменте SAS Data Integration. КХД, в свою очередь, получало данные из оперативного хранилища данных, реализованного на Oracle SuperCluster M8. А туда они реплицировались из автоматизированных банковских систем при помощи инструмента Oracle Golden Gate.
Корпоративное информационное хранилище – хранилище данных ВТБ, реализованное на Oracle Exadata X8-2 и ETL-инструменте Informatica Power Center.
Чтобы не формировать обязательную отчётность по объединённому ВТБ в ручном режиме, были созданы интеграции между хранилищами данных.
Это привело к ещё двум большим проблемам:
Увеличилось время получения данных, что часто приводило к срыву сроков предоставления информации.
По правилам ЦБ РФ отчётность за очередной месяц сдаётся в течение первых четырех дней следующего месяца. В банке под это задействуются огромные вычислительные мощности. Если первые дни месяца попадают на рабочие дни (как в марте), мы даже не имеем возможности вернуться и что-то пересчитать – это риск для банка не сдать отчётность вовремя. Повышение доступности данных на этом уровне играет огромную роль.
Из-за большого количества расчётов в хранилищах и копирования данных выросло количество инцидентов с качеством этих данных, что тоже очень сильно влияет на сроки предоставление отчётности.
Ещё один момент: многие компоненты нашей инфраструктуры, такие как Oracle SuperCluster, на котором у нас реализована большая часть аналитического ландшафта, попали под End of life. Они были сняты с поддержки производителем и больше не развивались, т.е. обновление необходимо было в любом случае.
Проблема окончания поддержки коснулась не только системы подготовки отчётности, но и озера данных на платформе Oracle Big Data Appliance. К тому моменту — а происходило все в 2018–2019 годах — сотрудники ВТБ уже в полной мере оценили data-driven подход и потребляли достаточно много данных. Поэтому с точки зрения бизнеса банка система была критичной. Т.е. перед нами стояла более глобальная задача масштабов всей инфраструктуры.
Параллельно в объединённом ВТБ началась масштабная цифровая трансформация, охватившая все уровни IT, начиная от создания новых ЦОДов и объединения сетей, и заканчивая унификацией автоматизированных банковских систем и созданием омниканальной платформы для фронтальных решений. Всё это кардинально меняло внутренний IT-ландшафт банка.
Поэтому мы задумались не просто об обновлении продукта, решающего частную задачу сбора отчетности, а об изменении аналитического ландшафта и подходов по работе с данными.
Логичная идея – создание единого аналитического контура, в рамках которого все данные будут находиться в едином хранилище данных и доступны для всех пользователей в удобном виде. Это привело нас к решению о построении платформы данных ВТБ.
Что такое платформа данных? Для себя мы определили её так: это набор сквозных интегрированных технологических решений (технологическое ядро), которые являются основой для разработки и функционирования сервисов по работе с данными банка ВТБ.
Главная часть платформы данных – технологическое ядро. Это системные компоненты, которые переиспользуются на всех уровнях платформы данных.
Мы выделили 6 компонентов технологического ядра:
Управление качеством данных.
Концептуальная архитектура платформы данных выглядит следующим образом:
Ядром платформы данных является СУБД, на которой реализовывается хранилище данных. Далее расскажу об этом подробнее.
Выбор новой платформы
Поскольку платформа данных содержит персональные данные о клиентах и банковскую тайну, требования по надёжности и безопасности были ключевыми. Однако они не лишали нас вариантов выбора – решений, которые могли бы нам подойти, было много.
Мы не просто подбирали систему по набору функций, мы смотрели в будущее. С точки зрения бизнеса нам выгоднее было искать продукт, на развитие которого мы сможем оказывать влияние. При этом разработка собственного инструмента (где все стратегии в наших руках) всё-таки не входила в наши планы. Это слишком трудозатратный подход, да и влияние других игроков рынка мы рассматривали как позитивное. Не только мы должны являться триггером для появления новых функций. Коллеги по рынку – другие клиенты разработчика – могли бы принести в такой продукт интересные идеи. По мере обновления версий мы получим технологическое развитие.
Мы рассматривали всех крупнейших производителей подобных решений: Oracle Exadata, Teradata, Huawei. Оценили отечественные разработки – практически все, что есть на рынке. Нам показался интересным опенсорс, тем более для банка это не первый заход в тему открытого исходного кода.
В принципе, можно было бы купить железо, скачать открытый код и собрать собственную платформу данных. Но для нас это означало серьёзные риски: нужны были компетенции, чтобы доработать всё это до уровня энтерпрайза. А на момент старта проекта у нас не было уверенности в успешном завершении подобного мероприятия. Поэтому мы сформулировали ещё один критерий – поставка решения в виде программно-аппаратного комплекса (ПАК), чтобы совместная работа железа и программных инструментов была протестирована с учётом версий. Так мы хеджировали риски, связанные с недостаточной экспертизой в опенсорсных решениях внутри ВТБ на момент старта проекта.
При выборе платформы мы учитывали следующие критерии:
отсутствие санкционных рисков
возможность гибкого масштабирования
наличие Road Map развития платформы и возможность на него влиять
стоимость владения – совокупные затраты на программно-аппаратный комплекс на горизонте 10 лет (TCO5).
Если взять последний критерий, то даже с учётом стоимости всех контуров Arenadata DB и самого проекта миграции мы получали существенную экономию на фоне Oracle SuperCluster.
В итоге по совокупности факторов мы выбрали Arenadata DB.
Тестирование платформы
Перед тем, как принимать окончательное решение, мы провели серию технологических испытаний, чтобы проверить систему на работоспособность и определить параметры сайзинга для целевого решения.
В итоге нами были проведены следующие проверки.
Сложность изменения запросов. Процедура предусматривает запуск исходного, не переработанного скрипта и контроль ошибок выполнения. В случае наличия ошибок, они исправляются и скрипт запускается повторно. От количества исправлений зависит оценка сложности.
Отказоустойчивость и отключение компонентов:
Отключение дисковых устройств на уровне БД для проверки стабильности работы кластера.
Отключение питания одного блока питания на серверах для проверки стабильности работы кластера.
Отключение сетевого подключения для имитации выхода из строя узла кластера в ходе тестирования отмечается, продолжил ли работать кластер, и фиксируется степень деградации производительности).
Совместимость со средствами резервного копирования банка:
Проведение цикла резервного копирования и восстановления БД на СРК Veritas Netbackup:
Полное резервное копирование БД
Инкрементальное резервное копирование БД
Управление и качество работы системы:
Перезагрузка кластера: фиксация успешного выполнения процедуры перезагрузки.
Мониторинг и управление: субъективная балльная оценка от 0 до 5.
Генерация тестового отчёта: прогон запроса изсистемы подготовки отчётности в Arenadata DB для анализа качества результата генерируемого отчёта – результаты выполнения отчёта должны быть идентичны.
Скорость загрузки данных
Интеграция с ПО Infomatica Power Center
Интеграция с Oracle BI
Интеграция с QlikView 12.
Результаты тестирования
В ходе тестирования кластера Arenadata DB показал высокую производительность как на синтетических тестах, так и на реальных нагрузках.
Ниже приведено сравнение скорости выполнения запросов по сравнению с текущим Oracle Super Cluster T5-8.
Тестирование проводил системный интегратор IBS Platformix.
Скорость выполнения синтетического запроса Jmeter (сек)
Кластер показал высокую скорость загрузки данных через ETL-инструмент Informatica Power Center: 200 Мбит/с.
В ходе тестирования была также осуществлена интеграция с основными BI-инструментами, используемыми в Банке ВТБ (Oracle BI и QlikView), и протестирован их функционал.
В QlikView на простейших SQL-запросах протестированы соединение с БД и выборка данных с последующей загрузкой в модель BI-инструмента.
Результаты выполнения представлены в таблице ниже.
Тест 1
Тест 2
select * from user.test1
select e.* from dds.accounts e
-and e.partition_source_system_cd =’00006′
and e.src_deleted is null
Скорость загрузки в модель, строк в сек.
При выполнении тестов была замечена особенность: получение первых строк данных из БД происходило с задержкой примерно в 23 секунды. После этого скорость выборки данных из БД и их доставки в QlikView становилась очень высокой.
Предположительно данная особенность связана c неоптимальной настройкой коннектора.
Нефункциональное тестирование показало, что кластер не имеет единой точки отказа и сохраняет свою функциональность при отказе любого из компонентов.
Цель теста
Предварительные условия
Процедура
Результат
Тестирование отказа диска с данными
Отказ диска эмулируется физическим извлечением диска или логическим отключения дискового уст-ва из работающего сервера.
Подключиться к серверу
Провести процедуру unmount для физического диска
Проверить доступность данных
Тестирование отказа кэширующего диска
Отказ диска эмулируется физическим извлечением диска или логическим отключения дискового устройства из работающего сервера
Подключиться к серверу
Провести процедуру unmount для физического диска
Проверить доступность данных
(Отказ кэширующего диска не приводит к потере данных)
Тестирование включения кластера после эмуляции аварии
Отказ сервера при выполнении SQL запроса к базе данных, эмулируется отключением электропитания работающего сервера
Подключиться к серверу
Выполнить SQL запрос
Перезапустить выполнение SQL
Данные получены при повторном SQL запросе
Благодарю Дениса Степанова и Никиту Клименко, экспертов IBS Platformix, за предоставленные результаты тестирования.
Сбор отчётности как пилот
Наша цель – это миграция на Arenadata DB всех существующих хранилищ банка ВТБ.
Но в качестве пилота мы запустили перевод систем сбора обязательной отчётности – проект, где обновление было наиболее критичным.
Arenadata – новая для нас платформа, а в перспективе она должна была стать стратегически важным элементом архитектуры. Поэтому мы выстроили партнёрство с компанией-производителем максимально плотно, вплоть до выравнивания планов по развитию. В рамках этого партнерства часть функционала, который был нам необходим для сбора обязательной отчетности, реализовали чуть раньше. Доработки позволили нам развернуть Arenadata на разных ЦОДах, обеспечив таким образом георезервирование.
Arenadata принципиально не создает под нас отдельное решение, а немного модифицирует стандартную поставку, так что другие участники рынка тоже могут пользоваться наработками, реализованными под одного из клиентов. От такого подхода выигрывают все: и коллеги, которые могут использовать наши идеи, и мы, поскольку наша платформа не “закуклится” внутри инфраструктуры, а будет обновляться в соответствии с веяниями рынка.
С глобальными сложностями в ходе проекта мы не сталкивались. Да, было много переговоров, в том числе по вечерам, когда мы придумывали схемы коммутации серверов и т.п. Но не было нерешаемых вопросов. Только сложные инженерные задачи.
Целевая архитектура платформы данных к концу 2022 года
Одновременно с обновлением системы сбора отчетности мы наращивали экспертизу внутри банка. Как я упоминал выше, на момент старта мы не были уверены, что сможем запустить такое решение из чистого опенсорса с нуля. Все это время мы плотно работали с подрядчиками, которые поставляли нам необходимую экспертизу, а также через обучение и тренинги развивали экосистему партнеров. Это наш резерв по разработке, который мы сможем подключить к развитию проекта в будущем.
Дистрибутив Arenadata Hadoop¶
Arenadata Hadoop (ADH) – это интегрированный набор компонентов корпоративного уровня на базе решений с открытым исходным кодом. Платформа включает в себя все необходимые компоненты для работы с данными: управление, доступ, анализ, интеграция, безопасность и администрирование.
Основная идея дистрибутива заключается в обеспечении возможности работы с любыми типами и форматами данных путем комбинированного использования различных технологических решений и архитектур обработки данных.
В настоящий момент все компоненты платформы оркестрируются через единую систему управления Arenadata Cluster Manager.
В 2016 году дистрибутив Arenadata Hadoop 1.3.2 прошел сертификацию и получил подтверждение о полном соответствии стандартам Open Data Platform Initiative (ODPi). ODPi – крупнейшее мировое сообщество разработчиков проектов хранения больших данных с открытым кодом под эгидой Linux Foundation: подробнее.
Текущий релиз версии 2.1.2 был выпущен в первом квартале 2020 года. В состав версии входят следующие компоненты: HDFS, YARN, Zookeeper, Tez, Hive, HBase, Phoenix, Spark, Zeppelin, Solr, Airflow, Flink.
В отличие от других корпоративных дистрибутивов, представленных на рынке, Arenadata Hadoop обладает рядом особенностей:
Arenadata Hadoop обеспечивает полный набор возможностей и инструментов для автоматического развертывания компонентов как на “голом железе”, так и на виртуальных машинах (в “облаке”). Средства мониторинга и управления конфигурацией кластера позволяют оптимизировать производительность для всех компонентов системы.
Оригинальная документация на русском языке позволяет облегчить процесс планирования и разворачивания кластера Hadoop. Инструкция может быть полезна администраторам, программистам, разработчикам и сотрудникам подразделений информационных технологий, осуществляющих внедрение и сопровождение кластеров Arenadata.
Далее в документации приведена инструкция по планированию и установке ADH, руководство администратора по работе с кластером, с HDFS, с YARN и с Hive, настройка авторизации и безопасности, а так же Release Notes.
Arenadata Streaming в Едином реестре российских программ для электронных вычислительных машин и баз данных
Arenadata Streaming — это универсальное средство для решения задач, связанных с потоковой обработкой данных в режиме реального времени. Система, построенная на базе Apache Kafka и Apache Nifi, обладает высокой отказоустойчивостью, легко масштабируется и адаптирована для корпоративного использования. Продукт способен получать и обрабатывать информацию из многочисленных внешних систем, хранить их в течение нужного для бизнеса периода времени и возвращать потребителям с удобной для них нагрузкой. ADS позволяет строить надежные потоковые конвейеры данных и разрабатывать приложения в реальном времени, а также разграничивать права доступа к потокам данных.
Реестр отечественного ПО Минкомсвязи создан в соответствии со статьей 12.1 ФЗ «Об информации, информационных технологиях и о защите информации» для популяризации российских решений и поддержки отечественных производителей. Он содержит данные о программном обеспечении, которое официально признано происходящим из Российской Федерации. Его могут использовать государственные заказчики — с начала 2016 года для них действует ограничение на закупку ПО, отсутствующего в реестре.
Arenadata Streaming можно развернуть как на bare-metal оборудовании, так и в облаке, или же воспользоваться гетерогенной ИТ-инфраструктурой или Multi-clouds. В основе решения — open-source технологии. Продукт и исходные коды можно скачать бесплатно.
Мощная распределенная аналитическая база данных для больших проектов
Arenadata DB | Управляемая СУБД
на основе Greenplum в облаке
Быстро выполняйте сложные аналитические запросы с Arenadata DB на основе Greenplum
Arenadata DB — аналитическая база данных на основе Greenplum с открытым исходным кодом. Это массивно-параллельная СУБД, обладающая линейной масштабируемостью. Применяется в критически важных системах, работающих с большими объемами данных: объем данных в базе не ограничен, и она работает на 20% быстрее других СУБД.
Arenadata DB как сервис — быстрое кластерное решение, которое позволяет в несколько кликов развернуть базу для хранения и обработки больших данных, не вкладываясь в собственную инфраструктуру и ее поддержку.
Почему Greenplum?
Полностью управляемая база данных
В нашу зону ответственности входит вся IT-инфраструктура, хостинг Arenadata DB, администрирование, обеспечение высокой доступности и соответствия требованиям, а вы управляете данными и извлекаете из них пользу.
Получите 3 месяца бесплатного использования Enterprise-версии Arenadata DB.
Преимущества Arenadata DB в облаке
Как создать и запустить базу данных Arenadata DB в облаке
Весь процесс создания и конфигурации СУБД автоматизирован. Это сокращает время запуска базы данных и ее настройки с нескольких дней до
5 минут в облаке. По умолчанию инстанс СУБД создается сразу на Linux: ОС уже предустановлена, а сама база готова к работе.
Мы записали для вас небольшое видео, в котором наглядно показали, как собрать нужную конфигурацию в панели управления и запустить Arenadata DB в нашем облаке.
Рассчитайте стоимость
Применения Greenplum в вашем бизнесе
Arenadata DB — корпоративная база данных, которая может использоваться банками, финансовыми и страховыми компаниями, телекомом, госорганами, промышленными предприятиями, ритейлом, логистикой и другими организациями в качестве основного хранилища данных и аналитической платформы.
Три версии Arenadata DB в облаке
Другие базы данных в облаке
3 000 ₽
на тестирование сервиса
По умолчанию все таблицы равномерно распределяются по серверам случайным образом. Поэтому в работе каждого запроса всегда используются все сегменты.
Дополнительно при создании таблицы можно указать ее ключ распределения по серверам (одно или несколько полей). В таком случае все соединения с указанной таблицей по этому полю (или полям) будут происходить быстрее. Подробнее о распределении данных в СУБД.
Да, поддерживается как строковое, так и колоночное хранение данных в таблицах. Для аналитической нагрузки предпочтительно колоночное хранение. Также можно создавать полиморфные таблицы, где часть данных (партиция) хранится строково, а часть — колоночно. Подробнее в документации.
ADB является ANSI SQL-совместимой системой: подробная информация доступна в документации.
Да, примерно на 95% совместим. Вы можете использовать стандартные PostgreSQL драйвера (JDBC, ODBC) для работы с ADB. Общее правило — все ПО, которое работает с PostgreSQL, работает и с ADB. Подробнее о совместимости с PostgreSQL.
Небольшие объемы можно загружать через стандартный PostgreSQL-интерфейс (например, JDBC или ODBC). Большие объемы эффективней грузить через специальный загрузчик (GPFDIST), который отправляет данные в СУБД параллельно. Подробнее о параллельной загрузке.
Объем данных в СУБД практически не ограничен.
Ограничения по объему данных в отдельных таблицах, строках и полях ниже:
Открытая аналитическая СУБД¶
Arenadata DB (ADB) – распределенная СУБД, использующая концепцию MPP (massively parallel processing, массивно-параллельные вычисления) и основанная на СУБД с открытым исходным кодом – Greenplum.
Аналитические массивно-параллельные СУБД предназначены для хранения и обработки больших объемов данных – от единиц до сотен терабайт данных. Такие СУБД чаще всего используются для предиктивной аналитики, регулярной отчетности, анализа оттока клиентов, построения корпоративных хранилищ данных.
До недавнего времени рынок аналитических массивно-параллельных СУБД делили между собой четыре игрока (Vertica, Teradata, Netezza и Greenplum), существовавшие вне сообщества Open Source, однако ситуация изменилась в 2017 году, когда проект Greenplum перешел в категорию открытых.
Открытие исходного кода позволило команде Arenadata начать проект Arenadata DB (ADB) – реляционная СУБД, имеющая массово-параллельную архитектуру без разделения ресурсов (Shared Nothing) и предназначенную для хранения, обработки и анализа больших объемов структурированных и слабоструктурированных данных. Используя вычислительную мощность сотен серверов, продвинутый оптимизатор запросов и гибкую систему резервирования данных, ADB позволяет существенно повысить производительность и надежность, сохраняя унаследованным приложениям ANSI SQL (полностью совместимый с PostgreSQL) доступ к данным.
Рис. 2. Консоль администратора ADB
Архитектура ADB – классический кластер: несколько серверов-сегментов, один сервер-мастер и один резервный, соединенные между собой быстрыми сетями (10G Ethernet или Infiniband). В каждом сервер-сегменте есть несколько сегментов (инстансов) PostgreSQL, содержащих данные. В случае отказа одного или нескольких сегментов они помечаются как сбойные и вместо них запускаются их зеркальные сегменты, репликация данных для которых происходит с помощью используемой в СУБД PostgreSQL технологии опережающей записи (Wright Ahead Log, WAL – все изменения таблиц и индексов записываются в файл только после их занесения в журнал).
Рис. 3. Архитектура ADB. Seg_N – сегмент, Mir_N – зеркальный сегмент
Использование нескольких интерконнектов позволяет повысить пропускную способность канала взаимодействия сегментов между собой и обеспечить отказоустойчивость кластера за счет перераспределения трафика. Распределение сегментов по сетевым интерфейсам выбирается индивидуально и может подстраиваться под задачи кластера – так, например, все основные сегменты можно заставить использовать один сетевой интерфейс, резервные сегменты же будет использовать второй.
В ADB реализуется классическая схема разделения (шардирования) данных – каждая таблица состоит из N таблиц, размещаемых на N сегментах кластера. Логика разбиения таблицы на сегменты задается ключом (полем) дистрибуции. Для каждой отдельной колонки в таблице можно задать свой тип и уровень сжатия. Помимо изначально доступных в Greenplum типов компрессии – zlib (одна из самых широко используемых библиотек сжатия, в частности, используется в дистрибутивах Linux) и RLE delta compression (хранение изменений между значениями полей в колонке) – в ADB доступен алгоритм zstandard, разработанный компанией Facebook и имплементированный командой Arenadata, который обеспечивает почти в четыре раза более высокую производительность по сравнению с zlib.
В ADB используется полиморфное хранение данных, например, одну таблицу можно разделить на вертикальные разделы (партиции), часть из которых будет храниться в виде строк, а часть – как колоночные объекты. При этом для пользователя такая таблица будет выглядеть одним объектом.
Рис. 4. Управление распределением данных в ADB
Безопасность в ADB достигается путем шифрования данных и соединений сервер-клиент по протоколу SSL на всех этапах их жизненного цикла. Кроме этого все внутренние взаимодействия компонентов СУБД ADB (сегменты, зеркала и мастера) также могут быть зашифрованы с помощью протокола SSL, а данные, хранящиеся на дисках кластера, могут быть зашифрованы с помощью ключей PGP (на уровне таблиц или колонок в таблицах). Все это позволяет исключить ситуации нахождения данных в незашифрованном виде.
Разграничения зон видимости данных и прав доступа обеспечивается благодаря ролевой модели доступа (Role Based Access Control, RBAC), позволяющей реализовать гибкие, изменяющиеся динамически в процессе функционирования платформы хранения и обработки данных правила разграничения доступа. Так, например, можно создать схемы ограничения доступа к таблицам и другим объектам СУБД, а также к строкам и столбцам отдельных таблиц.
Одно из важнейших качеств аналитической СУБД – гибкость и производительность при обмене данными с внешними системами. В частности, в ADB реализован протокол параллельного обмена данных со сторонними системами – PXF (Platform eXtension Framework), который обеспечивает взаимодействие с внешней системой одновременно всех сегментов кластера. Если система-источник также представляет собой кластер, то можно использовать кластерное взаимодействие с обеих сторон, что позволяет повысить производительность, причем скорость взаимодействия будет расти по мере расширения кластеров.
Гибкая система резервирования позволяет развернуть кластер с заранее заданным уровнем отказоустойчивости, позволяя СУБД работать даже при выходе из строя половины серверов из кластера. А больший выбор стратегий хранения данных в ADB обеспечивает необходимую производительность на всех этапах жизненного цикла данных – от получения новых онлайн-данных, хранения основных данных с разным уровнем компрессии до экспорта архивных данных в кластер Hadoop.
Рис. 5. Мониторинг в ADB
Ключевые преимущества ADB:
Возможности интеграции ADB с другими системами позволяют использовать эту СУБД для построения универсальных платформ хранения и обработки данных, таких, как Arenadata Enterprise Data Platfrom (Arenadata EDP) – открытое горизонтально масштабируемое решение для хранения и обработки больших объемов данных любых типов.
Рис. 6. Arenadata Enterprise Data Platfrom
Для эффективного использования СУБД необходимы средства управления и мониторинга – в ADB имеется пакет средств администратора: ПО мониторинга, управления СУБД и отправки уведомлений.
Высокая скорость обработки сложных запросов, линейное масштабирование, отсутствие специфических требований к аппаратному обеспечению, открытый исходный код, гибкость интеграции – вполне позволяют применять Arenadata DB в качестве аналитического хранилища данных корпоративных информационных систем, что по достоинству оценили как компании, близкие к ИТ-бизнесу (телеком, e-commerence, финтех), так и более традиционные отрасли (нефтегазовая и металлургическая промышленности).
Оригинальная документация на русском языке позволяет облегчить процесс планирования и разворачивания кластера. Руководства могут быть полезны администраторам, программистам, разработчикам и сотрудникам подразделений информационных технологий, осуществляющих внедрение и сопровождение кластеров Arenadata.