Инжиниринг Данных
23.4K subscribers
1.92K photos
57 videos
191 files
3.16K links
Делюсь новостями из мира аналитики и карьерными советами.

15 лет в Аналитике и Инжиниринге Данных, 10 лет в MAANG

🛠️ dataengineer.ru | 🏄‍♂️ Surfalytics.com

№5017813306

Реклама:
https://almond-rule-130.notion.site/1199f595f76a8030ba1be1e607c9a8ce
Download Telegram
Где искать работу зарубежом?

Международные стартапы с русскоговорящими фаундерами или командами – один из эффективных способов получить оффер за рубежом сейчас.

Вакансии именно в таких компаниях собирают ребята в канале Connectable Jobs Abroad, а также делятся прямыми контактами HR для отклика.
Как результат – уже десятки читателей получили офферы в Neon, InDrive, 1inch, Wheely и др.

Несколько актуальных вакансий:
Junior Product Analyst в Nexters (remote или Армения, Казахстан, Кипр. Помогают с релокацией)
System Analyst (Back Operations for our newly acquired Bank) в Salmon (remote или помогают с релокацией на Филиппины)
Data Analyst (AppGrowth) в Appodeal (remote)
Data Engineer в UCRAFT (Ереван)

Еще у ребят есть отдельный канал с вакансиями только для аналитиков и дата инженеров

💙Подписывайтесь и развивайте карьеру в будущем единороге!
14💯6🫡4❤‍🔥3
Пример типичной организации в Северной Америке и расходов на data-инструменты. Компания на 1000+ человек.

Команда данных состоит почти из 20 человек, и структура примерно следующая:
- Director Data Engineering (подчиняется VP Engineering)
- Manager Data Engineering (Pipelines) — команда занимается интеграцией данных (загрузка данных в Staging).
- Manager Data Engineering (Data Warehouse) — команда занимается созданием хранилища данных поверх Staging, то есть моделированием данных, использует dbt и применяет бизнес-логику, чтобы создавать корпоративную модель данных и рассчитывать бизнес-показатели. Команда — смесь Data Engineering и Analytics Engineering.
- Manager Data Enablement — команда представляет собой смесь Analytics Engineering и BI-разработчиков, делает дашборды в Tableau/Looker и, по необходимости, дорабатывает модели в dbt (кустарным способом, далеким от лучших практик DE).

Инструменты, которые используются:
- Snowflake — $100k в месяц только за compute.
- Airflow — оркестрация, open source, хостится на AWS ECS.
- dbt core — SQL-трансформации, open source, запускается на AWS ECS.
- Alation — $170k в год, дата-каталог, документация по показателям. Идея была внедрить Data Governance, единый портал для бизнес-пользователей, но фактически затея провалилась.
- Looker — $120k в год, конкурирует с Tableau (Enterprise-лицензия, такая же безлимитная по пользователям, но за дорого), и поэтому Looker долго не продержится.
- Monte Carlo — $140k в год, отличный инструмент для отслеживания Data Observability, качества данных, часто выручает, когда даже dbt tests ничего не видят. Но честно говоря, дорого — это где-то 8-10% от стоимости Snowflake.
- Hightouch — $30k в год, интеграция с Salesforce, Marketo и другими инструментами. Можно условно бесплатно сделать то же самое через Python+Docker, но по опыту с такими решениями из подручных средств страдают инженеры, и у вас вечные проблемы с различными изменениями в API, rate limit и т.п.
- Fivetran — $45k в год, интеграция с API Salesforce, Gsheets, Marketo, Zendesk и т.п. Так как это малая часть данных, то и цена небольшая.

Это расценки чисто на data-команду, а ещё есть ML-команда, расходы на AWS для инфраструктуры, и самая дорогая часть всего — data platform команда, которая использует Apache Kafka и пишет в S3 данные из MongoDB, Postgres, Cloudflare, серверных логов, Syslog и т.п. Точных цифр нет, но только расходы на платформенную команду могут составлять несколько миллионов долларов.

Какие выводы из этого маленького примера:

- Аналитика — это дорого.
- Облака — это дорого.
- Compute всегда дорого.
- Storage дорого.
- Использовать вендора — очень дорого, и ещё vendor lock в придачу.
- Инженеры — очевидно дорогие.
- Использовать бесплатный open-source — тоже дорого, и часто цена команды компенсирует цену лицензии.
- А самое дорогое — это уволить старую команду и нанять новую, чтобы новая всё починила и наконец-то показала ROI аналитики (хотя если старая не смогла, то и новая не факт, что поможет; хотя если мигрировать Snowflake на Databricks или наоборот, то на пару лет все будут заняты!).

Как ни крути — всё дорого.

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

Если команда использует open-source, старайтесь, чтобы все хорошо понимали, как это работает и как это обслуживается, иначе это будет black box и технический долг. Чаще проводите ревизию и удаляйте ненужные куски кода, старые pipelines, отчёты, dbt-модели и т.п. Сделайте leaderboard и пусть у вас будут top performers — те, кто удаляет старый и ненужный код.

И самое главное, обязательно фокус на business value, хотя это и так очевидно. Нужно балансировать между тем, что нужно бизнесу прямо сейчас и тем, что будет хорошо для аналитического решения и команды.

И чисто для инженеров было бы хорошо иметь 100% прозрачность в performance review, честный разговор о перспективах в компании. А то любят наобещать всего и побольше потом, а по факту 2% индексации🦯
Please open Telegram to view this post
VIEW IN TELEGRAM
68❤‍🔥21💯7👨‍💻6🤷‍♂1🍾1
Недавно попалась статья Hh.ru назвал российские компании с самой высокой зарплатой курьеров. Зарплаты курьеров до 250т рублей в Москве это круто. Мне кажется в среднем BI разработчик получает до 200х тысяч. Получается отличная работа на свежем воздухе и не нужно сидеть за компьютером.

Я кстати работал курьером несколько лет, так как ничего другого не мог найти в 11м классе и на первых курсах университета. Сначала я работал в тур фирме, а потом развозил платежи от 1С конторы. И уже тогда я делегировал часть заказов своему дедушке. Правда деньги были смешные, но самый крутой навык это ориентация на местности и карте (раньше не было gps и навигаторов), а была книжка с картой Москвы. И заодно очень хорошо знал Москву.

Может есть ниша онлайн курсов курьеров и insights как совмещать 2-3 работы доставки и outsource своих заказов?!
❤‍🔥2314🐳5
Знаете ли вы, что такое хранимые процедуры? Раньше в Oracle, SQL Server, Teradata без них никуда было не деться. На всех работах, где эти мастодонты хранилищ данных использовались, всегда применялись процедуры.

Например, Oracle PL/SQL — мощная штука, которая позволяет создавать ETL, не отходя от кассы выходя из Oracle. Это было задолго до появления всех ништяков в Python.

Я всегда думал, что хранимые процедуры для «олдов» (такой термин вообще существует?). Помню, как пришёл в Amazon в 2016 году, а там Oracle on-premises и весь ETL на PL/SQL. Прямо как в dbt: последовательность SQL-трансформаций (теперь это называется DAG), разные функции и даже возможность забирать данные из SFTP, API и других систем.

Тогда я все это дело переделал на Redshift + Matillion ETL. Подумал тогда: «Что за смех, мы тут в облаке AWS строим modern data stack (кстати, в 2016 году такой термин ещё не использовался), а они тут со своим PL/SQL и Git в Bitbucket». Теперь у нас low/no code (тоже не использовал такой термин), и я мышкой всё сделаю. И я, конечно, всё сделал, и оно до сих пор работает, но я бы им порекомендовал перейти на dbt и вообще подумать про Analytics/Infra as a code 😛

Самое интересное, что недавно у меня была задача затягивать данные из backend в Azure (Azure SQL, CosmosDB), и, очевидно, я использовал Azure Data Factory. Но ADF сам ничего не умеет. Там есть отличная интеграция между всеми сервисами Azure, и можно из любого сервиса выгрузить в Azure Storage. Но если я хочу реализовать инкрементальную загрузку, slowly changing dimensions, snapshots и т.п., мне нужно где-то хостить свою логику.

И я не придумал ничего лучше, чем использовать хранимые процедуры Snowflake. Там есть много вариантов: хочешь — пиши на SQL, хочешь — на JavaScript. В общем, я всю логику положил в Stored Procedures, и всё работает замечательно.

Вот пример:


create or replace procedure CONFIG.UPDATE_WATERMARK_JOB(SCHEMA_NAME VARCHAR, PIPELINE_NAME VARCHAR,
START_TIMESTAMP TIMESTAMP_NTZ, END_TIMESTAMP TIMESTAMP_NTZ,
SOURCE VARCHAR, TABLE_NAME VARCHAR,
LAST_CREATED_TIMESTAMP TIMESTAMP_NTZ,
LAST_UPDATED_TIMESTAMP TIMESTAMP_NTZ)
returns VARCHAR
language SQL
strict
as
$$
BEGIN

INSERT INTO raw.config.watermark_table
(schema_name, pipeline_name, start_timestamp, end_timestamp, source, table_name, last_created_timestamp, last_updated_timestamp)
VALUES
(schema_name, pipeline_name, start_timestamp, CONVERT_TIMEZONE('UTC', CURRENT_TIMESTAMP()), source, table_name, last_created_timestamp, last_updated_timestamp);

RETURN 'Success';
END;
$$;


Получается, что всё новое — это хорошо забытое старое!

Как у вас дела обстоят с хранимыми процедурами?
54🫡13🐳7❤‍🔥44
Николай Валиотти из @leftjoin ежегодно проводит независимое исследование онлайн-курсов по аналитике.

Гарантия трудоустройства, новая профессия в кратчайшие сроки, высокая зарплата и успешная жизнь после прохождения курсов — так ли все прекрасно, как обещают в популярных онлайн-школах?

Так что, если вы не так давно проходили курсы или осваивали профессию аналитика в онлайн-школе, пройдите опрос и напишите свое мнение. Пожалуй, тот самый случай, когда оно искренне важно для всех.

Будет отличный вариант рассказать все хорошее или плохое про курсы, и тот случай когда можно указать Data Learn (бесплатный курс на русском - от Excel до Spark и BigData) или Surfalytics (бесплатный курс на английском, где за основу я взял data learn но улучшил).

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

🔜 ссылка на опрос.

P.S. Ответы принимаются до 19 сентября включительно, поэтому не откладывайте это дело в долгий ящик.

P.P.S. А еще мы обсудили с Колей о подкасте, где обсудим вопрос развитие карьеры в сторону создания своего консалтинга, сложность service business, масштабирование, плюсы и минусы и вообще Коля расскажет свою история о создании успешной международной компании. Уверен будет много интересных тем подискутировать.
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤‍🔥92🌭1
Типичная задачка для ETL разработчик data engineer.

У нас есть приложение и у него есть backend база данных (она же OLTP).

Если вы еще изучаете, то вам нужно ответить сразу на два вопроса:
1) ETL vs ELT в чем собственно разница. Чтобы ответить, надо не chatGPT спрашивать, а прям реально самому попробовать на примере БД локальной, и прочувствовать разницу
2) OLTP vs хранилище данных, часто это называют OLAP, но я не люблю называть аналитические запросы OLAP, потому что это пересекается с MOLAP (кубы MS Analysis Services и язык MDX) или ROLAP (что по сути происходит в любом современном BI, когда с помощью запроса мы кешируем результат SQL и потом его slice and dice

У нас простая задача - нужно в отчете показать количество пользователей.

И тут сразу должны возникнуть вопросы:
Что такое пользователь?
Как его идентифицировать?
В какой таблице найти?
Как к нему подключиться?
Сколько там данных? (Строк)
А можно ли нагружать эту базу данных своими запросами? Вдруг это production БД

Ок, у нас реплика (тоже надо знать, что это такое, и как ее создают в backend). Мы можем к ней подключаться по JDBC/ODBC через SQL клиент, или даже BI инструмент, чтобы изучить данные. Как раз тот самый запрос поможет:


select * from users limit 10


Обязательно нужно узнать про уникальный ключ в этой таблице. Он нам поможет избежать дубликатов, так сказать uniqueness test. И еще можно отслеживать freshness таблица по какому-нибудь timestamp.

Дальше нам надо придумать как эту табличку тянуть в хранилище данных, обычно в staging слой. И тут есть разные способы и инструменты (их не так много). Например, мы можем использовать Change Data Capture метод, который позволяет нам копировать только свежие и измененные данные, я это еще называю incremental загрузка. Альтернатива это full reload.

Если вы посмотрите инструменты Fivetran, Airbyte, Meltano, Matillion - все они предлагают вам похожие способы забора и загрузки данных.

Ок, нам повезло - наша таблица содержит два ключевых timestamp:
- created_at
- updated_at
И мы можем использовать подход с watermark, то есть хранить последнее значение (или находить его) перед запуском загрузки, и при каждом запуске ETL job, мы просто должны:


select *
from users
where created_at >= $parameter or updated_at >= $parameter


Но не забывайте самое главное свойство ETL pipelines - idempotent - то есть если каким-то образом мы выполним один и тот же job много раз, результат будет всегда такой же.

Для этого при incremental (инкрементальной) загрузке у нас есть варианты разные DELETE/INSERT, UPSERT, MERGE, UPDATE/INSERT и зависит это от данных и возможностей базы данных.

Например для таблиц с логами, у нас история не меняется и всегда APPEND, то есть данные добавляются, и отлично подходит DELETE/INSERT, а для таблички с пользователями у нас для каждого USER_ID могу поменяться атрибуты, поэтому мы будем использовать UPSERT. Для этого важно знать уникальный ключа в таблице!

Выше я писал про свой подход с Snowflake Procedure, но это можно реализовать множеством других способов и инструментов. Главное суть остается та же.

Теперь у нас есть таблица с пользователями, которая обновляется каждый день. И у для разработчика сразу должны возникнуть вопросы к заказчику, так сказать уточнение требований отчета:
🫡36👨‍💻13🐳6
1) Мы хотим видеть просто абсолютное кол-во пользователей?
2) Если пользователей изменил пол (про это как то была дискуссия в телеге, про пример об неизменных dimension как пол клиента), но это было в прошлом, теперь все бывает, и разработчик должен быть готов использовать Slowly Change Dimensions, и хотя бы согласовать, что делать с изменением. Можно просто перезаписать (Type 1) или написать, что раньше пол-то был другой (Type 2). Реальные проблемы западных инженеров!
3) А еще вопрос, интересный, если пользователь удалился из backend, он же ведь все равно остался в хранилище данных и его может надо пометить как IS_DELETED. А для этого нам уже придется сравнивать полный snapshot и текущею базу и находить удаленных клиентов.
4) И возможно, мы хотим видеть историю роста, вчера было 100 клиентов, а сегодня 110, то есть нам надо делать SNAPSHOTS раз в день.

Казалось бы такая простая задача, а сколько возможностей. Самое интересное, что практически во всех организациях, где есть хранилище данных это делают. Часто терминология разная, но идея остается прежней, и ей уже лет 30 если не больше. И для этого не нужно знать ни python, ни Hadoop, ни streaming. Просто SQL и пару приемов, как данные сделать полезными для конечного потребителя.

Поэтому прежде чем получать сертификаты dbt, snowflake, Databricks и тп, попробуйте на локальной базе разобраться с этими вещами и потом будет легче делать все тоже самое но уже на modern data stack за хорошую денюшку.
1🫡46❤‍🔥13👨‍💻10🐳11
Коллеги из проекта @easy_report проведут 19 сентября вебинар, на котором поделятся опытом применения ИИ в BI в крупных российских компаниях.

🔥Тема вебинара: Как ИИ в BI меняет взаимодействие с данными. Сценарии применения BI-ассистента Easy Report

❗️Дата: 19 сентября 2024 года
❗️Время: 11:00 Мск, продолжительность – 1 час
❗️Участие бесплатное, требуется регистрация.

⬇️Содержание вебинара:

1. Применение ИИ в современных BI-решениях.
2. Эволюция self-service аналитики: как пользователи могут самостоятельно получать нужные данные без помощи ИТ-специалистов.
3. Реальные сценарии применения первого российского BI-помощника с ИИ – Easy Report.
4. Демонстрация работы Easy Report:
- обработка запросов на естественном языке,
- формирование отчетов и вычисления “на лету”,
- интерактивные графики в мессенджере,
- data alerts и др.


🚀Регистрация и подробности.
❤‍🔥93
🙈2717💯5
Как вы относитесь к 1:1, One-on-One, OOO встречам? И практикуются ли они у вас?

1:1 — это встреча между менеджером и его подчиненным (direct report), как правило, раз в неделю или раз в две недели на 30 минут.

Например, в РФ и в старых предприятиях такого не было, а вот в Amazon, Microsoft и других есть.

Так как я в Канаде проработал за 10 лет в 13-ти командах, 10 компаниях, из них 3 команды были в Amazon и 3 команды в Microsoft, то в каждой компании было по-своему. Мне вообще нравится сравнивать компании, менеджеров, культуру между собой. Когда менеджер со мной общается, я обычно смотрю не на то, что он мне говорит, а на то, как он это говорит. Чувствую себя исследователем корпоративной и стартап-культур, смотрю, что работает, а что нет. А главное, каким образом я могу управлять ожиданиями моего менеджера, чтобы не скатывалось все в микроменеджмент.

Поэтому интересно узнать ваше мнение пока только об аспекте 1:1 встреч. Если вы подчиненный, проводит ли ваш менеджер с вами такие встречи, как часто, полезно ли это? А если менеджер, проводите такие встречи с подчиненными, как часто, помогает?

В следующем посте уже напишу про эти встречи с “научной точки” зрения по книжкам для “эффективных менеджеров”.😝
Please open Telegram to view this post
VIEW IN TELEGRAM
1🫡28❤‍🔥97🌚4
Вопрос про 1:1 возник после книги. Я прослушал книгу The Effective Manager by Mark Horstman. Книгу нашёл в подписке Audible на распродаже. Кстати, на русском книга называется “Управляй как бог менеджмента 🔫😊🔫: Инструменты выдающегося руководителя”

Книга небольшая, и в ней много практических примеров.

Вообще, вот краткое содержание по главам:

Глава 1: Проведение эффективных индивидуальных встреч (One-on-Ones)

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

Глава 2: Давать конструктивную обратную связь

Марк Хорстман объясняет, как правильно давать обратную связь, которая способствует росту и улучшению работы сотрудников. Он выделяет ключевые принципы, такие как своевременность, конкретность и объективность. Важно не только указывать на ошибки, но и признавать достижения, что повышает мотивацию и укрепляет рабочие отношения.

Глава 3: Эффективный коучинг и развитие сотрудников

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

Глава 4: Делегирование задач и ответственности

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

Глава 5: Управление временем и приоритетами

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


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

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

Сотрудники должны работать много, хорошо, качественно, самостоятельно, с высокой отдачей, то есть иметь высокий КПД. Задача менеджера — создать условия, в которых это возможно. И как раз встречи 1:1 очень способствуют этому.

То есть в книге доказано, что при правильном использовании такого формата встреч это будет полезно для бизнеса, поэтому тут не обсуждается вопрос — нравятся они или нет. Как говорится — “нравится, не нравится, терпи моя красавица”.

Я прекрасно понимаю менеджеров, которым эти встречи надоели, и ещё больше понимаю сотрудников, которых эти встречи бесят. К сожалению для тех и других в книге очень развернуто написано, почему это плохо и что это показатель плохой вовлечённости. Ну если по-русски, значит таких людей, конечно, можно попробовать переубедить (и в книге даны примеры), но в целом это говорит о начале конца, и таких людей можно считать неэффективными, опять же в книге это обосновано почему.
Please open Telegram to view this post
VIEW IN TELEGRAM
22🐳3👨‍💻3💯2🙈2
Например, если менеджеру тяжело проводить 1:1 с его командой, возможно, у него очень большая команда. А ведь Безос нас учил — эффективная команда — это команда размером с две пиццы (2-pizza size). Может быть, у вас слишком много подчинённых? А может быть, вам надоело делать то, что вы делаете, и роль менеджера по работе с людьми (people manager) — это не ваше, а ваша роль — Individual Contributor?

А если вы инженер и вы терпеть не можете митинги, очевидно, такие встречи для вас могут казаться бесполезными. Хотят, тут многое зависит от менеджера и ваших способностей. Например, вы работаете над задачей и вам не хватает информации, как её делать, на встрече 1:1 ваш менеджер может вам подсказать и показать. Очевидно, такие встречи полезны. А если ваш менеджер не очень технический, то он просто будет требовать отчёты по статусу и срокам.

Как вы сами видите по комментариям в прошлом посте, подчинённым и менеджерам не нравятся лишние митинги, но таков путь.😎

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

Для меня встреча 1:1:
- Задать вопросы по проектам, где я заблокирован (полезно)
- Поговорить 5–10 минут ни о чём о том, как дела, как дети и отпуска (бесполезно)
- Выполнять формальности по оценке эффективности (performance review), заполнению документов и обязательных форм (нужно)
- Рассказать о своих успехах и достижениях (бесполезно, но создает видимость, что тебя хвалят и любят, и чувствуешь себя полезным)

Самое главное, что вам нужно знать о встречах 1:1 — это то, что они не предназначены для разговора о повышении. Конечно, они подразумевают общение на тему карьерного роста и развития карьеры, что сулит вам в лучшем случае 2% индексацию в год, а если вам повезёт — 10–15% при повышении. Поэтому важно понимать: ваше ментальное здоровье — это ваша ответственность, и на работу надо приходить без карьерных ожиданий, тогда стресса не будет. Что касается денег, это вопрос job hopping, job stacking, side hustle. К этому тоже надо прийти путем проб и ошибок.

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

П.С. Вообще понятие карьеры — это не обязательно работа “на дядю” в офисе 5 дней в неделю. Это ваш путь, где вам нужно что-то делать, что вам не противно и что приносит удовольствие, и за это хорошо платят или в долгой перспективе вам хорошо будут платить. Сюдя подходят и pet проекты, стартапы, и блоги, и свои каналы в Телеграме или YouTube. Главное — не быть зацикленным на текущей работе, особенно если вы чувствуете, что выгораете. То есть это не параллельная реальность.

У нас не должно быть двух реальностей — одна домашняя, личная жизнь, а другая карьера. У меня эти вещи переплетаются. Например, я использую единый календарь для всего, беру детей на конференции (брал на Snowflake в Лас-Вегас) или поездки в офис. Даю детям доступ в Slack, чтобы они могли помогать мне отвечать коллегам, когда я за рулем, если мы в поездке. Прошу жену заполнить Excel-таблицу. загрузить расходы и тп. Такое совмещение позволяет мне не разделять личную жизнь и работу и возможно это ответ на частый вопрос - “Как я все успеваю?”

Известный факт: человек — кузнец своего счастья, поэтому не нужно обижаться на менеджера или коллегу за свои неудачи, а лучше потратить энергию на то, чтобы стать лучше.💞
Please open Telegram to view this post
VIEW IN TELEGRAM
368❤‍🔥35🤷5🫡3🤷‍♀1🌭1😭1
Чем заместить SAP BW так, чтобы работало не хуже?

Компания-интегратор решила этот вопрос для своих заказчиков, предложив миграцию на комплекс российских и open source решений. На вебинаре 25 сентября эксперты из Sapiens solutions, Иннотех и Arenadata расскажут, как при реализации такого проекта в крупном системообразующем банке удалось нивелировать риски и получить качественный результат.

Тема вебинара:
Мигрируем аналитическую отчетность с SAP BW на импортонезависимый стек. Кейс клиента

Дата вебинара: 25.09.2024
Время начала: 11:00 Мск

Регистрация обязательна


❗️Ключевые моменты вебинара:

Кейс реализации проекта по импортозамещению SAP BW в системообразующем российском банке (целевая архитектура, проблемы и решения, подходы к оценке обьемов работ и приоритизации и др.)

Техническая реализация проекта (особенности реализации экстракции из ERP, реализация хранилища данных, доработка open source и др.)

Поддержка Arenadata


До встречи на вебинаре!
7❤‍🔥3🍌1🍾1👨‍💻1
Все чаще мелькает информация про YAML инженера.

Вот несколько статей:
YAML developers and the declarative data platforms

The rise of the YAML engineer

From Data Engineer to YAML Engineer

Data Orchestration Trends: The Shift From Data Pipelines to Data Products

Dbt модели у меня безусловно лидируют, так же использовал для Mock тестов в Pytest и Helm Charts и Kubernetes.
🐳4
Forwarded from BeOps
Книга Kubernetes in Action (2nd edition by Marko Lukša, Kevin Conner) — отличный старт для знакомства с Kubernetes

Когда я начал читать книгу Kubernetes in Action, сразу понял — это не просто теория. Автор делает акцент на понятном объяснении того, что такое Kubernetes, как он работает и почему его популярность так стремительно выросла. Честно говоря, я был впечатлен уже с первых страниц.

Что мне особенно понравилось

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

Теперь давайте разберем основные идеи первых глав (1.1 Introducing Kubernetes - 1.2 Understanding Kubernetes), которые привлекли мое внимание.

---

Введение в Kubernetes: Зачем это нужно?

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

Причем, как отмечает автор, имя Kubernetes символично. Как штурман направляет корабль, так Kubernetes направляет ваше приложение, оставляя за вами только ключевые решения.

---

Почему Kubernetes стал таким популярным?

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

---

Как Kubernetes решает повседневные задачи?

Читая книгу, я понял: Kubernetes — это не просто система для развертывания приложений. Это целая экосистема, которая позволяет автоматически управлять масштабированием, следить за здоровьем приложения и даже восстанавливаться после сбоев. Если ваше приложение упало — Kubernetes сам перезапустит его. А если произошел сбой оборудования, Kubernetes перенесет работу на здоровые узлы. Все это экономит время и нервы.

---

Основные компоненты Kubernetes

Автор подробно объясняет архитектуру Kubernetes, разделяя её на две главные плоскости: Control Plane и Workload Plane. Control Plane управляет состоянием всего кластера, а Workload Plane — это место, где запускаются приложения. Все выглядит логично, и благодаря иллюстрациям с каждым компонентом становится легче разобраться.

---

Личный опыт

Для меня этот материал стал отличным введением в тему. Книга Kubernetes in Action помогает понять не только теоретические основы, но и показывает, как Kubernetes действительно работает на практике. А самое главное — автор делает это легко и доступно, с примерами и наглядными пояснениями. Если вы хотите погрузиться в мир Kubernetes — это идеальная отправная точка.

От себя же я составил Mind Map первых двух частей, которым хотел бы поделиться в этом посте (пока что ссылкой на dropbox)

- https://www.dropbox.com/scl/fi/9fv5og1cchp44kofi9h0p/Kubernetes-in-Action-till-1.3.pdf?rlkey=vus4tw7vsrqf15naerns2x12v&st=6miusxfn&dl=0

Обзор следующих частей опубликую очень скоро🛥
❤‍🔥24🫡6🐳2
Собеседования тоже можно в бане проводить! Баня топчик!
❤‍🔥105
Forwarded from Невыно[Симов]
Сегодня первый раз побывал в общественном разряде бани.

Баня — это заебись! И вот почему:
♨️ Контекст максимально располагает к открытому и прямолинейному общению. Вместе с одеждой и аксессуарами спадает напускной флер, остается, так сказать, фактура. Это очень меняет ракурс восприятия себя самого и других людей;

♨️ Методичный алгоритм действий помогает переключиться и сосредоточиться на ощущениях, тело становится первостепенным, разум и рефлексия отходят на второй план;

♨️ Вокруг — разные, непохожие друг на друга люди, которым абсолютно все равно, кто ты за пределами этих стен.

💡Outcome на будущее: если хочешь получше узнать человека, сходи с ним в баню.
💯369🐳4
Еще один отзыв на Surfalytics/менторство.

Товарищ реально справился и смог себя мотивировать и как он правильно отметил - это «марафон», нужно терпение.

Впереди еще много работы, потому что на одну работу в Канаде особо не разгуляешься🤑

Как я искал работу в Канаде
Всем привет! Хочу поделиться историей сначала неуспеха, а потом успеха, к которому я шел почти год. Сейчас будет большое интро для контекста, но если это неинтересно, то можно сразу переходить к части про дата инженера.

Я переехал в Канаду год назад и почти сразу занялся поиском работы. Одновременно с этим я продолжал работать на компанию в Москве и работал по ночам из-за разницы во времени. Я работал риск-аналитиком уже 10 лет на тот момент и понял, что устал от рисков и решил, что переезд в другую страну это отличная возможность сменить профессию. Как же я ошибался.

Я стал искать работу дата аналитиком, откликнулся на 220 вакансий, прошел 16 интервью, но везде получал отказы. Потом я уволился из московской компании и решил искать работу в рисках.

Статистика стала намного лучше.

Откликнулся на 35 вакансий, прошел 7 интервью, в двух компаниях дошел до последнего этапа, но все равно везде получил отказы. Вообще работа в банковской сфере и особенно в рисках сильно отличается от рынка в России, так как крупных банков всего 5 и все главные офисы в Торонто.

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

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

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

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

В итоге за 3 месяца я откликнулся на 45 вакансий, прошел 8 интервью и наконец-то получил заветный оффер. Получилась статистика по поиску как в рисках, но деньги и перспективы гораздо выше, т.к. уровень зарплат у Дата инженеров примерно как у менеджеров и директоров в рисках, а количество таких вакансий очень ограничено по сравнению с инженерными позициями.

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

Главное не опускать руки, все отказы превращать в преимущество на следующем собеседовании, анализировать ошибки (в этом очень помогает запись интервью) и постоянно улучшать свои навыки.


#testimmonial
Please open Telegram to view this post
VIEW IN TELEGRAM
❤‍🔥61🐳26💯54👨‍💻2
Как работать с SQL запросами 🛠

Сделали небольшой коллаб с Димой Аношиным (Surfalytics) про работы с SQL. Дима как супер эксперт по дата инжинирингу рассказал про более правильную работу с SQL с точки зрения хранения и обработки кода. Так что много про версионирование, гит и качество данных. А от меня немного про форматирование SQL запросов для лучшей читабельности.

- Часть 1: версионирование, гит и первый pull request
- Часть 2: документация, code review и sql стайлгайд
❤‍🔥6822🗿6