Псевдокод - прием инженера.
🔍 Дата инженеры много работают с кодом. В этом посте я хочу поделиться простым лайф хаком, который мне не раз сохранил нервы и время.
💬 А продумывать помогает очень простой и удобный прием - псевдокод.
Псевдокод - описание простым человеческим языком конкретных шагов и действий, которые должны быть выполнены, чтобы мы получили желаемое поведение кода (метода, sql запроса). По сути мы отбрасываем синтаксис языка программирования и пишем с синтаксисом естественного языка 😉
❗️ Не путать с докстринг (docstrings). Докситринг для клиентов метода/класса - описание как использовать метод и для чего он нужен. А псевдокод для разработчиков - отражает конкретные действия в коде, то есть то как именно выполняется задача.
Вот пример псевдокода в методе класса на пайтоне. Хотя можно использовать везде и в sql запросах тоже.
📝 Любой код всего лишь техническая реализация какого-то алгоритма/логики, то есть до того как написать код мы знаем зачем нам он нам нужен.
Псевдокод позволяет:
🔸 продумать цепочку действий от начала до конца не отвлекаясь на синтаксис языка
🔸 увидеть логические противоречия до того как вы уже написали половину кода.
🔸 увидеть допущения и спорные моменты, которые были не очевидны
🔸 увидеть плюсы и минусы разных вариантов, оценить их потенциальное быстродейтсвие, выбрать лучший
🔸 делегировать написание самого кода кому-то (так еще не пробовал, но идея хорошая. Сюда же входит использование AI. А что? Чем псевдокод не промпт для chat gpt? 🤔)
📎 Псевдокод имеет еще один очень приятный и важный бонус. После завершения работы сохраните его - это же готовая документация к методу! Показывает как он работает и какие были рассмотрены варианты. Вы сами или кто-то другой сможете легко разобраться в коде, когда откроете код через несколько месяцев.
Так и получилось в моем недавнем кейсе. Метод стал медленно работать. Я прочитал псевдокод, понял работу метода, понял в каком месте есть потенциальная проблема, затем внес изменения сначала в псевдокод, убедился что логически это будет работать, затем легко нашел нужное место в коде и быстро внес изменения. Готово! 5 минут потратил, закрыл и забыл еще на месяц, на полгода или больше, пока логика снова не поменяется. 🙌
‼️ И еще помните! Комментарий, который не соответствует коду хуже, чем отсутствующий комментарий.
Попроси джуна и он сразу пойдет писать код, попроси сеньора и он сначала продумает решение от начала до конца (может для нескольких вариантов) и только потом напишет код.
Псевдокод - описание простым человеческим языком конкретных шагов и действий, которые должны быть выполнены, чтобы мы получили желаемое поведение кода (метода, sql запроса). По сути мы отбрасываем синтаксис языка программирования и пишем с синтаксисом естественного языка 😉
Вот пример псевдокода в методе класса на пайтоне. Хотя можно использовать везде и в sql запросах тоже.
def set_lead_id(self, *, crm_uri, calls_storage_uri):
"""
Performs actions to enrich calls data by lead_id and project_key
"""
# pseudocode
# Option 1:
# group calls in the same time range
# (half an hour) in order to reduce count of requests to crm
# reduce calls by caller number
# execute as many requests to crm as groups passing time range and phone. get lead_id, project.
# assign lead_id and project to every call in the initial calls list matching by phone.
# The assumption: all calls with the same phone number within a half an hour will have the same lead_id
# Option 2:
# get calls without lead within time range
# prepare request for every call with time range as call datetime +/- 2 minutes
# combine requests with UNION clause
# execute combined request to crm. get lead_id, project.
# push data to calls table
# Use option 2
# дальше пишем код, используя вариант 2
Псевдокод позволяет:
Так и получилось в моем недавнем кейсе. Метод стал медленно работать. Я прочитал псевдокод, понял работу метода, понял в каком месте есть потенциальная проблема, затем внес изменения сначала в псевдокод, убедился что логически это будет работать, затем легко нашел нужное место в коде и быстро внес изменения. Готово! 5 минут потратил, закрыл и забыл еще на месяц, на полгода или больше, пока логика снова не поменяется. 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👍4
“Правильность” данных
Осторожно! Душный пост! 🧐
Я заметил, что в общении с коллегами часто использую словосочетание - консистентность данных. Обычно все это понимают как некая “правильность” данных и в общем-то так и есть, но нам как инженерам, ответственным за эту правильность, стоит задуматься над тем что это такое. ☝️
Можно найти по этой теме с десяток понятий в разных публикациях типа consistency, integrity, quality, correctness, validity и тд. Определения этих понятий смешаны: где-то используются как синонимы, где-то имеют отдельные смыслы. И я вряд ли могу внести тут полную ясность, но свое мнение в общую массу мнений закину 😁
Я бы выделил как минимум согласованность (consistency) и целостность (integrity).
📝 Согласованность - состояние, при котором все копии данных одинаковы во всех связанных приложениях, базах данных и тд. (сайт IBM).
Для дата инженера это значит, что данные в хранилище (DWH или Data mart) или в отчёте не должны противоречить источникам данных.
🔖 Организовывая трансфер данных и выполняя трансформации, дата инженер должен быть аккуратен и безпристрастен. Есть риск увлечься! Нельзя допустить вольных изменений для красоты или для соответствия чьим-то личным ожиданиям и тд. Все операции в коде должны быть подкреплены бизнес логикой или логикой трансформации, то есть по каждой строчке можно обоснованно ответить на вопрос “почему так?”
Достаточно абстрактная штука и
даже не знаю как это контролировать и гарантировать. На ум приходит только внимательность дата инженера и проверка старшими товарищами.
📝 Целостность - состояние, при котором данные записаны именно в том виде, в котором было задумано. (В википедии неплохо написано). Такое определение очень широкое. С точки зрения дата инженера то, как “задумано” - это модель данных. То есть данные целостносты, когда они соответствуют модели данных (пост данные без модели - деньги на ветер).
🔖 Тут у меня хорошие новости. 😋 Соответствие модели можно и нужно гарантировать технически! Модель можно превратить в набор правил/требований к сущностям, к их свойствам, их типам, обязательности, наличии связей между сущностями и тд.
🤔 Подумаем про контроль. С архитектурный точки зрения должен быть некий “участник”, который возьмёт на себя эту функцию и ответственность гарантировать соответствие модели или целостность. Это может быть приложение, сервис, микросервис, непосредственно база данных, какой-то подключаемый инструмент и тд. Тут главное сделать так, чтобы был только один ответственный - одно место в архитектуре, которое держит необходимую для этого логику.
©️ Держа в уме согласованность с источниками и технически гарантируя соответствие данных модели, вы предоставите бизнесу достаточно “правильные” данные. 🙌 Хотя это конечно не все...
Осторожно! Душный пост! 🧐
Я заметил, что в общении с коллегами часто использую словосочетание - консистентность данных. Обычно все это понимают как некая “правильность” данных и в общем-то так и есть, но нам как инженерам, ответственным за эту правильность, стоит задуматься над тем что это такое. ☝️
Можно найти по этой теме с десяток понятий в разных публикациях типа consistency, integrity, quality, correctness, validity и тд. Определения этих понятий смешаны: где-то используются как синонимы, где-то имеют отдельные смыслы. И я вряд ли могу внести тут полную ясность, но свое мнение в общую массу мнений закину 😁
Я бы выделил как минимум согласованность (consistency) и целостность (integrity).
Для дата инженера это значит, что данные в хранилище (DWH или Data mart) или в отчёте не должны противоречить источникам данных.
Достаточно абстрактная штука и
даже не знаю как это контролировать и гарантировать. На ум приходит только внимательность дата инженера и проверка старшими товарищами.
🤔 Подумаем про контроль. С архитектурный точки зрения должен быть некий “участник”, который возьмёт на себя эту функцию и ответственность гарантировать соответствие модели или целостность. Это может быть приложение, сервис, микросервис, непосредственно база данных, какой-то подключаемый инструмент и тд. Тут главное сделать так, чтобы был только один ответственный - одно место в архитектуре, которое держит необходимую для этого логику.
Please open Telegram to view this post
VIEW IN TELEGRAM
Ibm
Data Consistency vs Data Integrity: Similarities and Differences | IBM
Data consistency refers to the state of data in which all copies or instances are the same across all systems and databases. Data integrity refers to the accuracy, completeness, and consistency of data throughout its life cycle.
🔥8👍4
Сюрпризы от базы данных приложения
База данных какого-то приложения обычный источник данных для дата инженера. Иногда приложение и его база может приподносить сюрпризы, усложняя нам жизнь.
Функция базы данных приложения - поддерживать работу приложения.
Схема в ней оптимизирована именно для этой задачи. В ней созданы те или иные таблицы только для того чтобы выполнять нужные задачи. В таких базах обычно дохрена таблиц с множеством связей в основном технических - нормализация для скорости CRUD операций 🚀. Данные одной бизнес сущности могут быть размазаны по множеству таблиц или же наоборот несколько бизнес понятий "впихнули" в одну таблицу. И все это нормально, потому что, повторюсь, это операционная база, а не аналитическая. Поэтому база данных приложения плохой источник правды для бизнеса и поэтому существуют ETL процессы с необходимой T - трансформацией.
Трансформация - изменение модели данных. В данном случае из модели базы данных приложения в модель бизнес сущностей.
Однако несмотря на все те нюансы выше, я стараюсь не "разрывать" аналитическую базу и базу приложения слишком сильно - обычно удается выявить какие-то основные таблицы и сохранять праймери кей из них как идентификаторы бизнес сущностей, что упрощает обновление данных в аналитической базе, упрощает проверку данных, сохраняет прямую связь для проверки "глазами" для особо мнительных пользователей 😇.
Но вот я недавно столкнулся ещё с одним неочевиднвм поведением, которое изменило мой взгляд на операционные базы ещё сильнее - стало ещё больше настороженности по отношению к ним. Собственно поэтому я и решил написать этот пост.
Приложение может удалять записи, описывающие бизнес сущность и пересоздавать их снова, правильно, с генерированием нового идентификатора. Ключевой момент здесь: с точки зрения бизнеса сущность та же! Просто приложению в каком-то сценарии было проще удалить запись и создать новую. То есть запись в базе данных новая, а бизнес сущность та же. Для приложения это норм, а вот для нашей аналитической базы возникают проблемы при наследовании идентификаторов из операционной базы. Мы уже не можем полагаться на такие идентификаторы и должны все усложнять выбирая другой уникальный ключ для связи.🥲
База данных какого-то приложения обычный источник данных для дата инженера. Иногда приложение и его база может приподносить сюрпризы, усложняя нам жизнь.
Функция базы данных приложения - поддерживать работу приложения.
Схема в ней оптимизирована именно для этой задачи. В ней созданы те или иные таблицы только для того чтобы выполнять нужные задачи. В таких базах обычно дохрена таблиц с множеством связей в основном технических - нормализация для скорости CRUD операций 🚀. Данные одной бизнес сущности могут быть размазаны по множеству таблиц или же наоборот несколько бизнес понятий "впихнули" в одну таблицу. И все это нормально, потому что, повторюсь, это операционная база, а не аналитическая. Поэтому база данных приложения плохой источник правды для бизнеса и поэтому существуют ETL процессы с необходимой T - трансформацией.
Трансформация - изменение модели данных. В данном случае из модели базы данных приложения в модель бизнес сущностей.
Однако несмотря на все те нюансы выше, я стараюсь не "разрывать" аналитическую базу и базу приложения слишком сильно - обычно удается выявить какие-то основные таблицы и сохранять праймери кей из них как идентификаторы бизнес сущностей, что упрощает обновление данных в аналитической базе, упрощает проверку данных, сохраняет прямую связь для проверки "глазами" для особо мнительных пользователей 😇.
Но вот я недавно столкнулся ещё с одним неочевиднвм поведением, которое изменило мой взгляд на операционные базы ещё сильнее - стало ещё больше настороженности по отношению к ним. Собственно поэтому я и решил написать этот пост.
Приложение может удалять записи, описывающие бизнес сущность и пересоздавать их снова, правильно, с генерированием нового идентификатора. Ключевой момент здесь: с точки зрения бизнеса сущность та же! Просто приложению в каком-то сценарии было проще удалить запись и создать новую. То есть запись в базе данных новая, а бизнес сущность та же. Для приложения это норм, а вот для нашей аналитической базы возникают проблемы при наследовании идентификаторов из операционной базы. Мы уже не можем полагаться на такие идентификаторы и должны все усложнять выбирая другой уникальный ключ для связи.🥲
👍4🔥2
Кайфанул от PostgreSQL Extensions
Тут я ловлю себя на мысли, что реально кайфанул от возможностей, которые дают расширения 😄
Читал я вот эту статью. В начале автор пишет:
Расширения PostgreSQL - это лучшая часть PostgreSQL. Они добавляют функционал в вашу базу данных, изменяя и улучшая выполнение процессов.
Дальше в статье перечислены некоторые расширения с примерами. Мне особенно понравились вот эти
🔸 pg_stat_statements - отслеживает статистику запросов выполняемых базой данных. Дает детальную информацию о плане выполнения. Поможет дебажить запросы, выявлять медленные запросы.
🔸 pg_partman - помогает управлять партициями. Пожалуй самое известное расширение.
🔸 postgres_fdw - позволяет настроить прокси подключение к другой PostgreSQL базе и запрашивать данные из нее так как будто эти данные лежат тут же в обычной таблице.
©️ Я со своей командой сейчас активно строим DWH на PostgreSQL и мы обязательно попробуем эти и другие расширения.👍
Я - сижу и читаю что-то в телефоне с довольным видом и издаю звуки удивления или восхищения.
Жена - Что читаешь?
Я - про PostgreSQL extensions. 😁
Тут я ловлю себя на мысли, что реально кайфанул от возможностей, которые дают расширения 😄
Читал я вот эту статью. В начале автор пишет:
Расширения PostgreSQL - это лучшая часть PostgreSQL. Они добавляют функционал в вашу базу данных, изменяя и улучшая выполнение процессов.
Дальше в статье перечислены некоторые расширения с примерами. Мне особенно понравились вот эти
Please open Telegram to view this post
VIEW IN TELEGRAM
Tiger Data Blog
Top 8 PostgreSQL Extensions
Check our eight top PostgreSQL extensions, along with sample queries and instructions. Read the full article on the Tiger Data blog.
🔥4👍3
600К баксов в год дата инженеру
Сегодня попалось видео с коротким интервью Zach Wilson.
Этот парень считается крутым дата профессионалом в сообществе. Впервые я увидел его контент на LinkedIn. Если на LinkedIn начать интересоваться постами о дата инжиниринге, то 100 пудов наткнешься на его профиль.
В этом видео меня зацепили пара моментов. И я решил с вами поделиться.
1️⃣ Во первых конечно - 600К в год! Это он получал, работая в Airbnb (ушёл оттуда год назад и создал свой продукт). Меня впечатлило само число‼️ (для особо дотошных после уплаты налогов это примерно 450К. я загуглил 😉) Я конечно знал что могут платить много, но я думал ну 250К ребята в США получают, а тут вот. При этом он сказал что это норма, что его коллеги получали не меньше.
2️⃣ Второе - это его мнение про базовые знания дата инженера. Тут конечно нужно учитывать, что интервью было короткое и ответ был тоже короткий, но тем не менее он назвал вот что:
🔸 языки - SQL, Python (scala, rust полезно, но не те как первые два)
🔸 оркестрация - Airflow и добавил что в общем-то оркестрация в целом.
🔸 Spark - по его мнению он станет ещё более популярным чем сейчас
🔸 Моделирование данных. Тут он сказал, что даже некоторые ребята, которые получают 500К, делают это хреново 😄
Заметьте тут нет упоминаний модных сейчас слов типа lakehouse, apache iceberg или snowflake или hive, hadoop и тд. Наверняка все это важно, но менее важно, чем пункты выше. В этом смысле мое мнение близко к его. Разве что, пожалуй, Spark в этом коротком списке я не ожидал увидеть. Отмечу ещё, что чуть позже в другом контексте он упоминал Data Mesh и Master Data Management. Возьмем на заметку ☝️
©️ Так что ребята нам ещё есть ого-го куда расти 📈 💲
❓ Что думаете про его мнение о базовых знаниях?
Сегодня попалось видео с коротким интервью Zach Wilson.
Этот парень считается крутым дата профессионалом в сообществе. Впервые я увидел его контент на LinkedIn. Если на LinkedIn начать интересоваться постами о дата инжиниринге, то 100 пудов наткнешься на его профиль.
В этом видео меня зацепили пара моментов. И я решил с вами поделиться.
Заметьте тут нет упоминаний модных сейчас слов типа lakehouse, apache iceberg или snowflake или hive, hadoop и тд. Наверняка все это важно, но менее важно, чем пункты выше. В этом смысле мое мнение близко к его. Разве что, пожалуй, Spark в этом коротком списке я не ожидал увидеть. Отмечу ещё, что чуть позже в другом контексте он упоминал Data Mesh и Master Data Management. Возьмем на заметку ☝️
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
How He Got $600,000 Data Engineer Job
First 100 can try Julius AI for FREE 👉🏼 https://julius.ai/?utm_source=youtube&utm_medium=SundasKhalid&utm_campaign=interview-integration
In this episode of https://youtube.com/playlist?list=PLNvMRDyXHRneiXWLSPJX2ZhMp09bpSJkV&si=I5-PDJKXBTSTsh1b, we are chatting…
In this episode of https://youtube.com/playlist?list=PLNvMRDyXHRneiXWLSPJX2ZhMp09bpSJkV&si=I5-PDJKXBTSTsh1b, we are chatting…
👍10🤔3❤2
Лучший ETL тот, которого нет
Такой “идеальный” ETL процесс можно получить используя postgres_fdw - расширение PostgreSQL (пост).
postgres_fdw - позволяет настроить подключение к другой postgresql базе и обращаться к таблицам в ней, так как будто они лежат в вашей базе.
При этом:
1️⃣ Данные не копируются. Когда пользователь выполняет запрос, та часть запроса, которая относится к внешним таблицам, “пробрасывается” в другую базу. Можно так работать как с DQL (select) так и с DML (insert, update, delete)
2️⃣ Можно выбрать таблицы, к которым подключаться.
3️⃣ Настройка расширения необходима только на стороне запрашивающей базы данных. Для базы данных-источника все выглядит как обычные запросы, она и не знает что вы какое-то хитрое соединение настроили.
4️⃣ Множество баз может быть подключено к одной основной базе.
При использовании fwd (foreign data wrapper) создаются внешние таблицы (foreign table). Такие таблицы отлично заменяют ETL процесс или трансфер данных, в котором нет трансформации (как бы EL процесс без T - трансформации) 😉. Другими словами, когда вы извлекаете данные откуда-то и загружаете куда-то “как есть”, можно просто использовать внешние таблицы с postgres_fdw и получить плюшки:
✔️ Гарантия согласованности (пост). Никакого физического процесса перекладывания данных нет, все успешно завершенные операции с данными в базе-источнике тут же доступны через базу, которая подключена через внешние таблицы. Это даже круче чем real-time.
✔️ Все обработки, трансформации, вычисляемые колонки (measures, metrics) и другие манипуляции с данными выполняются в одном месте - в основной базе, которая является источником для других.
✔️ Отсутствие лишнего ETL процесса, который нужно поддерживать, который потребляет ресурсы и тд.
✔️ Нет необходимости в бэкфиле данных в случае изменений в основной базе источнике
Есть и минусы конечно.🫣
🔵 Вся вычислительная нагрузка ложится на основную базу. Если это проблема, можно рассмотреть репликацию. Мы пока что наблюдаем.
🔵 Данные каждый раз проходят по сети между базами. Это не проблема, если базы у вас в одном месте (например в одном кубернетес кластере или в одном регионе AWS и тд). В других случаях есть риск недоступности из-за проблем с сетью, но это в общем-то касается любых способов как ETL, так и репликации.
Сама техническая реализация супер простая.
©️ Благодаря postgres_fdw мы отключили сразу ряд ETL процессов (дагов в Airflow)
➡️ PS. У Postgres есть и другие fwd (foreign data wrapper) для такого же хитрого подключения почти к любым источникам. Я видел, что есть к MySQL и к AWS S3 например 👍.
У нас в инфраструктуре есть mysql базы у приложений и я думаю мы ещё попробуем часть данных использовать оттуда без копирования🙌.
А возможность так подключаться к Aws s3 - это же вообще пушка! Это же получается Postgres можно использовать как вычислительный движок, физически разделив вычисление и хранение (архитектурный паттерн: separate compute and storage), но это уже другая история.🤓
Такой “идеальный” ETL процесс можно получить используя postgres_fdw - расширение PostgreSQL (пост).
postgres_fdw - позволяет настроить подключение к другой postgresql базе и обращаться к таблицам в ней, так как будто они лежат в вашей базе.
При этом:
При использовании fwd (foreign data wrapper) создаются внешние таблицы (foreign table). Такие таблицы отлично заменяют ETL процесс или трансфер данных, в котором нет трансформации (как бы EL процесс без T - трансформации) 😉. Другими словами, когда вы извлекаете данные откуда-то и загружаете куда-то “как есть”, можно просто использовать внешние таблицы с postgres_fdw и получить плюшки:
Есть и минусы конечно.🫣
Сама техническая реализация супер простая.
-- устанавливаем расширение
CREATE EXTENSION postgres_fdw;
-- создаем подключение к базе-источнику.
-- Этот шаг выполняется только один раз и в дальнейшем
-- может использоваться для добавления таблиц
CREATE SERVER dwh
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (dbname 'dwh', host 'your-host.rds.amazonaws.com', port '5432');
-- ваша база ходит к базе источнику с запросами и поэтому ей нужны креды
-- можно настроить для каждого пользователя индивидуально (для роли кстати нельзя)
-- или указать PUBLIC - все пользователи вашей базы будут обращаться ко внешним таблицам используя указанные креды
CREATE USER MAPPING FOR PUBLIC
SERVER dwh
OPTIONS (user 'data_mart', password '');
-- ВАЖНО! Создайте юзера с read only правами, чтобы избежать неожиданностей, когда кто-то сделает вам Insert, Update, Delete в вашей основной базе
-- создаем внешние таблицы, выбирая какие именно таблицы хотим из внешней базы и куда именно их определить в вашей
-- убрать limit to, чтобы забрать всю схему
IMPORT FOREIGN SCHEMA "foreign_schema_name" limit to (table1, table2)
FROM SERVER dwh INTO local_schema_name;
У нас в инфраструктуре есть mysql базы у приложений и я думаю мы ещё попробуем часть данных использовать оттуда без копирования🙌.
А возможность так подключаться к Aws s3 - это же вообще пушка! Это же получается Postgres можно использовать как вычислительный движок, физически разделив вычисление и хранение (архитектурный паттерн: separate compute and storage), но это уже другая история.🤓
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Инженер и данные
Кайфанул от PostgreSQL Extensions
Я - сижу и читаю что-то в телефоне с довольным видом и издаю звуки удивления или восхищения.
Жена - Что читаешь?
Я - про PostgreSQL extensions. 😁
Тут я ловлю себя на мысли, что реально кайфанул от возможностей, которые…
Я - сижу и читаю что-то в телефоне с довольным видом и издаю звуки удивления или восхищения.
Жена - Что читаешь?
Я - про PostgreSQL extensions. 😁
Тут я ловлю себя на мысли, что реально кайфанул от возможностей, которые…
🔥7🤨1
Логи! Если хочешь потратить время
Иногда у инженеров или аналитиков возникает идея извлечь полезные данные из логов. Иногда даже разработчики приложений сами говорят нам: ну вот же логи! там есть данные.
Работая с операционной базой, мы уже готовимся к неожиданностям, которых вроде бы должно быть немного, ведь работа приложения описана и тестируется. А логи...
Логи существуют для дебага работы приложения. Реже для целей мониторинга и алертов.
Таким образом, логи - технические данные для разработчиков и причины их изменения могут быть самые непредсказуемые.
На логи:
❌ НЕ пишут бизнес требования
❌ НЕ пишут документацию
❌ НЕ делают контракты на пейлоад
❌ НЕ проверяют качество и не тестируют.
а если все это делают то это уже не логи
Туда разве что для ресерча можно залезть👀(хотя для ресерча все можно) и то я бы полез туда только в крайнем случае: оставим дебаг тому кто это наделал разработчикам приложений.
©️ Извлечение аналитических данных из логов - ступенька вниз к хаосу или шаг в болото - пока по колено зашел вроде ниче, а чуть расслабился и затянуло с головой и тратишь все свое время на поддержку
Иногда у инженеров или аналитиков возникает идея извлечь полезные данные из логов. Иногда даже разработчики приложений сами говорят нам: ну вот же логи! там есть данные.
Работая с операционной базой, мы уже готовимся к неожиданностям, которых вроде бы должно быть немного, ведь работа приложения описана и тестируется. А логи...
Логи существуют для дебага работы приложения. Реже для целей мониторинга и алертов.
Таким образом, логи - технические данные для разработчиков и причины их изменения могут быть самые непредсказуемые.
На логи:
Туда разве что для ресерча можно залезть👀
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Особенности foreign data wrapper
Ранее я писал о плюсах использования внешних таблиц, теперь хочу написать об особенностях, которые в нашем use case приводят к проблемам. Спойлер: мы отказались от использования внешних таблиц.🙁
У foreign data wrapper есть особенность:
Fdw запрашивает фул таблицу с удалённого сервера, даже если вы применили фильтры в запросе.😮 Очевидно, что если внешняя таблица на миллионы строк, то ждать придётся очень долго пока вы получите всю таблицу. Эту особенность можно обойти, если “помочь” fdw понять как правильно подготовить запрос ко внешней таблице. Вот здесь хорошо описано и приведены способы написания запроса оптимального для внешних таблиц.🙌 Поэтому я назвал это особенностью. Сама по себе особенность не проблема, работать можно.☝️
А проблема обусловлена именно нашим кейсом.👀
📝 Ситуация (Кейс):
У нас есть DWH на Postgresql и есть Data Marts тоже на Postgresql. Дата марты содержат сабсеты данных специфические для какой-то задачи/домена/департамента. В тех случаях, когда данные в дата марте полностью совпадают с данными в двх как раз возникает отличная возможность избавиться от лишних ETL процессов. Тут то мы и применили внешние таблицы.
В нашем кейсе дата март - конечный продукт для пользователей. Туда приходят делать запросы для анализа, ресерча, построения отчётов и тд. Дата март как продукт должен предоставить возможность работать с данными, делать простые или сложные запросы, оптимальные или неоптимальные.
📝 Проблема:
Пользователям все равно какие там технологии применили под капотом дата инженеры. Естественно они не должны держать в голове, что там какие-то внешние таблицы и как-то правильно надо писать запросы, более того они вообще не должны знать о таких подробностях.☝️ В итоге это привело к резкому падению скорости обработки запросов, жалобам пользователей и отказу от использования внешних таблиц в этом кейсе.💔
📝 Решение:
Физическое хранение данных в самом дата март. Мы перешли к плану Б и настроили логическую репликацию на те таблицы, схема которых совпадает в двх и дата март, то есть там же где были внешние таблицы. 🙌
©️ Но мы не убираем foreign data wrapper “на помойку”! В других кейсах, где такими внешними таблицам будут пользоваться инженеры можно работать эффективно. Так что отложили пока в сторонку.
Кстати mysql_fdw тоже попробовал и он тоже отлично работает и настраивается так же легко как и postgres_fdw.
Ранее я писал о плюсах использования внешних таблиц, теперь хочу написать об особенностях, которые в нашем use case приводят к проблемам. Спойлер: мы отказались от использования внешних таблиц.🙁
У foreign data wrapper есть особенность:
Fdw запрашивает фул таблицу с удалённого сервера, даже если вы применили фильтры в запросе.😮 Очевидно, что если внешняя таблица на миллионы строк, то ждать придётся очень долго пока вы получите всю таблицу. Эту особенность можно обойти, если “помочь” fdw понять как правильно подготовить запрос ко внешней таблице. Вот здесь хорошо описано и приведены способы написания запроса оптимального для внешних таблиц.🙌 Поэтому я назвал это особенностью. Сама по себе особенность не проблема, работать можно.☝️
А проблема обусловлена именно нашим кейсом.👀
У нас есть DWH на Postgresql и есть Data Marts тоже на Postgresql. Дата марты содержат сабсеты данных специфические для какой-то задачи/домена/департамента. В тех случаях, когда данные в дата марте полностью совпадают с данными в двх как раз возникает отличная возможность избавиться от лишних ETL процессов. Тут то мы и применили внешние таблицы.
В нашем кейсе дата март - конечный продукт для пользователей. Туда приходят делать запросы для анализа, ресерча, построения отчётов и тд. Дата март как продукт должен предоставить возможность работать с данными, делать простые или сложные запросы, оптимальные или неоптимальные.
Пользователям все равно какие там технологии применили под капотом дата инженеры. Естественно они не должны держать в голове, что там какие-то внешние таблицы и как-то правильно надо писать запросы, более того они вообще не должны знать о таких подробностях.☝️ В итоге это привело к резкому падению скорости обработки запросов, жалобам пользователей и отказу от использования внешних таблиц в этом кейсе.
Физическое хранение данных в самом дата март. Мы перешли к плану Б и настроили логическую репликацию на те таблицы, схема которых совпадает в двх и дата март, то есть там же где были внешние таблицы. 🙌
Кстати mysql_fdw тоже попробовал и он тоже отлично работает и настраивается так же легко как и postgres_fdw.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5
Занимайтесь творчеством!
Когда я пробовал генерировать картинки с AI с меня слетели розовые очки.🫣 Я почему-то думал, что я дам ему текст поста и он что-то интересное нарисует. Как я ошибался! Ему нужно точное описание что нужно сделать: стиль композиция, фон, цвета, детали, эмоции, элементы, формы и все все. Получается нужно в голове полностью придумать изображение и описать его! Творческий процесс! И тут я наткнулся на мысль, а ведь творчество - это про придумать, а не про сделать.
Я порассуждал на эту тему и склоняюсь к тому, что продумать само решение - вот творчество! И с этим AI пока не справляется. Он может заменить последний этап, этап производства.
На самом деле так было всегда. 🤔
💃 Дизайнер одежды не шьёт, а сначала рисует, потом берет разные лоскуты и иголками или ещё как-то закрепляет на манекене, что-то меняет, думает, а готовый вариант может сшить подмастерье.
🏡 Дизайнер (домов, интерьера, рекламы, машин и т.д.) тоже продумывает композицию стиль, потом делает эскизы, рисует, а затем в заданном стиле можно создать множество изображений и добавить деталей.
🎨 Художник тоже изобретает стиль и какой-то уникальный подход. Знаменитые художники знамениты за их "новинки", уникальность, которую они придумали, а репродукцию (копию картины) могут сделать сотни или тысячи художников в мире. Насколько я знаю (где-то читал), у знаменитых художников были подмастерья, которые помогали писать, добавляли какие-то простые делали, фон типа неба или земли - делали рутину. Сегодня это может делать AI.
🎹 Композитор не играет сам партию каждого инструмента, он придумывает главную тему используя как правило только пианино, описывает ее, а потом ее можно масштабировать меняя оркестровку, темп, инструменты и тд (послушайте Ханса Циммера и его саундртеки к фильмам).
👨💻У нас как инженеров тоже такой процесс. У нас есть творчество! Придумать решение - творчество, написать код - рутина. Больше занимайтесь творчеством! Опустите технические детали до того момента, когда будете писать код. Опишите проблему и решение естественным языком. Нарисуйте ваше решение с простыми квадратиками и стрелочками (инструменты типа uml придут позже, когда вы сами поймете что они вам нужны), затем уже опишите конкретные шаги (пост про псевдокод). Решение готово! Кода нет? Напишите сами или отдайте AI - это рутина. ☝️
©️ Занимайтесь творчеством ребята!
Когда я пробовал генерировать картинки с AI с меня слетели розовые очки.🫣 Я почему-то думал, что я дам ему текст поста и он что-то интересное нарисует. Как я ошибался! Ему нужно точное описание что нужно сделать: стиль композиция, фон, цвета, детали, эмоции, элементы, формы и все все. Получается нужно в голове полностью придумать изображение и описать его! Творческий процесс! И тут я наткнулся на мысль, а ведь творчество - это про придумать, а не про сделать.
Я порассуждал на эту тему и склоняюсь к тому, что продумать само решение - вот творчество! И с этим AI пока не справляется. Он может заменить последний этап, этап производства.
На самом деле так было всегда. 🤔
💃 Дизайнер одежды не шьёт, а сначала рисует, потом берет разные лоскуты и иголками или ещё как-то закрепляет на манекене, что-то меняет, думает, а готовый вариант может сшить подмастерье.
🏡 Дизайнер (домов, интерьера, рекламы, машин и т.д.) тоже продумывает композицию стиль, потом делает эскизы, рисует, а затем в заданном стиле можно создать множество изображений и добавить деталей.
🎨 Художник тоже изобретает стиль и какой-то уникальный подход. Знаменитые художники знамениты за их "новинки", уникальность, которую они придумали, а репродукцию (копию картины) могут сделать сотни или тысячи художников в мире. Насколько я знаю (где-то читал), у знаменитых художников были подмастерья, которые помогали писать, добавляли какие-то простые делали, фон типа неба или земли - делали рутину. Сегодня это может делать AI.
🎹 Композитор не играет сам партию каждого инструмента, он придумывает главную тему используя как правило только пианино, описывает ее, а потом ее можно масштабировать меняя оркестровку, темп, инструменты и тд (послушайте Ханса Циммера и его саундртеки к фильмам).
👨💻У нас как инженеров тоже такой процесс. У нас есть творчество! Придумать решение - творчество, написать код - рутина. Больше занимайтесь творчеством! Опустите технические детали до того момента, когда будете писать код. Опишите проблему и решение естественным языком. Нарисуйте ваше решение с простыми квадратиками и стрелочками (инструменты типа uml придут позже, когда вы сами поймете что они вам нужны), затем уже опишите конкретные шаги (пост про псевдокод). Решение готово! Кода нет? Напишите сами или отдайте AI - это рутина. ☝️
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9
Сделал это фото сегодня в парке. Вряд ли это бульварный роман или очередная книга про успешный успех или как стать миллионером за 5 минут. 😁
Парень явно решил погрузиться в какую-то тему всерьёз. 👍
Я вот тоже все пытаюсь выработать привычку читать каждый день. Пока что получается только по настроению. Кстати сейчас читаю две книги: Fundamentals of Data Engineering и Дао Тойота.
CEO топовых компаний читают 50-70 книг в год! 😮 Я конечно не CEO (пока), но хотел бы выйти для начала хотя-бы на 5-10 книг в год. 😄
Хоть я и не много книг прочитал, но достаточно, чтобы убедиться, что они дают мощный буст в мышлении. Правильная книга в нужное время - равно переход на новый уровень! 🙌
Парень явно решил погрузиться в какую-то тему всерьёз. 👍
Я вот тоже все пытаюсь выработать привычку читать каждый день. Пока что получается только по настроению. Кстати сейчас читаю две книги: Fundamentals of Data Engineering и Дао Тойота.
CEO топовых компаний читают 50-70 книг в год! 😮 Я конечно не CEO (пока), но хотел бы выйти для начала хотя-бы на 5-10 книг в год. 😄
Хоть я и не много книг прочитал, но достаточно, чтобы убедиться, что они дают мощный буст в мышлении. Правильная книга в нужное время - равно переход на новый уровень! 🙌
🔥8👍4😁1
Ситуация©️ Проблема ©️ Решение
Большая часть работы состоит из решения проблем и различных коммуникаций по поводу их решения. Часто нужно описать проблему, поставить задачу так, чтобы твой коллега все понял. А чтобы объяснить кому-то нужно ещё понять проблему самому, добраться до сути. 🧐
Есть отличный и очень простой фреймворк, который помогает структурировать мысли, выделить суть и логически выстроить информацию, чтобы лучше понять проблему самому и доступно и убедительно объяснить её любому. 🙌
📝 Ситуация-Проблема-Решение или The "Situation-Complication-Resolution" (SCR) фреймворк широко используется в бизнес коммуникациях, сторителлинге, решении проблем.
🔸 Ситуация: основное на фактах описание текущей ситуации или состояния, окружения, контекста
🔸 Проблема: конфликт или разница между текущим состоянием и желаемым, блокер, то что требует действий.
🔸 Решение: что нужно сделать, чтобы разрешить проблему
По сути это метод рассуждения, который можно применять везде, а рассуждать я люблю и умею🤓. Я им пользуюсь часто для сложных и простых ситуаций, для постановки задач, для переписки в рабочих чатах или каналах и даже вот применил в посте. При этом не обязательно описывать (проговаривать) каждый из пунктов явно, можно о них подумать, а описать уже просто в виде нескольких связанных предложений.
И самое лучшее во фреймворке то, что применять его очень легко! Можете попробовать в понедельник описать таск используя СПР (SCR) фреймворк.
Кстати у нас в компании head of engineering так любит этот фреймворк, что у нас тикеты на команду девопсов имеют обязательные поля для заполнения Situation, Complication, Resolution.☝️
Пример есть в посте и еще пример в комментариях для простой технической задачи из недавних 👇
Большая часть работы состоит из решения проблем и различных коммуникаций по поводу их решения. Часто нужно описать проблему, поставить задачу так, чтобы твой коллега все понял. А чтобы объяснить кому-то нужно ещё понять проблему самому, добраться до сути. 🧐
Есть отличный и очень простой фреймворк, который помогает структурировать мысли, выделить суть и логически выстроить информацию, чтобы лучше понять проблему самому и доступно и убедительно объяснить её любому. 🙌
По сути это метод рассуждения, который можно применять везде, а рассуждать я люблю и умею🤓. Я им пользуюсь часто для сложных и простых ситуаций, для постановки задач, для переписки в рабочих чатах или каналах и даже вот применил в посте. При этом не обязательно описывать (проговаривать) каждый из пунктов явно, можно о них подумать, а описать уже просто в виде нескольких связанных предложений.
И самое лучшее во фреймворке то, что применять его очень легко! Можете попробовать в понедельник описать таск используя СПР (SCR) фреймворк.
Кстати у нас в компании head of engineering так любит этот фреймворк, что у нас тикеты на команду девопсов имеют обязательные поля для заполнения Situation, Complication, Resolution.☝️
Пример есть в посте и еще пример в комментариях для простой технической задачи из недавних 👇
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3👍2
Отношение меняет все
Как бы по инфоцыгански это не звучало, это так. Наши установки меняют мышление и настрой.
Плохие установки приводят к проблемам в коммуникации, к проблемам в доведении проекта до результата и тд.
Вот плохие установки, которые часто встречаются. И у меня тоже🙁, но я с ними борюсь
❌ Легаси код - плохой код. Есть такая цитата: легаси - это снизсходительное название того, что прямо сейчас приносит деньги.
❌ Заказчик/клиент глупый и не знает чего хочет. Классика. Лучше исходить из того, что заказчик - эксперт в своей области и нужно его понять и направить в нужное русло.
❌ Хочешь сделать хорошо, сделай сам. А потом выгори, сорви сроки, оттолкни от себя людей, которые хотят и могут помочь.
❌ Это не моя проблема, это их проблема. Все проблемы - это проблемы бизнеса. А мы работаем на бизнес. Это не значит что все нужно делать самому (смотри предыдущий пункт), но подсветить проблему, поделиться мнением, создать таск в беклог 😁 .
❌ Правила мешают работать. Однако их придумали неспроста. Они написаны кровью, пОтом и матами инженеров, которые были вынуждены разгребать хаос.
❌ Безопасники мешают работать (долго доступ дают и вопросы какие глупые задают). Во-первых смотри предыдущий пункт. Во-вторых тема безопасности данных вообще очень важна для нас и тут, наоборот, мы, как дата инженеры, должны первые встать и сказать, что с безопасностью что-то не так. Кстати в Fundamentals of Data Engineering безопасность данных - часть работы дата инженеров и их ответственность тоже .
Как бы по инфоцыгански это не звучало, это так. Наши установки меняют мышление и настрой.
Плохие установки приводят к проблемам в коммуникации, к проблемам в доведении проекта до результата и тд.
Вот плохие установки, которые часто встречаются. И у меня тоже🙁, но я с ними борюсь
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6👎1
Modern data stack
Цитата из книги Fundamentals of Data Engineering о современном дата стеке.
Меня позабавило скопление в одном предложении всех этих словосочетаний подчеркивающих простоту и быстроту развертывания и использования 😄. Может даже показаться что и дата инженеры-то не нужны😯. Но нам не о чем беспокоиться! Даже при использовании таких компонентов остаётся сложность создания собственно архитектуры с правильными компонентами и с правильным взаимодействием. Нужно стремиться стать гибким инженером(это я самому себе 😉) , способным эффективно использовать модерн дата стек, не застревая в двух крайностях:
😡 Олдскул: берём только проверенные временем компоненты, а все чего не хватает пишем сами.
😡 Resume-driven development - выбор исключительно крутых новейших технологий, забывая конечные цели проекта. Вот ещё одна цитата из той же книги.
©️ Перечитал пост и понял, что как и всегда все снова сводится к балансу и здравому смыслу 🤔
Цитата из книги Fundamentals of Data Engineering о современном дата стеке.
the main objective of the modern data stack is to use cloud-based, plug-and-play, easy-to-use, off-the-shelf components to create a modular and cost-effective data architecture.
Меня позабавило скопление в одном предложении всех этих словосочетаний подчеркивающих простоту и быстроту развертывания и использования 😄. Может даже показаться что и дата инженеры-то не нужны😯. Но нам не о чем беспокоиться! Даже при использовании таких компонентов остаётся сложность создания собственно архитектуры с правильными компонентами и с правильным взаимодействием. Нужно стремиться стать гибким инженером
There’s also a temptation to do resume-driven development, stacking up impressive new technologies without prioritizing the project’s ultimate goals.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6💯2
Мониторинг и алерты
Я очень люблю эту тему и почему-то о ней несправедливо мало говорят в контексте дата инжиниринга и вообще работы с данными.
📝 Я убежден, что мониторинг и алерты неотъемлемая часть хорошего инженерного решения.
Мы стараемся закрыть мониторингом и алертами все, за что отвечает наша команда. Иногда ребята меня спрашивают зачем нам приоритезировать работы по настройке мониторинга и алертов. Я обычно отвечаю, что задача алертинга уведомить нас о проблеме до того, как о ней узнает бизнес. Алерты работают на качество нашего сервиса (даже если вы работаете всегда внутри своей компании, заказчики - это аналитики или стейкхолдеры и вы оказываете им услуги). Все это правильно, но я чувствовал что тут есть что-то ещё, что меня беспокоит, когда нет алертов. И вот мне наконец удалось порассуждать, добраться до сути и сформулировать ее 🙌.
Пассивная уверенность vs активная уверенность.
Пассивная уверенность - состояние, при котором в любой момент времени, не предпренимая никаких действий, точно известно, что все работает хорошо. Например CEO подошел и спросил "все работает?" и ты через секунду уверенно отвечаешь - да.
Активная уверенность - состояние при котором, чтобы убедиться что все работает хорошо, нужно предпринять какие-то действия: открыть ui оркестратора, проверить наличие ошибок в логах и тд.
Вот оно! Я понял, что меня психологически не устраивает активная увереность. Поэтому я стремлюсь к состоянию пассивной уверенности.
Ксати я раньше не встречал нигде такие понятия и определения. Возможно я даже что-то новое сформулировал😎.
Кроме психологической причины есть ещё конечно чисто практическая. Пассивную уверенность можно масштабировать на неограниченное количество контролируемых единиц (сервисов, приложений, функций, дагов, етл процессов) - добавление очередной единицы не влечёт временных затрат на проверку.(только время реакции на алерт если он будет) . А вот активная напротив плохо масштабируется по понятными причинам: новая единица - время на проверку.
Я очень люблю эту тему и почему-то о ней несправедливо мало говорят в контексте дата инжиниринга и вообще работы с данными.
Мы стараемся закрыть мониторингом и алертами все, за что отвечает наша команда. Иногда ребята меня спрашивают зачем нам приоритезировать работы по настройке мониторинга и алертов. Я обычно отвечаю, что задача алертинга уведомить нас о проблеме до того, как о ней узнает бизнес. Алерты работают на качество нашего сервиса (даже если вы работаете всегда внутри своей компании, заказчики - это аналитики или стейкхолдеры и вы оказываете им услуги). Все это правильно, но я чувствовал что тут есть что-то ещё, что меня беспокоит, когда нет алертов. И вот мне наконец удалось порассуждать, добраться до сути и сформулировать ее 🙌.
Пассивная уверенность vs активная уверенность.
Пассивная уверенность - состояние, при котором в любой момент времени, не предпренимая никаких действий, точно известно, что все работает хорошо. Например CEO подошел и спросил "все работает?" и ты через секунду уверенно отвечаешь - да.
Активная уверенность - состояние при котором, чтобы убедиться что все работает хорошо, нужно предпринять какие-то действия: открыть ui оркестратора, проверить наличие ошибок в логах и тд.
Вот оно! Я понял, что меня психологически не устраивает активная увереность. Поэтому я стремлюсь к состоянию пассивной уверенности.
Ксати я раньше не встречал нигде такие понятия и определения. Возможно я даже что-то новое сформулировал😎.
Кроме психологической причины есть ещё конечно чисто практическая. Пассивную уверенность можно масштабировать на неограниченное количество контролируемых единиц (сервисов, приложений, функций, дагов, етл процессов) - добавление очередной единицы не влечёт временных затрат на проверку.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤2😎2
Лучший друг человека
Вчера весь день работал с другом. Я изучал работу со spark на aws emr serverless, aws glue, data catalog, а он мне помогал. Я говорю дай скрипт, который будет делать вот это, он даёт, я говорю, а почему вот тут не сделал проще? Он: точно! и поправляет. Я: вот тут какие ещё варианты? Уточни как это работает. А что под капотом по факту происходит? А вот тут похоже будут проблемы в таких-то кейсах? И тд...
Наверное вы уже догадались, что это ai chat. В этот раз конкретно я общался с windows copilot, а вообще я и с другими друзьями общаюсь 😂: с chatgpt, amazon q (когда в aws console), githab copilot (когда работаю в ide). Эта компания мне здорово помогает! 👍 Но у этих ребят конечно надо знать, что спрашивать! И я даже не про промпты, а про то, что нужно понимать контекст и главное понимать свою цель. ☝️
Раньше процесс изучения новых для меня технологий я начинал с обзорных статей, потом к статьям уже более детальным - туториалам, потом уже к документации или к еще более глубоким статьям. Теперь я заметил, что следующий шаг после обзора хорошо заменяют такие чаты, так как дают быстрый доступ к нужной информации(что логично ведь на основе открытой информации в интернете они и обучены) . Таким образом сначала все таки статьи, чтобы знать что к чему и знать, что спрашивать у друга. Потом ai друг. Ну а глубже пока эти друзья не тянут. Не то чтобы ошибаются, но скорее привирают или обобщают/упрощают. Для начального этапа погружения это ок, но для решения сложных проблем уже не то.
В итоге мой план на любой новый инструмент:
1️⃣ несколько обзорных статей наискосок,
2️⃣ пообщаться с ai другом и проба что-то сделать вместе с ним,
3️⃣ сделать рабочее решение моей задачи
4️⃣ уточнить детали в документации по мере необходимости.
5️⃣ А уж если цель - экспертность, тогда книга.
Вчера весь день работал с другом. Я изучал работу со spark на aws emr serverless, aws glue, data catalog, а он мне помогал. Я говорю дай скрипт, который будет делать вот это, он даёт, я говорю, а почему вот тут не сделал проще? Он: точно! и поправляет. Я: вот тут какие ещё варианты? Уточни как это работает. А что под капотом по факту происходит? А вот тут похоже будут проблемы в таких-то кейсах? И тд...
Наверное вы уже догадались, что это ai chat. В этот раз конкретно я общался с windows copilot, а вообще я и с другими друзьями общаюсь 😂: с chatgpt, amazon q (когда в aws console), githab copilot (когда работаю в ide). Эта компания мне здорово помогает! 👍 Но у этих ребят конечно надо знать, что спрашивать! И я даже не про промпты, а про то, что нужно понимать контекст и главное понимать свою цель. ☝️
Раньше процесс изучения новых для меня технологий я начинал с обзорных статей, потом к статьям уже более детальным - туториалам, потом уже к документации или к еще более глубоким статьям. Теперь я заметил, что следующий шаг после обзора хорошо заменяют такие чаты, так как дают быстрый доступ к нужной информации
В итоге мой план на любой новый инструмент:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6
В прошлом посте я упомянул, что изучал некоторые инструменты на aws для работы с данными. За один день я потрогал AWS EMR, AWS EMR Serverless, AWS Data Glue (catalog, crawler).
Как и всегда изначально у меня была четко сформулированная проблема, а точнее две. Это потом я уже выдвинул гипотезу, что эти проблемы можно решить на aws и потому туда и пошёл. Просто я свое время ценю и инвестирую его осознанно 😉
📝 Итак проблемы:
1. Compute выполняется на воркерах airflow, что очевидно ограничивает работу с большими данными.
Гипотеза: перенести работу в spark, а aws emr упростит поддержку кластера.
2. Зависимость от Postgresql. У нас DWH на Postgresql и архитектурно это ограничивает свободу выбора инструментов работы с данными.
Гипотеза: отделить слои трансформации+хранения от репрезантативного слоя, организовать data lakehouse с данными в открытом формате (iceberg) на aws s3, а postgresql сделать опцией.
✏️ Далее мои выводы и впечатления. Вкратце в виде обзора. Для тех кто уже знает эти инструменты ничего нового не скажу.
Пару слов о spark. Я думаю все как минимум слышали о нем. Это compute engine для распределенной обработки данных. Он изолирует все сложности под капотом, а снаружи дает простой интерфейс для разных языков программирования. Ему нужен кластер.
Aws emr как раз дает кластер, но он хоть и облачный, но все равно требует поддержки (конфигурация, мониторинг, деплой и тд), а мы этого делать не хотим, нам же надо modern data stack, значит сразу идем смотреть serverless. Тут aws даёт возможность забыть о кластере и просто слать ему job 👍. Aws при этом предоставляет библиотеку для airflow, в которой есть операторы для работы с Aws emr serverles. Супер! Все что нужно - это выполнить submit job!
В нашем случае мы уже изолировали оркестратор и даги строятся автоматически из конфигов и все что нужно сделать - это подготовить универсальный spark job script и подложить его в билдер. И вуаля! Десятки наших дагов начнут работать на spark и даже об этом не узнают 😁 - решение проблемы1️⃣ . А так же здесь можно перенаправить поток данных в aws s3 в файлы iceberg, так как spark умеет с ними работать - решение проблемы 2️⃣ . В общем-то уже тут я понял что не зря пришёл и с этим можно работать. 🙌
Продолжение в следующем посте⬇️
Как и всегда изначально у меня была четко сформулированная проблема, а точнее две. Это потом я уже выдвинул гипотезу, что эти проблемы можно решить на aws и потому туда и пошёл. Просто я свое время ценю и инвестирую его осознанно 😉
1. Compute выполняется на воркерах airflow, что очевидно ограничивает работу с большими данными.
Гипотеза: перенести работу в spark, а aws emr упростит поддержку кластера.
2. Зависимость от Postgresql. У нас DWH на Postgresql и архитектурно это ограничивает свободу выбора инструментов работы с данными.
Гипотеза: отделить слои трансформации+хранения от репрезантативного слоя, организовать data lakehouse с данными в открытом формате (iceberg) на aws s3, а postgresql сделать опцией.
Пару слов о spark. Я думаю все как минимум слышали о нем. Это compute engine для распределенной обработки данных. Он изолирует все сложности под капотом, а снаружи дает простой интерфейс для разных языков программирования. Ему нужен кластер.
Aws emr как раз дает кластер, но он хоть и облачный, но все равно требует поддержки (конфигурация, мониторинг, деплой и тд), а мы этого делать не хотим, нам же надо modern data stack, значит сразу идем смотреть serverless. Тут aws даёт возможность забыть о кластере и просто слать ему job 👍. Aws при этом предоставляет библиотеку для airflow, в которой есть операторы для работы с Aws emr serverles. Супер! Все что нужно - это выполнить submit job!
В нашем случае мы уже изолировали оркестратор и даги строятся автоматически из конфигов и все что нужно сделать - это подготовить универсальный spark job script и подложить его в билдер. И вуаля! Десятки наших дагов начнут работать на spark и даже об этом не узнают 😁 - решение проблемы
Продолжение в следующем посте
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7
Продолжение предыдущего поста
AWS Glue даёт возможность изолировать зоопарк ваших дата источников/дестинейшнов сколько бы их ни было. Базы данных, event stream (kafka), файлы любых форматов в aws s3 или где-то ещё. Он все это может понять и позволить работать со всем этим взаимодействуя только с одним интерфейсом, одной точкой - aws glue.
Это возможно при создании дата каталога - такое хранилище мета данных или другими словами схем данных: какие таблички в базе да с какими колонками и тд. При этом есть специальный инструмент - crawler, который по запросу или расписанию ходит везде и обновляет мета данные⛏ . Таким образом aws glue знает, что вот тут postgresql база и в ней такие таблицы и колонки, а вот тут mysql, а вот ещё kafka и тд. Это и позволяет Data Glue сидя сверху на каталоге делать грязную работу работать со всем многообразием за вас. И круто ещё и то, что под капотом spark! Все таблички из каталога уже в контексте! Вы в скрипте обращайтесь к чему угодно как к таблице, а дальше уже происходит магия и данные подтянутся будь-то csv файл, будь-то mysql табличка! (Сам на проде не пробовал пока, интересно как он будет билдить запросы. Поглядим 🤔).
В нашем случае ещё сильнее упрощается скрипт и упрощается работа с sql, так как не нужно думать о подключениях, базах, отличиях синтаксиса и тд. Звучит круто! Потом попробую на проде, расскажу 😄У aws glue ещё есть свой etl оркестратор типа для визуального построения флоу, но он что-то с первого взгляда меня не впечатлил.
Ну и вишенкойна торте на дата каталоге лежит AWS Athena. Если Glue даёт возможность работать со спарк скриптами, то этот инструмент даёт обычный sql интерфейс над всем каталогом 💪. Можно подключиться через ваш любимый database клиент, типа dbeaver или datagrip и работать с sql консолью, не думая о том, что там могут быть десятки баз данных и файлов! 😮 (тут я немного переживаю, не получится ли как с foreign data wrapper и его далекими от оптимальности запросами, пробрасываемыми непосредтсвенно в базу-источник, но есть надежда что в aws сделали получше)
Должен ещё упомянуть, что все это добро стоит недешево. Порядок чисел начинается с сотен долларов на минималках. Если мы решим туда идти, то обязательно будем внимательно следить за стоимостью и переходить постепенно. К слову есть такая штука как FinOps (что? Уже есть devops, dataops, а это ещё что? 😳). Да, оказывается дата инженеры ещё и немного финопсы! (Книга Fundamentals of data engineering). За modern data stack со всеми этими off-the-shelf, easy-to-use, plug-and-play надо платить.💰
©️ В итоге я понял, что обозначенные мной проблемы можно решить красиво, молодежно в AWS.
Спасибо, что прочитали этот длинный двойной пост 🤗
AWS Glue даёт возможность изолировать зоопарк ваших дата источников/дестинейшнов сколько бы их ни было. Базы данных, event stream (kafka), файлы любых форматов в aws s3 или где-то ещё. Он все это может понять и позволить работать со всем этим взаимодействуя только с одним интерфейсом, одной точкой - aws glue.
Это возможно при создании дата каталога - такое хранилище мета данных или другими словами схем данных: какие таблички в базе да с какими колонками и тд. При этом есть специальный инструмент - crawler, который по запросу или расписанию ходит везде и обновляет мета данные
В нашем случае ещё сильнее упрощается скрипт и упрощается работа с sql, так как не нужно думать о подключениях, базах, отличиях синтаксиса и тд. Звучит круто! Потом попробую на проде, расскажу 😄
Ну и вишенкой
Должен ещё упомянуть, что все это добро стоит недешево. Порядок чисел начинается с сотен долларов на минималках. Если мы решим туда идти, то обязательно будем внимательно следить за стоимостью и переходить постепенно. К слову есть такая штука как FinOps (что? Уже есть devops, dataops, а это ещё что? 😳). Да, оказывается дата инженеры ещё и немного финопсы! (Книга Fundamentals of data engineering). За modern data stack со всеми этими off-the-shelf, easy-to-use, plug-and-play надо платить.
Спасибо, что прочитали этот длинный двойной пост 🤗
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8
В выигрыше тот, кто делится
Нужно делиться экспертизой. И не потому что это полезно для вашей команды с точки зрения развития младших товарищей или с точки зрения исключения ситуаций, когда кто-то один обладает уникальными знаниями о реализации чего-то.
В этом посте я хочу сказать, что делиться экспертизой полезно именно для каждого отдельно взятого индивидуума.
При этом я знаю, что есть люди, которые намеренно не делятся знаниями, думая, что таким образом делают себя уникальными и незаменимыми! 😳 Не понимаю таких и их даже немного жалко: знания устаревают, а они топчатся на месте.
под спойлерами ниже вы найдёте параллели с базами данных, которы я добавил по приколу 😁
Я понял, что когда объясняшь кому-то что-то, то как бы:
©️ Лучше структурируешь информацию в голове у себя самого
. (Индексация, метаданные, связи)
©️ Фиксируешь знания и освобождаешь пространство для новых. Не знаю как это работает, может типа в долговременную память уходят.
(Партицирование, сохранение на диск и освобождение кэша)
©️ Освобождаешь время за счёт делегирования задач, где больше нет неопределенности - рутина.
(Тут не придумал аналогию. Может индекс скан?)
В итоге в выигрыше тот, кто делится!
Я и канал этот создал, потому что хотел поделиться с вами кучей мыслей, которые уже скопились в заметках и ещё возникают каждый день 😃
А канал мне помог создать Влад и его курс по ведению тг канала. У меня было много сомнений и пугала неизвестность, так как я ничего не знал о ведении канала. Влад помог и сомнения развеять и лайфхаков насыпал и нужный настрой задал! Ещё круто, что с первого дня мы создали свои каналы и начали писать! Вот этого пенделя мне и не хватало чтобы начать. 😁 а ещё Влад системный аналитик и ведёт свой канал.💪
Нужно делиться экспертизой. И не потому что это полезно для вашей команды с точки зрения развития младших товарищей или с точки зрения исключения ситуаций, когда кто-то один обладает уникальными знаниями о реализации чего-то.
В этом посте я хочу сказать, что делиться экспертизой полезно именно для каждого отдельно взятого индивидуума.
При этом я знаю, что есть люди, которые намеренно не делятся знаниями, думая, что таким образом делают себя уникальными и незаменимыми! 😳 Не понимаю таких и их даже немного жалко: знания устаревают, а они топчатся на месте.
Я понял, что когда объясняшь кому-то что-то, то как бы:
В итоге в выигрыше тот, кто делится!
Я и канал этот создал, потому что хотел поделиться с вами кучей мыслей, которые уже скопились в заметках и ещё возникают каждый день 😃
А канал мне помог создать Влад и его курс по ведению тг канала. У меня было много сомнений и пугала неизвестность, так как я ничего не знал о ведении канала. Влад помог и сомнения развеять и лайфхаков насыпал и нужный настрой задал! Ещё круто, что с первого дня мы создали свои каналы и начали писать! Вот этого пенделя мне и не хватало чтобы начать. 😁 а ещё Влад системный аналитик и ведёт свой канал.💪
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👍1👌1💯1
Родные ошибки
Когда старый подход к обработке данных неточный и все про это знают. Когда идёт ручная обработка данных, делают кучу допущений, ошибок и тд.
Приходят дата инженеры, все автоматизируют, настраивают процессы, отдают результат.... А они такие: "Не ну тут отклонение на 0,0001%, не будем смотреть!" 😮
Человек ко всему привыкает и даже к ошибкам. А собственные ошибки ещё и любит, оберегает и защищает! Потому что привык, потому что уже прикипел, потому что сложно признать что делали плохо, и, мое любимое, потому что "мы всегда так делали" 🤦♂.
И это я не жалуюсь. Это просто реальность, в которой мы работаем. В конце концов мы работаем с людьми и для людей, даже если вы круглые сутки пишете код, кто-то его читает и изменяет, кто-то использует само решение. А иногда техническое решение меняет рабочий процесс людей и их привычный уклад. А люди инертны и могут сопротивляться. Есть даже целая наука: менеджмент изменений.Когда-нибудь прочитаю на эту тему книгу.
Просто нужно быть готовым как к помощи увлеченных вашей идеей людей так и сопротивлению скептически настроенных людей. 🙌
Когда старый подход к обработке данных неточный и все про это знают. Когда идёт ручная обработка данных, делают кучу допущений, ошибок и тд.
Приходят дата инженеры, все автоматизируют, настраивают процессы, отдают результат.... А они такие: "Не ну тут отклонение на 0,0001%, не будем смотреть!" 😮
Человек ко всему привыкает и даже к ошибкам. А собственные ошибки ещё и любит, оберегает и защищает! Потому что привык, потому что уже прикипел, потому что сложно признать что делали плохо, и, мое любимое, потому что "мы всегда так делали" 🤦♂.
И это я не жалуюсь. Это просто реальность, в которой мы работаем. В конце концов мы работаем с людьми и для людей, даже если вы круглые сутки пишете код, кто-то его читает и изменяет, кто-то использует само решение. А иногда техническое решение меняет рабочий процесс людей и их привычный уклад. А люди инертны и могут сопротивляться. Есть даже целая наука: менеджмент изменений.
Просто нужно быть готовым как к помощи увлеченных вашей идеей людей так и сопротивлению скептически настроенных людей. 🙌
🔥4❤🔥2🤝2
Когда несколько дней пытался заставить работать интеграцию со внешним сервисом со сложным API и с неочевидной документацией. Потом оно заработало, но высосало все силы...
Люди делятся на два типа:
1️⃣ Больше никогда не буду брать задачи связанные с этим сервисом! Нахрен надо! Столько возьни! 🤬
2️⃣ Теперь я знаю как это работает, сделаю заметки, напишу комменты в коде и в следующий раз быстро решу задачу, связаную с этим сервисом! 🙌
К какому типу относитесь вы?
1 - 🤬
2 - 👏
Люди делятся на два типа:
К какому типу относитесь вы?
1 - 🤬
2 - 👏
Please open Telegram to view this post
VIEW IN TELEGRAM
👏17🤬5
Clean code приёмы в Airflow
📝 Делаем код с определением дага красивее 😉
Поделюсь с вами простой фишкой для передачи результата из одной таски в другую в рамках дага airflow, которая делает код чище.
У инстанса task в Airflow есть свойство output, которое содержит вывод функции вызванной в рамках задачи. Наример, если это PythonOperator, то там будет то, что вы вернули в через return. Посмотрим пример 👀
Обычно некрасивый код выглядит примерно так
Обратите внимание на явную зависимость функции process_data от оркестрации: функция вынуждена знать о деталях реализации контекста airflow, о том что существует xcom, что существует инстанс task под названием generate_data_task. Жесть! 😭
Теперь красивый код
Здесь видно что функция process_data стала независимой и явно принимает конкретный объект event и работает только с ним, выполняет свою задачу и ничего не знает лишнего. Детали о том, что оказывается generate_data_task возвращает именно event и что его надо передать в функцию process_data_task для дальнейшей обработки держит только оркестратор. ☝️
📝 Главный эффект такого чистого кода в том, что каждая функция становится независимой и принимает явно нужные для ее работы аргументы и ничего не знает об оркестраторе, других задачах в даге, зависимостях от других задач и последующих задачах. Каждая функция изолированно выполняет свою работу и все. Это позволяет отделить оркестратор и логику в функциях, а значит функции можно переиспользовать много раз в разных дагах или вообще без дагов и airflow! Для самой функции не имеет значения как ее вызвали и кто передал аргументы: вы руками для теста, или какой-то оркестратор, или что угодно еще. 🙌
Бонус
Когда писал этот пост попробовал спросить у ChatGPT дать пример дага с передачей результата из такси в таску, намеренно не упоминая свойство output. Невероятно, но он так и не предложил использование этого метода, даже после нескольких моих запросов типа “а как еще можно?”. 🫣 Только после того как я явно ему написал, типа “что ты знаешь о свойстве output?” он таки написал мне что да, это классный метод и изолирует все ручные операции и отметил readability, seamless, avoiding manual handling, simplifying dependencies. Я, если честно офигел, что он сам это не предложил! 😮
Так что ловите крутой прием, о котором даже chatgpt вам не подскажет! 😎
©️ Если интересны и другие подобные приёмы и фишки, то ставьте сердечко и напишу ещё. ❤️
Поделюсь с вами простой фишкой для передачи результата из одной таски в другую в рамках дага airflow, которая делает код чище.
У инстанса task в Airflow есть свойство output, которое содержит вывод функции вызванной в рамках задачи. Наример, если это PythonOperator, то там будет то, что вы вернули в через return. Посмотрим пример 👀
Обычно некрасивый код выглядит примерно так
def generate_data():
return {"event": "order closed", "project": "superpuper", "value": 2}
def process_data(**kwargs):
# Access the previous task's result using ti
ti = kwargs['ti']
task_output = ti.xcom_pull(task_ids='generate_data_task') # Access the result
processed_value = task_output["value"] * 2
print(f"Processed value: {processed_value}")
# Define the DAG
with DAG(
dag_id='example_ti_result_dag',
start_date=datetime(2023, 1, 1),
schedule_interval=None,
catchup=False,
) as dag:
# Task 1: Generate data
generate_data_task = PythonOperator(
task_id='generate_data_task',
python_callable=generate_data,
)
# Task 2: Process data
process_data_task = PythonOperator(
task_id='process_data_task',
python_callable=process_data,
)
# Define task dependencies
generate_data_task >> process_data_task
Обратите внимание на явную зависимость функции process_data от оркестрации: функция вынуждена знать о деталях реализации контекста airflow, о том что существует xcom, что существует инстанс task под названием generate_data_task. Жесть! 😭
Теперь красивый код
def generate_data():
return {"event": "order closed", "project": "superpuper", "value": 2}
def process_data(event):
processed_value = event["value"] * 2
print(f"Processed value: {processed_value}")
with DAG(
dag_id='example_output_property_dag',
start_date=datetime(2023, 1, 1),
schedule_interval=None,
catchup=False,
) as dag:
generate_data_task = PythonOperator(
task_id='generate_data_task',
python_callable=generate_data,
)
process_data_task = PythonOperator(
task_id='process_data_task',
python_callable=process_data,
op_kwargs={'event': generate_data_task.output}, # Using the .output property
)
generate_data_task >> process_data_task
Здесь видно что функция process_data стала независимой и явно принимает конкретный объект event и работает только с ним, выполняет свою задачу и ничего не знает лишнего. Детали о том, что оказывается generate_data_task возвращает именно event и что его надо передать в функцию process_data_task для дальнейшей обработки держит только оркестратор. ☝️
Бонус
Когда писал этот пост попробовал спросить у ChatGPT дать пример дага с передачей результата из такси в таску, намеренно не упоминая свойство output. Невероятно, но он так и не предложил использование этого метода, даже после нескольких моих запросов типа “а как еще можно?”. 🫣 Только после того как я явно ему написал, типа “что ты знаешь о свойстве output?” он таки написал мне что да, это классный метод и изолирует все ручные операции и отметил readability, seamless, avoiding manual handling, simplifying dependencies. Я, если честно офигел, что он сам это не предложил! 😮
Так что ловите крутой прием, о котором даже chatgpt вам не подскажет! 😎
Please open Telegram to view this post
VIEW IN TELEGRAM
❤20👍6