Pull to refresh
30
0
Дмитрий Павлов @kapustor

User

Эта ветка комментариев каждый раз заставляет меня начать рефлексировать :) Прошло 6 лет... Сколько компаний, проектов, технлогий...

У Greenplum складывается непростая, но интересная судьба. Естественно, всё что ниже это моё субъективное мнение.

Условно-негативное:

  • Компании Pivotal уже несколько лет не существует - её поглатила Vmware. Соответвенно, теперь это VMware Greenplum

  • Для Vmware это непрофильный актив, и в первый год после поглощения было заметно как его пытаются "натянуть на глобус" - а давайте его продавать поверх виртуалок, а давайте засунем его в новый виртуальный апплаенс, и тд

  • Около двух лет назад из команды Greenplum ушла большая часть сениор разработчиков которые были там длительное время (видно по активности тут)

  • Greenplum не стал развиваться в сторону cloud решений, не появился serverless Greenplum поверх AWS, GCP etc. Это в целом понятно с учётом специфики нового владельца

Условно-позитивное:

  • Greenplum финансируется, и в некоторых сферах смена владельца пошла ему на пользу (маркетинг, например). Судя по активности видно что проект живёт

  • Ну и, конечно, потрясающая ситуация с Greenplum в РФ. После ухода зарабежных вендоров open-source решение с поддержкой от локальных вендоров обрело взрывную попкулярность. Сюда же можно добавить Greenplum as a service от крупнейших облачных провайдеров РФ

P.S. Я больше не связан с Greenplum напрямую, поэтому держать руку на пульсе уже не могу, возможно что-то упустил.

Пять лет - это маленький юбилей!)

Что ж, изменений много. Greenplum выбран лучшей СУБД для абсолютно всех задач, его используют во всех девайсах сложнее тетриса, встроенная в ГП библиотека MADLIB предсказала ковид за год до пандемии, автопилот Тесла использует ГП для движению по маршруту, и выяснилось, что на борту Вояджер-1 также работает Greenplum - именно поэтому Вояджер всё ещё в строю :)

Ну а если серьёзно, то это классное место чтобы написать для себя отчёт за год. Итак:

  1. Сообщество российских инженеров Greenplum выросло до 1080 человек и растёт дальше - мы прорвались в Full HD. По моему субъективному мнению в РФ практически не осталось специалиста по реляционным СУБД, не слышавшего или не работавшего с Greenplum

  2. За время нашей пятилетней переписки я во второй раз сменил компанию-работодателя, и я всё также остаюсь связан с Greenplum. В этом году мы запустили Managed Greenplum в облаке Yandex.Cloud - полностью управляемый сервис Greenplum, который берёт на себя задачи мониторинга, бекапирования, резервирования, масштабирования и другую грязную работу. Оставили пользователям самое вкусное - загрузку и преобразование данных.

  3. В процессе реализации п.2 полечили одну из родовых травм Greenplum - отсутствие нормальных бекапов. Теперь бекапы можно делать через WAL, без дополнительных блокировок на таблицу.

  4. В этом году планируем много классных фич - Managed PXF, Performance Diagnostics, автоматическое переключение на зеркальные сегменты и стендбай мастер.

P.S. Публично приглашаю вас впервые за пять лет встретиться и выпить пива :)

Я уже 4 года как не работаю в Тинькофф, поэтому лучше, если ответит кто-то из ребят команды DWH :)
Но насколько я знаю (и, кажется, могу это озвучивать тк озвучивал это лет пять назад на одном из митапов), в Тинькофф наследуются модель из продукта SAS Analytics for Banking, так как ещё до ГП хранилище было целиком построено на технологиях SAS. Наверно, ближе всего из вашего списка это к 3nf — что-то среднее между Кимбалом и Инманом, но, повторюсь, лучше спросить ребят из Тинькофф.
Да, имелось ввиду что для аналитических сценариев нужен специфический функционал, которого нет в Citus и PostgresXL, но он есть (в том или ином виде) в GP.
Этой ветке комментариев 4 года, как летит время… Но теперь я знаю, что вы не бот :)
  1. Greenplum сейчас, пожалуй, главный тренд аналитических СУБД в России. За год мы выполнили несколько очень крупных (>100Тб) внедрений, также GP внедряют коллеги по цеху — интеграторы. Сейчас Greenplum в России только по моим данным используют больше 50 относительно крупных компаний (с учётом специфики аналитических СУБД для больших объёмов это весомое количество пользователей)
  2. В том числе выполнили несколько миграций с других СУБД — с Терадата и Экзадата
  3. Greenplum доступен как сервис в нескольких облачных провайдерах, и скоро их будет больше
  4. Активно ведётся разработка Greenplum 7 — уже сейчас понятно, что он будет основан на PG 12, если это случится это будет большая победа для сообщества GP
  5. За прошедший год провели несколько митапов по GP, последний очный митап собрал около 170 человек. Мы уже были готовы перейти к формату конференции, но вмешалась пандемия, поэтому откатились до онлайн-формата. Скучаю по ламповым посиделкам с пиццей и спорами за MERGE JOIN
  6. За год обучение эксплуатации Greenplum прошли более 300 человек. Это DBA, архитекторы, разработчики

Понятно, спасибо. Хорошо, если хватает пропускной способности мастера, но в случае масштабирования нагрузки и самого кластера крайне рекомендую вложиться в загрузчик на gpfdist :)

Использовался ли при загрузке в Greenplum параллельный загрузчик gpfdist, или заливали через JDBC/ODBC? В последнем случае все данные льются через мастер, это плохой способ загрузки в Greenplum.
Создатель канала не захотел наплыва пользователей в канал и изменил ссылку(
Не буду из-за этого давать прямую ссылку, но вот его оригинальная статья на драйве, там внизу есть правильная ссылка на канал: www.drive2.ru/l/485801071864709696
Вот тут интересный опыт управления Bluetooth плеером штатными кнопками на руле Opel Astra.
А вот тут ТГ-сообщество CAN-хакеров семейства авто Opel (Astra, Corsa, Zafira и тд). Там есть и более интересные проекты — с выводом своей инфы на дисплей, изменением логики поведения авто, автозапуском и так далее.

От Nestea. Горлышко шире :)

О, с RLE ситуация интересная. Действительно, RLE даёт фантастическую степень сжатия (в моей практике доходило до 60-70 раз). Иногда. Если быть точным, при соблюдении нескольких условий:
1. Дельта между данными (строками) небольшая и одинаковая
2. Таблица отсортирована (в случае с ГП это INSERT… SELECT… ORDER BY… )
На практике RLE выстреливает ОЧЕНЬ редко. Всегда надо пробовать и смотреть, что оно даст. Обычно получается использовать RLE для подневных витрин или таблиц фактов.

Про метаданные — всё так. Другой вопрос, что если у вас настолько много метаданных, что они реплецируются по интерконнекту часами, то, возможно, стоит пересмотреть модель? В нашей практике есть только один заказчик с действительно раздутыми каталогами.

gp_upgrade — да, пока не доделан. Кстати, наша команда (Arenadata) принимала активное участие в его разработке этим летом, надеемся к нему вернуться. Минусы бекапа и рестора понятны, но есть разные методики, ускоряющие миграцию, мы в том числе и этим помогаем нашим заказчикам.
В целом, правильно, но есть нюанс: один запрос утилизирует максимум одно ядро на один сегмент. То есть, если, например, в вашем примере 6 сегментов и 16 ядер на сегмент-сервер, то один запрос утилизирует максимум 6 ядер, два запроса — 12 ядер, и так далее. Так как обычно в аналитической СУБД работает 20-100 запросов, то проблем с утилизацией не возникает почти никогда (если, конечно, совсем не жестить и не делать по одному сегменту на сервер).
Так вот же в официальной документации PostgreSQL 9.4:

GRANT { { SELECT | INSERT | UPDATE | REFERENCES } ( column_name [, ...] )
[, ...] | ALL [ PRIVILEGES ] ( column_name [, ...] ) }
ON [ TABLE ] table_name [, ...]


И там же пример:

GRANT SELECT (col1), UPDATE (col1) ON mytable TO miriam_rw;
Каааак?? Как вы это делаете? :)
Вышел Greenplum 6 — только что опубликовал статью про новые фичи.
А так всё прекрасно, Greenplum в России становится всё больше и это очень приятно.

На всякий случай, в Greenplum есть транзакции (ACID + ANSI SQL). С нагрузкой тоже все ок, эксплуатируем очень жёсткие кластера по 20+ нод :)
Но Вертика тоже отличная система и у вас грандиозные планы, так держать!

Не поделитесь инфой про ORC? Очень интересно.
Да, LLAP есть, но, со слов нашей поддержки, вам очень повезло что он работает хорошо. У нас были кейсы с ним, используем очень осторожно.
Всем привет.
Я отвечаю за продуктовое наполнение платформы в Arenadata. Попробую ответить на вопросы в статье и в комментариях. В нашей платформе я технически больше погружен в Greenplum и Clickhouse, чем в Hadoop, но постараюсь использовать экспертизу коллег. Боюсь, правда, получится очень много букв :)

Для начала, кто мы такие. Команда Arenadata (AD) формировалась в 2014-2017 году. Все мы (на тот момент около 5 человек, сейчас уже больше 40) до AD многие годы занимались корпоративными хранилищами данных (КХД) — кто-то разрабатывал Hadoop и Greenplum (CEO и CTO пришли из Pivotal), кто-то внедрял в интеграторах (Glowbyte), кто-то поддерживал на местах (я занимался эксплуатацией Greenplum и Hadoop в Tinkoff). В какой-то момент мы поняли, что объединившись мы сможем улучшить те open-source проекты, с которыми до этого работали, объединив их в единую платформу и наделив её enterprise-фичами — глубоким саппортом, единым мониторингом и управлением, обучающими программами для спецов заказчика и возможностью менять код под заказчиков.

При этом мы не просто собираем open-source на коленке и продаём:
1) Большинство наших разработок мы отдаём в open-source (комитим в проекты, больше всего в Greenplum, в Hadoop поменьше)
2) Мы разрабатываем собственную систему управления кластерами (вот тут и тут можно посмотреть как это выглядит), и она доступна абсолютно бесплатно на нашем сайте. Код также скоро будет открыт. Мы берём деньги лишь за техподдержку.

Да вы же просто слизали всё у Хортона! DrunkBear
И да, и нет. Мы никогда не ставили себе целью сильно отличаться от Hortonworks (точнее, от Bigtop) — это банально вопрос совместимости, заказчики не хотят vendor lock-in. Более того, специально для того, чтобы не отличаться от Хортон и Клаудеры, в 2015-м году мы прошли сертификацию нашего дистрибутива в ODPi — часть Linux Foundation (и каждый год проходим её снова) — это гарантия того, что мы не делаем наколеночного, закрытого и несовместимого ни с чем решения.
Также, мы никогда не будем сильно отличаться от Bigtop ещё и потому, что более-менее серьёзные изменения в коде мы комитим в сам Bigtop и другие репы. Кстати, один из наших PR принял лично Alan Gates.
С другой стороны, мы видим слабые стороны у дистрибутивов Хортона и Кладудеры (хотя теперь уже не разберёшь кто есть кто), которые мы смогли сделать своими преимуществами:
1) Сильное отставание версий компонентов от upstream
2) Невозможность обновлять компоненты по отдельности (по краней мере без танцев с бубном, но мы же говорим об Enterprise, верно?)
Поэтому версии компонентов у нас всегда немного впереди (про 3.0 чуть дальше), а благодаря нашему Cluster Manager заказчики могут обновлять компоненты по отдельности.

Когда наконец будет 3.х? DrunkBear
Ох, тоже самое спрашивают наши заказчики) С 3.х есть два нюанса:
1) Недавно было объявлено, что Ambari — deprecated и скоро умрет, поэтому мы решили полностью отказаться от Ambari в нашем 3.х и перевести всё управление в Arenadata Cluster Manager, чем сейчас и занимаемся. Это займёт ещё несколько месяцев, дальше будет проще.
2) По мнению наших спецов, 3.х ещё всё-таки не настолько стабилен, чтобы брать его на саппорт.

Что с саппортом? Можете ли вы соответствовать уровню хортона? DrunkBear
Да, можем, а за счёт 3-го пункта мы даже немного лучше:
1) У нас саппорт 24х7, за счёт того что наши специалисты находятся в разных часовых поясах в России
2) За этот год мы очень сильно нарастили ресурсы на саппорт — сейчас это самый многочисленный отдел в AD (9 человек + подключаем разработчиков на сложные кейсы)
3) В отличии от Хортона и Клаудеры, мы готовы адаптировать дистрибутив под адекватные хотелки заказчиков — в том числе вносить (комитить) изменения в основные OS-репы. Мы здесь, в России, с нами можно и нужно встречаться, договариваться и развивать продукты вместе.

Ваше импортозамещение — это переклеенная этикетка DrunkBear
Вот тут будет сложно, но я попробую.
1) В первую очередь, в нашу платформу входят дистрибутивы продуктов (Hadoop, Greenplum, Clickhouse), а не их аналоги или свои разработки с нуля. Мы нигде и никогда не скрывали, что используем OS-проекты. Разрабатывать с нуля свой аналог дистрибутива Hadoop в 2019-м году — безумие.
2) Работать с open-source можно и нужно только одним способом — делиться ресурсами, отдавая свои наработки в open-source. Это не просто (куча бюрократии, согласований, общения с сообществом и тд), но мы это знаем и умеем. Это значит, что у нас (надеюсь) никогда и не будет своего отдельного форка Hadoop или Greenplum. При этом, мы делаем много дополнительного функционала (коннеткоры, управлялки и тд).
3) Рискую отхватить за политику, но я попробую.
Откуда растут ноги у импортозамещения? Всё просто: большие государственные (иногда и частные) предприятия опасаются, что в какой-то момент они не смогут использовать зарубежное ПО из-за:
— санкций с нашей стороны
— санкций с той стороны
— валютных изменений
— ухода экспертизы по этому ПО с нашего рынка
Мы закрываем эти риски. Более того, в случае глобального экстерминатуса (т-т-т), мы сможем поддерживать и развивать эти OS-проекты независимо (повторюсь, это не является целью).
4) Импортозамещение — не основной драйвер нашего бизнеса, так как большинство наших заказчиков — частные компании, которые в первую очередь ценят экспертизу (Х5 Retail Group, IQ Option, Touch Bank и другие). Потребность в импортозамещении у госов — приятный бонус, не более.

А Pivotal и Hortonworks вообще знают, чем вы тут занимаетесь?
Не просто знают, а ещё и помогают нам. Вот тут к нам на митап приехал Pivotal Director of Data Engineering, а вот тут я выступал на Greenplum Day в Нью-Йорке вместе с CIO Morgan Stanley — крупнейшим пользователем Greenplum в мире. Так работает open-source — рынок захватывает технлология, а уже потом его делят вендоры.

Где Ranger и Zeppelin? sshikov
Ranger есть в платформе, на сайте, увы, сильно устаревшая информация. Мы использовали его в двух проектах, всё ок. Sentry действительно похоже умирает.
А вот от Hue мы отказались в пользу Zeppelin (он у нас выделен в отдельный продукт, как и Kafka) — кстати, рекомендую, новый Zeppelin 0.8 стал очень крутым.

Код полностью скопирован с hdp и hdf с минимальными допилами loltrol
Выше я ответил, почему это так и почему это правильно.

Взяли за основу древнюю версию. loltrol
Вот тут не очень понял — можете указать на версии компонентов, которые по вашему мнению устарели? Уточню у наших ребят.

Сайт у вас отстой.
Мы знаем :( Этот сайт создавался когда нас было 5 человек, мы вообще плохо умеем в дизайн и сайты. Этим летом хотим переделать, если у вас есть контакты студии, которая сможет сделать сайт не хуже pivotal.io — поделитесь в ЛС плз.

Почему у вас нет блога на хабре? Почему так мало информации?
Блога нет, потому что дорого :)
Информации о нас в открытом доступе мало, потому что рынок очень узкий, и мы своих потенциальных заказчиков знаем и так.
Ну и плюс мы активно участвуем в конференциях, организуем митапы и т.д.

А ещё...
А ещё мы:
1) Раз в квартал проводим митапы по распределённым системам — присоединяйтесь, следующий будет в сентябре, сможете спросить и высказать нам всё лично :)
2) Ведём чат в ТГ по Greenplum, там есть почти все наши заказчики — можете спросить их о качестве нашего сервиса
3) Сейчас совместно с Яндекс запускаем продукт на базе Clickhouse — детали сможем опубликовать чуть позже, но получается круто!

Мне кажется, получилось очень много информации для комментария. Есть ли смысл оформить отдельную статью, где рассказать о нас подробней?
А вы точно не бот?)
На самом деле очень много что появилось и изменилось, но если по верхам:
  • Готовится к выходу Greenplum 6 — Postgres версии 9.4, Replicated-таблицы, новый алгоритм хеширования, новый сетевой протокол и ещё куча новых фич
  • В нашем дистрибутиве Greenplum — Arenadata DB — добавлена (и уже работает у наших заказчиков) компрессия ZSTD — arenadata.tech/products/db
  • Наша же команда реализовала графический инсталятор для open-source data-сервисов — Arenadata Cluster Manager, и первым продуктом в нём конечно же стал Greenplum — docs.arenadata.io/adb/install/adcm/ru/index.html
  • Присоединяйтесь в чат Greenplum Russia, почти все экплуатанты Greenplum в России сидят там, стараемся помогать друг другу — t.me/greenplum_russia
Люблю такие развёрнутые и подробные комментарии, спасибо.

Такой подход (портирование фич вместо постоянного rebase'а) имеет свои плюсы и минусы.

Надо понимать, что Greenplum имеет очень много концептуальных и архитектурных отличий от PostgreSQL (свой планировщик, column-storage, шардирование, партиционирование, своя WAL-репликация, компрессия и т.д). В таких условиях rebase на более новую версию PostgreSQL — очень сложная, дорогая и долгая процедура. Например, rebase на версию 8.4 (сейчас 8.3) продолжается уже c полгода.

Как показывает практика других похожих по функционалу проектов (Citus Data, PostgresXL), построить полноценную аналитическую колоночную СУБД для DWH просто добавляя простенькую реализацию шардирования к PostgreSQL не получается. Хорошее распределённое OLTP-хранилище — да, OLAP RDBMS — нет.

Выдержка из поста представителя Citus Data на одном из форумов:
Сitus is not a traditional data warehouse. We position Citus as the real-time, scalable database that serves your application under a mix of high- concurrency short requests and ad-hoc SQL analytics (i.e. think both random and sequential scans for a customer-facing analytics app). The default storage engine for Citus is the PostgreSQL storage engine, which is row-based. This is in contrast to many data warehouses, which often use a column store and/or batch data loads, and are focused purely on analytics. The trade-offs you get are: — Citus vs. DWH performance: DWH and Citus both have a similar parallelization for analytics queries (multi-core, multi-machine), but most data warehouses typically use a columnar storage engine instead of a row-based one. Columnar storage is designed for faster analytics queries, so that makes columnar DWH generally faster on longer running analytics queries. However, this comes at the expense of (1) concurrency and (2) short-request performance (think simple lookups, updates, real-time data ingest) vs. Citus' row-based storage.


Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity