Чем заместить SAP BW так, чтобы работало не хуже?
Компания-интегратор решила этот вопрос для своих заказчиков, предложив миграцию на комплекс российских и open source решений. На вебинаре 25 сентября эксперты из Sapiens solutions, Иннотех и Arenadata расскажут, как при реализации такого проекта в крупном системообразующем банке удалось нивелировать риски и получить качественный результат.
Тема вебинара:
Мигрируем аналитическую отчетность с SAP BW на импортонезависимый стек. Кейс клиента
Дата вебинара: 25.09.2024
Время начала: 11:00 Мск
Регистрация обязательна
❗️Ключевые моменты вебинара:
✅ Кейс реализации проекта по импортозамещению SAP BW в системообразующем российском банке (целевая архитектура, проблемы и решения, подходы к оценке обьемов работ и приоритизации и др.)
✅ Техническая реализация проекта (особенности реализации экстракции из ERP, реализация хранилища данных, доработка open source и др.)
✅ Поддержка Arenadata
До встречи на вебинаре!
Компания-интегратор решила этот вопрос для своих заказчиков, предложив миграцию на комплекс российских и open source решений. На вебинаре 25 сентября эксперты из Sapiens solutions, Иннотех и Arenadata расскажут, как при реализации такого проекта в крупном системообразующем банке удалось нивелировать риски и получить качественный результат.
Тема вебинара:
Мигрируем аналитическую отчетность с SAP BW на импортонезависимый стек. Кейс клиента
Дата вебинара: 25.09.2024
Время начала: 11:00 Мск
Регистрация обязательна
❗️Ключевые моменты вебинара:
✅ Кейс реализации проекта по импортозамещению SAP BW в системообразующем российском банке (целевая архитектура, проблемы и решения, подходы к оценке обьемов работ и приоритизации и др.)
✅ Техническая реализация проекта (особенности реализации экстракции из ERP, реализация хранилища данных, доработка open source и др.)
✅ Поддержка Arenadata
До встречи на вебинаре!
Все чаще мелькает информация про 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.
Вот несколько статей:
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
Обзор следующих частей опубликую очень скоро🛥
Когда я начал читать книгу 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
Обзор следующих частей опубликую очень скоро🛥
Dropbox
Kubernetes in Action till 1.3.pdf
Shared with Dropbox
❤🔥24🫡6🐳2
Forwarded from Невыно[Симов]
Сегодня первый раз побывал в общественном разряде бани.
Баня — это заебись! И вот почему:
♨️ Контекст максимально располагает к открытому и прямолинейному общению. Вместе с одеждой и аксессуарами спадает напускной флер, остается, так сказать, фактура. Это очень меняет ракурс восприятия себя самого и других людей;
♨️ Методичный алгоритм действий помогает переключиться и сосредоточиться на ощущениях, тело становится первостепенным, разум и рефлексия отходят на второй план;
♨️ Вокруг — разные, непохожие друг на друга люди, которым абсолютно все равно, кто ты за пределами этих стен.
💡Outcome на будущее: если хочешь получше узнать человека, сходи с ним в баню.
Баня — это заебись! И вот почему:
♨️ Контекст максимально располагает к открытому и прямолинейному общению. Вместе с одеждой и аксессуарами спадает напускной флер, остается, так сказать, фактура. Это очень меняет ракурс восприятия себя самого и других людей;
♨️ Методичный алгоритм действий помогает переключиться и сосредоточиться на ощущениях, тело становится первостепенным, разум и рефлексия отходят на второй план;
♨️ Вокруг — разные, непохожие друг на друга люди, которым абсолютно все равно, кто ты за пределами этих стен.
💡Outcome на будущее: если хочешь получше узнать человека, сходи с ним в баню.
💯36
Еще один отзыв на Surfalytics/менторство.
Товарищ реально справился и смог себя мотивировать и как он правильно отметил - это «марафон», нужно терпение.
Впереди еще много работы, потому что на одну работу в Канаде особо не разгуляешься🤑
Как я искал работу в Канаде
Всем привет! Хочу поделиться историей сначала неуспеха, а потом успеха, к которому я шел почти год. Сейчас будет большое интро для контекста, но если это неинтересно, то можно сразу переходить к части про дата инженера.
Я переехал в Канаду год назад и почти сразу занялся поиском работы. Одновременно с этим я продолжал работать на компанию в Москве и работал по ночам из-за разницы во времени. Я работал риск-аналитиком уже 10 лет на тот момент и понял, что устал от рисков и решил, что переезд в другую страну это отличная возможность сменить профессию. Как же я ошибался.
Я стал искать работу дата аналитиком, откликнулся на 220 вакансий, прошел 16 интервью, но везде получал отказы. Потом я уволился из московской компании и решил искать работу в рисках.
Статистика стала намного лучше.
Откликнулся на 35 вакансий, прошел 7 интервью, в двух компаниях дошел до последнего этапа, но все равно везде получил отказы. Вообще работа в банковской сфере и особенно в рисках сильно отличается от рынка в России, так как крупных банков всего 5 и все главные офисы в Торонто.
Как я стал Дата инженером
После этого я решил вернуться к тому с чего начал, к поиску работы дата аналитиком или даже замахнуться на позицию дата инженера.
Работа в сфере данных давала больше возможностей, как по зарплате, так и по количеству вакансий. Но мне было очень тяжело начинать заново искать и учиться после неудачных поисков в прошлом, а тем более искать на Дата инженера, это казалось совсем другим уровнем. Дима начал помогать мне с поисками, подсказывал какие инструменты изучать, как улучшить резюме.
Пошли первые собеседования и первые отказы, которые помогали понять слабые стороны, улучшить их и быть готовым к следующему интервью.
По большому счету вопросы повторяются из раза в раз, просто нужно понять перед собеседованием основные боли интервьюера и рассказывать об этом.
В итоге за 3 месяца я откликнулся на 45 вакансий, прошел 8 интервью и наконец-то получил заветный оффер. Получилась статистика по поиску как в рисках, но деньги и перспективы гораздо выше, т.к. уровень зарплат у Дата инженеров примерно как у менеджеров и директоров в рисках, а количество таких вакансий очень ограничено по сравнению с инженерными позициями.
Вывод из всего этого я сделал такой - поиск работы это марафон, важно постоянство в откликах и всё прочее, о чем говорят многие, это действительно так и есть, и это помогает, но еще больше помогает, если есть человек, который направляет в этом пути.
Главное не опускать руки, все отказы превращать в преимущество на следующем собеседовании, анализировать ошибки (в этом очень помогает запись интервью) и постоянно улучшать свои навыки.
#testimmonial
Товарищ реально справился и смог себя мотивировать и как он правильно отметил - это «марафон», нужно терпение.
Впереди еще много работы, потому что на одну работу в Канаде особо не разгуляешься
Как я искал работу в Канаде
Всем привет! Хочу поделиться историей сначала неуспеха, а потом успеха, к которому я шел почти год. Сейчас будет большое интро для контекста, но если это неинтересно, то можно сразу переходить к части про дата инженера.
Я переехал в Канаду год назад и почти сразу занялся поиском работы. Одновременно с этим я продолжал работать на компанию в Москве и работал по ночам из-за разницы во времени. Я работал риск-аналитиком уже 10 лет на тот момент и понял, что устал от рисков и решил, что переезд в другую страну это отличная возможность сменить профессию. Как же я ошибался.
Я стал искать работу дата аналитиком, откликнулся на 220 вакансий, прошел 16 интервью, но везде получал отказы. Потом я уволился из московской компании и решил искать работу в рисках.
Статистика стала намного лучше.
Откликнулся на 35 вакансий, прошел 7 интервью, в двух компаниях дошел до последнего этапа, но все равно везде получил отказы. Вообще работа в банковской сфере и особенно в рисках сильно отличается от рынка в России, так как крупных банков всего 5 и все главные офисы в Торонто.
Как я стал Дата инженером
После этого я решил вернуться к тому с чего начал, к поиску работы дата аналитиком или даже замахнуться на позицию дата инженера.
Работа в сфере данных давала больше возможностей, как по зарплате, так и по количеству вакансий. Но мне было очень тяжело начинать заново искать и учиться после неудачных поисков в прошлом, а тем более искать на Дата инженера, это казалось совсем другим уровнем. Дима начал помогать мне с поисками, подсказывал какие инструменты изучать, как улучшить резюме.
Пошли первые собеседования и первые отказы, которые помогали понять слабые стороны, улучшить их и быть готовым к следующему интервью.
По большому счету вопросы повторяются из раза в раз, просто нужно понять перед собеседованием основные боли интервьюера и рассказывать об этом.
В итоге за 3 месяца я откликнулся на 45 вакансий, прошел 8 интервью и наконец-то получил заветный оффер. Получилась статистика по поиску как в рисках, но деньги и перспективы гораздо выше, т.к. уровень зарплат у Дата инженеров примерно как у менеджеров и директоров в рисках, а количество таких вакансий очень ограничено по сравнению с инженерными позициями.
Вывод из всего этого я сделал такой - поиск работы это марафон, важно постоянство в откликах и всё прочее, о чем говорят многие, это действительно так и есть, и это помогает, но еще больше помогает, если есть человек, который направляет в этом пути.
Главное не опускать руки, все отказы превращать в преимущество на следующем собеседовании, анализировать ошибки (в этом очень помогает запись интервью) и постоянно улучшать свои навыки.
#testimmonial
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥61🐳26💯5⚡4👨💻2
Forwarded from настенька и графики
Как работать с SQL запросами 🛠
Сделали небольшой коллаб с Димой Аношиным (Surfalytics) про работы с SQL. Дима как супер эксперт по дата инжинирингу рассказал про более правильную работу с SQL с точки зрения хранения и обработки кода. Так что много про версионирование, гит и качество данных. А от меня немного про форматирование SQL запросов для лучшей читабельности.
- Часть 1: версионирование, гит и первый pull request
- Часть 2: документация, code review и sql стайлгайд
Сделали небольшой коллаб с Димой Аношиным (Surfalytics) про работы с SQL. Дима как супер эксперт по дата инжинирингу рассказал про более правильную работу с SQL с точки зрения хранения и обработки кода. Так что много про версионирование, гит и качество данных. А от меня немного про форматирование SQL запросов для лучшей читабельности.
- Часть 1: версионирование, гит и первый pull request
- Часть 2: документация, code review и sql стайлгайд
❤🔥68⚡22🗿6
fundamentals-of-data-engineering.pdf
7.6 MB
Наверно уже все и так скачали книгу Fundamentals of Data Engineering, но вот есть легальная ссылка на скачку.
Я сам прочитал только 3 главы. На каждую тему в книге у меня мысли были примерно такие - “ага, знаю”, “так, все правильно”, “точно, согласен” и тп.
То есть с одной стороны книга включает в себя многие аспекты инжиниринга данных, а с другой стороны она теоретическая и для новичков будет непонятна, потому что нет контекста и упражнений.
А вы читали?
Я сам прочитал только 3 главы. На каждую тему в книге у меня мысли были примерно такие - “ага, знаю”, “так, все правильно”, “точно, согласен” и тп.
То есть с одной стороны книга включает в себя многие аспекты инжиниринга данных, а с другой стороны она теоретическая и для новичков будет непонятна, потому что нет контекста и упражнений.
А вы читали?
❤🔥50
Media is too big
VIEW IN TELEGRAM
Сегодня был интересный опыт - Vancouver Career Fair, поделился инсайтами🍿
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡32💯6🗿3❤🔥1🙉1
Тут возможно самый полный сборник всего, что есть по DE или около того. https://github.com/DataExpert-io/data-engineer-handbook
Забавно получается, чем больше материалов, ссылок, книг, курсов в одно месте, тем сложнее в этом разобраться.🙌
Забавно получается, чем больше материалов, ссылок, книг, курсов в одно месте, тем сложнее в этом разобраться.
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - DataExpert-io/data-engineer-handbook: This is a repo with links to everything you'd ever want to learn about data engineering
This is a repo with links to everything you'd ever want to learn about data engineering - DataExpert-io/data-engineer-handbook
Какие технологии видятся мне перспективными из тех, с которыми я не работал или работал немного? У меня есть общее представление, но я глубоко не погружался, и надеюсь найдется время, чтобы исправить это.
- Apache Arrow
- Apache Iceberg ( я работал уже с готовыми решениями, но не строил с 0)
- DuckDB
- Polars
- Rust/Golang языки программирования для задач дата инжиниринга
- Ray (spark)
- Protobuf (использую по факту, обычно в связки с event и streams)
- Apache XTable
Из старого но важного:
- Kubernetes
- Apache Kafka
- Apache Flink
- Fast API
У меня список своеобразный конечно. Что еще есть интересного?
- Apache Arrow
- Apache Iceberg ( я работал уже с готовыми решениями, но не строил с 0)
- DuckDB
- Polars
- Rust/Golang языки программирования для задач дата инжиниринга
- Ray (spark)
- Protobuf (использую по факту, обычно в связки с event и streams)
- Apache XTable
Из старого но важного:
- Kubernetes
- Apache Kafka
- Apache Flink
- Fast API
У меня список своеобразный конечно. Что еще есть интересного?
❤🔥24💯8⚡3🍾1🙈1
Вебинар: ➡️Мигрируем аналитическую отчетность с SAP BW на импортонезависимый стек. Показываем вживую
На вебинаре команда Sapiens solutions поделится техническими деталями реализации проектов миграции.
📅Дата вебинара: 01.10.2024
⌚️Время начала: 11:00 Мск
Регистрация обязательна
❗️Ключевые моменты вебинара:
1️⃣ Загрузка данных из SAP ERP с помощью OData в Greenplum
2️⃣ Фреймворк управления загрузками и расчетами Proplum
3️⃣ Внедрение современного хранилища данных.
4️⃣ Демонстрация процесса доставки данных - от создания документа в ERP до отображения в отчете
5️⃣ Apache Superset как фронт BI: соответствие объектов SAP BW/BO и Superset, разработанный функционал форка
Вебинар будет полезен, даже если вы не используете SAP. Мы рассмотрим технологические аспекты работы с Arena DB и Superset, а также дополнительные компоненты, которые дают возможность ADB быть чуть более "low code". Для Superset покажем расширения для сводных таблиц и другие компоненты.
До встречи на вебинаре!
На вебинаре команда Sapiens solutions поделится техническими деталями реализации проектов миграции.
📅Дата вебинара: 01.10.2024
⌚️Время начала: 11:00 Мск
Регистрация обязательна
❗️Ключевые моменты вебинара:
1️⃣ Загрузка данных из SAP ERP с помощью OData в Greenplum
2️⃣ Фреймворк управления загрузками и расчетами Proplum
3️⃣ Внедрение современного хранилища данных.
4️⃣ Демонстрация процесса доставки данных - от создания документа в ERP до отображения в отчете
5️⃣ Apache Superset как фронт BI: соответствие объектов SAP BW/BO и Superset, разработанный функционал форка
Вебинар будет полезен, даже если вы не используете SAP. Мы рассмотрим технологические аспекты работы с Arena DB и Superset, а также дополнительные компоненты, которые дают возможность ADB быть чуть более "low code". Для Superset покажем расширения для сводных таблиц и другие компоненты.
До встречи на вебинаре!
❤🔥6
Сегодня разбирали архитектуру большой американской компании, которая собирает данные клиентов с мобильных телефонов.
Решение на AWS, куча Kinesis стримов, которые пишут в S3 (json), дальше lambda их обрабатывает и пишет в другой S3. Есть еще DynamoDB с клиентской информации, которая делает ежедневные snapshots в S3. В конце с помощью Athena таблицы и запросы.
Компания продает обезличенные данные на млн долларов для других компаний. И товарищ непосредственно занимается интеграцией и выгрузкой данных для сторонних компаний.
Выгрузка происходит раз в час, когда Glue Python Shell запускает запросы Athena и делает unload в S3. С помощью вспомогательных запросов отслеживается качество данных и результат пишется в Cloud Watch и там всевозможные алерты на отклонения качества данных.
Решение будет переделано на Databricks и Delta.
Решение на AWS, куча Kinesis стримов, которые пишут в S3 (json), дальше lambda их обрабатывает и пишет в другой S3. Есть еще DynamoDB с клиентской информации, которая делает ежедневные snapshots в S3. В конце с помощью Athena таблицы и запросы.
Компания продает обезличенные данные на млн долларов для других компаний. И товарищ непосредственно занимается интеграцией и выгрузкой данных для сторонних компаний.
Выгрузка происходит раз в час, когда Glue Python Shell запускает запросы Athena и делает unload в S3. С помощью вспомогательных запросов отслеживается качество данных и результат пишется в Cloud Watch и там всевозможные алерты на отклонения качества данных.
Решение будет переделано на Databricks и Delta.
❤🔥26👨💻8
Иногда кажется чем больше rejection rate, тем лучше для HR и они наверно еще бонусы получают и хвастаются у кого больше rejection и что вообще можно все автоматизировать и оно само будет делать screening и rejection.
Позабыты хлопоты, остановлен бег, Вкалывают роботы, а не человек!
До чего дошел прогресс! Было времени в обрез, А теперь гуляй по свету - хочешь, с песней, хочешь, без!
Позабыты хлопоты, остановлен бег, Вкалывают роботы, а не человек!
До чего дошел прогресс! Было времени в обрез, А теперь гуляй по свету - хочешь, с песней, хочешь, без!
В Surfalytics мы делаем типичные Data Engineering проекты нетипичным образом. Обычно цель любого end-to-end проекта — это использование стандартных настроек и минимальной конфигурации.
Практически любой проект на Youtube это будет набор команд и шагов. Часто человек может даже не понимать как работает, но с покер фейсом нас учить, как делать Copy-Paste и строить решение. На выходе, у нас много pet проектов и 0 релевантного опыта и главное вообще не понятно как это применять в реальных условиях.
Сегодня Максим проводил проект по созданию end-to-end решения для работы с API (job posting сайт) с использованием стека AWS, включая такие сервисы, как Lambda, Step Functions, Redshift и другие.
Но вместо того, чтобы слепо следовать шагам, мы его мучаем вопросами на каждом этапе. Например:
1. Почему Lambda?
2. Почему Python 3.11?
3. Что такое API rate limit и как его избежать?
4. Какие есть альтернативы Lambda в AWS?
5. В чем разница между IAM role и IAM user? Что лучше и почему?
6. Что такое VPC и subnet, почему используется default VPC?
7. Какие есть соображения по безопасности? Где найти лучшие практики AWS (подсказка: AWS Well-Architected Framework)?
8. Как проверить работу AWS Lambda function?
9. Какова стоимость?
10. Почему Redshift? Почему Serverless? Какие плюсы и минусы у Redshift Serverless?
11. Почему не использовать Glue + Athena вместо Redshift?
12. Какова стоимость за запуск/в день?
И так далее. Некоторые вопросы даже мне сложно ответить.
Другими словами, в Surfalytics мы не гонимся за количеством pet projects. Мы сосредоточены на том, чтобы превратить ваш pet project в реальный проект и по-настоящему понять разницу. Мы не принимаем ничего на веру и считаем, что все может быть неправильно.
В результате, на выполнение 1/3 проекта у нас ушло более 3 часов, хотя при простом копировании и запуске кода это заняло бы всего 60 минут.
В каждом проекте мы детально разберемся, почему так, что стоит за капотом, и убедимся, что вы будете готовы ответить на вопросы hiring manager.
Хотелось бы конечно больше проектов и чаще делать, но пока основное время занимает работа.
PS другой интересный аспект - это персональный бренд. Этот пунктик очень важен в Surfalytics. Например, пост Максима набрал 162 лайка про этот проект! Это дает уверенность и Максиму и нанимающему менеджеру и вообще делать свой бренд в Linkedin прежде всего это про выйти из зоны комфорта.
PPS Ссылки:
Все проекты Surfalytics: https://github.com/surfalytics/data-projects (у нас еще много проетов в разработке включая Kubernetes, Open Source stack и тп)
Проект Максима: From API to Dashboard: Building an End-to-End ETL Pipeline with AWS
Практически любой проект на Youtube это будет набор команд и шагов. Часто человек может даже не понимать как работает, но с покер фейсом нас учить, как делать Copy-Paste и строить решение. На выходе, у нас много pet проектов и 0 релевантного опыта и главное вообще не понятно как это применять в реальных условиях.
Сегодня Максим проводил проект по созданию end-to-end решения для работы с API (job posting сайт) с использованием стека AWS, включая такие сервисы, как Lambda, Step Functions, Redshift и другие.
Но вместо того, чтобы слепо следовать шагам, мы его мучаем вопросами на каждом этапе. Например:
1. Почему Lambda?
2. Почему Python 3.11?
3. Что такое API rate limit и как его избежать?
4. Какие есть альтернативы Lambda в AWS?
5. В чем разница между IAM role и IAM user? Что лучше и почему?
6. Что такое VPC и subnet, почему используется default VPC?
7. Какие есть соображения по безопасности? Где найти лучшие практики AWS (подсказка: AWS Well-Architected Framework)?
8. Как проверить работу AWS Lambda function?
9. Какова стоимость?
10. Почему Redshift? Почему Serverless? Какие плюсы и минусы у Redshift Serverless?
11. Почему не использовать Glue + Athena вместо Redshift?
12. Какова стоимость за запуск/в день?
И так далее. Некоторые вопросы даже мне сложно ответить.
Другими словами, в Surfalytics мы не гонимся за количеством pet projects. Мы сосредоточены на том, чтобы превратить ваш pet project в реальный проект и по-настоящему понять разницу. Мы не принимаем ничего на веру и считаем, что все может быть неправильно.
В результате, на выполнение 1/3 проекта у нас ушло более 3 часов, хотя при простом копировании и запуске кода это заняло бы всего 60 минут.
В каждом проекте мы детально разберемся, почему так, что стоит за капотом, и убедимся, что вы будете готовы ответить на вопросы hiring manager.
Хотелось бы конечно больше проектов и чаще делать, но пока основное время занимает работа.
PS другой интересный аспект - это персональный бренд. Этот пунктик очень важен в Surfalytics. Например, пост Максима набрал 162 лайка про этот проект! Это дает уверенность и Максиму и нанимающему менеджеру и вообще делать свой бренд в Linkedin прежде всего это про выйти из зоны комфорта.
PPS Ссылки:
Все проекты Surfalytics: https://github.com/surfalytics/data-projects (у нас еще много проетов в разработке включая Kubernetes, Open Source stack и тп)
Проект Максима: From API to Dashboard: Building an End-to-End ETL Pipeline with AWS
GitHub
GitHub - surfalytics/data-projects: Surfalytics projces on Data Engineering and Analytics
Surfalytics projces on Data Engineering and Analytics - surfalytics/data-projects
❤🔥45⚡12🎄1🗿1
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🌚20🦄7❤🔥3🐳3😭2⚡1💯1