Замечательная штука для решения 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.

Продолжаю работу над порталом Дата Инженеръ.

Сегодня обновил главную страницу, чтобы задать контекст ресурса:

• Цель сайта
• Для кого этот сайт?
• Что такое аналитика?
• Архитектура аналитического решения
• Ключевые роли в аналитике
• Инжиниринг данных
• Учебные материалы
• Как добавлять ресурсы?

Из готовых страниц — ресурсы по SQL.

Портал создан с помощью Jekyll и хостится через GitHub Actions. Каждая страница — это Markdown-документ, что значительно упрощает работу. Поскольку сайт является репозиторием, контрибьютить в него можно через Pull Request, что делает процесс простым и прозрачным. Осталось только собрать модераторов и контрибьюторов.

Задача — собрать самые ценные и полезные ресурсы: white papers, тренажеры, выступления, тренинги и книги, структурированные по ролям. Отдельно добавлю дорожные карты для нескольких профессий и ссылки на ресурсы для самостоятельного обучения. Дорожные карты будут 2х типов - для отечественного рынка и для западного. Отличаться будет лишь набором инструментов, фундаментально все совпадает.

P.S. С доменом dataengineer.ru повезло. Пришла идея создать что-то полезное и упорядочить знания и ресурсы, накопившиеся за последние 10 лет, и оказалось, что домен выставлен на продажу за 100 тысяч рублей. Раз уж я занимаюсь этим последние 15 лет и мне нравится вносить вклад в русскоязычное сообщество (потому что вижу отклик и реальную пользу для людей), то почему бы не закрепить это правильным доменом.

В продолжение поста про DuckDB, ссылка на сам урок и hands-on (модуль 2, про базы данных).

Кто ты?

Я пробовал 1, 2, 3. Но сейчас мне прям понравился 2 но с экраном в 1,5 раза больше - 49”.

Такой в офисе есть, он размером как 3 монитора 27” и все на одном экране, у меня на нем 1.5x производительность.

Сегодня на проекте 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 канал: 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, которые мы строим.

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

Каждый раз, как Bitcoin пробивает потолок, я иду смотреть цену акций old school BI - Microstrategy. Хотя, если он падает, я делаю тоже самое.

Linting — это автоматический процесс форматирования кода в соответствии с правилами и лучшими практиками (best practices). Например, для Python часто используется стиль PEP8. Для проверки написания кода можно применять библиотеки flake8 и black, которые выполняют эту задачу автоматически. Желательно, чтобы в команде было соглашение по стандартам. Всё это можно настроить через pre-commit и continuous integration.

Когда речь заходит о SQL, ситуация гораздо сложнее. Чаще всего никаких стандартов и инструментов не используется. Однако самый популярный линтер для SQL — это sqlfluff. Он отлично работает с популярными облачными хранилищами данных и dbt.

Недавно я узнал о линтере на Rust под названием SDF Lint. Утверждается, что он в 1000 раз быстрее. Сам я его ещё не тестировал, так как меня устраивает sqlfluff — торопиться некуда.

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

А вы что-нибудь используете?

На дворе 2025 год и сейчас становится актуальный новый тренд оверэмполймент. Скоро вас даже на работу брать не будут если вы не работали минимум на 2х работах😂

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

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

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

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

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

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

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

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

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

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

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

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

Давайте расскажу, что мы добавили на сайт 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 для профессий и привязать его к ресурсам.

#dataengineer_ru

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

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

В статье 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 за секунду». Да, это не универсальная истина, но эта оценка — хороший инструмент.

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

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