(кажется) и к сожалению я (с on hands опытом только в PG и пайтоне) самый опытный на проекте, так что сам придумываю дизайн. Можете оценить и указать на косяки?
Задача: хранить IoT таймсерии, 2+TB за год, начнем с трех лет данных. Использование: отдавать эти ряды алгоритмам или делать аналитику. Ограничение: все он прем, часть таймсерий должна лежать в файлах и быть доступна для прямого чтения из файла, без какого-либо квери движка, это обязательно прям.
Что я придумал пока:
Доменные метаданные в PG, таймсерии в локальном S3 совместимом сторадже в виде паркет файлов, Hive Metastore и Trino что бы запрашивать их через SQL-like синтаксис, возможность прямого чтения файлов через пайтон сохраняется. Таймсерии хранить в виде узких файлов вида "timestamp,value".
Я так понимаю Trino + HMS это примерно минимальная конфигурация, которую можно собрать, для того что бы дать аналитику возможность работать с таким объемом данных на более-менее новом стеке. Всякие штуки типа айсберга и худи не подходят потому что они ломают возможность напрямую читать паркет файлы (я так понял там сложная структура внутри). Меня еще очень смущает что таймсерии и доменные метаданные разделены по разным базам, не понимаю какой тут стандартный подход.
Можешь чуть еще пояснить про "доступность из файла"? Зачем оно? Для разовых вещей? Если так, то можно писать все в греенплум, а оттуда деалать UNLOAD какой-нибудь
не разовых, там в середине пайплайна будет трейнинг моделей, они сформрованные датасеты данных будут читать много раз и нужно отдавать их как можно быстрее. идея в том что датасет/файл готов и очищен, надо его просто загрузить и скормить в модель. пока общее решение чтов этой ситуации самое простое - это сложить в файл и читать его напрямую из кластера экзекьюторов
Ты в модель кормишь не файлы же, а строчки. Их и датабаза может отдать
как можно быстрее это как раз про датабазы вроде клика
но в том и вопрос. все эти накладные действия типа распарсить запрос, выполнить и отдать строчки быстрее ли чем чтение файла
быстрее чем прочитать файл?
Почему скороть так критична? Какая разница, моделька всосет данные за 5 минут или за 10
Почему именно такой подход выбрали? Какое время ответа должно быть, латенси и для каких подключений? Какие объемы планируется выгружать и для каких целей, какие латенси и сла на это?
эм ну, такой реквест от заказчика, хотят минимизировать время обучения, включая всасывания файлов
Во времени обучения основной потребитель времени - это само обучение 🤔
эт все оч смешные расходы на деле, не о том ты сейчас думаешь.. :) данных у тебя мало
Я подозреваю, что у тебя тот самый случай, когда postgre is fine ))
Все от задач зависит. Прочитать файлик это одно, но там ведь всякая аналитика появляется вроде группировок, иногда джойнов.
1. самая простая конфигурация с возможностью чтения данных и в виде файла и при помощи sql-like запроса. 2. для аналитических запросов - до 5 секунд, для запросов на чтение чанками / файлами - как можно быстрее. я понимаю что "как можно быстрее" - это не особо внятный ответ, это хороший поинт, я уточню конкретные требования. 3. 1 TB датасетов разбитых на файлы, для чтения ml моделями для трейнинга. опять же, нет внятных цифр, пока. окей, вероятно нужен более формальные вопросы бизнесу задать
да, я понимаю, но они хотят все не профильное подчистить. ну и на обучение я не влияю, а на это влияю
в смысле что не будет большой разницы как ни крути?
переварить 6Tb за 5 секунд?
А что будет если аналитический запрос вместо 5 секунд будет исполняться 1 минуту? Вообще, 5 секунд, когда надо посчитать на миллиардах строк - уже нетривиально. Если 5 секунд, то уже надо под конкретный аналит.запрос pre-compute делать с предвр.агрегатами
ну в смысле. если мы сложим в посгре 1+TB в одну таблицу и будем пытаться делать на этом аналитику - мне кажется он не вытянет?
для этого и хочу трино
Вопрос - почему таблица одна. Я поясню - сложно любые произвольные квери на 1ТБ сделать 5 секунд с гарантией Так что я предлагаю уточнять: - почему 5 секунд, а не 45 - какие именно квери должны в 5 секунд укладываться. "любые" - так себе ответ, нужно большей конкретики добиваться
смотря какая аналитика. Если таймсериез скорее всего есть партиция по дате и тут вопрос какой объем данных нужен для анализа. Если нужно вычитать весь терабайт то да, будет больно. Если нужны данные за день то вполне норм. Но все равно это не стыкуется с твоим требованием выше про : хотим иметь файлы в открытом формате
я понимаю что не стыкуется, но я не могу это требование передавить и поэтому что-то изобретаю
Обсуждают сегодня