Comments 11
Так и не выложили коннектор в Maven :(
Я может чего не понимаю, но в jdbc-коннекторе есть возможность параллельного чтения данных с разбиением на партиции по одной колонке, с параллельной записью тоже проблем нет, тем более gp должен поддерживать copy, можно ж просто сделать dataframe.foreachPartition и в ней через copy залить. Едтнственное, где я вижу необходимость в своем коннекторе - если spark-ноды и gp-ноды нахожятся на одних машинах, и надо по возможности read local обеспечить. В любом случае, исходники на гитхаб было бы плюсом, а так в статье одна вода "какие мы молодцы бла бла бла и как мы круто сделали бла бла бла"
Поддерживаю, совершенно непонятный выпад в сторону параллелизма spark. Еще в первые вижу, чтобы driver и executor называли master и slave.
На наш взгляд мы не сделали никаких выпадов в сторону реализации параллелизма в Spark, мы лишь отмечаем, что не для любой внешней массивно-параллельной системы (такой как Greenplum) имеются готовые коннекторы, которые работают оптимально с нашей точки зрения. И это вполне естественно.
Термины master и slave относятся здесь вообще не к Cпарку, а к классам, которые мы разработали на основе механизма удалённого вызова процедур. Есть класс который выполняет роль master и есть slave. Slave подключается к мастеру. Совместно они выполняют координацию работы драйвера и екзекуторов Спарк.
COPY будет передавать данные через мастер, он для таких объёмов не предназначен. Нужен CREATE EXTERNAL TABLE на стороне Greenplum + веб-сервер на стороне Spark executor'ов, реализующий gpfdist протокол, чтобы передавать данные напрямую на GP сегменты, минуя мастер.
На наш взгляд, в предлагаемом вами решении отсутствует возможность фиксации или отката всего батча одной транзакцией, что с нашей точки зрения является важным, и наш коннектор позволяет это делать.
Возможность data-locality, о которой вы упомянули, тоже играет не последнюю роль, хотя это у нас всё ещё в процессе.
Поправьте меня если я заблуждаюсь, но jdbc коннектор в Спарке рассчитан на PostgreSQL, а не на Greenplum.
Для нас это означает, что данные в транзакции чтения, получаемые Спарком из Гринплама, будут передаваться через Координатор(мастер) хост Гринплама для всех екзекуторов Спарка (это плохо), если только вам не удастся также задействовать операцию copy при чтении. Наш коннектор позволяет избежать этого — данные на екзекуторы передаются непосредственно с сегментов Greenplum.
При этом не нужно задумываться как распределить данные по партициям Спарка — коннектор (с помощью Гринплама) далает это автоматически.
В целом наше мнение здесь однозначно:
Мы предпочитаем использовать специализированный коннектор, который гарантирует консистентность передаваемых данных в любых ситуациях в сочетании с хорошей пропускной способностью, масштабируемостью и универсальность по отношению к структуре данных вне зависимости от каждой конкретной задачи.
jdbc коннектор в Спарке рассчитан на PostgreSQL
да, это так. Все через координатор гоняет. Я очень сильно протупил, перепутал внезапно с apache phoenix-ом.
Почитал ваш коннектор, я немного не до конца понял, как у вас планируются партиции ( это надо видимо с дебагером погонять), а в каждом PartitionReader-е/DataWriter-е у вас внутри RmiSlave поднимается http-server c gpfdist-протоколом, и одновременно создается в gp внешка с location-ами этих серверов, и в нее пишется/из нее читается. В принципе, это все и без коннектора можно сделать, будет проще. Я свой последний коннектор написал в 2020м, и в принципе, кмк, его стоит писать только тогда, когда есть возможность обеспечить data locality.
И почему-то меня не покидает ощущение, что можно сделать еще проще (возможно, ложное).
Конечно можно и без коннектора сделать, но коннектор удобно инкапсулирует всё это. Мы считаем это полезным, чтобы не отвлекаться при решении конкретных практических задач. Также мы надеемся, что нам удастся перенести так сказать "ядро" этого технического решения на некоторые другие системы при их сопряжении (не Спарк и не Гринплам).
Ссылку на репозитарий прикрепили в конец статьи. Дублируем здесь: https://github.com/itsumma/spark-greenplum-connector
Соединяя лучшее из двух миров: как мы построили мост между Spark и Greenplum в ITSumma