mayton2019

Несколько мыслей.
- sqlite - это не база для BigData.
- в клипе не будет смысла. А для сравнения картинок - поищи что такое perceptual hash. Статья была гдето.

Если зайти в вики по ключевому слову MNIST - можно найти наборы для распознавания рукописного ввода. И еще от самой странчки MNIST еще 2 ссылки идут на аналогичные тестовые сеты.

+UPD

https://en.wikipedia.org/wiki/MNIST_database
https://www.kaggle.com/datasets

Это стандартный туториал из книжки Изучаем Apache Spark. Там за 5 строчек кода ведется подсчет частоты слов.

Сам себе отвечаю.

collect_list() и explode()

- две функции которые делают нужные преобразования.

Но практически - моя постановка изменилась и сейчас сводится к работе с JSON-arrays которые лежат
в ячейках таблицы. Для них collect/explode мне не подошел. А подошли функции transform и cast.
Часть из них доступны начиная со Spark 3.1.1 и Databricks 9.1.x-LTS Runtime. Поэтому надо модернизироваться срочно.

Немного бухгалтерии. Если взять по максимуму.

Размер одной записи должен быть порядка 60 + 32 +8 = 100 символов (байт для простоты)

При 50 млрд записей объем хранимых данных должен быть порядка

50 000 000 000 * 100 = 5 000 000 000 000 = 5 триллионов байт.

В дисковом хранении это будет примерно 4.5 терабайта. Задачка для in-memory неподъемная. Нужен диск + мемори.

Если я там где-то ошибся в расчетах - то только в средних значениях. Если подставить не максимумы а среднее - то цифры будут поскромнее. Но в любом случае - многовастенько для покупки памяти.

Вобщем нужна дисковая БД которая встраивается в приложение. На требование менеджеров которые запретили использовать БД забейте. Они ничего не понимают. Делайте БД встраиваемую в приложение. В качестве таких (встраиваемых систем можно поробовать) LevelDb, BerkeleyDb, RocksDb. Они поддерживают индекс класса B+Tree и это даст возможность искать группы записей по одному ID. Для этого класса систем любую запись можно найти за 4-5 дисковых IOPS. Если какдый IOPS стоит 15 мс (это я так мерял свой собственный магнитный HDD) то любой поиск группы ключей для TTFB будет порядка 15 * 5 = 75 милисекунд. Ну если вы поставите SSD - то быстрее.

По поводу предложений хранить в файлах. До того как обсуждать это - надо уяснить требования по времени отклика. Сколько секунд вы согласны ждать - насколько можно и партицировать (или шардировать ваш файл).
В простейшем случае мы делим большой CSV файл на 512 partitions по хешу от ID и получаем соотв время фулл-скана всего файла поделенное на 512. Дальше - играйтесь с этим параметром партишенинга выводя его на доступный уровень отклика. Из недостатков - будет россыпь файлов. Надо почиать документацию на вашу файловую систему (ext4?) и тюнить ее так чтоб она не сдохла от такого числа inodes.

Я поддержу оба сценария. И с встраиваемой БД и с файлами. Но с БД надежнее т.к. есть транзакции а файлы у вас могут быть в крешнутом состоянии долго. И вы об этом ничего знать не будете.

По поводу Parquet. Не взлетит. Скорее всего индекс по данному типу файла - это совсем не то что вкладывают туда релационные системы. Обычно Parquet/Orc/Delta вкладывают в индекс смысл - отбрасывания тех полосок данных (stripes) которые бесполезны при чтении всего файла. Такой индес - обычно просто либо range-признак либо карта Блума. И в случае с range - дает эффект на сортированных данных. Для прочих - будет бесполезно т.к. фулл-скан все равно обеспечен. А если фулл-скан то зачем тогда вообще индекс.

Вобщем для дизайна архитектуры нам нужны цифры. Средние длины по колонкам. И я-бы еще запросил кардинальность по полю ID.

Посмотри Collaborative Filtering https://spark.apache.org/docs/latest/ml-collaborat...

Да ничего тут нельзя особо сделать. 10 секунд - холодный запуск группировки по 88 млн строк - это вполне себе хорошая цифра. Сомнительно что железо выдавит из себя больше. Ведь так или иначе нужно эти 88 млн пересчитать и даже будь это все в памяти - все равно обойти каждую ячейку. А дальше дело будет только хуже. Ведь табличка растет.

Есть техники микро-батчинга когда большая задача разбиватеся на порции. Например у тебя есть дневной партишен на 15 млн. Делишь его на часовые. Получается по 625 тыщ строк. Уже лучше.

Делаешь некую кумулятивную табличку. Типа

create table charge_cumulative(
  id long,
  cnt_cumulative long,
  delta_sum_cumulative long
)

Ну и на каждый микро-батч добавляешь к ней значения count, delta_sum. У тебя вроде удачно получается что можно только складывать.

Каналы в телеге можно глянуть

https://t.me/hadoopusers
https://t.me/apache_spark
https://t.me/devsp

Есть еще куча групп в ЛинекдИн и Фейсбуке. Но насколько я понимаю в РФ они зобанены.

Очень удивило наличие у вас вопроса по IRC-каналам. Удивлен что вообще кто-то это использует.

У гугла есть открытые учебные датасеты. Можно их посмотреть. Там и графика. И финансовая информация.

По поводу терабайтов в открытом доступе. Я не находил. В рамках студенческой дипломной работы трудно будет найти бесплатное облако или кластер который будет способен перемалывать терабайты за доступное время. Поэтому я-бы не ставил упор на объём.

Но можно найти гигабайты. Географические базы. https://www.openstreetmap.org/
Там есть данные по 40 гигабайт в XML формате. География - кстати очень интересная тема.
Особенно если данные географии накладывать на какие-то другие. Экология там... ковид. И прочее.

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

В идеале - реплицировать все данные в другую БД с другой геометрией таблиц или вообще в систему другого типа.

Любая современная биг-дата будет дешевле по стоимости владения по сравнению с DBMS.

В науке и технике используются логарифм и экспонента. Только надо подобрать коэффициенты.
Результат сохраняет монотонность. Но малые значения усиливаются а большие ослабляются.

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

Тоже сохраняет мототонность.