Визуализация из Канадской действительности - Shopify нарисовал карту доставок 1 Ноября 2023 - 31 Декабря 2023:

Shopify attached the above image in the letter, claiming it illustrates domestic urban and rural orders (in blue and red, respectively) from Shopify merchants that were fulfilled by Canada Post from Nov. 1, 2023 to Dec. 31, 2023. Shopify said a 2024 map “wiped clean” due to prolonged strike action would “devastate” the economy.

Open letter claims at least 67,000 Shopify-powered small businesses rely on Canada Post.

Даже я сам affected от такого беспредела, потому что не могу заказать в своем же магазине shop.surfalytics.com себе же одежду и подарки знакомым.

Canada Post мусолит эту тему с 25 октября. Сначала это было по фану всем, а теперь совсем нет. У многих зависли визы и паспорта, а скоро отпуска. И нет никакой альтернативы.

Теперь мы знаем почем Amazon зарубил профсоюзы накорню - How Amazon Crushes Unions.

Читать полностью…

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

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

Где и когда?

👉 Нижний Новгород, 5 декабря
👉 Санкт-Петербург, 6 декабря

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

Количество мест ограничено — успей занять своё и прикоснуться к миру рекомендательных систем! 😉

Читать полностью…

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

Но сегодня хотел поделиться другим инсайтом, который не может не радовать - кол-во русскоязычных постов в LinkedIn и аудитории растет. Если раньше все пытались подстроиться по платформу и писать на английском, то теперь все хотят быть сами собой и писать так как им нравится. В общем мега круто, всегда интересно читать посты на русском - diversity и inclusion, как говорится🇷🇺

Читать полностью…

В статье Learnings after 4 years working with +50 companies on data engineering projects автор поделился интересными наблюдениями посли 4х лет консалтинга. Chatgpt перевел и я подправил по возможности.

Некоторые практические выводы, без особого порядка:

- Многие думают, что быстро делать ETL невозможно. Большинство считает, что пайплайны, которые обрабатывают большой объём данных, должны занимать часы. На деле в большинстве случаев можно решить задачу в реальном времени (запросы <1 сек) с меньшим количеством железа. Хороший дизайн всегда лучше железа.

- В большинстве проектов хранят данные, которые никогда не используются (иногда более 90%). И их обрабатывают. Каждый день/час/минуту. Никто об этом не задумывается.

- Люди сосредотачиваются на изучении инструментов, и это хорошо, но забывают про принципы. Я не могу сосчитать, сколько раз видел, как SQL-запрос мог бы работать в 1000 раз быстрее, если бы данные были правильно отсортированы. Люди отлично знают, как использовать Spark/Snowflake/BigQuery, но никогда не тратят полдня, чтобы понять, как эти инструменты работают «под капотом». Поверьте, есть 3-4 базовые концепции, которые дают 80% необходимых знаний. Я 7 лет управлял огромным кластером Postgres, но так и не уделил достаточно времени его принципам. Сейчас я уже забыл, как работать с Postgres, но уверен, что запомнил бы основы, если бы уделил им больше времени.

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

- Ingestion — это 80% работы, но его обычно даже не мониторят. Есть сотни причин, почему `INSERT` может не сработать или быть медленным. Данные, которые вы не смогли загрузить, ломают весь пайплайн, а ошибки остаются незамеченными. Вы видите проблему в SQL-запросах, когда уже слишком поздно и всё слишком сложно.

- Качество данных — это как unit-тестирование, но в продакшене. Тестировать пайплайны в CI (и только 10% людей это делают) недостаточно, нужен постоянный мониторинг.

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

- Да, есть проекты, где нужен открытый формат схем, но schemaless в масштабе очень дорого, и вам обычно придётся делить логику работы между типовыми случаями и редкими исключениями. Проще говоря, если вы разрешаете пользователям отправлять что угодно, будьте готовы бороться с 0.0000001% событий, которые содержат 3MB атрибут.

- Быстро, дёшево, гибко. Выберите два.

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

- end-to-end задержки = K / $. Если вы хотите, чтобы данные были доступны как можно быстрее, нужно железо. Это не линейная зависимость: чтобы сократить задержки с 10 сек до единиц секунд, придётся вложить много денег (и при этом ещё держать низкие задержки на чтение, иначе в чём смысл).

- Люди всегда думают, что операции завершатся успешно. Использование неизменяемого workflow и атомарных операций всегда экономит дни на исправление некорректных или частичных данных.

- Большинство людей не имеют интуиции, что современное железо может или не может. Простая формула может помочь: «одна машина может обработать около 500MB за секунду». Да, это не универсальная истина, но эта оценка — хороший инструмент.

Читать полностью…

30 дней орекстреции с Dagster - https://github.com/slopp/30_days_of_dagster/

Хороший вариант поковырять Dagster и поучиться. Уже день 8.

Читать полностью…

Устроиться аналитиком в Яндекс за выходные

7–8 декабря проводим Weekend Offer Analytics. До 4 декабря оставьте заявку на участие, 7 декабря пройдите технические собеседования, а 8 декабря познакомьтесь с командами и получите офер.

В мероприятии участвует 7 команд: Crowd, Карты, Поиск, YaGPT 2, Автономный транспорт, Реклама и Ecom-сценарии. Вы сможете пообщаться с менеджерами и выбрать проект, который покажется самым интересным.

Нанимаем в офисы России и Республики Беларусь.

Узнать подробности и зарегистрироваться можно здесь.

Читать полностью…

📊  Оверимплоймент: что это? Примите участие в новом исследовании от NEWHR и получите инсайты рынка

Вы сотрудник и совмещаете несколько мест работы? Или пока только задумываетесь о поиске подработки и взвешиваете «за» и «против»? А может, никогда не смотрели в эту сторону? Или вы — работодатель, который сталкивается с феноменом оверимплоймента среди своих сотрудников? А может, не сталкивались или не знаете наверняка, совмещают ли ваши сотрудники? Расскажите нам о своем опыте и/или отношении к вопросу!

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

В рамках исследования узнаем:

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

👉🏻 Пройти опрос 👈🏻

Результаты исследования опубликуем в начале 2025 года.

🎁 Для всех, кто поучаствует в опросе:

- мы сделаем специальный расширенный материал с глубинным исследованием по вашей профессии: эти материалы получат только респонденты исследования
- предоставим возможность узнать результаты первыми
- проведем закрытый эфир с инсайтами исследования и возможностью задать любые вопросы экспертам NEWHR

📎 Для отправки результатов исследования мы попросим вас оставить электронную почту в конце. Это не обязательно, но гарантирует, что вы получите результаты первыми. Вы можете использовать любую комфортную для вас почту.

👉 Расскажите о вашем отношении к совмещению работ и/или поделитесь этим постом с теми, кому может быть интересна эта тема. Опрос займет не больше 6 минут.

Читать полностью…

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.

Читать полностью…

DuckDB посчитал быстрей кол-во строк в CSV, чем UNIX wc -l.


Unix:

time wc -l services-2023.csv

21239394 services-2023.csv
wc -l services-2023.csv  2.66s user 0.29s system 99% cpu 2.966 total

DuckDB:

time duckdb -c "select count(*) from read_csv('services-2023.csv', header = false)"

count_star()
int64
21239394

duckdb -c "select count(*) from read_csv('services-2023.csv', header = false)" 11.17s user 0.57s system 930% cpu 1.261 total

Если еще не начали использовать, то самое время попробовать.

Из DuckDB white paper:

Перевод как обычно 🙌


DuckDB — это встроенная аналитическая база данных с открытым исходным кодом, созданная для выполнения аналитических SQL-запросов непосредственно внутри процесса хост-приложения.

Она решает ограничения существующих встраиваемых решений, таких как SQLite, которая не подходит для аналитических (OLAP) нагрузок, и заполняет пробел в таких сценариях, как интерактивный анализ данных (например, в R или Python) и edge computing.

Основные моменты:

Проблема: Традиционные базы данных работают как отдельные серверные процессы и требуют значительных ресурсов. SQLite широко используется, но оптимизирована для транзакционных (OLTP) задач, что делает её неэффективной для аналитики. Необходима встроенная аналитическая система.

Особенности DuckDB:

- Высокая производительность для OLAP, сохраняя базовые возможности OLTP.
Устойчивость: предотвращение сбоев хост-приложения и безопасное завершение запросов при нехватке ресурсов.

- Эффективный обмен данными внутри процесса между базой данных и приложением.
- Портативность и минимум внешних зависимостей.

Дизайн и реализация:

- Используется модульная архитектура (parser, optimizer, execution engine), адаптированная для встроенной аналитики.

- Применяется векторизированное выполнение (vectorized execution) для повышения производительности и портативности, избегая сложных зависимостей, таких как LLVM.

- Обеспечивается поддержка ACID через Multi-Version Concurrency Control (MVCC).

- Используется оптимизированный формат хранения данных с компрессией и индексированием.

Демонстрация:

- DuckDB сравнивается с SQLite, MonetDBLite и HyPer на идентичном оборудовании с использованием TPC-H benchmarks, чтобы показать её превосходство при обработке больших объёмов данных.

- Позволяет пользователям запускать запросы и в реальном времени проверять масштабируемость и производительность.

Применение и будущее развитие:

- Подходит для сценариев, где требуется встроенная аналитика, например, edge computing или интерактивный анализ в лёгких инструментах.

- Планируется добавление intra-query параллелизма, балансировки ресурсов и механизмов устойчивости к аппаратным сбоям.

Видео (4 года назад)- Dissecting DuckDB:
The internals of the “SQLite for Analytics”

Бесплатная Книга - DuckDB in Action"

DuckDB официально поддерживается dbt.

В целом, если вы хотите сделать аналитическое решение с Open Source для небольшого объема (данные помещаются на одной машине), то в качестве SQL движка можно использовать DuckDB вместе с:
- Minio для object storage
- dbt для трансформаций
- Metabase/Superset для BI
- Airflow/Dagster/Prefect для оркестрации
- Prometheus/Grafana для data observability
- Open Metadata/Data Hub для бизнес каталога и lineage
- GitHub/GitLab для версионности и CI/CD
- Terraform или Tofu для инфраструктуры как код
- Можно и streaming добавить Redpanda, Flink, Kafka, Debezium

Все это дело можно запустить в контейнерах или на (managed) Kubernetes кластере.

Вместо DuckDB можно и кучу других решений - Trino, ClickHouse, Greenplum или коммерческий продукт (я обычно не экономлю на storage инструменте)

Читать полностью…

В статье SSDs Have Become Ridiculously Fast, Except in the Cloud затронули интересную тему.

SSD диски сейчас стали лучше и быстрей. Но оказывается, что облачные провайдеры AWS, Azure, GCP не спешат заменять свой парк, и их диски до сих пор на уровне 2017 года.

Получается, аналитика (и не только) on-premise может быть быстрей и дешевле.

Другой вопрос, что делать если вы купили on-premise железо в 2017 и ранее, не выкидывать же его

Читать полностью…

- Завершу этим, хотя это больно: большинству компаний нужны базовые знания bash / make, SQL-движок для одной машины (DuckDB, CHDB или несколько python-скриптов), распределённая файловая система, git и девелоперский workflow (CI/CD). Всё остальное — это «сахар» и «enterprise». Не говорю, что они не важны, но основы должны быть закрыты, иначе будет хаос. Меня всё ещё удивляет, как быстро мы забываем хорошие практики, которые изучили за годы в софтверной инженерии (тестирование, деплой, совместная работа, мониторинг и так далее).

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

Читать полностью…

ДМИТРИЙ АНОШИН: КАК ДАТА ИНЖЕНЕРУ ЗАРАБАТЫВАТЬ 2+ МЛН - подкаст с Андрон Алексанян, автор тг-канала ANDRON ALEXANYAN.

Мы записали подкаст относительно давно, я даже не помню о чем мы говорили, но точно знают, что все важное и крутое! Поэтому реально вам не смогу сказать сейчас про 2+млн сходу, ответ вы сможете найти в подкасте😎

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

Всем хороших выходных!

Читать полностью…

Давайте расскажу, что мы добавили на сайт dataengineer.ru

1. К ресурсу присоединились котрибьютеры и еще общаюсь с топ-экспертеми в разных областях, чтобы смогли добавлять самые полезные ресурсы для вас.
2. Завели табличку дата сообществ, пока туда добавляют котрибьютеры свои сообщества
3. Завели секция по поиску работы
4. Добавили уже несколько ключевых white papers для нашей индустрии
5. Стали добавлять книги.

И теперь по скилам и инструментам:
1. Добавили еще ресурсов в SQL
2. Новая секция большая про визуализацию данных
3. В секцию BI добавили видео - что такое BI
4. Добавили ресурсов про хранилище данных.
5. Вводная информация про моделирование данных
6. Добавили отечественных вендоров для облака
7. Создали секцию про DevOps (CI/CD, git, Linting, Docker, Kubernetes/Minikube). Секция новая пока, в процессе доработки.
8. Секция про IDE и CLI для инженеров и аналитиков.
9. Секция про AI в контексте инструментов для повседневной работы и помощи в работе.
10. Раздел про API
11. Языки программировани, пока только про Python
12. Apache Spark готова.

До других разделов у нас еще не дошли руки.

Планирую еще добавить разделы про:
- Безопасность
- Privacy/Compliance
- Сети
- Примеры архитектурных решений для аналитики (Open Source, Commercial, On-Premise, Cloud)
- Примеры решений в зависимости от размера компаний (от стартапа до большого Enterprise)

В существующие разделы нужно добавить рекомендации про инструменты (BI, хранилища данных, ETL и тп).

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

Читать полностью…

В Америке главный праздник - Thanks given day.

День благодаре́ния (англ. Thanksgiving Day) — североамериканский праздник, отмечается в четвёртый четверг ноября — в США и во второй понедельник октября в Канаде. С этого дня начинается праздничный сезон, который включает в себя Рождество и продолжается до Нового года.

Очень хороший праздник, коллеги американцы не работают и всем остальным можно тоже не работать🍾

Да и вообще уже конец года, можно расслабится до февраля.😊

И еще есть много мемов про индюшку.

Читать полностью…

На дворе 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/

Читать полностью…