Forwarded from Andre
Руслан
Всем привет. Посоветуйте пожалуйста пару курсов или статей по проектированию хранилищ данных, построение правильных молей данных ( слои, интеграции, олап кубы)?
А что значит правильные модели?
Forwarded from Vadim
Руслан
Всем привет. Посоветуйте пожалуйста пару курсов или статей по проектированию хранилищ данных, построение правильных молей данных ( слои, интеграции, олап кубы)?
Литературы очень мало, причем, понятия различаются.
Попробуй начать с этого ресурса
https://dataengineering.wiki/Concepts/Concepts
Попробуй начать с этого ресурса
https://dataengineering.wiki/Concepts/Concepts
Data Engineering Wiki
Concepts - Data Engineering Wiki
Core Concepts How to build a data pipeline Data Modeling Batch vs Stream processing Indexing Relational vs Non-relational data OLTP vs OLAP Database ConceptsCAP Theorem Column-oriented Database Docum…
Forwarded from 🔋 Труба данных (Simon Osipov)
https://db.cs.cmu.edu/papers/2024/whatgoesaround-sigmodrec2024.pdf
What Goes Around Comes Around... And Around... или SQL Forever.
Удивительно, но я давно не читал пейперов, а тут вывалился случайно в ленте и я с удовольствием прочитал.
Как вы могли догадаться из названия, исследование касается того, что происходило с SQL / NoSQL и как первый так и не помер, не смотря на все попытки сделать no-code / low-code штуки, а второй не сильно прижился и почти все инструменты заимели поддержку SQL в том или ином виде.
В итоге:
- это либо выпиливают как MapReduce
- или это получило поддержку транзакций как у Mongo
- или можно писать как SQL запрос, например, у DynamoDB или Mongo
- было заменено на Redis и подобное
В общем, почитайте, чтиво небольшое, но оч прикольное.
@ohmydataengineer
What Goes Around Comes Around... And Around... или SQL Forever.
Удивительно, но я давно не читал пейперов, а тут вывалился случайно в ленте и я с удовольствием прочитал.
Как вы могли догадаться из названия, исследование касается того, что происходило с SQL / NoSQL и как первый так и не помер, не смотря на все попытки сделать no-code / low-code штуки, а второй не сильно прижился и почти все инструменты заимели поддержку SQL в том или ином виде.
В итоге:
- это либо выпиливают как MapReduce
- или это получило поддержку транзакций как у Mongo
- или можно писать как SQL запрос, например, у DynamoDB или Mongo
- было заменено на Redis и подобное
В общем, почитайте, чтиво небольшое, но оч прикольное.
@ohmydataengineer
Forwarded from 🔋 Труба данных (Simon Osipov)
Smart Data 2024
В этом году, к моему сожалению, не попадаю ни на оффлайн часть, нет возможности и поработать в ПК. Поэтому в этом году я - простой зритель.
За 2 года вне РФ пока не натыкался на хорошо организованную конференцию по DE, зато маркетинговых около-MDS - тонна.
Поэтому рад из чего выбирать: из интересующих меня докладов выбрал вот эти 6 как самые знакомые больные темы, но вроде бы должно еще появиться что-то в программе. Программа тут https://smartdataconf.ru/schedule/days/, билеты там же.
Еще из забавного: когда у BestDoctor не было никаких DWH и вообще ничего, я помогал их CTO и Head of Dev с DE роадмапом и первой вакансией дата-инженера. Как давно это было... 😂
P.S. как вы видите - у ссылок нет никаких UTM меток, меня никто не просит ничего рекламировать и ничего мне не платит (я знаю, что вы накидаете 💩 все равно). Промокоды - не знаю, есть ли, но если очень надо - я могу спросить, контакты остались. Пишите в личку тогда, но ничего гарантировать не могу.
@ohmydataengineer
В этом году, к моему сожалению, не попадаю ни на оффлайн часть, нет возможности и поработать в ПК. Поэтому в этом году я - простой зритель.
За 2 года вне РФ пока не натыкался на хорошо организованную конференцию по DE, зато маркетинговых около-MDS - тонна.
Поэтому рад из чего выбирать: из интересующих меня докладов выбрал вот эти 6 как самые знакомые больные темы, но вроде бы должно еще появиться что-то в программе. Программа тут https://smartdataconf.ru/schedule/days/, билеты там же.
Еще из забавного: когда у BestDoctor не было никаких DWH и вообще ничего, я помогал их CTO и Head of Dev с DE роадмапом и первой вакансией дата-инженера. Как давно это было... 😂
P.S. как вы видите - у ссылок нет никаких UTM меток, меня никто не просит ничего рекламировать и ничего мне не платит (я знаю, что вы накидаете 💩 все равно). Промокоды - не знаю, есть ли, но если очень надо - я могу спросить, контакты остались. Пишите в личку тогда, но ничего гарантировать не могу.
@ohmydataengineer
Forwarded from 🔋 Труба данных (Simon Osipov)
Forwarded from rzv Data Engineering
#видео #моксобес
Вернулся из отпуска не с пустыми руками. Четвёртый выпуск серии мок-собесов на youtube
-> Ссылка на видео
Видео-половинка с разбором и обратной связью уже на бусти boosty.to/rzv_de
(скоро должна допроцесситься, прошлая часть тоже доедет сегодня-завтра)
В этот раз тоже пожёстче спросил по теории, и кандидат отлично сдержал удар.
Как и раньше, запрашиваю у тебя жёсткую обратную связь по тому, что стоит улучшить.
Вернулся из отпуска не с пустыми руками. Четвёртый выпуск серии мок-собесов на youtube
-> Ссылка на видео
Видео-половинка с разбором и обратной связью уже на бусти boosty.to/rzv_de
(скоро должна допроцесситься, прошлая часть тоже доедет сегодня-завтра)
В этот раз тоже пожёстче спросил по теории, и кандидат отлично сдержал удар.
Как и раньше, запрашиваю у тебя жёсткую обратную связь по тому, что стоит улучшить.
YouTube
Мок-собеседование на middle+ Data Engineer S1E4 | rzv_de | Jul 2024
Погружаемся в роли интервьюера и кандидата на час, плотная получасовая обратная связь уже выложена на бусти.
https://boosty.to/rzv_de
https://boosty.to/rzv_de
https://boosty.to/rzv_de
Я не представляю компанию из интервью, вакансия выбрана кандидатом для…
https://boosty.to/rzv_de
https://boosty.to/rzv_de
https://boosty.to/rzv_de
Я не представляю компанию из интервью, вакансия выбрана кандидатом для…
Forwarded from rzv Data Engineering
#реклама
С улыбкой делюсь перспективным каналом по DE с тобой.
Вспомнил, с каким трепетом сам писал первые посты (кстати, рекомендую пролистать наверх тем, кто недавно на канале).
"""
✋🏻 Всем привет, меня зовут Дмитрий, я работаю дата инженером.
Мне крайне интересна эта область, поскольку я очень любознательный.
В своем недавно созданном канале пишу про инженерию данных, рабочие кейсы и свои мысли.
Я учусь, поэтому могу где-то допускать ошибки.
Канал будет интересен и новичкам, и средним по уровню специалистам.
Присоединяйтесь, комментируйте, давайте обратную связь. Надеюсь, материал будет для вас полезным.
📝 Блог https://t.iss.one/kuzmin_dmitry91
"""
С улыбкой делюсь перспективным каналом по DE с тобой.
Вспомнил, с каким трепетом сам писал первые посты (кстати, рекомендую пролистать наверх тем, кто недавно на канале).
"""
✋🏻 Всем привет, меня зовут Дмитрий, я работаю дата инженером.
Мне крайне интересна эта область, поскольку я очень любознательный.
В своем недавно созданном канале пишу про инженерию данных, рабочие кейсы и свои мысли.
Я учусь, поэтому могу где-то допускать ошибки.
Канал будет интересен и новичкам, и средним по уровню специалистам.
Присоединяйтесь, комментируйте, давайте обратную связь. Надеюсь, материал будет для вас полезным.
📝 Блог https://t.iss.one/kuzmin_dmitry91
"""
Telegram
Дмитрий Кузьмин | Инженерия данных
Путь Data engineer от Junior до Lead.
Делюсь мыслями, рабочими кейсами, обучением. Блог для junior - middle DE.
Мой профиль: @dim4eg91
Сайт: https://kuzmin-dmitry.ru
Практикум Data engineer: https://kuzmin-dmitry.ru/de_practicum
Делюсь мыслями, рабочими кейсами, обучением. Блог для junior - middle DE.
Мой профиль: @dim4eg91
Сайт: https://kuzmin-dmitry.ru
Практикум Data engineer: https://kuzmin-dmitry.ru/de_practicum
Forwarded from rzv Data Engineering
#вести_с_полей
Как DE может решать задачи CI/CD 1/3
🔸 Представь, что есть некоторый сервис интеграции с источниками данных, который можно конфигурировать через JSON по API. И ещё у сервиса есть визуальный интерфейс, через который эти конфиги можно задавать напрямую, в обход гита, что и делали последние несколько месяцев, потому что так быстрее.
🔸 Какие минусы у ручного подхода? Нет истории изменений, проверки перед применением очередной версии конфига, ещё и параметры подключения к сервисам (credentials) могут храниться в обычном текстовом виде. Безопасники не будут дружить с такими дата инженерами. И, если контур один, эти изменения применяются напрямую на проде, что редко добавляет стабильности работе системы.
🔸 Такие проблемы можно решить через CI/CD: CI -- непрерывная интеграция (continuous integration), CD -- непрерывная доставка (delivery) или развёртывание (deploy). Объединяет и упрощает совместные изменения в команде и унифицирует способ "применения" изменений на разных контурах (дев, тест, прод). Для дев/тест среды обычно есть тесты перед авто-развёртыванием, а для для прода часто выбирают Continuous Delivery -- подготовку поставки, которую можно развернуть по нажатию кнопки человеком. Например, через approve pull request'a.
Как DE может решать задачи CI/CD 1/3
🔸 Представь, что есть некоторый сервис интеграции с источниками данных, который можно конфигурировать через JSON по API. И ещё у сервиса есть визуальный интерфейс, через который эти конфиги можно задавать напрямую, в обход гита, что и делали последние несколько месяцев, потому что так быстрее.
🔸 Какие минусы у ручного подхода? Нет истории изменений, проверки перед применением очередной версии конфига, ещё и параметры подключения к сервисам (credentials) могут храниться в обычном текстовом виде. Безопасники не будут дружить с такими дата инженерами. И, если контур один, эти изменения применяются напрямую на проде, что редко добавляет стабильности работе системы.
🔸 Такие проблемы можно решить через CI/CD: CI -- непрерывная интеграция (continuous integration), CD -- непрерывная доставка (delivery) или развёртывание (deploy). Объединяет и упрощает совместные изменения в команде и унифицирует способ "применения" изменений на разных контурах (дев, тест, прод). Для дев/тест среды обычно есть тесты перед авто-развёртыванием, а для для прода часто выбирают Continuous Delivery -- подготовку поставки, которую можно развернуть по нажатию кнопки человеком. Например, через approve pull request'a.
Forwarded from rzv Data Engineering
Как DE может решать задачи CI/CD 2/3
🔸 Итак, реализация. В 90+% случаев это или Gitlab CI, или Github Workflows, или Atlassian Bamboo (в дополнение к bitbucket). Код workflow (или pipeline) задаётся в YAML файле, где определяются атомарные действия (шаги, степы) и группы шагов (джобы). Внутри обычно встретишь или много bash кода, или готовые "actions" из маркетплейса (примерно как операторы в airflow).
🔸 У каждого шага и джоба есть статус выполнения, input, output, к которым можно обращаться в других шагах и джобах. Можно вешать условия на выполнение -- например, делать деплой только после успешного выполнения всех тестов.
🔸 Также удобно выносить часть кода в переиспользуемые действия, обращаясь к ним как к степам из маркетплейса. И, что мне как питонисту близко, -- выносить код взаимодействия с сервисом в набор .py скриптов. Поэтому в дополнение к главному YAML может быть ещё директория в гите, где лежат тесты и код деплоя, общающиеся с сервисом через API. А workflow склеивает это воедино и задаёт логику перехода между шагами. И отчёты формирует для чтения статуса людьми.
🔸 Итак, реализация. В 90+% случаев это или Gitlab CI, или Github Workflows, или Atlassian Bamboo (в дополнение к bitbucket). Код workflow (или pipeline) задаётся в YAML файле, где определяются атомарные действия (шаги, степы) и группы шагов (джобы). Внутри обычно встретишь или много bash кода, или готовые "actions" из маркетплейса (примерно как операторы в airflow).
🔸 У каждого шага и джоба есть статус выполнения, input, output, к которым можно обращаться в других шагах и джобах. Можно вешать условия на выполнение -- например, делать деплой только после успешного выполнения всех тестов.
🔸 Также удобно выносить часть кода в переиспользуемые действия, обращаясь к ним как к степам из маркетплейса. И, что мне как питонисту близко, -- выносить код взаимодействия с сервисом в набор .py скриптов. Поэтому в дополнение к главному YAML может быть ещё директория в гите, где лежат тесты и код деплоя, общающиеся с сервисом через API. А workflow склеивает это воедино и задаёт логику перехода между шагами. И отчёты формирует для чтения статуса людьми.
Forwarded from rzv Data Engineering
Как DE может решать задачи CI/CD 3/3
🔸 Первое время немного неуклюже выглядит интеграция python и bash. Для этого нужно пробрасывать параметры из workflow в python скрипт и передавать результат работы обратно, но GPT помогают с нюансами Bash, и со временем картинка выстраивается. Кстати, я недавно перешёл на Claude Sonet, пока нравится больше, чем Gemini. Приятно, этот инструмент становится привычным, и на дейликах разработчики больше не стесняются говорить о парной работе с таким помощником.
🔸 Немного про разделение ответственности. В компаниях, где я работал, обычно было так: девопсы поднимают сервисы в ВМ или в контейнерах, а как с ними будут работать DE -- дело последних. Например, пайплайн по перезапуску упавшего Airflow скорее напишет DevOps. Пайплайн по доставке дагов из гита и тесты для проверок кода скорее будут писать DE.
❕ Пиши в комментах, с какими нюансами CI/CD столкнули рабочие задачи тебя. Или пока ещё дикий запад и всё накатывается руками?
🔸 Первое время немного неуклюже выглядит интеграция python и bash. Для этого нужно пробрасывать параметры из workflow в python скрипт и передавать результат работы обратно, но GPT помогают с нюансами Bash, и со временем картинка выстраивается. Кстати, я недавно перешёл на Claude Sonet, пока нравится больше, чем Gemini. Приятно, этот инструмент становится привычным, и на дейликах разработчики больше не стесняются говорить о парной работе с таким помощником.
🔸 Немного про разделение ответственности. В компаниях, где я работал, обычно было так: девопсы поднимают сервисы в ВМ или в контейнерах, а как с ними будут работать DE -- дело последних. Например, пайплайн по перезапуску упавшего Airflow скорее напишет DevOps. Пайплайн по доставке дагов из гита и тесты для проверок кода скорее будут писать DE.
❕ Пиши в комментах, с какими нюансами CI/CD столкнули рабочие задачи тебя. Или пока ещё дикий запад и всё накатывается руками?
Forwarded from AI with Parissan 🤖🦾 (Pariss)
Data Engineering Cookbook.pdf
1.8 MB
Forwarded from Ivan Begtin (Ivan Begtin)
К вопросу о 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
В работе в 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
Forwarded from AI with Parissan 🤖🦾 (Pariss)
𝗣𝘆𝘁𝗵𝗼𝗻_𝗰𝗹𝗲𝗮𝗻_𝗖𝗼𝗱𝗲✅.pdf
601.2 KB
✅ Python Clean Code book 🚀🧨🚀🧨🚀🧨🚀
#python #programming #projecs #datascience #artificialinteligence
AIwithParissan | AI Tutorials
#python #programming #projecs #datascience #artificialinteligence
AIwithParissan | AI Tutorials
Think Python.pdf
857.8 KB
✅Python book 💥
✅ آموزش پایتون 💥💥
#python #programming #projecs #datascience
AIwithParissan | AI Tutorials
✅ آموزش پایتون 💥💥
#python #programming #projecs #datascience
AIwithParissan | AI Tutorials