Конечно можно и без коннектора сделать, но коннектор удобно инкапсулирует всё это. Мы считаем это полезным, чтобы не отвлекаться при решении конкретных практических задач. Также мы надеемся, что нам удастся перенести так сказать "ядро" этого технического решения на некоторые другие системы при их сопряжении (не Спарк и не Гринплам).
На наш взгляд мы не сделали никаких выпадов в сторону реализации параллелизма в Spark, мы лишь отмечаем, что не для любой внешней массивно-параллельной системы (такой как Greenplum) имеются готовые коннекторы, которые работают оптимально с нашей точки зрения. И это вполне естественно.
Термины master и slave относятся здесь вообще не к Cпарку, а к классам, которые мы разработали на основе механизма удалённого вызова процедур. Есть класс который выполняет роль master и есть slave. Slave подключается к мастеру. Совместно они выполняют координацию работы драйвера и екзекуторов Спарк.
На наш взгляд, в предлагаемом вами решении отсутствует возможность фиксации или отката всего батча одной транзакцией, что с нашей точки зрения является важным, и наш коннектор позволяет это делать.
Возможность data-locality, о которой вы упомянули, тоже играет не последнюю роль, хотя это у нас всё ещё в процессе.
Поправьте меня если я заблуждаюсь, но jdbc коннектор в Спарке рассчитан на PostgreSQL, а не на Greenplum.
Для нас это означает, что данные в транзакции чтения, получаемые Спарком из Гринплама, будут передаваться через Координатор(мастер) хост Гринплама для всех екзекуторов Спарка (это плохо), если только вам не удастся также задействовать операцию copy при чтении. Наш коннектор позволяет избежать этого — данные на екзекуторы передаются непосредственно с сегментов Greenplum.
При этом не нужно задумываться как распределить данные по партициям Спарка — коннектор (с помощью Гринплама) далает это автоматически.
В целом наше мнение здесь однозначно:
Мы предпочитаем использовать специализированный коннектор, который гарантирует консистентность передаваемых данных в любых ситуациях в сочетании с хорошей пропускной способностью, масштабируемостью и универсальность по отношению к структуре данных вне зависимости от каждой конкретной задачи.
К сожалению, не выложили. Нам мешает ряд нетехнических моментов, повлиять на которые мы попросту не в состоянии. Но мы надеемся и верим, что всё образуется и наш коннектор ещё окажется в Maven.
Обусловлены опытом, тк никакого общепринятого стандарта с которым они коррелируют нет.
Ответ, как мониторить, собственно в конце поста:
Мы мониторим синхронизацию времени, запрашивая статус работающих на сервере утилит. Например, ntpd, chronyd или systemd-timesyncd, и используем алерты следующего вида:
Однажды Сергей Павлович Королев сказал одному из своих подчиненных такую фразу: «Не согласен — критикуй, критикуешь — предлагай, предлагаешь — делай, делаешь — отвечай!»
Поэтому отвечаем. Нам показалось, что вакуумирование, вакуумировать — это вполне подходящее название для процесса очистки "раздутых" таблиц. Собственно, прилагательное "раздутый" вполне можно связать с чем-то, что чрезмерно наполнено газом или воздухом. И как вы правильно заметили, вакуумирование — это удаление воздуха или газа. Только у нас вместо веществ, способных распространяться по всему доступному им пространству, равномерно заполняя его, данные, которые действуют схожим образом в табличных БД, вроде Greenplum. Поэтому и вакуумирование.
Но мы с радостью почитаем ваш вариант, как можно было бы перевести на русский язык этот английский термин без потери смысла.
Вероятно на вашем уровне компетенций эта статья может показаться пустой. Ну что ж, пусть так. Но в ней мы просто даем базу для новичков в преобразовании данных.
Прекрасно, что вы настолько осведомлены и разбираетесь в вопросе, что наша абсолютно базовая статья показалась вам неактуальной. Однако, все ещё есть люди, которые не настолько разобрались в преобразовании данных. Как раз для них мы и опубликовали этот текст.
Конечно можно и без коннектора сделать, но коннектор удобно инкапсулирует всё это. Мы считаем это полезным, чтобы не отвлекаться при решении конкретных практических задач. Также мы надеемся, что нам удастся перенести так сказать "ядро" этого технического решения на некоторые другие системы при их сопряжении (не Спарк и не Гринплам).
Ссылку на репозитарий прикрепили в конец статьи. Дублируем здесь: https://github.com/itsumma/spark-greenplum-connector
На наш взгляд мы не сделали никаких выпадов в сторону реализации параллелизма в Spark, мы лишь отмечаем, что не для любой внешней массивно-параллельной системы (такой как Greenplum) имеются готовые коннекторы, которые работают оптимально с нашей точки зрения. И это вполне естественно.
Термины master и slave относятся здесь вообще не к Cпарку, а к классам, которые мы разработали на основе механизма удалённого вызова процедур. Есть класс который выполняет роль master и есть slave. Slave подключается к мастеру. Совместно они выполняют координацию работы драйвера и екзекуторов Спарк.
На наш взгляд, в предлагаемом вами решении отсутствует возможность фиксации или отката всего батча одной транзакцией, что с нашей точки зрения является важным, и наш коннектор позволяет это делать.
Возможность data-locality, о которой вы упомянули, тоже играет не последнюю роль, хотя это у нас всё ещё в процессе.
Поправьте меня если я заблуждаюсь, но jdbc коннектор в Спарке рассчитан на PostgreSQL, а не на Greenplum.
Для нас это означает, что данные в транзакции чтения, получаемые Спарком из Гринплама, будут передаваться через Координатор(мастер) хост Гринплама для всех екзекуторов Спарка (это плохо), если только вам не удастся также задействовать операцию copy при чтении. Наш коннектор позволяет избежать этого — данные на екзекуторы передаются непосредственно с сегментов Greenplum.
При этом не нужно задумываться как распределить данные по партициям Спарка — коннектор (с помощью Гринплама) далает это автоматически.
В целом наше мнение здесь однозначно:
Мы предпочитаем использовать специализированный коннектор, который гарантирует консистентность передаваемых данных в любых ситуациях в сочетании с хорошей пропускной способностью, масштабируемостью и универсальность по отношению к структуре данных вне зависимости от каждой конкретной задачи.
К сожалению, не выложили. Нам мешает ряд нетехнических моментов, повлиять на которые мы попросту не в состоянии. Но мы надеемся и верим, что всё образуется и наш коннектор ещё окажется в Maven.
В текст закралась ошибка, автор имел в виду вот этот редактор: https://codebeautify.org/yaml-editor-online Спасибо за вашу внимательность!)
Обусловлены опытом, тк никакого общепринятого стандарта с которым они коррелируют нет.
Ответ, как мониторить, собственно в конце поста:
Мы мониторим синхронизацию времени, запрашивая статус работающих на сервере утилит. Например, ntpd, chronyd или systemd-timesyncd, и используем алерты следующего вида:
Спасибо, рады, что принесли вам пользу!)
Думаете у них все будет дальше грустно? Вроде бы пока что они не плохо справляются.
Либо так, либо подпишитесь на наш ТГ: https://t.me/itsumma Туда тоже обязательно выложим.
Однажды Сергей Павлович Королев сказал одному из своих подчиненных такую фразу: «Не согласен — критикуй, критикуешь — предлагай, предлагаешь — делай, делаешь — отвечай!»
Поэтому отвечаем. Нам показалось, что вакуумирование, вакуумировать — это вполне подходящее название для процесса очистки "раздутых" таблиц. Собственно, прилагательное "раздутый" вполне можно связать с чем-то, что чрезмерно наполнено газом или воздухом. И как вы правильно заметили, вакуумирование — это удаление воздуха или газа. Только у нас вместо веществ, способных распространяться по всему доступному им пространству, равномерно заполняя его, данные, которые действуют схожим образом в табличных БД, вроде Greenplum. Поэтому и вакуумирование.
Но мы с радостью почитаем ваш вариант, как можно было бы перевести на русский язык этот английский термин без потери смысла.
Если зарегистрируетесь, пришлем запись вам на указанную почту после вебинара. Сможете посмотреть в удобное для вас время)
Вероятно на вашем уровне компетенций эта статья может показаться пустой. Ну что ж, пусть так. Но в ней мы просто даем базу для новичков в преобразовании данных.
Прекрасно, что вы настолько осведомлены и разбираетесь в вопросе, что наша абсолютно базовая статья показалась вам неактуальной. Однако, все ещё есть люди, которые не настолько разобрались в преобразовании данных. Как раз для них мы и опубликовали этот текст.
Здравствуйте! Спасибо за вашу внимательность, все исправили: https://www.itsumma.ru/services/big-data/its-dpp
Оно обязательно будет) Правда пока не можем сказать, когда)
Отлично, ведь мы сейчас как раз работаем сейчас над технической статьей по этому кейсу;)
Наверное это будет похоже на то, что готовил Бендер в Футураме: https://youtu.be/KLit7q0-mqk?si=0qyuwljamTybVAlr
Добрый день! Планируем опубликовать там следующую версию инструмента. Релиз намечен на конце сентября.
Если возникнут вопросы -- смело пишите нам) Поможем разобраться.