DataEng – Telegram
DataEng
4.35K subscribers
40 photos
9 files
537 links
Канал про Data Engineering & Distributed Systems.

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

Автор @adilkhash
Download Telegram
Запись докладов ранее анонсированной конференции: https://youtu.be/WHN8bLSqebQ
Отличный ресурс про внутреннее устройство PostgreSQL: https://www.interdb.jp/pg/index.html
Wes McKinney, автор pandas, пишет 3-е издание своей книги Python for Data Analysis в рамках Open Edition: https://wesmckinney.com/book/
Мой опыт работы с pandas начинался именно с этой книги, хотя тогда она мне казалась далеко не дружелюбной для новичков.
Исследование data engineering позиций внутри биг-техов

Наткнулся на небольшое исследование рынка dataeng позиций среди биг-тех компаний: Amazon, Google, Facebook (ой, Meta) и т.д. Автор вручную проанализировал 1К вакансий и выяснил некоторые инсайты:

- основное требование это знать Python и SQL
- чтобы расти дальше по технической части необходимо помимо Python/SQL иметь знания Java/Scala/C++
- биг-техи предпочитают code-heavy решения вместо новомодных low/no-code перделок
- почему то автор в статье упоминает Airflow как low-code pipeline solution, думаю это опечатка
- доля Amazon среди открытых вакансий по dataeng 65%
- Tableau в 2 раза популярнее Power BI
- Доли среди клауд провайдеров: AWS 53% (но стоит учесть, что 65% всех вакансий от Amazon), у Azure и GCP доли примерно одинаковые
- стриминг становится всё популярнее (spark streaming, flink, kafka)
- автор не забыл и про софт-скиллы, как ни крути, а работаем мы прежде всего с людьми

У меня была идея сделать анализ dataeng вакансий среди популярных площадок для понимания наиболее актуальных требований и не ограничиваться только FAANG. Ждите в ближайшее время (это, кстати, также может стать неплохим data engineering проектом в копилку).
🔥4👍1
У ребят из Astronomer прошел очередной вебинар, на этот раз тема вебинара — Масштабирование Airflow
Посмотреть можно в ютубе: https://www.youtube.com/watch?v=i9F0LFobejc
Основной фокус сделали на двух самых популярных Executors: CeleryExecutor и KubernetesExecutor. Рассказали про нюансы и подводные камни каждого, в целом получилось полезно!
👍9
Налетай, разбирай!
На Udemy раздают двухчасовой курс по Redis бесплатно и без смс, но с регистрацией: https://bit.ly/3LeuoBQ
👍13
Forwarded from How to DWH with Python
Подготовил конспект статьи от Shopify о сетапе Airflow на 10 тысяч DAG'ов со 150 тысячами запусков в день. Сэкономит вам время на прочтении и поможет освежить в памяти в будущем.

#briefly #airflow Airflow: scaling out recommendations by Shopify
https://telegra.ph/Airflow-scaling-out-recommendations-by-Shopify-06-03

What's inside:
— Cloud Storage vs Network File System.
— Metadata retention policy.
— Manifest file.
— Consistent distribution of load.
— Concurrency management.
— Using different execution environments.

Origin: Lessons Learned From Running Apache Airflow at Scale
🔥10👍4
Доклады с Airflow Summit 2022 подъехали: https://bit.ly/3mzyl9T
👍7🔥2🎉1
Хех, тут новый релиз Luigi нарисовался — https://github.com/spotify/luigi/releases/tag/3.1.0
В интернетах народ уже давно похоронил этот замечательный фреймворк, апеллирует народ в основном к тому, что, мол, давно не было обновлений. А обновлять то там особо нечего, он простой и работает без сбоев. У меня, например, Luigi вот уже много лет бэкапит все сайты и складывает на S3.
🔥6
Про таймауты и внешние API

Хорошей практикой при работе с внешними сервисами я считаю явное указание таймаутов ожидания соединения и ответа от хоста. Такой подход поможет избежать проблем с "зависанием" соединения и, как следствие, блокировкой процесса (для блокирующих соединений). На моей памяти было 2 неприятных кейса. В далёком 2015 я использовал requests для работы с сервисом поиска и бронирования ЖД билетов в Казахстане, по-умолчанию в requests нет таймаута и ожидание может превратиться в бесконечность. Всё было хорошо до тех пор пока у внешнего сервиса не начались проблемы, и он перестал отвечать на запросы. Все worker-процессы ушли в бесконечное ожидание, и мой сервис перестал принимать новые соединения, сайт попросту сломался. Тогда мне потребовалось некоторое время, чтобы понять в чем проблема.

Со второй проблемой я столкнулся неделю назад. Сейчас я разрабатываю веб-сервисы для автоматизации рекламных сетей, активно пользуюсь Facebook Ads. Для работы с маркетинговым сервисом Фейсбука существует библиотека facebook-python-business-sdk. Внимание! Под капотом она использует requests 😉 И у неё нет таймаута по умолчанию. Я наткнулся на те же грабли, когда ФБ стал подтормаживать.

К слову, если вы как и я пользуетесь facebook-python-business-sdk, то таймаут можно установить через инициализацию API-класса:

FacebookAdsApi.init(access_token=access_token, api_version='v13.0', timeout=settings.FACEBOOK_ADS_API_TIMEOUT)

Не наступайте на грабли, ставьте таймауты 😉

Также по теме в ленте увидел пост про патчинг requests: https://adamj.eu/tech/2022/06/23/how-to-patch-requests-to-have-a-default-timeout/
👍21
Forwarded from DevBrain
Прошлый пост касался архитектуры Redis, а сейчас предлагаю вам познакомиться с кишками memcached: https://bit.ly/3czb6eQ

Лет 5-6 назад я был активным пользователем memcached, использовал его во всех проектах как основной кэш-бэкенд, но с бурным развитием Redis я переключился на него. Тем не менее, memcached поддерживается (последняя версия вышла 26 августа 2022 года), видео считаю очень полезным (как и канал автора в целом).
👍4👎2