свежий хадуп только в сдх6, да и то не 3.1 а 3.0 плюс на нем уже нарвались на несколько багов =\ ну и еще минусы: норм поддержка докера на хадупе в cdh так и не сделали

поэтому что будет с дистрами хзхз =)

когда я в спарке делаю create temporary view? оно в какой БД деляет его? Точно не default, т.как потом ругается на Table or view not found: default.table1539671279988

Ни в какой

Если хочешь выйти за пределы сессии, задай глобальный темп вью

когда я в спарке делаю create temporary view? оно в какой БД деляет его? Точно не default, т.как потом ругается на Table or view not found: default.table1539671279988

оно не в бд, оно в SparkSession

ок, спс

когда я в спарке делаю create temporary view? оно в какой БД деляет его? Точно не default, т.как потом ругается на Table or view not found: default.table1539671279988

Пробуй createGlobalTemporaryView и смотреть в global_temp

Пробуй createGlobalTemporaryView и смотреть в global_temp

заработало, просто правил чужой код, там везде имя БД указано, т.как код делался для Хайва, для файлов они недоделали. Всем спасибо!

День добрый. Есть ли у кого опыт поднятия kafka connect?

День добрый. Есть ли у кого опыт поднятия kafka connect?

@proKafka

@proKafka

Спасибо! Я там уже спросил и там уже ответили)

Моя очередь спрашивать) Подскажите, пожалуйста, в спарке 1.6 есть возможность писать в паркет?

df.write.parquet

да, паркет поддерживается где-то 1.3 если не изменяет память

клоудеровский 1.6 точно умеет это все делать

если в табличку -

df.write.mode(SaveMode.Overwrite).format("parquet").saveAsTable("tab1")

df - собственно ваш DataFrame

Вот у меня и задачка как раз про это. В cdh 5.13 укладывать записи из базы в паркет. Пока только написал hello World)

В доках 1.6 про паркет не нашёл ничего пока.

Посмотрите внимательнее- оно там есть

https://spark.apache.org/docs/1.6.1/sql-programming-guide.html#hive-metastore-parquet-table-conversion

Мне ещё нужно размером файлов управлять, чтобы по возможности сразу укладываться в хадупный размер блока

https://spark.apache.org/docs/1.6.1/sql-programming-guide.html#hive-metastore-parquet-table-conversion

Спасибо большое

Мне ещё нужно размером файлов управлять, чтобы по возможности сразу укладываться в хадупный размер блока

А зачем делать за хдфс его работу?

А зачем делать за хдфс его работу?

Ну типа parquet.block.size в идеале не должен быть больше хадупного, чтобы запросы пошустрее работали в hive

Или напутал?

в идеале да, в этом случае у тебя все может оказаться локально в пределах одной машинки один таск-одинблок-однамашинка

если паркет блок будет больше хдфсного то там сетевой трафик может еще вылезти

но я бы пока на твоем месте сразу попытался решить задачу сразу а потом уже занимался оптимизациями

в идеале да, в этом случае у тебя все может оказаться локально в пределах одной машинки один таск-одинблок-однамашинка

А как влияет размер блока на размещение? О_о размер повлияет на количество операций ввода-вывода на сервере, которые по сути самые дорогие в расчетах

И по умолчанию разве не будет использоваться стандартная настройка из параметров хдфс?

смотри, для тебя как потребителя файл это один сплошной поток для hdfs это набор кусков (те же кластера на hdd) когда скедулер решает куда закидывать задачу он уточняет где лежит указанная часть файла и пытается кинуть его на ту же машинку в итоге тот же спарк екзекутор запрашивает через hdfs клиент у datanode нужный файл и получает по shortpath целиком файловый дескриптор (если данные на одной ноде) и читает очень быстро если у тебя файл состоит из 2х блоков то один блок ты еще локально прочитаешь, а второй уже будешь запрашивать с другой ноды по сети

И по умолчанию разве не будет использоваться стандартная настройка из параметров хдфс?

Ну по умолчанию можно написать файл 7гб при размере блока 128мб и блоки в общем случае будут лежать на разных нодах.

это если совсем грубо

Ну типа parquet.block.size в идеале не должен быть больше хадупного, чтобы запросы пошустрее работали в hive

я бы на вашем месте запустила и как миниум глянула размер получившихся файлов, паркет формат не строчный, он не будет равен размеру изначальных данных

я бы на вашем месте запустила и как миниум глянула размер получившихся файлов, паркет формат не строчный, он не будет равен размеру изначальных данных

Управлять не получится?

вопрос скорее а надо ли ?

@barloc в одном случае у тебя чистый ио с файловым дескриптором, во втором работа с сетью, что может быть не очень хорошо

@barloc в одном случае у тебя чистый ио с файловым дескриптором, во втором работа с сетью, что может быть не очень хорошо

Вот так одним махом ты преимущество хдфс для спарка записал в минусы )

почему в минусы?

Тем не менее, размер блока не влияет на локальность

вопрос скорее а надо ли ?

Ну если потом оптимизировать , то нет. А если можно сразу положить хорошо, почему бы и нет.

скедулер пытается добиться локальности, но конечно не гарантирует в случае если у тебя файл разбит на 2 равных блока ты 100% локальность почти никогда и не получишь

по мне хадуп и хдфс с самого начала это было про локальность данных

спарк тоже вкладывается много в локальность данных, будь то hbase, es, kafka везде пытаются минимизировать трафик между машинками в коннекторах спарка

Short Circuit Local Reads On HDFS спецом для этого и разрабатывали =) чтобы минимизировать доп прослойки но чтобы его утилизировать нужна локальность “this is only possible in cases where the client is co-located with the data.”

Ну если потом оптимизировать , то нет. А если можно сразу положить хорошо, почему бы и нет.

ну посмотрите документацию - насколько помню там есть свойство размер файлов паркета

спарк тоже вкладывается много в локальность данных, будь то hbase, es, kafka везде пытаются минимизировать трафик между машинками в коннекторах спарка

Аналогии не сработают, у каждой системы своя заточка

Смотри какая штука про локальность без ссд

Есть у тебя в сервере 8-12 дисков сата 7200, которые могут 70-100 иопс каждый

@barloc задачи у всех один =) быстро читать-писать это без локальности не будет зачастую для тебя это прозрачно полностью, ты работаешь с hdfs client который тебе инпут стрим возращает весь Short Circuit Local Reads проходит внутри него под капотом

ну посмотрите документацию - насколько помню там есть свойство размер файлов паркета

Обязательно. Спасибо большое. На коленке планировалось разместить данные спарком на hdfs, а затем в hive создать external таблицу и из неё заинсертить уже в новую оптимизированную.

Уверен, что есть более красивый способ.

@barloc задачи у всех один =) быстро читать-писать это без локальности не будет зачастую для тебя это прозрачно полностью, ты работаешь с hdfs client который тебе инпут стрим возращает весь Short Circuit Local Reads проходит внутри него под капотом

Вот только размер у всех разный и способ чтения. У Кафки - последовательная запись и чтение. Без рендома спарка

У хбейза очень мощный кеш и сериализация

ну давай представим что у тебя таблица из 100 файлов по 1ГБ и блоком на хдфс в 1ГБ дальше есть 100 машинок предположим что задачи разлетелись равномерно и локалити сработало дальше каждая с локального диска подняла по дескриптору, прочитала, выполнила и послала в драйвер результаты (вернее подымет датанода, но вернет тебе дескриптор и ты прозрачно с него читать будешь, не зная ничего в самом спарке) теперь вторая ситуация: ну давай представим что у тебя таблица из 100 файлов по 1ГБ и блоком на хдфс в 128МБ (файл получается состоит из 8 блоков) дальше есть 100 машинок то есть локальности ты можешь добиться только на первых 100 блоков, остальные 700 блоков должны гнаться по сети это 1) нагрузка на datanode (она должна прочитать данные с диска, закинуть в память, сериализовать, отдать по сети клиенту). мы все знаем что тут начинается еще давление на gc в датаноде + количество хэндлеров на работу тоже не безлимитно 2) нагрузка на сеть, когда все начинают ломиться ко всем вопрос: какая из двух ситуаций отработает быстрее

когда с паркетом работаешь зачастую это линейный скан страницы/чанка

Интересный пример

А что будет при изменении данных в файле, полная перезапись?

С синхронизацией по всем репликам?

а разве хдфс поддерживает изменения файлов?

только дозапись

а разве хдфс поддерживает изменения файлов?

ну может имеется ввиду копи он райт

нету такого

файл immutable

я про это и говорю, читается мап файл, меняется, трется, записывается

писать в середину нельзя, CoW hdfs тоже не поддерживает

и тут без разницы какой у тебя размер блока

Управлять не получится?

Через repartition

Ок. Тогда второй вопрос - у тебя уже прям чоткая законченная таблица в 100 гигабайт, точно распределённая по 100 серверам. Но мы же знаем, что так не бывает. Данные растут, постоянно выдерживать распределение?

Ну и ещё вопрос к файловой системе опреционки

да, данные новые это новые файлы, пускай появляются, но желательно тоже одинарными блоками

Размер 128 мегабайт - понимается, что ты на диске получишь линейную запись и чтение

Прям начиная с железки - потом ос - потом хдфс

Что будет с фрагментацией при 1 гбайте?

На железном уровне разброс записи куда попало?

размер хдфс блока важен для самой hdfs и информирует когда нужно делать отсечку и начинать писать в другой блок все понимают что 100ГБ одним блоком не записать, нужно как-то делить для ос один hdfs блок это один файл, hdfs держит набор dirs в пределах датаноды и пытается как-то выровнять их загрузку, но правило “1 блок hdfs = 1 файл на файловой системе” сохраняется

если ты пишешь линейно файл, то и ос постарается на железе заалоцировать это линейно

а давайте еще рассмотрим разные варианты с parquet.block.size ,

но мы все понимаем, что никто гарантий не даст

parquet.block.size - в принципе это размер страйпа внутри паркет файла =) но выравнивать еще и их и держать выровненными по hdfs блоку намного сложнее

размер хдфс блока важен для самой hdfs и информирует когда нужно делать отсечку и начинать писать в другой блок все понимают что 100ГБ одним блоком не записать, нужно как-то делить для ос один hdfs блок это один файл, hdfs держит набор dirs в пределах датаноды и пытается как-то выровнять их загрузку, но правило “1 блок hdfs = 1 файл на файловой системе” сохраняется

Да почему нет то? Запросто. Вон диски в 12 тер. Пиши не хочу

parquet.block.size - в принципе это размер страйпа внутри паркет файла =) но выравнивать еще и их и держать выровненными по hdfs блоку намного сложнее

во-во-во! может приведете рекомендации из своего опыта?

для hdfs клиент не знает ничего про диски под ними =) хдфс не всегда имеет одинаковые ноды в кластере может быть как говно по 1тб, так и 12тб и на момент создания файла не всегда ты это знаешь, сколько же зальешь

во-во-во! может приведете рекомендации из своего опыта?

не, ничего сильно не скажу, тут уж все от задач зависит, читать/писать/фильтровать/компрессия

для hdfs клиент не знает ничего про диски под ними =) хдфс не всегда имеет одинаковые ноды в кластере может быть как говно по 1тб, так и 12тб и на момент создания файла не всегда ты это знаешь, сколько же зальешь

Именно. Ты смотришь на все с другой стороны, клиента. Так то вообще наплевать, файл на 1 мегабайт или на 100 гигабайт - если его доставать одинаково быстро

не, ничего сильно не скажу, тут уж все от задач зависит, читать/писать/фильтровать/компрессия

ну т.е. как и все - забить на размер паркет-блока

Именно. Ты смотришь на все с другой стороны, клиента. Так то вообще наплевать, файл на 1 мегабайт или на 100 гигабайт - если его доставать одинаково быстро

так в том то и дело что варианты НЕ одинакого быстрые 1) прочитать с диска 2) прочитать с удаленной датаноды

если у тебя 100гбит сетка, везде ссд и датаноды кастомные (тот же мапр заявляет более шуструю работу их аналога hdfs), то может тебе и не нужно заботиться о локалити

во всех остальных нужно

если у тебя 100гбит сетка, везде ссд и датаноды кастомные (тот же мапр заявляет более шуструю работу их аналога hdfs), то может тебе и не нужно заботиться о локалити

Наоборот

Ты очень критично смотришь на все, но вся система построена на компромиссах

просто я видел как из-за кривой локалити загибались датаноды и сеть =)

И размер блока тоже

В ситуации фрагментации файловой системы сервера твой 1 гигабайт будет раскидан по жёсткому диску в разных местах. В итоге для его чтения потребуется не 1 операция чтения, а допустим тысяча