Всем привет.
Я отвечаю за продуктовое наполнение платформы в 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.
Зависит от числа ядер, памяти и среднего количества одновременных запросов. Очень грубо — если вы знаете, что у вас в системе будет 1-2 параллельных запроса, берите число сегментов=число ядер/потоков на сервер. Если одновременных запросов, наоборот, ожидается много, можно снизить число сегментов на сервер.
У вас 6 сегментов на весь кластер или 6 сегментов на машину? Я не знаю, что у вас за машины, но 2 сегмента на сервер выглядит очень маленьким значением.
Виден системный подход к комментированию :)
Да, и добавить есть много чего, информации слишком много для одного комментария:
Greenplum теперь полноценный Open-source дистрибутив, 09.2017 был первый OS-релиз 5.0.0 (сейчас уже 5.1.0 + через пару дней будет 5.2.0 + появились первые наброски 6.0.0);
в 5.0.0 появилось очень много нового: новый способ взаимодействия с Hadoop (Hive, HDFS), новый SPARK-коннектор, много новых фич (dblink, Anonymous blocks и т.д.);
По части эксплуатации системы в Тинькофф могу сказать, что до июля 2017-го года GP показывал себя хорошо и каких либо эксцессов не было, после чего я начал работу в другой компании — Arenadata. Мы разрабатываем, внедряем и поддерживаем свой корпоративный дистрибутив Greenplum с учётом уже имеющихся best practices.
Ignite (aka GridGain) сейчас тестируем для немного другой задачи. Сейчас, к сожалению, не могу рассказать подробности, надеюсь, со временем напишем отдельную статью.
С Ignite пока есть неопределённость как минимум с выбором persistent-движка.
Возможно, там было ограничение не на объём памяти в кластере, а на объём на одной машине (3 ТБ в нашем случае).
Идея с STD[IN, OUT] хорошая, спасибо. JDBC хотели использовать, потому что Greenplum по сути представляет собой множество инстансов постгреса на серверах-сегментах, соответственно, можно читать в параллель со всех серверов ГП. Если отказаться от идеи не использовать мастер-сервер ГП, то можно читать в несколько потоков с мастера, разделяя данные по служебному полю с номером сегмента (есть в каждой таблице в ГП). Вобщем, будем думать, проблема не выглядит тупиковой, надо пробовать :)
wildraid правильно заметил, пока тяжело добиться чтения с диска) Мы проводили сравнительное тестирование на меньших объёмах памяти, но там и данных тоже было меньше, результаты есть в статье.
1) Вендору пришлось пересобирать БД под наш объём памяти в кластере (6 Тб), были какие-то ограничения в коде из-за которых БД падала;
2) Были проблемы с таймзоной, вендор тоже правил в коде БД что-то и пересобирал под нас;
3) Пока не научились грузить данные параллельно из Greenplum в Exasol без промежуточного приземления на диск — при запуске параллельной вычитки из сегментов GP через множество jdbc-соединений лоадер Экзасола падает и валит за собой всю базу.
Вобщем, проблемы есть, но поддержка адекватная, реагирует быстро, работаем :)
P.S.: Буду очень благодарен, если ребята из Тинькофф Банк (@Kapustor) поделятся информацией о своём итоговом выборе
Привет!
Спасибо за статью, интересно!
Про наш выбор: сейчас начинаем второй этап PoC, ставим Exasol на боевые машины с 3 Тб памяти и даём бизнесу новую игрушку. По результатам могу отписаться здесь, например.
Скорее нет, чем да. Серьёзных происшествий не было (т-т-т), найдено пара багов, отправлены в саппорт и уже даже исправлены в новой (4.3.10) версии. Установили во все сервера продуктовых кластеров PCI-SSD диски, вынесли туда некоторые особо критичные к скорости таблицы и ворк-схемы SAS-джобов. Готовимся к очередному экспанду (упираемся и в место на кластере, и в производительность).
Интересно. Можете привести данные, которые это доказывают? Действительно, нигде в документации прямо не указывается о наследовании, но это и не опровергается (не нашёл, по крайней мере).
1) Версии указаны в статье в таблице. Memsql — 5.1.0. Версию 5.5 не тестировали, она вышла уже после завершения тестирования, когда машины у нас забрали.
2) Характеристики машин указаны в начале статьи (две машины на каждую БД).
3) Везде, где возможно, использовали Columnstore.
4) Использовали MONTH() и YEAR().
Тогда неудивительны, как минимум, хорошие показатели SAP HANA в вашем тесте — у нас к ней претензии именно в неспособности грамотно утилизировать все ресурсы кластера.
Распределённость добавляет тестированию остроты :)
Инженеры HANA проводили тестирование на нашем железе, да и некие официальные договорённости у нас с ними есть (сотрудничаем с этой компанией и по другому софту SAP).
Про деперсонализацию — обещаю в ближайшее время проработать вопрос (нужно согласие руководства + оценить объём работ по деперсонализации, там не только номера счетов), напишу в личку заинтересовавшимся :)
Про преимущества той или иной ФС для GP не могу сказать, подробно не изучал вопрос (полагался на вендора:) ). Однако, в моём комментарии выше я был немного неправ, ZFS поддерживается для GP on Solaris.
Вот тут немного информации о ZFS <> XFS для GP:
https://discuss.pivotal.io/hc/en-us/community/posts/200796448-Solaris-ZFS-v-Linux-XFS
Я отвечаю за продуктовое наполнение платформы в 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 — детали сможем опубликовать чуть позже, но получается круто!
Мне кажется, получилось очень много информации для комментария. Есть ли смысл оформить отдельную статью, где рассказать о нас подробней?
На самом деле очень много что появилось и изменилось, но если по верхам:
Такой подход (портирование фич вместо постоянного rebase'а) имеет свои плюсы и минусы.
Надо понимать, что Greenplum имеет очень много концептуальных и архитектурных отличий от PostgreSQL (свой планировщик, column-storage, шардирование, партиционирование, своя WAL-репликация, компрессия и т.д). В таких условиях rebase на более новую версию PostgreSQL — очень сложная, дорогая и долгая процедура. Например, rebase на версию 8.4 (сейчас 8.3) продолжается уже c полгода.
Как показывает практика других похожих по функционалу проектов (Citus Data, PostgresXL), построить полноценную аналитическую колоночную СУБД для DWH просто добавляя простенькую реализацию шардирования к PostgreSQL не получается. Хорошее распределённое OLTP-хранилище — да, OLAP RDBMS — нет.
Выдержка из поста представителя Citus Data на одном из форумов:
У вас 6 сегментов на весь кластер или 6 сегментов на машину? Я не знаю, что у вас за машины, но 2 сегмента на сервер выглядит очень маленьким значением.
Да, и добавить есть много чего, информации слишком много для одного комментария:
С Ignite пока есть неопределённость как минимум с выбором persistent-движка.
Идея с STD[IN, OUT] хорошая, спасибо. JDBC хотели использовать, потому что Greenplum по сути представляет собой множество инстансов постгреса на серверах-сегментах, соответственно, можно читать в параллель со всех серверов ГП. Если отказаться от идеи не использовать мастер-сервер ГП, то можно читать в несколько потоков с мастера, разделяя данные по служебному полю с номером сегмента (есть в каждой таблице в ГП). Вобщем, будем думать, проблема не выглядит тупиковой, надо пробовать :)
1) Вендору пришлось пересобирать БД под наш объём памяти в кластере (6 Тб), были какие-то ограничения в коде из-за которых БД падала;
2) Были проблемы с таймзоной, вендор тоже правил в коде БД что-то и пересобирал под нас;
3) Пока не научились грузить данные параллельно из Greenplum в Exasol без промежуточного приземления на диск — при запуске параллельной вычитки из сегментов GP через множество jdbc-соединений лоадер Экзасола падает и валит за собой всю базу.
Вобщем, проблемы есть, но поддержка адекватная, реагирует быстро, работаем :)
Привет!
Спасибо за статью, интересно!
Про наш выбор: сейчас начинаем второй этап PoC, ставим Exasol на боевые машины с 3 Тб памяти и даём бизнесу новую игрушку. По результатам могу отписаться здесь, например.
2) Характеристики машин указаны в начале статьи (две машины на каждую БД).
3) Везде, где возможно, использовали Columnstore.
4) Использовали MONTH() и YEAR().
Распределённость добавляет тестированию остроты :)
Про деперсонализацию — обещаю в ближайшее время проработать вопрос (нужно согласие руководства + оценить объём работ по деперсонализации, там не только номера счетов), напишу в личку заинтересовавшимся :)
Про преимущества той или иной ФС для GP не могу сказать, подробно не изучал вопрос (полагался на вендора:) ). Однако, в моём комментарии выше я был немного неправ, ZFS поддерживается для GP on Solaris.
Вот тут немного информации о ZFS <> XFS для GP:
https://discuss.pivotal.io/hc/en-us/community/posts/200796448-Solaris-ZFS-v-Linux-XFS