Это решается либо ссд, либо увеличением дисков в датаноде

я знаю что может быть раскидан

а теперь представь что он может быть раскидан + еще и промежуточная датанода на jvm + загруженная сеть

Немного не так

почему же?

Какой шанс, что раскидает 128 мегабайт против 1 гигабайта?

Раз в 10 меньше

А уж если это стандартный размер

И кластер равномерно забит

Прилично меньше

И тебе для чтения этого гигабайта понадобится 10 операций чтения вместо 1000 локальных

+ Нетворк латенси

эм, для файловой системы как-то пофиг это 128мб или 1гб, ей пишут, она алоцирует и выдает след кластер

эм, для файловой системы как-то пофиг это 128мб или 1гб, ей пишут, она алоцирует и выдает след кластер

Ещё ниже опустись

Диску не пофиг

Есть сектора последовательные

А есть сектора в начале диска и конце

я понимаю, откуда ОН знает сколько на него будут писать?

Скорость чтения с блина также разная

я понимаю, откуда ОН знает сколько на него будут писать?

Не знает

Если есть место подряд, то он будет писать подряд

Если места нет, он будет писать в свободное место

тогда почему 128мб он может записать последовательно, а 1гб блоками по 128мб или 512мб последовательно не может

1) У тебя не просто 1 гигабайт, по твоим словам этот размер прыгает. 2) при заполнении дисков эти невыравненные блоки будут писаться и стираться рандомно 3) работа с хадупом - это кластер кучи данных

тогда почему 128мб он может записать последовательно, а 1гб блоками по 128мб или 512мб последовательно не может

Может

Особенно на чистом кластере

Дальше процент будет падать

Меньше места, больше падение

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

Хотя даже хбейз режет размер кстати

Ты смотрел?

У него такие же блоки по 128 мегабайт )

1-2) и будет он прыгать в пределах одной машинки или нескольких тебе без разницы 3) да но мы говорим сейчас о 2х фрагментациях 1) фрагментация физического диска 2) фрагментация на уровне hdfs в итоге я предпочитаю на клиенте когда работаю иметь хотябы только 1, а не как жадный загребать и 1 и 2

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

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

моя локальность когда hdfs еще версии 0.18 был ? и даже аппенда не поддерживал

Не получается у нас вообщем) ладно, у меня просто нет таких обработок, чтобы сразу все данные считать. У меня ограниченные селекты с партиционированием хайва, и зачем мне читать 1 гигабайт вместо чтения 128 мегабайт ?

Аналитика, нужно прочитать все и отфильтровать

Или агрегировать

Если данные упорядочены то там тебе фитрами и min/max уже усечет неплохо

А если каша, то близко к фулскану

https://databricks.com/session/hdfs-on-kubernetes-lessons-learned

Там хорошо про даталокалити прошлись

всем привет! а подскажите какое-нибудь достаточно быстрое in memory text search решение? Попробовал потестировать ElasticSearch, но как-то он не очень быстрый(

всем привет! а подскажите какое-нибудь достаточно быстрое in memory text search решение? Попробовал потестировать ElasticSearch, но как-то он не очень быстрый(

elastic не in memory, может что-то не так с тестами, насколько быстрым должно быть?

Ну и elastic вообще не про скорость

Не очень быстрый - какую скорость Вы ожидали?

тест очень простой - есть http сервис (tornado.web.Application), в него прилетает query - пара-тройка слов - terms. нужно чтобы сервис отдавал (и очень быстро отдавал) из базы комментов такие комменты, где встречаются эти terms, в произвольном порядке. Например: q = "hello world" db = [ (1, "some comment"), (2, "world hello today"), (3, "only hello"), (4, "hello world tomorrow") ] def search(q,db): .... return h search(q,db) -> [2,4] Сейчас в виде db и search я использую эластик, и скорость там не особая - меньше чем если просто тупо хранить всю db в памяти питона как пачку словарей и ходить по ним циклом на каждый запрос. Я конечно понимаю что в продакшене пачка словарей в памяти храниться не будет, поэтому нужна альтернатива - и достаточно быстрая)

Ignite?

https://www.slideshare.net/profyclub_ru/sphinx-41345784 тут приведены критерии выбора и как правильно делать бенчмарки (чтобы не тестировать например скорость отдачи кеша эластика)

а так если нужно только вхождение слова (без всяких словоформ, морфологии, ранжирование и т.д.), то строй инверт индекс и храни в inmemory base

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

Вроде же из документации Row group size: Larger row groups allow for larger column chunks which makes it possible to do larger sequential IO. Larger groups also require more buffering in the write path (or a two pass write). We recommend large row groups (512MB - 1GB). Since an entire row group might need to be read, we want it to completely fit on one HDFS block. Therefore, HDFS block sizes should also be set to be larger. An optimized read setup would be: 1GB row groups, 1GB HDFS block size, 1 HDFS block per HDFS file

всем привет! а подскажите какое-нибудь достаточно быстрое in memory text search решение? Попробовал потестировать ElasticSearch, но как-то он не очень быстрый(

reindexer

https://github.com/Restream/reindexer

https://github.com/Restream/reindexer

Пробовал? Есть чего рассказать? =)

Друзья мои, мы, потихонечку, начинаем готовить Moscow Spark #6. Состоится он, видимо, во второй половине ноября. Когда пройдет, по крайней мере, Highload++. Если у кого-то есть материал, чтобы сделать клевый доклад, жду вас в личку )

Как в спарке кастомный запрос в бд превратить в dataframe?

spark.sql("твой кастомный запрос")

Ну это если хайв

sqlContext.read().format("jdbc").options().load только всю таблицу грузит

Ну это если хайв

Мне надо через jdbc

sqlContext.read().format("jdbc").options().load только всю таблицу грузит

Не, не загрузит. Вычисления же ленивые

?

Нужно jdbc селект в скобки обернуть и подать как аргумент в table

table = sqlContext.read().format("jdbc").options().load table.createOrReplaceTempView("people") spark.sql("select * from people where people.gender == 'm'").take(5)

Нужно jdbc селект в скобки обернуть и подать как аргумент в table

Select from Select?))

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

Например тип intervals teradata спарк не сьест

Например ты пишешь: spark.read.jdbc(table=“(select * from table where ...) as X)”)

Спасибо!

Например тип intervals teradata спарк не сьест

Сьест если кастомный диалект написать и подложить!)

да так тоже можно

у тебя в логах и написано что на всех нодах такая хрень

Забавно, но хардкод в hosts решил те редкие проблемы резолвинга )

Простите, вопрос начинающего: загружаю dataframe из .parq. Делаю .describe() выдаёт ошибку 143. Причём на одном столбце работает : .describe(column) . Пробовал увеличить partitions не помогает. Есть какие идеи ?

Добрый вечер. Тоже вопрос начинающего, есть hadoop cluster учебный, 1 NN + 5 DN. Необходимо - перевести его под управление yarn, чтобы поизучать yarn прежде всего. Праивльно ли понимаю, что будет достаточно сконфигурировать yarn так чтобы RM был на NN, а NM и AM на дата нодах ? В проме используется такое или для RM всё таки лучше отдельную машину ?

Так и используется

Добрый вечер. Тоже вопрос начинающего, есть hadoop cluster учебный, 1 NN + 5 DN. Необходимо - перевести его под управление yarn, чтобы поизучать yarn прежде всего. Праивльно ли понимаю, что будет достаточно сконфигурировать yarn так чтобы RM был на NN, а NM и AM на дата нодах ? В проме используется такое или для RM всё таки лучше отдельную машину ?

у нас на одном master-узле стоит Active NN и Standby RM, на втором master-узле - Standby NN и Active RM

у нас на одном master-узле стоит Active NN и Standby RM, на втором master-узле - Standby NN и Active RM

И как загрузка? И мощность обоих машинок

Понял, спасибо. Попробую

И как загрузка? И мощность обоих машинок

а я суеверный, не буду отвечать )

Есть трехузловая архитектура, на 2 NN, на 3 RM, везде JN и звередержатель

Есть трехузловая архитектура, на 2 NN, на 3 RM, везде JN и звередержатель

Угу, стандарт вроде

Для прода

Я такого никогда ещё не делал, вот сейчас первый раз попробую

о, а у вас Kafka на ПРОДе отдельно от HDFS DataNode/YARN NM?

У нас?

ну, вы со Станиславом вроде коллеги?

о, а у вас Kafka на ПРОДе отдельно от HDFS DataNode/YARN NM?

Да, выделенные ноды изза специфики нагрузки

Может быть, но мы незнакомы и прод у нас точно разный. У нас картофки пока нет на проде.

Из-за ненадобности

Всем. привет. Есть какие-то бест-практис касательно бекапов данных хранимых в hdfs? Там просто оченьго много мельких файлов, сейчас уже почти 500к, а будет больше. Если делать distcp на S3 это очень медленно, примерно 1000 файлов в час. Крайне неприемлемая скорость.