Привет, Хабр! Я Максим Еремин, руководитель направления развития PaaS и Big Data в beeline cloud. Расскажу, как эффективно использовать корпоративные данные: какие сложности с хранением и обработкой данных мы наблюдаем на примере наших клиентов и какие технологические решения предлагаем им для построения платформы данных.
Последние пару лет не перестает сходить с первого плана вопрос импортозамещения софта ушедших вендоров. Мы занимаемся данными, поэтому и делимся опытом импортозамещения платформ данных у наших enterprise заказчиков.
Если попробовать классифицировать причины импортозамещения, то это могут быть снижение вендорских рисков, требования Минцифры, сложность и стоимость закупки сертифицированного «железа» под импортные платформы и так далее.
Кстати, далеко не на последнем месте запрос команд разработки и поддержки на реализацию проектов на российском и open source технологическом стеке. Российский рынок вакансий на западном проприетарном вендорском ПО постепенно сужается, так как сейчас спрос российских компаний на такой софт стремится к нулю и такие системы постепенно превращаются в Legacy.
Так или иначе, российский крупный бизнес постепенно приходит к задаче импортозамещения и вместе с этим к целому спектру сложных задач, начиная от выбора подходящих целевых систем и технологий и их «допиливания», разработки,внедрения, до удовлетворения ожиданий не всегда простых бизнес-пользователей.
Разделим проблему на две части – подходящий апробированный технологический стек с формированием команды и сатисфакция бизнес-пользователей.
Привет! Меня зовут Антон Васильев, я работаю инженером технической поддержки компании Arenadata и нередко сталкиваюсь с довольно каверзными задачами и багами. Одной из них была проблема оптимизации механизма UPSERT в Greenplum 6. В этой статье я хочу рассказать, как эта задача может быть решена.
Добрый день. Меня зовут Иван Клименко, и я архитектор департамента поддержки продаж компании Arenadata. В основном занимаюсь продуктом Arenadata Streaming (ADS) — это масштабируемая отказоустойчивая система для потоковой обработки данных в режиме реального времени, адаптированная для корпоративного использования и построенная на базе Apache Kafka и Apache NiFi. В продукт входит замечательный сервис Arenadata Streaming NiFi, который является low‑code средством построения интеграционных потоков с возможностью масштабирования.
Сегодня хочу показать на одном из практических случаев, что не всегда в NiFi удаётся следовать шаблонному подходу record‑oriented в разработке потоков обработки и трансформации данных.
Будет большой JSON, будет Avro‑схема, будет JOLT‑спецификация.
Перед вами заключительная, третья часть обзора изменений в Greenplum 7. Если вы по каким-то причинам пропустили прошлые публикации, то их можно найти в нашем блоге здесь и здесь. А сегодня мы поговорим об изменениях в партиционировании таблиц и ресурсных группах, JIT-компиляции выражений и многом другом. Давайте начнём!
В прошлой части обзора изменений и нововведений Greenplum 7 мы рассмотрели миграцию движка Append Optimized таблиц на использование интерфейса табличных методов доступа, оптимизацию добавления столбцов в таблицы, а также изменения, связанные с поддержкой индексов.
Сегодня мы поговорим об ещё одном новом для Greenplum типе индексов и не только.
- Что вы ожидаете от Greenplum 7?
- Postgres 12!
Если бы мы проводили опрос наших заказчиков, ответ на данный вопрос прозвучал бы именно так.
Как известно, Greenplum является одним из многочисленных форков Postgres, кодовая база которого наконец-то догнала ещё пока поддерживаемую версию Postgres (отмечу, что последний релиз Postgres 12 состоится в ноябре текущего года).
Однако наличие какого-либо функционала в Postgres не гарантирует его работу в рамках распределённой системы. В этой статье я начну рассказывать о функциях, которые стали доступны в новой версии, и о том, какой путь пришлось пройти, чтобы обеспечить их работоспособность, а также о возможных ограничениях и причинах их возникновения.
По опыту нашей продуктовой команды разработки и поддержки, пользователи, оперирующие большими объемами данных компании часто используют несколько разрозненных кластеров Greenplum.
Мотивация такого решения может быть разной: организационная - разные команды-владельцы бизнес-данных выстраивают свои модели данных, обрабатывают их нужным для них образом; техническая - распределенные по различным датацентрам кластеры и т.п. Однако, рано или поздно возникает задача использовать данные из "соседних" хранилищ. Это могут быть как разовые сценарии единичных запросов, так и организация более сложных ETL-процессов. Реализация подобных механизмов опять-таки может быть разной со своими достоинствами и недостатками, исходя из возможностей и ограничений.
В этой статье рассматривается детали предлагаемой нами реализации коннектора для выполнения, так называемых, гетерогенных запросов в рамках разных кластеров ArenadataDB и/или Greenplum - задача, которой наша команда разработки занималась в 2023 году. Этот коннектор позволяет объединять в запросах разные кластеры ADB, но при этом пользоваться возможностями установления соединений между сегментами.
Но обо всем по порядку.
В этой статье я опишу наш путь реализации глобальных индексов в шардированной базе данных. Расскажу обо всех проблемах, с которыми столкнулись, и решениях, которые приняли, чтобы их обойти. Мы поговорим про реализацию на основе базы данных Tarantool, но общий подход применим и к другим шардированным базам данных без встроенной поддержки таких индексов, да и встроенная реализация часто строится по похожим принципам. Эта статья поможет разобраться в деталях, компромиссах и ограничениях работы глобальных индексов.
Всем привет, меня зовут Алексей Марьин, я IT-лидер стрима «Озеро данных» в ВТБ. До 2019 года мы активно и вполне успешно использовали для анализа и обработки больших данных продукт Oracle Big Data Appliance с Cloudera Hadoop Distribution внутри. И всё было хорошо, пока Oracle не решил прекратить развивать это направление бизнеса. Тогда пришлось задуматься об альтернативе, и мы обратились к Arenadata Hadoop. По пути мы столкнулись с некоторыми, так скажем, особенностями: пришлось кое-что допиливать напильником.
Сейчас многие сталкиваются с похожими проблемами импортозамещения продуктов. Так что мы с коллегой, директором проектов службы развития больших данных Дмитрием Власовым, решили написать эту статью, чтобы подсказать решения и предупредить о трудностях.
Наличие хорошо структурированной, подробной и вовремя актуализируемой технической документации — важный индикатор зрелости любой софтверной компании.
Но что, если документация в компании долгие годы велась разработчиками по остаточному принципу и понемногу стала превращаться в хаос? С чего начать разработку своего портала документации и с какими препятствиями можно на этом пути столкнуться?
В этой статье мы поделимся своим опытом создания документации «с нуля» на примере Arenadata.
Привет! Меня зовут Савр, я работаю инженером технической поддержки Arenadata. В прошлом году нам, как и многим другим компаниям, использовавшим зарубежное ПО, пришлось переходить на российские аналоги. В частности, с болью в сердце мы отказались от Jira Service Management (далее SM) — нашей системы управления обращениями заказчиков и основного инструмента службы поддержки. Мы были вынуждены перейти на российскую разработку SimpleOne.
Поскольку наша команда привыкла к предыдущей функциональности, после миграции мы сделали ряд доработок нового сервиса. В этой статье я расскажу о некоторых из них: почему мы решили это исправить и как именно реализовали. Сразу оговорюсь, что мы не претендуем на статус великих специалистов или консультантов по SimpleOne, а лишь хотим поделиться своим опытом и идеями с теми, кто тоже рассматривает этот инструмент как альтернативу существующему решению.
Всем привет, меня зовут Андрей, я – системный архитектор Arenadata и в этой статье мы рассмотрим интеграцию решения логического резервного копирования и восстановления gpbackup/gprestore с программно-аппаратным комплексом Dell EMC Data Domain — задача, которой наша команда разработки занималась в 2022 году.
Итогом этой разработки стал плагин-коннектор для нативного использования этой системы хранения данных в задачах резервного копирования и восстановления данных. С декабря 2022 года мы поставляем его в Enterprise Edition нашего продукта Arenadata DB.
Так же, как и многие другие компании, мы долго и счастливо использовали целый стек популярных облачных сервисов (Github, Slack, Jira, Confluence и т.д.) и связывал это все Google Workspace, который выступал в том числе и как SSO для всех используемых сервисов.
В связи с последними событиями нам пришлось достаточно быстро искать и реализовывать альтернативу из отечественных сервисов и open source продуктов. При этом одним из требований стало использование общей с «офисными»
и почтовыми сервисами точки аутентификации.
В этой статье я расскажу о том, как мы решали задачу создания SSO поверх выбранного поставщика почтового и «офисных» сервисов для используемых нами приложений с помощью Keycloak и с какими проблемами мы при этом столкнулись.
Привет, Хабр! Меня зовут Роман, я работаю разработчиком в компании Arenadata, где мы решаем много задач, связанных с Greenplum. Как-то мне представился случай разобраться с одним непростым, но вполне типичным для этой СУБД кейсом. Необходимо было выяснить, на обработку каких запросов уходит неадекватно много системных ресурсов. В этой статье мне бы хотелось поделиться своими наработками и рассказать о трёх проверенных мной способах мониторинга утилизации системных ресурсов, потребляемых запросами в Greenplum.
В Arenadata мы используем Jenkins для CI. Почему? Как бы банально это ни звучало — так исторически сложилось. Мы хранили код в GitHub, когда там ещё не было Actions, и продолжаем хранить, потому что много работаем с Open Source. За три года работы с Jenkins мы неплохо разобрались в нём, в том числе научились быстро масштабироваться, чтобы удовлетворять запросы разработки. В этой статье хочу поделиться тем, что мы успели понять про разные способы балансировки нагрузки в Jenkins. Если вам это близко, добро пожаловать под кат.
Привет, меня зовут Денис, в Arenadata я занимаюсь Greenplum — распределённой СУБД с открытым исходным кодом, разработанной на основе PostgreSQL и заточенной под аналитический профиль нагрузки. Моя работа (помимо разработки) заключается в разборе инцидентов, когда в кластерах клиентов происходит что-то непонятное для нашей технической поддержки. Такие истории обычно заканчиваются детальным внутренним разбором произошедшего, рекомендациями для клиентов и внесением правок в код Greenplum (как в наш fork, так и в upstream). Я расскажу вам про один из инцидентов, которым я занимался в последнее время. Хотя этот случай не привел к технически сложным доработкам, он является показательным примером того, как мы исследуем проблемы с Greenplum. Заодно я расскажу о подробностях внутреннего устройства Greenplum и PostgreSQL, которые не описаны в документации.
Привет, Хабр. Меня зовут Дмитрий Гусаков. Я тимлид команды QA в компании Arenadata. Наша команда занимается тестированием компонентов Arenadata Enterprise Data Platform, в том числе тестированием оркестратора гибридного data-ландшафта Arenadata Cluster Manager. Каждый день мы пишем и актуализируем большое количество тестов для API. Поэтому сегодня я хочу обсудить тему автоматической генерации таких тестов и поделиться с сообществом нашими решениями и опытом.
Всем привет! Меня зовут Андрей, я работаю системным архитектором в Arenadata. В этой статье расскажу, как и зачем мы сделали свой инструмент для обмена данными между Arenadata DB (аналитическая MPP-СУБД на базе Greenplum) и фреймворком для распределенной обработки данных Apache Spark (входит в экосистему Arenadata Hadoop).
Часто при работе с разными базами данных необходимо отслеживать выполнение текущих запросов. В основном это связано с задачами администрирования или аналитики. Средства мониторинга, позволяющие управлять и наблюдать за выполнением запросов, сильно помогают в этом. Я расскажу о том, с какими задачами мы столкнулись при проектировании и реализации системы мониторинга запросов для Arenadata DB.