Комментарии 23
Расскажите, как вы его мониторите. Из ванильного GP удалили gpperfmon с подтекстом "в GPCC всё есть, купи поддержку". Или, если общались с Pivotal, значит, поддержка куплена и все эти проблемы вас стороной обходят?
Кажется про мониторинг будет отдельная статья =)
У нас GP далек от апстрима и gpperfmon у нас пока есть, но в целом активно думаем над своим решением для глубокого мониторинга. А пока - sql_exporter, node_exporter, process_exporter, сбор логов, небольшая логика вокруг и Grafana на всё это.
Часть метрик подсмотрели у коллег из Леруа Мерлен (они делали классный доклад на тему на Yandex.Scale)
Вы не правильно подаете информацию, касательно инструмента attunity.
Во-первых, хорошо было бы упомянуть что ваш опыт работы с инструментом Attunity датируется примерно так 2015-2016 годом, чтобы не вводить в заблуждение неискушенного читателя. А то ведт прочитают и отложал в голове себе что Attunity плохой.
Во-вторых, задача прямой реал-тайм репликации в GrennPlum (да и в любую другую аналитическую MPP SN систему в принципе) не решаемая, вне зависимости от инструмента. Apply в реальном времени большого количества изменений невозможен ввиду особенностей внутренней архитектуры GP. Именно поэтому вы перешли на архитектуру предварительного приземления изменений (тн landing) и затем забор этих изменений в батч\микро-батч режиме и накат их на GP.
Альтернативой этому решение может быть Kafka (в реал тайм CDC пишет в Kafka, интервалами читаем из kafka, схлопывая изменения и пишем батчем в GP). При этом роль CDC с таким подходом может выполнять хоть OGG, хоть Attuninty (который нынче Qlik Replicate), хоть Debezium
В-третьих "Поэтому все хранилища любят CDC — change data capture. Это когда мы забираем изменения в данных маленькими кусочками — батчами ". Это не CDC :)
CDC это прежде всего захват изменений. А делаете вы это через чтение redo журналов, WAL-журналов в реальном времени, или через логический инкремент батчами, как вы пишите, уже конкретный способ захвата изменений. Тем не менее, большинство специалистов в сообществе под CDC будут понимать именно real-time захват в тч с возможностью изменений DDL на источнике.
Про то, что опыт с Attunity - из 2015-2016 - да, дополню статью сегодня.
Про полную realtime репликацию, как и любые другие честные realtime изменения в Greenplum в статье, кажется, речи и не шло. Да, по-честному это не решить, не убив MPP систему, потому везде и возникают микробатчи.
Ок, про CDC не совсем корректно написал, но смысл вы поняли и мне кажется, что и остальные читатели тоже вполне поняли о чем собственно речь. Если сможете помочь с более правильной формулировкой - с удовольствием поправлю в статье.
Про realtime захват изменений данных и DDL на источниках - фактически у нас это NRT (near real time), но с учетом сбора микробатчей кажется, что буквой N тут можно пренебречь.
смотрите в чем проблема:
Вы пишите (вернее читается так) что было все плохо потому что был attunity. А на самом деле было плохо потому что задача в принципе нерешаемая на GP (real time). Для near real-time нужна другая архитектура и вы ее реализовали, правда уже с другим инструментом.
ну я так понимаю - был бы Атунити кастомизируемый - с гибкой настройкой размеров батчей - было бы все проще.
Вы не совсем правильно понимаете. У Attunity тех лет были проблемы, конечно. И он действительно Х изменений в рамках одной транзакции на источнике повторял как Х изменений на приемнике. Но даже если бы он этого не делал и схлопывал изменения которые можно свернуть в рамках одной транзакции, это бы не решило задачу real-time в GP. Проще бы было, но не так чтобы оно заработало :)
В целом идея проигрывать все изменения источника на приемнике это плохая идея. Опыт показал что самый оптимальный метод - CDC который пишет Change Tracking на промежуточной среде (для GP это лучше делать на postgres), а дальше разбирать change tracking, схлопывать изменения по ключу в той гранулярности времени, которая нужна (t-15 мин до t-1день) и писать в приемник.
кстати CDC это не только "прежде всего захват изменений" - это на самом деле предоставление данных в виде логов изменений! Чтобы можно было запросами анализировать отдельные изменения в источнике.
In databases, change data capture (CDC) is a set of software design patterns used to determine and track the data that has changed so that action can be taken using the changed data.
CDC is an approach to data integration that is based on the identification, capture and delivery of the changes made to enterprise data sources.
No comments
задача прямой реал-тайм репликации в GrennPlum (да и в любую другую аналитическую MPP SN систему в принципе) не решаемая
ну зачем же так категорично
вполне себе решаема - вертика, например, вполне позволяет в себя такое лить
история с кафкой кстати вообще не проходит
кафка лишь буфер для небольшого кусочка журнала
изменения в этом буфере может затрагивать данные за его пределами
как результат, кафка вообще бесполезна в онлайн репликации источников
А что вам мешает сделать кафку не небольшим кусочком журнала, а большим ? И не журнала а распаренных в DML изменений, которые перед накатом можно свернуть в один батч?
Пытался понять логику, но не мог.
В чем плюс? Размер батча нарастить для вставки? Ну так не спасет, если нужны обновления или удаления из табличек.
Чтобы, условно, вместо 100 операций изменения по ключу сделать 1, которая покажет состояние на момент фиксации.
Пример реализации может быть такой:
-Из кафка писать все изменения как insert only + вектор изменения (i/u/d) раз в Х минут
-После записи разбираем батч, записанный кафкой и наканываем на целевой объект
В итоге вместо реал тайм получает микри\мини батч
Окей. Остается понять зачем здесь кафка :)
Все равно все операции происходят внутри буфера приложения :)
Никто ж не заставляет комитить транзакции из вол журнала по 1, можно и по 100, и по 1000 читать.
Внимательнее читайте первичный комментарий :) Нужен landing буфер который пример на себя удар. Для GP для этого хорошо Postgres подходит тк по типам данных родственники. Альтернативой (имелось ввиду альтернативой СУБД) может быть кафка. Что не так? :)
Так не нужен буфер то, вол журнал источника уже выступает таким буфером.
Зачем городить лишнее звено в этой цепочке?
Журнал надо трансформировать в DML операции, журнал надо удерживать пока все изменения как минимум не распарсили, а как максимум не донесли до приемника, журналу надо обеспечить отказоустойчивость чтобы в случае его потери не потерять изменения.
На кафка это сделать проще.
Есть еще сценарии где промежуточное звено вам точно нужно - тиражирование изменений. Когда одна и та же таблица приемника может накатываться в разные среды да еще и с разной гранулярностью (условно в ХД t-15 мин, в Data Lake t-1час, а в какую нибудь помойку датасатанистов t-4 часа) или же определенные события писать у другой топик Kafka (например в систему принятия решений).
Так она и на GP может быть "решаемая". там же есть OLTP Tables в 6й версии. А решаемая в кавычках потому что
1 Одно дело реплицировать 10 табличек, а другое несколько десятков
2 одно дело делать делать insert новых записей, а другое дело "проигрывать изменения источника". Вы представляете как работает например АБСка в банке? Как там меняются данные? Начисления процентов, закрытие опердня, сторнирование и все такое? Это в условном телекоме - вставляй себе call record detail сверху и нет проблем, или в условном avito - вставляй себе клик во времени пользовательской сессии. Но в фин области изменения прилетают глубиной за несколько лет порой - привет update по ключу большого объема.
Об особенностях работы Vertica с операцией update можем подискутировать отдельно. Там очень много интересного :)
3 Одно дело обработать в реальном времени накат, а другое дело чтобы с этими данными еще можно было еще и работать пока идет накат изменений. Ваш кластер со временем, как ни масштабируй только и будет что работать на репликацию.
4 Vertica имеет примерно тот же подход по MVCC что и GP и принципиально ничем тут отличаться не может.
У нас реплицируется онлайн порядка полутысячи таблиц большей частью из мусклей. Конечно, большие обновления или удаления - это боль, проще переналивать в этом случае.
Тем не менее работает, дискутировать особо не про что :)
Насколько я помню, в озоне - похожая история с онлайн репликацией в вертику.
Ну я о том и пишу что вставлять строки онлайн и GP умеет, это вопрос масштабирования и железа, а накатить в онлайне закрытие опердня c апдейтами из АБСки для Vertica и GP уже rocket science который кавалеристским наскоком не решается. Перезаливать это уже не онлайн, увы.
Было бы здорово если бы свой опыт описали как раз.
Сама Vertica сейчас меняет подход записи, выпиливая WOS из архитектуры. Запись из WOS в ROS (moveout) была однопоточной и поэтому не такой быстрой чтобы переваривать большой объем изменений, запись Direct ROS была многопоточной с перезаписыванием контейнеров (mergeout) работала быстрее, но давала большую нагрузку на дисковую подсистему. Гипотетически мелкие ROS контейнеры которые будут образовываться онлайн вставкой без direct нужно периодически схлопывать через тот же mergeout. Вряд ли что то принципиально изменилось в работе процесса tuplemover'а.
Все так, переезд на 10 версию вертики все ухудшил. Надо контролировать количество партиций в таблице-приемнике и отслеживать количество рос для нее.
Ну и достаточно уродский профиль нагрузки у серверов, с преобладанием цпу на рам.
Про закрытие опердня - наверное. Мне не совсем понятно зачем такое катить через сдс, если это и так операция батчевая. Тема про сдс - очень специфичная, ресурсная и не везде применимая, никак не похожая на серебряную пулю :)
Helicopter - можно ссылку на технологию?
А то в поисковике одни фертолеты :)
Как мы используем Greenplum в платформе данных Тинькофф