Forwarded from Igor Melnikov
Часть вторая.
Смотрю БД. В БД есть несколько основных таблиц фактов, гигантских размеров. Все несекционированные.
Занимают 90% объема всей БД. В общем обычная история.
Первым делом, как это было всегда в оракловых проектах , предлагаю секционировать эти таблицы по месяцам.
Начинается нехилый проект по секционированию. В downtime, конечно, перелив не укладывается - пишу скрипты перелива данных в секции. Потом выясняется, что данные меняются задним числом - поэтому пришлось на исходные таблицы навесить DML-триггеры, которые фиксируют факт изменения строки в отдельную лог- таблицу. Соответственно, в процедуре перелива обрабатываю данные этой лог таблицы.
Потом была проблема в том, что перелив одной операции в партицию (INSERT SELECT ... WHERE sale_date='month_year') падал то по таймауту, то по ошибке PG. PG очень не любит длинные транзакции, поэтому пришлось мелкими порциями строки переливать в партицию (cекционирование по месяцам).
Ну и конечно пришлось увеличивать дисковое пространство в облаке - объем БД увеличился. Смутило, что объем стал не в два раза больше, а в четыре раза (4). Почему-то в суматохе не обратил на это внимание.
В общем все позади, и в выходные ночью доливаю последние изменения, обрабатываю лог-таблицы и переключаю на новые таблицы: исходные таблицы переименовываю, а секционированные переименовываю в имя исходной таблицы).
На следующий день начался кошмар, который продолжался в течении пары недель.
Продолжение в третьей части ...
Смотрю БД. В БД есть несколько основных таблиц фактов, гигантских размеров. Все несекционированные.
Занимают 90% объема всей БД. В общем обычная история.
Первым делом, как это было всегда в оракловых проектах , предлагаю секционировать эти таблицы по месяцам.
Начинается нехилый проект по секционированию. В downtime, конечно, перелив не укладывается - пишу скрипты перелива данных в секции. Потом выясняется, что данные меняются задним числом - поэтому пришлось на исходные таблицы навесить DML-триггеры, которые фиксируют факт изменения строки в отдельную лог- таблицу. Соответственно, в процедуре перелива обрабатываю данные этой лог таблицы.
Потом была проблема в том, что перелив одной операции в партицию (INSERT SELECT ... WHERE sale_date='month_year') падал то по таймауту, то по ошибке PG. PG очень не любит длинные транзакции, поэтому пришлось мелкими порциями строки переливать в партицию (cекционирование по месяцам).
Ну и конечно пришлось увеличивать дисковое пространство в облаке - объем БД увеличился. Смутило, что объем стал не в два раза больше, а в четыре раза (4). Почему-то в суматохе не обратил на это внимание.
В общем все позади, и в выходные ночью доливаю последние изменения, обрабатываю лог-таблицы и переключаю на новые таблицы: исходные таблицы переименовываю, а секционированные переименовываю в имя исходной таблицы).
На следующий день начался кошмар, который продолжался в течении пары недель.
Продолжение в третьей части ...
Forwarded from Руслан
Всем привет. Посоветуйте пожалуйста пару курсов или статей по проектированию хранилищ данных, построение правильных молей данных ( слои, интеграции, олап кубы)?
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