Теперь вы знаете как делать топ конференция!

Там реально можно набить татуху с AWS сервисом или мультяшкой!

Не благодарите за идею к вашему следующему ивенту и новогодним корпоративам))

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

В последнее время было тихо у AWS на фоне AI. Они просто ждали свою конференцию re:Invent, чтобы анонсировать все. Уже все написали за нас, осталось попросить chat gpt перевести:

Amazon на этой неделе решил действовать жестко. Они только что анонсировали собственные foundation models, на 75% дешевле. Плюс AI Chips. Плюс суперкомпьютер. Они нацелились на ВСЕХ.

Это похоже на скоординированную атаку на всех основных фронтах искусственного интеллекта.

Amazon одновременно бросает вызов OpenAI/Microsoft в области foundation models, NVIDIA в разработке чипов, xAI в суперкомпьютерах, и заручается поддержкой мощных союзников, таких как Anthropic и Apple. Кстати, SAP в восторге от этого.


1. Доминирование в Foundation Models

- Шесть новых моделей Nova, которые соответствуют или превосходят конкурентов
- На 75% ниже стоимости по сравнению с текущими лидерами рынка
- Уже используются в 1000 приложений Amazon
- Дорожная карта на 2025 год включает революционные модели "speech-to-speech" и "any-to-any"
- Поддержка 200+ языков, в то время как конкуренты сосредоточены на английском

2. Революция в чипах

- Чипы Trainium2 демонстрируют 4-кратный прирост производительности
- Снижение стоимости на 50% по сравнению с Nvidia
- Apple подписан как крупный клиент
- Глубокое сотрудничество с Annapurna Labs
- Уже разрабатываются чипы следующего поколения Trainium3

3. Project Rainier: Суперкомпьютер

- Создание крупнейшего в мире распределённого AI-кластера
- Сотни тысяч чипов Trainium работают в унисон
- В 5 раз мощнее текущих систем Anthropic
- Многоузловой дизайн для беспрецедентного масштаба
- Прямой конкурент Colossus от xAI

4. Сделка с Anthropic

- Масштабные инвестиции в размере $8 миллиардов
- Закрепление за собой роли основного поставщика облачных услуг
- Эксклюзивный доступ к будущим моделям Claude
- Глубокое техническое сотрудничество по оптимизации чипов
- Ранний доступ для клиентов AWS

Самое впечатляющее: Amazon создаёт целую экосистему. Они одновременно решают задачи вычислительных мощностей (Project Rainier), чипов (Trainium), моделей (Nova) и партнёрств (Anthropic) — и при этом снижают цены для всех.

Source

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

Snowflake знают все, даже если вы его никогда не использовали, но если вы работаете в области аналитики данных или инжиниринга данных, вы точно о нём слышали.

Главная его особенность заключается в том, что Snowflake фактически создал концепцию Lake House до того, как она стала популярной в 2020-2021 годах. Идея заключалась в разделении Compute (вычисления на виртуальных машинах) и Storage (хранение данных на S3, Azure Storage, GCP Storage).

То есть все данные хранятся в одном большом хранилище (storage), а вычисления могут выполняться на любом подходящем ресурсе.

Речь, в данном случае, о кластерах Snowflake (Compute Warehouse). Единственный недостаток этой технологии — данные хранятся в закрытом формате, представляющем собой black box для конечного пользователя, что также приводит к эффекту vendor lock.

Чтобы упростить продажу продукта, Snowflake позиционируется как хранилище данных. Если бы в 2016-2017 годах компания пыталась объяснять клиентам, что это нечто большее, чем классическое хранилище, и не совсем хранилище, это значительно усложнило бы продажи.

С 2020 года стали активно развиваться открытые форматы таблиц, которые заменили классический каталог Apache Hive: Delta, Iceberg и Hudi.

Hudi стух. Delta стал стандартом для Databricks. Iceberg занял лидерство в индустрии.

Snowflake также добавил поддержку каталога Iceberg. В свою очередь, Databricks приобрел компанию Tabular (создателей Iceberg), чтобы унифицировать формат внутри своего lake house — Delta Lake Universal Format (UniForm).

И теперь снова о Snowflake, который считается дорогим, но при этом удобным и простым в использовании. В сети полно информации о том, как можно оптимизировать затраты, самый популярный метод — включить AUTO Suspend.

Однако мы наблюдаем сдвиг в сторону унификации аналитических решений. По умолчанию Snowflake скрывает свои данные и хранит их в собственном формате, как любая база данных. Но с развитием интеграции Iceberg появилась возможность переносить часть данных из Snowflake во внешнее хранилище и создавать Snowflake-Iceberg Managed Catalog.

Это открывает множество возможностей использовать каталог Snowflake, задействуя внешние вычислительные движки, такие как DuckDB, Trino, Spark, Polars и PyArrow.

Несколько ссылок по теме:
- Quack, Quack, Ka-Ching: Cut Costs by Querying Snowflake from DuckDB
- Execute Snowflake queries locally on DuckDB
- Processing Trillions of Records at Okta with Mini Serverless Databases

Пока это не полноценная замена Snowflake или унификация методов хранения и доступа к данным, но видно как это направление набирает обороты и позволяет уже сейчас сократить расходы Snowflake.

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

Визуализация из Канадской действительности - 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 такой роли вот нет, ну и хорошо:)

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

O’Reilly анонсировала новую книжку - AI Engineering: Building Applications with Foundation Models

Recent breakthroughs in AI have not only increased demand for AI products, they've also lowered the barriers to entry for those who want to build AI products. The model-as-a-service approach has transformed AI from an esoteric discipline into a powerful development tool that anyone can use. Everyone, including those with minimal or no prior AI experience, can now leverage AI models to build applications. In this book, author Chip Huyen discusses AI engineering: the process of building applications with readily available foundation models.

The book starts with an overview of AI engineering, explaining how it differs from traditional ML engineering and discussing the new AI stack.

The more AI is used, the more opportunities there are for catastrophic failures, and therefore, the more important evaluation becomes. This book discusses different approaches to evaluating open-ended models, including the rapidly growing AI-as-a-judge approach.

AI application developers will discover how to navigate the AI landscape, including models, datasets, evaluation benchmarks, and the seemingly infinite number of use cases and application patterns. You'll learn a framework for developing an AI application, starting with simple techniques and progressing toward more sophisticated methods, and discover how to efficiently deploy these applications.

- Understand what AI engineering is and how it differs from traditional machine learning engineering

- Learn the process for developing an AI application, the challenges at each step, and approaches to address them

- Explore various model adaptation techniques, including prompt engineering, RAG, fine-tuning, agents, and dataset engineering, and understand how and why they work

- Examine the bottlenecks for latency and cost when serving foundation models and learn how to overcome them
Choose the right model, dataset, evaluation benchmarks, and metrics for your needs

Вот кому-то нужно часто менять резюме и профайл:

Data Analyst -> Data Scientist -> ML Engineer -> Deep Learning Engineer -> LLMs Engineer -> AI Engineer.

Это как мне видится процесс, сам я не из sexy jobs 21 века, могу ошибаться.

У нас по проще:

Database (SQL) Developer -> ETL Developer -> Big Data Engineer -> Data Engineer.

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

И в продолжение последних нескольких постов про Apache Iceberg - Announcing Amazon S3 Tables – Fully managed Apache Iceberg tables optimized for analytics workloads

То есть можно сразу писать в S3 и подключать SQL/Compute engineer. Все в одно месте. Будет интересно смотреть как дальше все будет развиваться.

# создаем таблцу в S3
$ aws s3tables create-table-bucket --name jbarr-table-bucket-2 | jq .arn
"arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-2"

# переменная с ARN бакета
$ export ARN="arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-2"

# получаем список таблиц в S3
$ aws s3tables list-table-buckets | jq .tableBuckets[].arn
"arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-1"
"arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-2"

# создаем схему MYDATA в каталоге MYTABLEBUCKET используя Spark
scala> spark.sql("""CREATE NAMESPACE IF NOT EXISTS mytablebucket.mydata""")

# создаем таблицу
spark.sql("""CREATE TABLE IF NOT EXISTS mytablebucket.mydata.table1
 (id INT,
  name STRING,
  value INT)
  USING iceberg
  """)

# проверяем, что все на месте
$ aws s3tables list-namespaces --table-bucket-arn $ARN | jq .namespaces[].namespace[] 
"mydata"
$
$ aws s3tables list-tables --table-bucket-arn $ARN | jq .tables[].name
"table1"

# вставляем записи в таблицу
spark.sql("""INSERT INTO mytablebucket.mydata.table1
  VALUES
  (1, 'Jeff', 100),
  (2, 'Carmen', 200),
  (3, 'Stephen', 300),
  (4, 'Andy', 400),
  (5, 'Tina', 500),
  (6, 'Bianca', 600),
  (7, 'Grace', 700)
  """)

Такой подход открывает огромное кол-во возможностей для создания дата инфраструктуры на AWS с использованием открытого формата Iceberg. Теперь ждем ответ от Azure, GCP. Я уже выше писал несколько постов, насколько iceberg упрощает жизнь.

Ну и конечно, интересно как у VK, Yandex с Iceberg.

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

Недавно я писал про приятный инсайт и русский линкедин. Но теперь мне хотелось бы поделиться инсайтом, какие посты я вижу. Там почти не пишут про инструменты или архитектуру, или про какие-то вещи с индустрией. Если полистать и присмотреться, что пишут, то оказывается что каждый второй, если не каждый первый пост будет попадать в следующую категорию:
- HR (бывшие) теперь консультанты и коучи, могут быстро прокачать вас до нужного уровня, составить резюме и помочь найти работу.
- Специалисты (особенно в области product), могут вас поменторить и прокачать, составить резюме и помочь найти работу.
- Success stories как кто-то нашел работу благодаря консультации тех самых специалистов
- Скриншоты переписки при поиске работы. Тут возможно 2 вариант: Кандидат отжигает или HR отжигает.

Тем неменее, все равно прикольно читать, разбавляет индуских data influencers!

А что вам попадется в Linkedin на русском? 😝

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

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

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