Делюсь новостями из мира аналитики и вредными карьерными советами;) 8 лет в FAANG, инвестиции в недвижимость, компании и акции, solo entrepreneur🏄♂️ Контакты и реклама: @dimoobraznii (сам не предлагаю купить рекламу или взаимопиар за деньги).
На дворе 2025 год и сейчас становится актуальный новый тренд оверэмполймент. Скоро вас даже на работу брать не будут если вы не работали минимум на 2х работах😂
PS я вопросы посмотрел в опросе, но они плохо ложаться на оверимплоймент, но идея классная.
Каждый раз, как Bitcoin пробивает потолок, я иду смотреть цену акций old school BI - Microstrategy. Хотя, если он падает, я делаю тоже самое.
Читать полностью…Сегодня на проекте Surfalytics мы потратили 3 часа, чтобы лучше разобраться в Apache Iceberg, и Snowflake интеграции с Iceberg-каталогом.
Если кратко, Snowflake поддерживает два варианта:
1. Managed Iceberg Catalog by Snowflake — мы создаём Iceberg-каталог в S3, и Snowflake полностью его контролирует: выполняет запись, чтение, управление доступом (RBAC), применяет row-level security, Data Masking и Data Sharing. Это получается Iceberg + Snowflake Enterprise Features. Однако не совсем понятно, что произойдёт, если мы захотим отключить Snowflake-каталог и подключить свой. Думаю, это возможно, но явно не то, что хочет Snowflake, чтобы продолжать зарабатывать на вас деньги.
2. Catalog Integration — это вариант интеграции, например, с Glue Catalog. В AWS стало очень просто создавать Lakehouse на основе Iceberg: мы сразу создаём Iceberg-таблицы в Glue и можем работать с ними через Athena или Glue Spark.
Snowflake может подключаться к Glue, но для каждой таблицы нужно создавать свою абстракцию в Snowflake, что выглядит не слишком удобно. В целом, интеграция слабая и неудобная, согласно документации.
За 3 часа мы успели:
1. Повторить разницу между Data Warehouse, Data Lake и Lakehouse.
2. Пройтись по основным принципам Apache Iceberg на основе книги Definitive Guide: Apache Iceberg. Разобрали ключевые элементы Iceberg-формата, такие как мета-файлы и их назначение, а также реальный пример использования с Trino, AWS и Databricks.
3. Выполнить Snowflake tutorial по созданию Managed Iceberg Catalog в Snowflake, а затем изучить, как Apache Spark подключается к этому каталогу.
4. Ознакомиться с Snowflake tutorial по интеграции с AWS Glue Iceberg Catalog.
В итоге я для себя понял, что Snowflake + Iceberg пока выглядит довольно сырым решением. Теоретически вы можете построить Iceberg Lakehouse, использовать Snowflake для вычислений, чтобы читать и писать данные в формате Iceberg, и даже подключаться к этому каталогу извне. Но создаётся ощущение, что Snowflake пытается запутать и реально не хочет, чтобы у вас был полностью открытый Lakehouse без привязки к вендору (vendor lock-in).
На базе Snowflake я бы такое решение строить не стал.
А что вы думаете по этому поводу?
Полезные ссылки:
Видео загружу на YouTube канал: SurfalyticsTV" rel="nofollow">https://www.youtube.com/@SurfalyticsTV (подпишитесь, чтобы не пропустить), туда же мы выкладываем другие проекты. И там мега крутая секция запись реальных собеседований (обезличенных).
Все ссылки на tutorials и книгу по Iceberg тут: https://github.com/surfalytics/data-projects/tree/main/de-projects/16_snowflake_and_iceberg_lakehouse В этом репозитории вы найдете множество других проектов для BI, DE, AE, которые мы строим.
В продолжение поста про DuckDB, ссылка на сам урок и hands-on (модуль 2, про базы данных).
Читать полностью…Замечательная штука для решения LeetCode на собеседовании. Но к сожалению не работает, может есть альтернативы или кто-нибудь запустит у себя? https://github.com/bipbop-sadrobot/cheetah
With Cheetah, you can improve your interview performance and increase your chances of landing that $300k SWE job, without spending your weekends cramming leetcode challenges and memorizing algorithms you'll never use.
Disclaimer зачет:
Cheetah is a satirical art project and is not intended for use in real-world settings. It may generate incorrect or inappropriate solutions. Users should exercise caution and take responsibility for the information provided by the app.
Code of Leadership #22 - Интервью с Дмитрием Аношиным про data engineering (Рубрика #Data)
В этом выпуске ко мне пришел в гости крутой гость, Дмитрий Аношин. Дима является экспертом в data engineering, ведет канал @rockyourdata, также Дима почти 10 лет работал западных Bigtech компаниях. Кстати, выпуск доступен в виде подкаста и в Яндекс Музыке.
Мы обсудили следующие темы:
- Как Дима входил в IT порядка 15 лет назад
- Как он развивал свои навыки как дата инженер
- Как он уехал в Канаду и адаптировался там
- Как развивалась карьера Димы в Amazon, Microsoft и что он вынес из этого опыта
- Как Дима стал создателем обучающих проектов datalearn, surfalytics, а также как ему удалось написать целую гору книг
- Как находить мотивацию для роста и развития
Если говорить подробнее про Дмитрия, то он уже больше 15 лет занимается аналитикой и инжинирингом данных, а 10 последних лет проработал в Северной Америке. Из них 5 лет в Амазоне, где работал в нескольких командах, включая Alexa AI (в Бостоне) и Customer Behaviour Analytics (в Сиэтле). Поучаствовал в действительно инновационных проектах, где драйвером являются данные. Видел и Big Data и Machine Learning в действии в масштабе крупнейшей компании мира. После Амазона работал 4 года в Microsoft Xbox и Microsoft Azure Data&AI. Активно принимал участие в развитии Microsoft продуктов для аналитики - Synapse, Fabric, Azure Databricks.
Теперь, Дмитрий помогает создавать инновационные аналитические решения, дата команды и модернизировать устаревшие решения через свою компанию rockyourdata.cloud и глобально готовит инженеров и аналитиков через свое сообщество Surfalytics.com (на английском), до этого несколько лет развивал проект Datalearn.ru, на котором делился фундаментальными знаниями и помогал бесплатно всем желающим войти в ИТ, знания там все еще актуальны.
Дмитрий написал несколько книг по аналитике и преподает несколько лет Облачные Вычисления (Cloud Computing) в партнерстве с Microsoft в Университете Виктории.
Еще из интересных проектов:
- Создал онлайн выставку писем CEO про увольнения в крупных компаниях - https://www.layoffmemos.com/
- Совместно с Московским Зоопарком и Вконтакте организовал группу по наблюдению за популяцией пеликанов и экомониторинга с использованием AI - https://www.scifly.ai/
Из последнего, Дмитрий создает главный Российский портал Дата Инженеръ посвященный карьере дата инженера, куда он планирует добавить road map для вакансий Инженера Данных, Аналитика и BI разработчика и ссылки на лучшие бесплатные ресурсы: книги, тренинги, курсы, видео, телеграмм каналы, и многое друго, что поможет понять, кто такой иженер данных и как таким стать, преимущественно на русском языке.
#Database #Architecure #Software #Data #SystemDesign #Management
Сэкономил тысячи долларов в год, добавив кастомную авторизацию в Metabase.
По прежнему считаю, что Metabase одна из самых удобных BI систем для пользователей.
Но есть одна проблема - коммерческая PRO версия довольно дорогая - 500 долларов в месяц плюс 10 за пользователя.
Мне нужна была только одна фича из PRO - моя собственная система авторизации.
В итоге я хакнул код Metabase, и опубликовал свою версию с инструкциями здесь
https://github.com/rzykov/metabase/blob/fiev_auth/Fief_auth.md
Демо видео https://www.youtube.com/shorts/hfmGOYF_6RI
Кому это нужно:
1) Вы пишите стартап/продукт и вам нужно дать поиграться данные пользователям в приличном интерфейсе
2) Вы внедряете Metabase, но пока хотите сэкономить 🙂
Пользуйтесь на здоровье
Мне всегда нравился продуктовый подход в аналитике. При таком подходе легче донести ценность до бизнеса и удобней измерять эффективность аналитического решения.
Сегодня увидел новую книгу - Managing Data as a Product: A comprehensive guide to designing and building data product-centered socio-technical architectures
Я уже давно подписан на автора в LinkedIn и мне нравится его специализация и подход.
Про книгу:
Traditional monolithic data platforms struggle with scalability and burden central data teams with excessive cognitive load, leading to challenges in managing technological debt. As maintenance costs escalate, these platforms lose their ability to provide sustained value over time. Managing Data as a Product introduces a modular and distributed approach to data platform development, centered on the concept of data products.
In this book, you’ll explore the rationale behind this shift, understand the core features and structure of data products, and learn how to identify, develop, and operate them in a production environment. The book also guides you through the design and implementation of an incremental, value-driven strategy for adopting data product-centered architectures, including strategies for securing buy-in from stakeholders. Additionally, it explores data modeling in distributed environments, emphasizing its importance in fully leveraging modern generative AI solutions.
Upon completing the book, you’ll have gained a comprehensive understanding of product-centric data architecture and the necessary steps to begin adopting this modern approach to data management.
What you will learn
- Recognize challenges in scaling monolithic data platforms, including cognitive load, tech debt, and maintenance costs
- Discover the benefits of adopting a data-as-a-product approach for scalability and sustainability
- Gain insights into managing the data product lifecycle, from inception to decommissioning
- Automate data product lifecycle management using a self-serve platform
- Implement an incremental, value-driven strategy for transitioning to data-product-centric architectures
- Master data modeling in distributed environments to enhance GenAI-based use cases
В русскоязычном дата сообществе есть несколько экспертов за кем я давно слежу. Один из них это Александр Бараков. Он пишет про стратегию и управление аналитикой и точно знает, как должно выглядеть BI решение, чтобы соответствовать требованиям бизнеса, пользователей и разработчиков. Я не знаю ни одного человека, который так глубоко специализируется на BI стратегии.
Вот несколько примеров:
- BI Strategy Guide
- BI Adoption Health Check
В этих схемах и диаграммах заложено много фундаментальных знаниях, которые помогут современным data leaders не наступать «на грабли» и воплощать в жизнь «data-driven» подход.
Уже несколько лет Александр проводит курсы по BI Стратегии и Data Governance.
Эти курсы у меня в обязательном списке.
4-13 декабря 2024 года он проводит как раз курс - Основы Data Governance.
Как вы могли понять из сообщения я не рекламирую курс, я его рекомендую, на рынке немного экспертов, которые не скатились в коммерцию и не «продают курсы» любой ценой. Эта программа проводится редко, не чаще чем раз в год. Поэтому рад поддержать данную инициативу.
🗂На курсе будет:
- Теоретические основы - основные элементы, технологии и практики DG и DQ
- Практические аспекты - почему дата каталоги, не взлетают, как создавать гибридные операционные ролевые модели, каким метриками обкладывать DG проекты т.д. Саша постил интересное исследование на эти темы на основе своих интервью с 20 компаниями - /channel/datanature/371
- DG здравого смысла - как-таки внедрять практики управления данными с учетом реалий и зрелости компании. Видео Александра на эту тему - Data Governance здравого смысла
- Кейсы участников, их проблемы и успешные решения.
- «Домашки» Каждый участник будет заполнять excel-гайд своего проекта Data Governance, применяя разделы курса на контекст своей компании.
- Нетворкинг: Участвуйте в активном обмене опытом с другими участниками курса и расширьте свою профессиональную сеть. На курсе обучаются CDO, руководители аналитики и дата менеджеры из всех крупнейших компаний.
Ссылка для регистрации: https://biconsult.ru/datagovernance/
Бесплатные курсы по Snowflake на Coursera:
- Intro to Snowflake for Devs, Data Scientists, Data Engineers
- Introduction to Modern Data Engineering with Snowflake
⛄️
Товарищи эксперты, филологи, отличники и отличницы, знатоки русского языка, как вы считаете, как правильно писать дата инженер на дореволюционной орфографии?
- дата инженеръ
- дата инжѣнѣръ
- дата инжѣнѣр
(Слово дата оставим как есть, его все равно не было)
Источники:
- Немного о дореволюционной орфографии. Лебедев.
- БУКВА "ЯТЬ"
- Конвертер в старославянский
Товарищ решил провести бесплатный bootcamp по DE, обычно он за 1500$ продает, а потом пишет в блоге как млн заработал🦯
💯 маркетинговый ход, но если есть время, то почему бы и нет?! Можно и английский подтянуть вместо сериальчиков👉
LinkedIn продолжает пестрить разочарованием в прошедших выборах. Некая Бренда заявила, что больше не будет качать Community, Кейт ее поддержала. И таких постов много.
Пока одни ноют другие ищут возможности. Вот теперь кто-нибудь может забрать сообществе себе, нет желающих?))
В Канаде все просто, тут могут помочь 👻 всем желающим, кому тяжело жить. Не знаю как там в штатах с помощью.
Apache Airflow очень популярный инструмент для оркестрации наших джобов по загрузке и трансформации данных. В РФ это по-моему просто number one инструмент для аналитика-инженера.
Появилась новая книга Apache Airflow Best Practices от Packt Publishing.
With practical approach and detailed examples, this book covers newest features of Apache Airflow 2.x and it's potential for workflow orchestration, operational best practices, and data engineering
This book covers the following exciting features:
- Explore the new features and improvements in Apache Airflow 2.0
- Design and build data pipelines using DAGs
- Implement ETL pipelines, ML workflows, and other advanced use cases
- Develop and deploy custom plugins and UI extensions
- Deploy and manage Apache Airflow in cloud environments such as AWS, GCP, and Azure
- Describe a path for the scaling of your environment over time
- Apply best practices for monitoring and maintaining Airflow
Книга про 2ю версию, хотя уже скоро будет версия 3.0.
Есть книга Data Pipelines with Apache Airflow
Ближайшие бесплатные аналоги - Prefect, Dagster, Luigi. Есть еще другие SaaS инструменты.
Есть еще на русском хороший вебинар на datalearn - ВВЕДЕНИЕ В AIRFLOW / ПОНЯТИЕ DAG'а / НАСТРОЙКА DAG'а В AIRFLOW от Дмитрий Браженко. Я с ним виделся на нашем митапе в Seattle и он теперь важный ML инженер в Microsoft и пилит Copilot.
Расскажите, кто что использует?
Спасибо, что отдали голос за правильного кандидата🍾😝
PS я тут скинул в Slack в Американской-Европейской компании S&P500 такое же и там гробовая тишина, походу одни демократы. У нас с ними всегда не сходились мнения что делать с homeless и другим nonsense в городах Северной Америки😵 (это вообще мои главные вопросы к местным, чтобы понять с ними можно выпить или нет🍷)
PPS Еще оказывается Симпсоны были не правы первый раз😂
Linting — это автоматический процесс форматирования кода в соответствии с правилами и лучшими практиками (best practices). Например, для Python часто используется стиль PEP8. Для проверки написания кода можно применять библиотеки flake8 и black, которые выполняют эту задачу автоматически. Желательно, чтобы в команде было соглашение по стандартам. Всё это можно настроить через pre-commit и continuous integration.
Когда речь заходит о SQL, ситуация гораздо сложнее. Чаще всего никаких стандартов и инструментов не используется. Однако самый популярный линтер для SQL — это sqlfluff. Он отлично работает с популярными облачными хранилищами данных и dbt.
Недавно я узнал о линтере на Rust под названием SDF Lint. Утверждается, что он в 1000 раз быстрее. Сам я его ещё не тестировал, так как меня устраивает sqlfluff — торопиться некуда.
Линтеров, конечно, гораздо больше. Например, на сайте представлен целый список. Их много не надо, нужен работающий.
А вы что-нибудь используете?
What Goes Around Comes Around... And Around... Part I (Рубрика #Data)
Интересная обзорная статья 2024 года от Michael Stonebraker и Andrew Pavlo про развитие баз данных за последние 20 лет. Оба автора являются корефееями в области баз данных: Michael создал Postgres и еще кучу других баз, а Andrew - исследователь в области баз данных, профессор и преподаватель, лекции которого доступны на Youtube.
Сама статья продолжает статью 2005 года "What Goes Around Comes Around", которую написали Michael Stonebraker и Joseph M. Hellerstein. Они проанализировали историю развития баз данных за 35 лет и предсказали что модные тогда объектные и xml базы данных не смогут обойти по реляционную модель.
С тех пор прошло порядка 20 лет и пришло время сделать новый обзор мира баз данных. Для этого авторы решили посмотреть на это с двух сторон:
- Модели данных и языки запросов
- Архитектура баз данных
Начнем с разбора существующих data models и query languages:
1. MapReduce-системы
Изначально они были разработаны в Google для обработки больших объемов данных (веб-краулер). MapReduce не использует фиксированную модель данных или язык запросов, они выполняют пользовательские операции map и reduce. Открытой версией MapReduce стал Hadoop, который сейчас не очень популярен из-за низкой производительности и заменяется более современными платформами аля Apache Spark или просто СУБД.
2. Key-Value хранилища
У них максимально простая модель данных: пары "ключ-значение". Они используются для задач кэширования (Memcached, Redis) или хранения сессий. Возможности в модели ограничены - нет индексов или операций join, что усложняет применение для сложных приложений. Многие KV-хранилища (например, DynamoDB, Aerospike) эволюционировали в более функциональные системы с поддержкой частичной структуры (JSON). Среди популярных встроенных k/v решений популярны LevelDB и RocksDB.
3. Документные базы данных
Они хранят данные в виде документов (например, в формате JSON). Изначально получили популярность благодаря простоте интеграции с веб-приложениями (например, MongoDB), предлагая подход schema on read. Интресно, что к 2020-м годам большинство документных СУБД добавили SQL-подобные интерфейсы и поддержку ACID-транзакций, а иногда и schema on write.
4. Column-Family базы данных (wide columns)
По-факту, это упрощенная версия документной модели с ограниченной вложенностью. Начиналось все с Google BigTable, а в миру есть open source реализация в виде Apache Cassandra. Изначально в Cassandra не было вторичных индексов и транзакций. Но по мере развития они появились (но там все очень интересно)
5. Поисковые движки
Они нужны для полнотекстового поиска (Elasticsearch, Apache Solr). Поддерживают индексацию текста, но ограничены в транзакционных возможностях. Реляционные СУБД также предлагают встроенный полнотекстовый поиск, но с менее удобным API.
6. Базы данных для массивов
Они предназначены для работы с многомерными массивами, например, научные данные (SciDB, Rasdaman). Ниша ограничена специфическими областями применения: геоданные, изучение генома.
7. Векторные базы данных
Используются для хранения эмбеддингов из машинного обучения (Pinecone, Milvus). Основное применение — поиск ближайших соседей в высокоразмерных пространствах. Реляционные СУБД уже начали добавлять поддержку векторных индексов.
8. Графовые базы данных
Моделируют данные как графы (узлы и связи). Примеры: Neo4j для OLTP-графов, TigerGraph для аналитики. Большинство графовых задач можно реализовать на реляционных СУБД с помощью SQL/PGQ (новый стандарт SQL:2023).
Общие выводы
- Большинство нереляционных систем либо занимают нишевые рынки, либо постепенно сближаются с реляционными СУБД.
- SQL остается основным языком запросов благодаря своей гибкости и поддержке современных приложений.
- Реляционные СУБД продолжают развиваться и интегрировать новые возможности (например, JSON, векторные индексы), что делает специализированные системы менее конкурентоспособными.
В продолжении поста будет про архитектуру баз данных.
#Data #Architecture #Software #DistributedSystems
Кто ты?
Я пробовал 1, 2, 3. Но сейчас мне прям понравился 2 но с экраном в 1,5 раза больше - 49”.
Такой в офисе есть, он размером как 3 монитора 27” и все на одном экране, у меня на нем 1.5x производительность.
Продолжаю работу над порталом Дата Инженеръ.
Сегодня обновил главную страницу, чтобы задать контекст ресурса:
• Цель сайта
• Для кого этот сайт?
• Что такое аналитика?
• Архитектура аналитического решения
• Ключевые роли в аналитике
• Инжиниринг данных
• Учебные материалы
• Как добавлять ресурсы?
Из готовых страниц — ресурсы по SQL.
Портал создан с помощью Jekyll и хостится через GitHub Actions. Каждая страница — это Markdown-документ, что значительно упрощает работу. Поскольку сайт является репозиторием, контрибьютить в него можно через Pull Request, что делает процесс простым и прозрачным. Осталось только собрать модераторов и контрибьюторов.
Задача — собрать самые ценные и полезные ресурсы: white papers, тренажеры, выступления, тренинги и книги, структурированные по ролям. Отдельно добавлю дорожные карты для нескольких профессий и ссылки на ресурсы для самостоятельного обучения. Дорожные карты будут 2х типов - для отечественного рынка и для западного. Отличаться будет лишь набором инструментов, фундаментально все совпадает.
P.S. С доменом dataengineer.ru
повезло. Пришла идея создать что-то полезное и упорядочить знания и ресурсы, накопившиеся за последние 10 лет, и оказалось, что домен выставлен на продажу за 100 тысяч рублей. Раз уж я занимаюсь этим последние 15 лет и мне нравится вносить вклад в русскоязычное сообщество (потому что вижу отклик и реальную пользу для людей), то почему бы не закрепить это правильным доменом.
За последние несколько дней я наткнулся на несколько постов о закате профессии Analytics Engineer как таковой. И это вовсе не плохо. Лично для меня профессия AE была сформирована под влиянием dbt (тогда еще Fishtown Analytics) и экосистемы вокруг Modern Data Stack. Это когда аналитическое решение можно строить по принципу “*як *як и в продакшн”, используя готовые блоки для интеграции данных, трансформации, визуализации и т. п. Основной акцент делался на трансформацию данных, желательно с использованием подхода “as a code”, то есть с применением Git и систем контроля версий. Как правило, для ролей AE не требовалось глубоких знаний в области сетевых настроек, инфраструктуры, безопасности данных и других аспектов уровня enterprise.
Возможно, я ошибаюсь, но, на мой взгляд, роль AE действительно становится излишней. Достаточно иметь Data Engineer (DE) и BI-аналитика, которые совместно решают, кто что делает на проекте. Я работал в двух компаниях в общей сложности 5 лет в качестве DE, где было четкое разделение на AE и DE. И нередко возникали вопросы от менеджеров: а действительно ли нужна роль AE?
У этого явления были свои плюсы, которые мы продолжаем использовать в Surfalytics. Например, если вы хотите получать зарплату Data Engineer, но ваши знания пока соответствуют уровню BI, решение довольно простое: стать AE. Для этого достаточно пройти курс по dbt, освоить немного Git, CI/CD и сделать пару pet-проектов — и вы уже претендуете на зарплату DE, избегая сложностей инфраструктурного уровня. Думаю, у нас еще есть время пользоваться этим лайфхаком, но лучше ставить целью стать полноценным Data Engineer. Если же вам не нравится заниматься техническими задачами, всегда есть путь стать Engineering Manager или Product Manager.
Как вам АЕ роль?
Кстати на HeadHunter такой роли вот нет, ну и хорошо:)
Прямо сейчас начинается онлайн конференция https://osacon.io/schedule/
Читать полностью…Вот что ждет в Т-Банке аналитиков DWH, кроме ДМС, крутых офисов и других плюшек:
▪️Актуальный стек. Здесь следят за трендами и быстро внедряют новое.
▪️Улучшения может предложить каждый. Здесь знают, как устроен продукт, и влияют на его развитие.
▪️Прозрачная система роста. Вы всегда будете знать, какие навыки нужно подтянуть и как получить повышение.
▪️Вы окажетесь среди профессионалов, у которых можно многому научиться. А если захотите — можете стать ментором для младших коллег.
Устраивайтесь в Т-Банк на позицию аналитика DWH до 23 декабря 2024 года и получайте приветственный бонус в размере одного оклада.
Хорошая книжка с терминологией и приятными картинками.
Сам BI инструмент Holistics топит за аналитику как код, такой вот азиатский looker.
Идея FIRE (Financial Independence, Retire Early) уже не новая. FIRE с детьми и без - это очень большая разница. Есть еще semi-FIRE.
Вот 3 топ статьи на эту тему:
- An ex-Meta employee calculated that his family of 3 needs $5.6 million to retire in San Francisco. Here's the formula he used and how he plans to hit his 'enough number.'
- FIRE Lessons From ex-AMZN Director Dave Anderson
- Your Neighbors Are Retiring in Their 30s. Why Can’t You?
Интересно, кто-нибудь из подписчиков на пути к FIRE?
Лично у меня не получается. Возможно, причина в том, что в молодости всегда был дефицит, и поэтому постоянно хотелось «хороших и дорогих вещей, путешествий и тп». Когда начинаешь зарабатывать, появляется желание купить всё и сразу. Возможно, вам знакомо такое чувство. Лучше всего сначала купить то, что хочется, а потом уже думать, как быть дальше.
Про FIRE я даже не думаю, а вот semi-FIRE — это хорошая цель. Главное преимущество — не зависеть на 100% от работы. Например, вас сократят, а вам всё равно: у вас есть альтернативные источники дохода или сбережения.
Добавил видео о NoSQL базах данных в контексте аналитики, а именно об их использовании в качестве ИСТОЧНИКА данных для аналитических решений. В качестве примера выбрал документ-ориентированную базу данных MongoDB.
После обзора стандартной архитектуры аналитического решения, возможных use cases и обсуждения особенностей MongoDB и ее структуры, перешел к практическим упражнениям:
- установка MongoDB через Docker Compose;
- создание облачной (бесплатной) версии MongoDB Atlas;
- написание запросов к базе данных.
В завершение рассмотрел основные способы извлечения данных из MongoDB:
- low-code/no-code: Matillion, Fivetran;
- code-based: Meltano, AirByte, Python, Airflow.
Не затронул только стриминг данных с помощью Kafka Connect или Debezium.
Ссылка на видео: https://youtu.be/bzTfn7WI5h8?si=W9jnt6cwqi8vhqQH
00:19 Welcome Message
01:00 NoSQL use cases for Data Professionals
07:31 Amazon Oracle Migration
00:12:08 MongoDB is a bad choice for data warehouse
00:13:21 MongoDB introduction
00:18:49 MongoDB elements
00:21:17 JSON, JSON Object, JS Object, BSON
23:41 MongoDB Installation
25:07 MongoDB Atlas Cluster Overview
25:28 MongoDB Charts Overview
30:40 Running MongoDB in Docker Compose
35:00 MongoDB GUIs Overview
38:49 Connect MongoDB Atlas with CLI
42:42 Query MongoDB collections
51:15 Data Integration with MongoDB using Low Code Applications, Python and Airflow
Ссылка текст и код: https://github.com/surfalytics/analytics-course/blob/main/02_getting_started_with_databases/06_nosql_databases/mongodb/readme.md
Как подготовиться к публичному выступлению? Даже бывалые спикеры мандражируют перед своей речью, что уж говорить о новичках.
Поэтому хорошо, когда есть план, которому следуешь. Такой, например, уже прописали HR из Яндекса в посте у себя в канале. Актуально не только для крупных профессиональных конференций, но и для рабочих встреч, где вы, например, питчите проект. Вот три самых важных момента:
1. Изучите аудиторию. Нужно подобрать формат выступления, основываясь на степени экспертности и заинтересованности ЦА.
2. Определите ключевые месседжи. Это главное, что слушатели запомнят и вынесут из вашего выступления.
3. Обходитесь без зубрежки. И не прописывайте все фразы на слайдах. Органичнее будет выглядеть свободная речь, словно разговор в кругу знакомых.
И бонусом еще советы от профи, которые готовят спикеров: прогоните выступление перед друзьями, запишите вашу репетицию на видео или аудио и не забывайте анализировать свой опыт.
В Surfalytics у нас сегодня был проект с DuckDB. Для многих это была первая возможность попробовать эту технологию.
Вот несколько классных вариантов использования для аналитики и инженерии данных:
- Запросы к локальным файлам с помощью SQL
- Исследование данных, хранящихся удалённо в S3, Azure или GCP
- Использование DuckDB как альтернативы обычному Postgres в качестве хранилища данных
- Удобно работать с dbt для чтения внешних таблиц/файлов и преобразования их в source
модели dbt и уже строить модели внутри базы
- Работа с современными lakehouse форматами, такими как Iceberg и Delta
- Альтернатива Spark DataFrames при обработке небольших данных
- Эффективное преобразование данных из CSV в Parquet или другие форматы
- Запись результатов напрямую в Markdown для pull-запросов или код-ревью
- Удобно при работе с API - связка Python + DuckDB
Этот список можно продолжать!
Вот само упражнение, можете повторить и все будет понятно: https://github.com/surfalytics/analytics-course/tree/main/02_getting_started_with_databases/07_duckdb
Завтра у нас будет BigQuery + dbt на GCP - большой проект. Прошлый был про Redshift Serverless + Lambda + AWS Step Functions - делали ETL по извлечению из API.
Статья про внутрянку Amazon - Amazon’s Exabyte-Scale Migration from Apache Spark to Ray on Amazon EC2.
Все началось в 2016 году, когда Амазон начал мигрировать с Oracle on-premise на AWS. Как раз имея этот опыт миграции on-premise в cloud я придумал делать консалтинг Rock Your Data. Миграцию закончили в 2018.
Далее уже стали строить внутреннее озеро данных с использованием AWS EMR (Hadoop), Spark, Redshift, Glue и тп.
Spark стал главным инструментом для пользователей, чтобы извлекать из центрально озера данных.
Amazon’s petabyte-scale data catalog had grown to exabyte-scale, and their Apache Spark compactor was also starting to show some signs of its age. Compacting all in-scope tables in their catalog was becoming too expensive. Manual job tuning was required to successfully compact their largest tables, compaction jobs were exceeding their expected completion times, and they had limited options to resolve performance issues due to Apache Spark successfully (and unfortunately in this case) abstracting away most of the low-level data processing details.
В 2020 году они сделали PoC по Ray - 12X larger datasets than Apache Spark, improve cost efficiency by 91%, and process 13X more data per hour
Сейчас у них классные результаты:
During the first quarter of 2024, BDT used Ray to compact over 1.5EiB of input Apache Parquet data from Amazon S3, which translates to merging and slicing up over 4EiB of corresponding in-memory Apache Arrow data. Processing this volume of data required over 10,000 years of Amazon EC2 vCPU computing time on Ray clusters containing up to 26,846 vCPUs and 210TiB of RAM each.
What’s more impressive, is that Ray has been able to do all this with 82% better cost efficiency than Apache Spark per GiB of S3 input data compacted. For BDT, this efficiency gain translates to an annual saving of over 220,000 years of EC2 vCPU computing time. From the typical Amazon EC2 customer’s perspective, this translates to saving over $120MM/year on Amazon EC2 on-demand R5 instance charges.
Кто-нибудь использовал Ray? Опыт может подойти компаниям с огромными данными Pb+. А Tb мы можем и в Snowflake/Databricks гонять)
Я всегда использую draw.io как бесплатный инструмент для диаграмм, оказывается есть plugin для VSCode.
Читать полностью…Слышали про duckdb?! Вот быстренький туториал https://motherduck.com/blog/duckdb-tutorial-for-beginners/ можете пройти и пощупать руками.
Можно даже в браузере запустить: https://shell.duckdb.org/
Например удобный способ почитать Parquet файл, вместо Parquet CLI-утилит.
Одна из интересных фич “Larger-Than-Memory Workloads (Out-of-Core Processing)”
В целом большинство сценариев про локальное чтение файлов или чтение из S3/GCP/Azure Storage.
Пока не очень понятно как использовать DuckDB для реального распределенного озера данных (lakehouse, data lake). Вот в этой статье - Okta's Multi-Engine Data Stack, Jake рассказывает как они съехали со Snowflake на DuckDb для их security сценариев. (Я его хорошо знаю). Там и ссылка на его доклад.
В целом я отношу сие изделие к разряду fancy. Есть категория разработчиков, кто любит всякие такие штуки использовать, пока другие стучат молотком работают с Databricks, Snowflake, BigQuery и тп.
Статьи по теме:
Build a poor man’s data lake from scratch with DuckDB
Process Hundreds of GB of Data with DuckDB in the Cloud
🦆 vs ❄️ ... 💸 ?