Pull to refresh

Comments 28

интересно, но нифига не понятно.
в связке с greenplum, в чем спарк запускался? из текста складывается впечатление, что спарк на одной единственной ноде запутили в локальном режиме.
когда сравнивали с хадуп, что за енжин был у hive? hive on spark пробовали?
На доступном железе для экспериментов пробовали стендалон. Спарк запускался на одной ноде, также пробовался на двух и трех нодах (тоже стендалон). Есть идея использовать yarn, до этого пробовался mesos (без связки с гринпламом).
Очень много разнородной информации, которая занимает время, а еще сам стек требует гораздо больше железных ресурсов, которые не всегда доступны :)
Если у вас был опыт и рекомендация, где все-таки лучше запускать spark в контексте удобства масштабирования/управления и возможности поставить рядом какую-нибудь базу, то буду рад ответу.

Hive запускался с TEZ (с mr не помню уже, какие-то проблемы возникали). Также пробовали impala — работает побыстрее, но лицензионные ограничения и периодически что-то отваливалось при нагрузочном тестировании. Hive on Spark даже не рассматривался, основные данные лежали в HDFS.
на сколько я знаю на cвоем железе всего 2 варианта (не считая локал) пускать спарк — хадуп кластер или k8s кластер. k8s как менеджер для spark — совсем новая тема, в проде для совсем смелых и там большой минус — нет «data locality». на хадупе — spark с yarn кажется чаще встречается. без хадупа, поднять лишь yarn думаю не выйдет. yarn наверняка нужен и zookeeper, спарку точно нужен общий сторидж (hdfs). имхо разумней весь хадуп для спарка поднять, тем более что там же у вас и kafka будет.
Hive on Spark именно с HDFS и работает, но думаю медленее Impala на простых запросах, зато стабильно. Impala, да, с тяжелыми запросами и тучей пользователей и у нас плохо дружит.
мне вот интересно как была скорость у Impala/HDFS на фоне Greenplum, обгоняла, если хватало ресурсов выполнить запрос?
Спасибо за хороший и развернутый ответ!
Да, похоже от хадупа не уйти никуда и надо ставить всю инфраструктуру, слишком много в этой экосистеме завязок — hdfs, yarn, hive опять же (если потребуется), mapreduce разве что не надо :)
Несмотря на то, что k8s сейчас почти везде и спарк научился с ним работать 3 года назад — тоже есть большие опасения для использования в проде, плюс про «data locality» хороший поинт
Ну hive on spark с hdfs я так понимаю работает через spark же? Просто я к тому, что это дополнительное звено и не уверен, что так быстрее — хотя про эту схему как-то не подумал

Честно говоря конкретных замеров и сравнений impala/hdfs именно с greenplum не было, но «по ощущениям» вроде было сопоставимо, хотя как пишет сама cloudera (еще бы им не верить :)) — должно быть быстрее blog.cloudera.com/apache-impala-leads-traditional-analytic-database
А вот в блоге tinkoff например пишут, что greenplum пошустрее работает, чем impala — habr.com/ru/company/tinkoff/blog/310620

По возможности, конечно, будет интересно проверить еще и самостоятельно, согласен
Но сейчас как сама impala, так и эксперименты с ней уже утеряны
Удивительно конечно что «тест Тинькофф» которому уже 5 лет продолжает быть референсным :)
А ведь о чем «тест» то был? Специалисты GreenPlum проверяли in-memory движки и на всякий случай решили запустить запросы на Impala (при этом не будучи специалистами в этой области). Ни конфигурации, ни версий, ни настроек стенда Cloudera и Impala, ни планов запроса, ни профилей запроса не предоставлено.
Сама методика тестирования тоже вызывает много вопросов — на системах массивных параллельных вычислений запускают один запрос (!) и сравнивают его время работы. Ээээ, что простите? Вы в реальной жизни где такую ситуацию увидите? В реальной жизни на MPP системе высококонкурентная нагрузка и поэтому тестировать надо ни одни запрос, а 20, 30, 40, 60 и тд одновременно работающих и сравнивать не только общее и среднее время работы но и разброс max, min (чтобы увидеть ситуацию когда пришел первый и сожрал все ресурсы, а остальные стоят в сторонке). А в этом конкретном тесте проверили как система может выделить ресурсы одной сессии.
В реальной жизни на большинстве задач Impala быстрее GP и вот почему:
-Impala читает только те данные, что удовлетворяют условиям запроса тк происходит фильтрация на уровне сканирования (отсеиваются блоки, а начиная с версии 3.4 отсеиваются даже страницы, не удовлетворяющие выборке). Аналог storage index (zone maps) в Exadata (Netezza)
-Умеет строить динамические и bloom фильтры, чтобы как раз сканировать то что надо, а не поднимать все
-Принцип работы обработки — непрерывный pipeline данных от storage слоя до выдачи результата
-В версии 3.4 появился полноценный intra node параллелизм, который распараллеливает не только по кластеру выполнение, но и внутри одного узла, что приводит к кратному (!) увеличению производительности.

GP иногда будет быстрее только если ключ сегментирования совпадает с условиями соединения и\или условия запроса совпадут с ключом секционирования. В реальной жизни, условно, никто не будет сегментировать банковскую проводку по номеру счета для скорости работы соединения с таблицей счетов тк это вызовет адский перекос данных. Во всех остальных ситуациях GP уйдет в full scan. Именно поэтому рекомендация по железу от вендоров — много маленьких и быстрых дисков на сегмент ноду.
Научить GP фильтрации данных на уровне чтения Pivotal обещает только к концу 2021 года и только в своей версии (в open source и прочих сборках поделках этого не будет скорее всего).

PS
Impala у вас плохо дружит с тучей пользователей потому что вы не настраивали admission control скорее всего. Я имею возможность работать с кластером где в сутки исполняется миллион SQL запросов на кластере Impala с одновременно работающими 50-60 сессиями
ну не знаю, десяток узлов с импалой 3.2, Enable Impala Admission Control галочка стоит, mem_limit стоит и для Impala Daemon Coordinators и для Impala Daemon Executors (30 и 80Gb сотетсвенно), scratch_dirs настроены.
типичная ошибка
Memory limit exceeded: Failed to allocate row batch
EXCHANGE_NODE (id=5) could not allocate 32.00 KB without exceeding limit.
Error occurred on backend host010.domain.net:22000
Memory left in process limit: 9.51 GB
Query(3d4641a8c316a52d:f17a2b7100000000): Reservation=51.78 GB ReservationLimit=64.00 GB OtherMemory=22.00 MB Total=51.80 GB Peak=51.80 GB
Fragment 3d4641a8c316a52d:f17a2b7100000006: Reservation=320.00 MB OtherMemory=2.89 MB Total=322.89 MB Peak=322.89 MB


если в запросе ставить явно SET MEM_LIMIT тупо вываливается по достижении лимита. примерно те же проблемы на координаторах — он тянет весь результирующий датасет к себе в память, т.е. памяти на координаторе надо больше, чем клиент попытается утащить.
Конфигурация узлов по CPU и RAM какая?
Impala вычитывает данные в память и потом пайпом проводит все операции. Если вам не хватает памяти чтобы поднять блоки, нужные для обработки, запрос падает с таким вот сообщением. В скратч область может уходить только hash и сортировка.
В вашем случае правильное решение — понять сколько памяти нужно запросу и поднять mem_limit до нужного значения.
В любом случае — это проблема одного конкретного запроса, а не одновременного кол-ва запросов. Бест практис проектирования кластера под импалу с высококонкурентной нагрузкой — много памяти.

GP рабоатет немного под другому. Каждый воркер постгреса начинает вычитывать данные и сразу сваливать их в кэш, который уходит в файловый кэш операционки, который в свою очередь занимает оперативку. те оперативнка гринпламом жрется под файловый кэш оси :) именно поэтому поднятие памяти, выделяемого воркеру (по умолчанию 50мб), не дает никакого эффекта обычно.
хабр дурковатая платформа, одним комментарием в день лимитирует.
Impala Daemon десять штук, Impala Daemon Executors mem_limit 80Gb, не понятно почему вы на этот запрос грешите, вроде очевидно Admission Control толком не работает: лимит 64, выбрано 51.78, в логе он откровенно пишет: Memory left in process limit: 9.51 GB
значит проблема не в лимите запроса, а том что Executor не может выделить запросу 32.00 KB. по мне так очевидно, что параллельные запросы тоже потребляют память на узле и все скопом не уместились, а Admission Control похоже не угадывает сколько запросу на этом узле следовало бы зарезервировать памяти, увеличивает резервацию по ходу выполнения.
Admission работает, с ним проблем нет.
Как выделяется память:
-определяется параметр mem_limit установленный на уровне ресурсного пула либо сессии. пусть будет 10Гб для простото расчета
-дальше эти 10Гб выделяются а каждом узле на котором есть демон импалы. Демон разумеется должен быть на всех узлах где есть HDFS. Иначе это говноконфигурация. Предположим у вас 10 узлов те суммарно запросу будет доступно 100Гб
-Далее, согласно дефолтовым параметрам, 80% от этого объема выделяется сканерам, читающим данные из HDFS в память (остальные 20% резервируются на другие операции, но они могут уходить в скратч, если что). те формально вы можете поднять сканерами не больше 80Гб.
-теперь оцените размер датасета, который вы поднимаете запросом. Бьюсь об заклад он выше.

Как побороть — поднять память на уровне сесси через set mem_limit либо на уровне очереди. Поднимите память на запрос и он отработает. Либо поменяйте настройки пула. В третьей ветки импалы есть параметр верхнего выделения запросу, выше которого он не может резервировать память пула, но если он не исчерпывается то память доступна конкурентным сессиям.
Цель admission контрола не угадывать память, а разруливаьт конкурентную работу, распределяя ресурсы.

Другие методы — поработать с планом запросы чтобы он не сканировал много. тут надо смотреть профиль и план. Методы есть (например задать параметр повышенного ожидания построения фильтра, которые потом будет поднимать с паркета только нужные данные; те Impala сперва построит фильтр, а потом наложит на данные вместо того чтобы сканировать все и потом фильтровать).

Так кстати и не написали конфигурацию дата узла.
можете пояснить, что значит «Memory left in process limit: 9.51 GB» в моем логе?
мне не понятно зачем трогать лимит, если он и близко не превышен? Impala Daemon Executors mem_limit итак уже поднят до 80Gb, причем таких узлов 10. 800G — этого хватает одному такому запросу, если никто крупный параллельно не исполняется. значит в целом на кластере хватает и памяти и лимитов.
Почему вы путаете лимит, выделяемый Impala на одном узле и лимит выделяемый одному запросу на одном узле?
Вангую что лимит одного запроса на узле 10Гб. Собственно его превышение и фиксируется.
Чтобы запрос отработал нужно либо на уровне сессии поднять лимит например set mem_lim=20g Либо сразу на уровне пула (https://docs.cloudera.com/documentation/enterprise/latest/topics/impala_admission.html#admission_memory раздел Clamp MEM_LIMIT Query Option)
если бы я путал, то рестарт запроса не помогал бы. лимит тут не причем, на свободном кластере запрос проходит. когда запрос упирается в лимит демона, на демоне вообще ничего не стартует. при срабатывании лимита демона ошибку кидает координатор, что-то типа такого:
Memory limit exceeded: Query a34a9afbf1a71fb1:85f3fbd100000000 could not start because the backend Impala daemon is over its memory limit

в моем же случае демон запрос пропустил и начал исполнять, в первую очередь потому что запрос проходит по всем лимитам. и по общему на запрос (в моем случае его не было) и по лимиту на демоне. демон начал исполнять, но заранее не зарезервировал достаточно памяти, потому свалился до достижении лимита демона.
Спасибо, про clickhouse хорошее уточнение. Он действительно шустро работает и сейчас даже из коробки интегрирован с кафкой. Похоже, что в некоторых ситуациях — это идеальное решение. Например, события какие-нибудь собирать — журналы, статистику и т.д.
Единственный недостаток — ограничения в SQL-синтаксисе, т.е. например раньше нельзя было делать более одного JOIN, сейчас есть ограничения на сложные запросы с алиасами. И для тех, кто занимается аналитикой такие ограничения могут быть критичными в плане времени на переучивание — сложность при портировании легаси, меньше гибкости. Конечно, clickhouse развивается и активно дорабатывается и скорее всего в будущем будет разумным перейти именно на него

Про Яндекс.Танк — для кастомных пушек есть pandora, достаточно удобно если умеешь на go писать.

Да, спасибо, хорошее дополнение. Даже была идея использовать сам github.com/yandex-load/phantom и написать на C, но в итоге остановились на подручных материалах — python + aiohttp / aiokafka
Иван, а вы смотрели Arenadata DB? Мы вместе с Pivotal занимаемся разработкой и развитием Greenplum, по количеству комитов занимаем второе место и обогнали ещё год назад Alibaba. Основные отличия от ванильного Greenplum — собственный оркестатратор ADCM, с которым значительно удобнее деплоить систему, возможность offline установки, нативная интеграция с Hadoop, ClickHouse, Kafka, NiFi, Elasticsearch, наличие системы мониторинга и оповещения, Command Center — инструмент для работы с запросами (SKEW), поддержка x86 и Power-совместимого оборудования, возможность влиять на развитие и доработка ядра Greenplum под требования заказчика и поддержку 24x7. Вот тут в видео рассказываем подробнее про отличия от «ванилки» www.youtube.com/watch?v=_0AEkmGb3PM Можете скачать и потестить с нашего стора, или взять в аренду в облаке Mail.ru.
Спасибо за ваш комментарий — он позволит точнее расставить акценты. Сразу отвечаю на ваш вопрос: конечно смотрели, itsumma как раз вдохновлялась вашей деятельностью.

Существует два пути при создании платформы обработки данных — использовать либо готовое решение и разработанную кем-то платформу с энтерпрайз-поддержкой, либо пробовать собрать in-house разработку самостоятельно из опенсурс-решений.

Готовых решений на рынке вспоминается сразу несколько — это как облачные, так и on-premise решения (как у вас): Google Dataproc, Amazon EMR, Microsoft HDInsight, Bluemix, Oracle Cloud Infrastructure Data Flow, Cloudera конечно же (ранее сюда можно было hortonworks добавить) — это то, что за рубежом.

Если говорить про Россию — здесь есть Yandex Data Proc, MCS и конечно же ваша компания с вашим продуктом Arenadata EDP, поэтому для меня это честь получить комментарий от вас: большой вклад в сообщество — телеграм-каналы, обучающие курсы, опенсурс-код и коллосальный объем работы по созданию такого рода решений и продвижению их в РФ.

Не хотел рассказывать про существующие продукты на рынке в самой статье, но благодаря вашему комментарию получилось дополнить статью уже в обсуждении. Если я не ошибаюсь, то ваше решение так же не предоставляет spark-greenplum коннектор (хотя у вас упоминаются собственные разработки коннекторов для кафки и кликхауса). Все упоминания в контексте вашей платформы были про существующий проприетарный jar-файл коннектора от Pivotal, лицензионные соглашения на который все также остаются у Pivotal.

Насколько я понимаю подобные сложности возникали и в китайских компаниях, можно судить по косвенному признаку то, что автор github.com/yaooqinn/spark-greenplum работает в крупной китайской интернет-компании NetEase.

Статья же все-таки была про недостающее звено, которое обязательно потребуется, чтобы собрать свою in-house разработку на данном стеке технологий. Это была та пустота, которую попытались заполнить и надеюсь до определенной степени мой комментарий прояснил акценты. Если наш опыт кому-то поможет — уже классно.

Еще раз благодарен за ваш комментарий, который (несмотря на заслуженную рекламу:)) позволил дополнить статью
У Arenadata DB есть свой Spark-Greenplum коннектор. Он сильно отличается от коннектора NetEase и прочих вариаций. Функционал нашего коннектора:
чтение данных из ADB, запись данных в ADB с помощью различных режимов записи (overwrite, append, errorIfExists), поддержка структурированных данных, автоматическое формирование схемы данных, настраиваемое партиционирование (целочисленные типы, даты), push-down операторов (отсекание колонок, push-down фильтров), извлечение дополнительных метаданных из ADB (схема распределения данных, статистика, оптимизация count-ов), выполнение произвольного sql через master ADB, батч режим. P.S. опять реклама вышла :)

Звучит круто! А он проприетарный и только по подписке? На вашем сайте просто ничего такого не находил. Можете скинуть ссылку на описание, если есть возможность. А вы планируете в опенсурс выкладывать? :)

Но за анонс спасибо, возможности выглядят неплохо
Коннектор проприетарный, пока не планируем выкладывать в Open Source. Продукт свежий, документация по нему готовится. Общее описание на сайте стоит ожидать не раньше марта. И есть идея написать статью на Хабр по нему с разъяснением функционала.
Спасибо, понял, успешного релиза! А в статью на хабр или на сайт тесты и сравнения с pivotal-коннектором планируете? Это было бы супер
Хорошая идея сравнить с Pivotal, спасибо!

А с чего вы взяли что Pivotal не продает и не имеет поддержки в РФ? Еще как продает и поддерживает. С Confluent проблемы есть, но и они решаются через локального партнера и поддержку полноценную получить можно.

Спасибо, это интересное замечание. Могу рассказать свою историю — смотрели их лицензионные соглашения и разные ограничения, связанные с использованием их продуктов и посчитали, что поддержка может прекратится в любой момент. И летом прошлого года сам коннектор (речь о greenplum-spark) было нельзя никак скачать с их сайта, даже зарегистрировавшись — была только надпись обратиться по адресу export@pivotal.io, где никак не отвечали. Плюс история с confluent в рф добавила когнитивных искажений, что возможно у pivotal такая же ситуация (учитывая отсутствие хоть какого-то ответа). Вполне возможно контакт надо получать другим образом, тут согласен, и если подскажите куда стучаться — буду благодарен.

Тогда дополню статью, чтобы не вводить в заблуждение. Прошу прощения, если не прав. Если есть публичные примеры — было бы классно, в голову приходят только Tinkoff и ArenaData, но почему-то складывалось впечатление, что это все in-house разработки без официальной поддержки Pivotal
Несколько запоздалое дополнение к статье: разработка начиналась до существующих opensource-альтернатив нашим (к сожалению, бывшим) коллегой, который собственно и начинал погружаться в эту тему.

Первую версию этого коннектора и наработки можно найти на github в его личном репозитории github.com/hide42/greenplum-spark

Автор также теперь есть на хабре — hide100
Sign up to leave a comment.