Тут логстэш в названии индекса же, скорее всего никакого источника и нету уже.

Если в логстеше что-то ценное (видимо из-за чего спарком выкачивают), то обычно логстеш пишет ещё куда-нибудь в кафку, и дальше в объектный сторадж или базу

полностью поддерживаю мысль - эластик не есть источник для select *, он на это просто не рассчитан. Я когда в него писал (те самые миллионы, о которых выше) картинка была прикольная: он 20 секунд пишет, 20 секунд стоит. Я - к админам (что за фигня!), оказалось, это сборка мусора... Так и жили

Поэтому да - в кафку и оттуда спокойно, быстро и надежно

Все так, эластик это FTS индекс, вторичная структура для специального поиска; как data management она много чего не умеет, от нормальных бэкапов, до репликаций и экспорта

да, но - блин: если ее (или solr, что один фиг) использовать (для поиска), то получаем полное дублирование... так и не переварил, как лучше сделать (у нас нужно было найти все записи в этих миллионах по вину авто, без индексов это утопия...). Или через hdfs но медленно, или через эластик (=полное дублирование плюс доп инфраструктура) и быстро...

Так а как вы ищете из HDFS?

спарк

в смысле select через внешнюю таблицу

Spark вроде не умеет FTS

Были какие-то ранние поделки, но в ванили ничего такого нет

да, так, НО, там у нас была "мега идея" (опять же блин - я не смог ее задавить): мы сделали "витрину", вытянув JSON (котрый из эластика) в плоскую таблицу а 500 полей (с полями вида "водитель1", "водитель2", ...) и вот в ней ищем по "любому полю" - это требование заказчиков (я неаккуртано написал выше, забыл уже, ибо дело прошлое)

Так может заказчику был нужен полнотекстовый поиск, а не просто сиквельные равенства и лайки?

не, там в данных - запросы на получение страхового тарифа, там цифры и буквы вполне себе структурированные. Лайки тоже нужны (только не просто лайки, а фузилайки - на предмет ошибок и подбора тарифа). "Заказчик" он внутренний (его уговорить было можно, а вот CDO на предмет не делать такую "витрину" - никак. Еле уговорил (вместе, кстати, с заказчиком) вынести хотя бы ЛДУ в отдельную "витрину" и связать их...

тогда видимо по месту эластик применен, туда можно всяких матчеров понаписать, удобно (а если скажем поиск сразу по нескольким языкам - вообще без вариантов)

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

"все записи в этих миллионах по вину авто" - а порядок миллионов не озвучите? Пока все это не выглядит чем то проблемным, кроме использования самого поискового движка в непредназначеном для него амплуа.

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

дык выше писал: 4 года по миллиону (грубо) в день

Привет, кто-нибудь видел хорошую статью про то, как Спарк читает hive таблицу? Я хочу понять из-за чего может происходить OOM при чтении списка партишенов, если партишенов 300-400 штук. Сохраняет ли Спарк пути к каждому файлу в памяти, и если файлов много происходит ООМ? С другой стороны, зачем ему сохранять пути к каждому файлу, если он может сохранить путь к папке с партишеном - не понятно
Хочется разобраться, как это работает

А как вы запускаете джобу?
Локально или на кластере?
Оом на драйвере или на экзекьюторе?
Сколько памяти выделяете при запуске джобы?