🔥Data Engineering Cookbook 🔥

#dataengineer #bigdata #cloudcomputing


AIwithParissan | AI Tutorials

К вопросу о poor man data engineering, как обрабатывать данные в условиях ограниченных ресурсов с минимальными нагрузками на диск и на оперативную память, в первую очередь.

В работе в Dateno есть задача по добавлению стат. индикаторов в основной индекс и расширение фасетов на данными о частоте обновления индикаторов и временном промежутке который он охватывает (год начала и год окончания). Не у всех датасетов такие метаданные есть и есть особенность датасетов Европейского центрального банка (ECB) в том что для массовой выгрузки доступны сами данные, но не метаданные. Хотя обычно наоборот. А в данном случае можно скачать все значения, а метаданные из них надо извлечь.

Эти значения публикуются в виде коллекции из 108 CSV файлов общим объёмом в 93GB. Это не то чтобы много, но много для статистики и для обработки на десктопе. Первая мысль которая возникает, а не уменьшить ли эти данные в объёме. Можно их сжать, но ещё эффективнее преобразовать в parquet. После преобразования они занимают 664 MB. Это 0,7% от изначального объёма, итого сжатие в 140 раз! Такая эффективность редкость, обычно сжатие в 5-15 раз, но здесь накладывается эффект колоночного сжатия поскольку данные ECB денормализованные, эффективность хранения там уступает полноте публикации и простоте раскрытия.

Далее обработка. Чтобы получить метаданные каждого индикатора надо:
1. Получить список уникальных идентификаторов индикаторов
2. Для каждого ключа сделать запрос одной записи для извлечения метаданных
3. Получить минимальное и максимальное значения временного периода
4. Извлечь год из минимального и максимального значения если период не равен году.

Итого 3 запроса, которые, наверняка, можно было бы оптимизировать до 2-х и которые можно делать напрямую к файлам parquet. Однако ситуация осложняется тем что эти файлы parquet хотя и хорошо сжаты, но могут содержать до 570+ тысяч индикаторов, как это, например, происходит с датасетом Securities Issues Statistics, который в оригинале составляет 19GB CSV файл и содержит 30 миллионов строк.

При работе с этим датасетом, даже после преобразования в parquet, DuckDB "съедает" до 15GB RAM и работает, хотя и быстро, но не так быстро как хотелось бы.

Варианты решения:
1. Попробовать преобразовать данные в базу DuckDB, построить индексы и так обрабатывать. Минус: резко увеличивается объём хранения данных, не увеличивается скорость обработки.
2. Попробовать нормализовать данные и извлекать метаданные из нормализованных баз. Минус: время на преобразование многократно больше времени сбора метаданных из существующих parquet файлов, а также у разных датасетов разная схема данных и требуется потратить больше времени на их анализ.

Варианты с тем чтобы загрузить в какую-то другую СУБД или даже не рассматривались поскольку задача именно в обработке на среднемощном десктопе/ноутбуке и без резкого роста объёмов хранения.

Итоговое решение оказалось очень простым. Специфика запросов в том что они полностью локализованы внутри данных конкретного индикатора.
Но, так повезло, что в этих датасетах индикаторы разделены по группам являющихся странами или территориями, от 8 до 33 в одном датасете и разделять можно по ним. Данные отдельных индикаторов полностью попадают в один из разделённых файлов. И, одна из фишек DuckDB - это очень дешёвое разделение данных с точки зрения скорости и нагрузки на память. До обработки большого датасета через серию COPY TO операций из него создаются десятки меньших .parquet файлов каждый из которых обрабатывается по отдельности.

Итого:
- средняя скорость однопоточной обработки достигает 78 индикаторов в секунду
- потребление RAM не превышает 100MB, а в среднем держится менее 50MB
- потребление диска +664MB, теперь не в 140 раз меньше чем оригинальные CSV файлы, а только в 70 раз, но всё ещё очень и очень мало.

Понятно что перенеся всё это на серверную инфраструктуру, в несколько потоков и тд. можно многократно ускорить обработку данных, но и так с помощью DuckDB конвейеры данных можно запускать на очень дешёвом железе и получать приемлемый результат.

#data #thoughts #tech #duckdb #dataengineering

Презентация sqlwagon новой книги Azure Data Factory Cookbook 2nd edition. (На английском, это вообще то будет для Linkedin)

Сегодня посмотрим на компоненты хранилища данных.

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

Хранилище данных объединяет все технические компоненты в одной системе.

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


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

Это приводило к множеству проблем. Масштабирование становилось большой проблемой, так как объемы данных быстро росли, а количество и интенсивность нагрузок росло.

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

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

Хранилище данных до сих пор является отличным решением для построения аналитического решения.

Минису все известны:
- Поддержка только SQL
- Вы платите за compute и storage вместе (Snowflake и тп это lakehouse и о нем будет позже)
- Сложно использовать для ML, так как данные нужно выгружать
- У вас schema on write (то есть у вас таблица создана и вы в нее уже пишите как есть)
- Не очень удобно для streaming/real time аналитики, обычно это batch - раз в час, раз в сутки
- Это Vendor Lock

В след посте рассмотрим озеро данных.

Источник: https://www.oreilly.com/library/view/apache-iceberg-the/9781098148614/ch01.html

PS Судя по прошлым комментариям, я рад что ребята в Авито Тех тоже прочитали книгу и поделились знаниями со своей аудиторией🙃

В Surfalytics я попросил всех прочитать 1ю главу и понять, так как очень важно понимать разницу между DW/Data Lake/Lake House и знать их особенности.

Ребята из DevCrowd впервые проводят большое исследование специалистов, работающих в направлениях DS/ML/AI:

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

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

👉Пройти опрос

Посмотреть другие исследования проекта

PS не реклама, просто дружеский пост.

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

- Командная строка (CLI), та самая, которая у вас могла быть в школе на информатик в CMD. Сейчас если у вас MacOS, то Zsh с приятными плагинами Oh My Zsh, если Windows, то сразу ставьте Ubuntu WSL.

- Среда разработки (IDE), самый лучший вариант это VSCode. Бесплатно и есть плагины для всего. Отлично подойдет, чтоб редактировать файлы, писать код и запускать окошко с командной строкой.

- Git система. Самая популярная и бесплатная это GitHub. Создайте себе аккаунт и каждый день делайте туда commit, через branch, чтобы потом сделать Pull Request. А еще вы можете бесплатно запостить свой сайт про себя, использую GitHub Pages.

- Markdown - очень просто текстовый язык. Используйте его, чтобы создавать в каждой папке в вашем репозитории GitHub файлик readme.md и там описывайте шаги, храните код. Намного полезней, чем Google Doc. Конечно не так удобно как Notion, но пользы лучше. И в конце-концов ваш GitHub профайл, это ваш актив.

- Контейнеры, используйте Docker File, потренируйтесь создавать к `DockerFile и потом к нему подключаться.

Как правило все эти навыки не обязательны для аналитиков и BI разработчиков. Но это будет ваше преимущество и откроет вам много возможностей в будущем. А так же вы сможете быстро “въехать” в существующие проекты и понять, что где хранится и для чего делает, но и разговаривать на одном языке с инженерами. Да и быстрей станете сами инженером, ведь им платят больше!

PS Обо всем этом я рассказывал в 0м модуле Surfalytics (на английском) с упражнениями и примерами. В 1м модуле я рассказывал про роли и roadmap. А сейчас уже записываю 2й модуль и во 2м уроке мы использовали SQLite, Postgres на локальной машине, а потом тоже самое но в Docker контейнере.

Возможно вам будет сложно на английском, но мой английский с русским акцентом вам должен быть понятен, и сам навык английского очень важен, я еще в 2010 году читал Kimbal на английском и различные блоги и документацию. Поэтому Surfalytics для вас как бесплатный сериальчик на английском с субтитрами. А если прям хотите каждый день практиковаться, приходите в Surfalytics сообщество.

PPS еще есть замечательная книга Missing Readme, которая на пальцах рассказывает, что зачем для junior software engineer.

Подписывайтесь на YouTube, это мне поможет, я верю, что материал хороший, но сложно сейчас пробиться с 0, поэтому like, follow очень помогает!

Как подготовиться к собеседованию на инженера данных

Подготовка к интервью на позицию инженера данных может быть сложной задачей. Этот пост поможет вам изучить ключевые структуры данных и алгоритмы, а также типичные вопросы на собеседованиях. Узнайте, как улучшить свои знания и уверенно пройти собеседование. Эффективные Методы Поиска и Алгоритмы для Инженеров Данных

В статье рассматриваются популярные алгоритмы поиска, такие как глубинный и ширинный поиск (DFS и BFS), а также бинарный поиск. Описаны их итеративные и рекурсивные версии. Статья полезна для подготовки к интервью по данным профессиям.

Читать подробнее

#en

@big_data_analysis | Другие наши каналы

Unified Data Architecture - еще один термин, обозначающий примерно то же самое - консолидация данных для принятия бизнес решений и с недавних пор для использования данных в машинном обучении. Другими словами синоним слова “хранилище данных”. Но в данном контексте это уже может быть что угодно - реляционная база данных, озеро данных на Hadoop или микс хранилища и озера данных, как например Snowflake или Redshift + Redshift Spectrum. Очень хорошая диаграмма, на которой по слоям все расписано от источника до отчета.