Инжиниринг Данных – Telegram
Инжиниринг Данных
23.5K subscribers
1.98K photos
56 videos
192 files
3.2K links
Делюсь новостями из мира аналитики и карьерными советами.

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

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

№5017813306

Реклама:
https://almond-rule-130.notion.site/1199f595f76a8030ba1be1e607c9a8ce
Download Telegram
Как вы знаете, есть два основных типа загрузки данных в хранилище данных(или озеро данных), это batch (грузим пачками раз в сутки или в час) и streaming (поток данных). Как правило ETL/ELT поддерживает только batch. Для стрима нужно использовать другие решения. Самое популярное это Apache Kafka. Ее коммерческая версия это Confluent. Так же у облачных провайдеров есть свои решения. Самое популярное AWS Kinesis. А вот и ссылка с туториал по кафке
Большие данные стали ещё больше
Вы слышали про DevOps? Это понятие пришло из разработки ПО, по простому это как мы разрабатываем ПО, есть ли у нас версионность кода, можно ли вместе менять код, где хранить код, как мы разделяем тест и прод и ТП. Это важно и в аналитике, часто когда мы меняем код (ETL, DW, BI) мы легко можем все поломать и бизнес пользователи не довольны. Отсюда и DevOps для аналитики. Для предикативных моделей тоже важно. https://www.red-gate.com/simple-talk/sql/database-devops-sql/introduction-to-devops-devops-and-the-database/
AWS опубликовал новый блогрост про построение озера данных. Озеро данных это по-сути защищённое файловое хранилище где можно хранить данные в сыром виде и анализировать. Дёшево и быстро, но можно легко превратить все это в болото данных если не подумать о сборе метаданных, такой вот справочник, что и где храниться. Другая сложность, что в озере сложно редактировать историю данных(если вам надо обновить что-то в прошлом) поэтому хорошо использовать вместе с хранилищем данных.
Фоточка из Бостона. Кстати немножко не в тему, я перешёл с iPhone на Google pixel 3xl. Телефон очень понравился, много полезный фич, которых нет у Айфона, а главное я купил его на Amazon renewed (только в штатах) новый со скидкой 50%. Так что если вы заказываете что-то из Америки то это отличный вариант сыкономить на технике и аксессуарах
Вот и Forbes пишет, что без аналитике нынче никуда. В своей свежей статье они вам расскажут аж про 5 способов, как аналитика поможет бизнесу. Сейчас все просто, вам нужны инструменты для аналитики, люди, которые смогут работать с этими инструментами (могут быть и разработчики, аналитики и просто бизнес пользователи) и, конечно, вам необходимо понимать взаимоотношения данных и бизнес процессов, а то будет как в пословице - смотрю в дашборд, а вижу фигу;)
Учите Azure? Пользователь Reddit подготовил список ресурсов для подготовки к экзамену https://www.reddit.com/r/AZURE/comments/cp70ux/az103_lab_study_guide/
Почему бы вам не попробовать создать озеро данных на AWS? Лучший способ понять, что это такое, это попробовать повторить шаги из блога AWS. В данном случае используется cloud formation, это такой шаблон создания инфраструктуры. Если вам нужно копировать инфраструктуру и ее настройки, то вы можете один раз создать шаблон со всеми параметрами и использовать его, это очень экономит время.
Если вы следите за трендами аналитики, то вы уже слышали про Snowflake. Обычно все его хвалят, а вот оказывается не все. В любом случае у вас есть 30 дней, чтобы бесплатно попробовать. Ещё я заметил много компаний мигрирует не просто в облако, но уже начинают внутри облака менять продукты. Очень популярно с Redshift на Snowflake. Говорят дешевле получается. Или возможно не хватает инженеров поддерживать разросшийся кластер Redshift.
Мы слышали, что data scientist зарабатывает больше всех. Вот и в новостях пишут TechRepublic: Data scientists: Earn the highest salary in these 5 cities.
https://www.techrepublic.com/article/data-scientists-earn-the-highest-salary-in-these-5-cities/ Но 127к в год в Америке, это конечно хорошо, но мы заплатим 50% налогов и останется не так много денег. А в городах, где платят такую зарплату, рент будет стоить 2-3к. А если у вас ещё семья, дети, то уже будете жить еле сводя концы с концами.

Другой момент, что такая зарплата и у BI, DWH, Data Engineers. По сути это новости искажены и далеки от реальности. Возможно бог экселя будет зарабатывать намного больше.

Кстати я узнал, что в Амазоне старшый дата инженер может зарабатывать до 400к в год (вместо со стоком).

Но проблема в корпоративной полиси, если вас взяли на 90к, то ваш рост не более 5% в год.
Любите удивлять коллег необычными графиками? Bar/line графики для слабаков? Вот вам график улитка. Будьте первым, удивите ваших коллег вашей креативностью!;)
Вы знакомы с термином ACID в теории биз данных? Он описывает требования к транзакционной системе (например, к СУБД), обеспечивающие наиболее надёжную и предсказуемую её работу. Требования ACID были в основном сформулированы в конце 70-х годов Джимом Греем.

Расшифровывается:
Atomicity — Атомарность
Атомарность гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни одной. Поскольку на практике невозможно одновременно и атомарно выполнить всю последовательность операций внутри транзакции, вводится понятие «отката» (rollback): если транзакцию не удаётся полностью завершить, результаты всех её до сих пор произведённых действий будут отменены и система вернётся во «внешне исходное» состояние — со стороны будет казаться, что транзакции и не было.

Consistency — Согласованность
Транзакция, достигающая своего нормального завершения (EOT — end of transaction, завершение транзакции) и, тем самым, фиксирующая свои результаты, сохраняет согласованность базы данных. Другими словами, каждая успешная транзакция по определению фиксирует только допустимые результаты. Это условие является необходимым для поддержки четвёртого свойства.

Isolation — Изолированность
Во время выполнения транзакции параллельные транзакции не должны оказывать влияния на её результат. Изолированность — требование дорогое, поэтому в реальных БД существуют режимы, не полностью изолирующие транзакцию (уровни изолированности Repeatable Read и ниже).

Durability — Долговечность
Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.

А статья на медиум с примерами для Oracle/Postgres.
Кстати, согласно новостям Oracle doing great, то есть вроде как мы его уже не жалуем для хранилищ данных, но это возможно всего лишь мой когнитивный баис, и компанию чувствует себя прекрасно.
Про NULL в базе данных