Мой самый популярный пост в Linkedin оказался не про айти и аналитику….


Ведь реально получается:
1) Лучшая инвестиция это в семью и детей
2) Пословица про свой самовар самая правильная
3) Там еще добавил бы ликбез про ипотеку
4) Подход я работаю, жена тратит деньги работает отлично, чем больше жена потратила, тем больше я заработал, или наоборот

Так хорошо отдохнул, что забыл ноутбук за 500км, забыл его в пятницу, а вспомнил в понедельник вечером! Повезло, что он отмечен в Find My Device.

Основных компоненты системы для аналитики (System Designed for OLAP Workloads)

В данном контексте OLAP подразумевает аналитические запросы (сложные запросы на исторических данных).

Хранилище (Storage)
Для анализа исторических данных из различных источников необходимо иметь систему, позволяющую хранить большие объемы данных. Хранилище — это первый компонент системы, способной обрабатывать аналитические запросы к большим наборам данных. Варианты хранилища включают локальную файловую систему (DAS), распределенную файловую систему (HDFS) и объектное хранилище от облачных провайдеров (Amazon S3).

Типы хранилищ могут быть строковыми (row) или поколоночными (columnar) базами данных, или их комбинацией. Columnar уже является стандартом.

Формат файлов (File format) Для хранения, данные должны быть организованы в определенном формате файла. Выбор формата файла влияет на сжатие данных, их структуру и производительность работы.

Форматы файлов делятся на три категории: структурированные (CSV), полуструктурированные (JSON) и неструктурированные (текстовые файлы). В структурированных и полуструктурированных форматах данные могут быть организованы построчно или поколоночно. Примеры построчных форматов — CSV и Apache Avro, поколоночных — Apache Parquet и Apache ORC.

Формат таблицы (Table Format)
Важный компонент для системы, поддерживающей аналитические запросы к большим объемам данных. Формат таблицы действует как слой метанных над форматом файла и отвечает за расположение данных в хранилище.

Цель формата таблицы — упростить структуру данных и обеспечить возможности для операций с данными (вставка, обновление, удаление) и изменения схемы таблицы. Современные форматы таблиц также обеспечивают атомарность и согласованность операций.


Движок хранения (Storage engine)
Отвечает за размещение данных в заданном формате таблицы и поддержание всех файлов и структур данных в актуальном состоянии.

Движок хранения выполняет такие задачи, как оптимизация данных, поддержание индексов и удаление старых данных.

Каталог (Catalog)
При работе с данными из разных источников важно быстро находить нужные данные. Каталог решает эту задачу, используя метаданные для идентификации наборов данных.

Каталог — это центральное место, где можно найти информацию о таблицах, их схеме и расположении данных. Некоторые каталоги являются внутренними для системы (например, Postgres и Snowflake), другие, такие как Hive и Project Nessie, могут использоваться любыми системами.

Вычислительный движок (Compute Engine)
Последний компонент, необходимый для обработки больших объемов данных, выполняет пользовательские запросы по обработке данных. В зависимости от объема данных и типа нагрузки можно использовать один или несколько вычислительных движков. Для работы с большими объемами данных часто требуется распределенный вычислительный движок (MPP), такие как Apache Spark, Snowflake и Dremio.

PS надеюсь теперь вы поймете разницу между Parquet (file format) и Iceberg/Delta (table format)

Сегодня посмотрим на компоненты хранилища данных.

Хранилище данных это у нас просто большая база данных, часто это может быть распределенная (кластер из нескольких машин, чтобы они вместе все параллельно обрабатывали данные, ведь так быстрей и можно больше данных обработать - ну или просто Massive Parallel Processing)

Хранилище данных объединяет все технические компоненты в одной системе.

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


До примерно 2015 года большинство хранилищ данных имели компоненты хранения и вычислений, жестко связанные на тех же узлах, так как они были разработаны и использовались в основном на местах.

Это приводило к множеству проблем. Масштабирование становилось большой проблемой, так как объемы данных быстро росли, а количество и интенсивность нагрузок росло.

Не было возможности независимо увеличивать ресурсы хранения и вычислений в зависимости от задач. Если ваши потребности в хранении данных росли быстрее, чем потребности в вычислительных ресурсах, вам все равно приходилось платить за дополнительные вычислительные мощности, даже если они вам не были нужны.

Это привело к созданию следующего поколения хранилищ данных с акцентом на облачные технологии. Эти хранилища данных начали набирать популярность примерно в 2015 году, когда облачные вычисления стали более распространенными, позволяя разделять компоненты хранения и вычислений и масштабировать эти ресурсы в соответствии с задачами. Они даже позволяли отключать вычислительные ресурсы, когда они не использовались, и не терять при этом данные.

Хранилище данных до сих пор является отличным решением для построения аналитического решения.

Минису все известны:
- Поддержка только SQL
- Вы платите за compute и storage вместе (Snowflake и тп это lakehouse и о нем будет позже)
- Сложно использовать для ML, так как данные нужно выгружать
- У вас schema on write (то есть у вас таблица создана и вы в нее уже пишите как есть)
- Не очень удобно для streaming/real time аналитики, обычно это batch - раз в час, раз в сутки
- Это Vendor Lock

В след посте рассмотрим озеро данных.

Источник: https://www.oreilly.com/library/view/apache-iceberg-the/9781098148614/ch01.html

PS Судя по прошлым комментариям, я рад что ребята в Авито Тех тоже прочитали книгу и поделились знаниями со своей аудиторией🙃

В Surfalytics я попросил всех прочитать 1ю главу и понять, так как очень важно понимать разницу между DW/Data Lake/Lake House и знать их особенности.

А вот и книжка!

Мы рассмотрели компоненты хранилища данных, теперь озеро данных. К нему можно применить термин decoupled.

Изначально использовался Hadoop — открытая распределенная вычислительная платформа и компонент файловой системы HDFS для хранения и обработки больших объемов структурированных и неструктурированных данных на кластерах недорогих компьютеров. Для аналитики использовался MapReduce, но написание задач было сложным, поэтому был создан Hive для преобразования SQL-запросов в задачи MapReduce.

Со временем перешли от кластеров Hadoop к облачным объектным хранилищам (Amazon S3, Minio, Azure Blob Storage) из-за удобства и дешевизны. MapReduce заменили другие распределенные движки, такие как Apache Spark, Presto и Dremio. Однако формат таблиц Hive остался стандартом для распознавания файлов как таблиц для аналитики.

Ключевое отличие озера данных от хранилища данных — возможность использования разных вычислительных движков для различных задач. В озере данных нет службы, выполняющей функции движка хранения; обычно движок вычислений решает, как записывать данные, которые редко оптимизируются и совершенствуется.

Преимущества:
- Низкая стоимость: Хранение данных и выполнение запросов дешевле, чем в хранилище данных.
- Открытые форматы хранения: Можно использовать любые форматы файлов.
- Обработка неструктурированных данных: Озера данных могут обрабатывать данные, такие как данные сенсоров, вложения электронной почты и журналы.

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

Хранилище данных или озеро данных?
Озера данных хорошо подходят для хранения структурированных и неструктурированных данных, но имеют свои недостатки. Для высокоприоритетной аналитики данные часто копируются в хранилище данных, что приводит к дополнительным затратам и созданию множества копий данных, что не очень удобно и очевидно дороже.

Для выполнения запросов на озере данных можно использовать движки, такие как Dremio, Presto/Trino, Apache Spark и другие, но они сталкиваются с трудностями при обновлении данных из-за ограничений формата таблиц Hive.

Таким образом, озера данных и хранилища данных имеют свои уникальные преимущества и недостатки, что привело к появлению новой архитектуры, сочетающей их плюсы и минимизирующей минусы, — Data Lakehouse.


Как я первый раз познакомился с Lakehouse?
Был 2021 год, я был в Amazon Alexa, у нас было много данных и централизованный Redshift на 128 нод (максимальное кол-во нод) использовался для BI use cases. Redshift (хранилище данных) был единственный вариант для BI (отчетность), так как подключаться к озеру данных через Athena, Hive, Spark было не очень удобно из-за объема и особенности BI.

Тем не менее у Alexa было и озеро данных (upstream) на S3 и EMR (managed Hadoop). И там не было проблем с производительностью или хранением большого объема данных. Главная проблема была подружить это с BI и поэтому приходилось выгружать из озера и грузить в хранилище, а потом еще раз выгружать из хранилища обратно в S3 для ML.

Как раз в это время вступил в силу закон про data privacy (GDPR), для нас это простая задача - удалить CUSTOMER_ID(s) по запросу клиента раз в неделю. Это очень просто в реляционном хранилище данных, но очень сложно в озере данных (так как у вас просто куча файлов)

Поэтому мы стали смотреть в сторону Lakehouse, и первый open source был Delta для Spark.

Я как разу перешел в Xbox, и у меня была идея построить Delta Lake на Databricks, что я и сделал. Тогда Delta Lake был топ формат таблицы (теперь то мы знаем, что это не формат файлов). А вот сейчас походу надо уже строить на Iceberg. Хотя в Databricks все еще по умолчанию используется Delta.

А как было у вас?

Обучаем IT-специалистов и берём в команду ⚡️

Лучших выпускников пригласим на интервью и предложим карьерный фаст-трек до мидла в Т1.

🎓 Открытые школы Т1 — это месяц онлайн-интенсива с возможностью попасть в штат Холдинга Т1 — крупнейшей ИТ-компании в России по версии RAEX 2023, в портфеле которой 800+ масштабных проектов и 70+ продуктов и услуг.

Зачем участвовать?

⚙️ Уникальный рыночный опыт. Одними из первых на рынке внедряем технологии для управления данными. В ближайшем будущем ими будут пользоваться большинство крупных предприятий страны.

⚙️ Попасть в число лучших. Проекты Т1 ежегодно получают лучшие награды на ИТ-конкурсах: Global CIO, Национальная банковская премия и др.

⚙️ Поддержка. Нам удалось собрать команду опытных профессионалов в области разработки хранилищ данных и аналитических систем, которые помогут расти и развиваться.

Выбирай:

📁 аналитик DWH
🖥 разработчик DWH
📊 системный аналитик

Для участия нужен опыт работы от 1 года в выбранном направлении.

⏰ Быстрое обучение: 1 месяц
📱 Гибкий формат: онлайн по вечерам (от 8 часов в неделю на вебинары и практику)

Подавай заявку до 24 июля!
Старт интенсива: 29 июля.

Реклама. Информация о рекламодателе

Что пишут про главный сбой Microsoft?

Перевод поста Gergely Orosz, автора Pragmatic Engineer.

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

(Ниже фото из аэропорта Сиднея, где большинство экранов показывают синий экран смерти Windows, а планы путешествий нарушены из-за этого сбоя.)

Сбой затронул машины на Windows, которые используют Crowdstrike для защиты конечных точек (антивирус, файрвол, обнаружение вторжений, шифрование и контроль приложений).

Crowdstrike - это компания по кибербезопасности, оцененная в $80 миллиардов, и лидер рынка в области защиты конечных точек Windows с долей рынка около 22%. Таким образом, 1 из 5 компаний, использующих Windows, пользуется их услугами.

По-видимому, Crowdstrike выпустила достаточно невинное обновление программного обеспечения... на все машины Windows, по всему миру, практически одновременно. Программное обеспечение Crowdstrike работает на уровне ядра: и это обновление вызывает сбой Windows.

Обычно, когда баг в коде попадает в продакшн: вы просто отменяете это изменение и выпускаете предыдущую версию (или код, который работает корректно), и когда клиенты получают этот патч, их системы восстанавливаются. Но не в этом случае: потому что эти машины не функционируют.

Решение - как советует Crowdstrike - ручное и трудоемкое, и его нужно повторить для каждой машины на Windows, которую затронул сбой. Машину нужно загрузить в безопасном режиме, удалить файл, затем перезагрузить.

Что непонятно в этом сбое, так это как (и почему?) Crowdstrike выпустила глобальное обновление программного обеспечения без постепенного развертывания (так называемого развертывания с канарейками)? Это не имеет смысла, и ни один поставщик кибербезопасности с разумными практиками развертывания никогда бы не сделал этого. Насколько нам известно, это "глобальное развертывание" больше похоже на "YOLO развертывание" (мы рассматривали подходы к развертыванию в продакшн в The Pragmatic Engineer, включая YOLO развертывания на https://lnkd.in/dsQzhQ7). YOLO развертывания подходят, когда неважно, если развертывание пойдет не так, и достаточно просто вернуть все назад. Развертывание, которое может вывести из строя большинство ваших клиентов, не должно экспериментировать с этим подходом.

Для меня непостижимо, как можно было обойти постепенное развертывание: как это не стало обязательным процессом для всех развертываний, больших или маленьких. Последствия этого сбоя, несомненно, будут заметны на глобальном уровне ВВП - и это будет очень плохая новость для бизнеса Crowdstrike в будущем (кто захочет работать с поставщиком безопасности, который вызывает сбой 100% машин на Windows, на которых установлено их ПО, когда оно должно их защищать?)

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


PS кто-нибудь заметил сбой?

17 августа в Москве будет IT-пикник.
Это мероприятие для профессионалов IT-сферы, и на этот раз вход на пикник будет по пожертвованию в один из десяти благотворительных фондов. 💡💻

В программе IT-пикника:
📚 Лекции от топовых спикеров
🛠 Воркшопы для взрослых и детей
🔬 Научпоп-программа
🎮 Интерактивные зоны
🎵 Музыкальная программа

Ребята из Карельского регистра доноров костного мозга, который помогает пациентам с лейкозом найти совместимого донора стволовых клеток, попросили рассказать про мероприятие и упомянуть их фонд, так как участники it-пикника сами выбирают, в какой из благотворительных фондов будет перечислен их взнос. Все фонды с хорошей репутацией и заслуживают доверия. Каждый из них решает проблемы в определенной сфере: помогает онкопациентам, бездомным животным и так далее.

Для многих таких пациентов донорство – это последний шанс на выздоровление💖
Так ваше пожертвование в этот фонд поможет оплатить обследование новых доноров, каждый из которых может спасти жизнь.

IT-пикник – это замечательная возможность объединить приятное с полезным: посетить интересное мероприятие и помочь в спасении жизней. 🙌

Спасибо за вашу поддержку! ❤️

Ежегодная вечеринка с bbq и танцами в центре Ванкувера Surfalytics&Friends

📢 Друзья! 📢

В среду на канале DataLearn вебинар!
Тема: "Использование RAG и AI-агентов для поддержки клиентов" 🤖💬

🗓 Дата: 24 июля
🕗 Время: 20:00 по МСК

👨‍💻Спикер - CTO Wikibot Роман Чуприков!
Ребята уже приходили к нам и рассказывали про LLM модели🌟

Что обсудим:
🔸 Введение в Retrieval Augmented Generation (RAG) — торт или провал? 🍰❌
🔸 Парсинг данных — скучно, но важно! 📊
🔸 Разбиение документов на фрагменты и семантический поиск. 📚
🔸 Идеальный промпт существует? Как сделать так, чтобы бот отвечал «Я не знаю». 🤔
🔸 Первая линия поддержки — корректные ответы на важные вопросы. 🛡
🔸 От ответов к действиям — как обучить бота задавать уточняющие вопросы и работать с тикетами.
🔸 Бортовой журнал — интерфейс для постоянного дообучения бота.

Не пропустите! 🌟

👉 Ссылка на вебинар: https://youtube.com/live/IQjmR6jIlV0

Будем рады видеть вас! 😃👋
#datalearn #вебинар

Недавно посетила мысль, что телеграмм каналы делятся на 2 типа:

1) Телеграмм канал, который ведет автор, и делится своими идеями, мнениями, да хоть предпочтениями во вкусах мороженного. Но сам факт того, что телеграмм канал имеет живое “лицо” как-то располагает и его интересно читать.

2) Телеграмм канал, который посвящен какой-то теме, но он обезличенный, “бездушный”. Набор ссылок, новостей, мемов, часто бесполезных и противоречивых.

Почему-то с недавних пор 2ой типа каналов совсем стали неинтересны, а вот 1й тип, наоборот. Мне горазде интересной узнать как дела у автора, чем живет, что думает, куда двигается и тп. Это как сериал с любимыми актерами, но только в реальной жизни.

А как у вас?

Продолжаем нашу тему про Lakehouse. Самое важное это формат таблицы (table format).

Формат таблиц — это метод структурирования файлов набора данных, чтобы представить их как единую "таблицу".

Основная цель формата таблиц — предоставить абстракцию, которая позволяет пользователям и инструментам легко и эффективно взаимодействовать с данными.

Форматы таблиц существуют с момента появления реляционных СУБД, таких как System R, Multics и Oracle. Эти системы позволяли пользователям обращаться к набору данных как к таблице, абстрагируя сложные детали хранения данных на диске.

В современных системах большие объемы данных хранятся как файлы в хранилищах данных (например, Amazon S3, Azure Data Lake Storage, Google Cloud Storage). Использование SQL или кода для работы с этими файлами может быть неудобным и приводить к несогласованности данных.

Изначально изобрели Hive и он стал стандартом формата таблиц. Hive был разработан Facebook в 2009 году для упрощения аналитики в Hadoop, предоставляя возможность писать SQL-запросы вместо сложных задач MapReduce. (MapReduce писался на Java🫣)

Формат таблиц Hive определяет таблицу как все файлы в указанной директории и использует Hive Metastore для отслеживания этих таблиц.

Простой пример:
Если вы запустите Apache Spark локально и создать с помощью Spark SQL таблицу или вью, то метанные сможете найти в Hive Metastore. В Databricks Hive тоже по умолчанию, но там лучше подключить Unity Catalog. В AWS Glue, лучше использовать Glue Catalog и тд. А так все это про метанные и их управление.

Преимущества Hive:
- Поддержка более эффективных запросов благодаря техникам, таким как разделение и хеширование.
- Независимость от формата файлов, что позволяет использовать такие форматы, как Apache Parquet.
- Возможность атомарных изменений на уровне разделов таблицы.

Недостатки Hive:
- Неэффективность изменений на уровне файлов.
- Отсутствие механизма для атомарного обновления нескольких разделов.
- Проблемы с одновременными обновлениями.
- Замедление запросов из-за необходимости чтения и списка файлов и директорий.
- Ограниченные статистические данные для оптимизации запросов.
- Проблемы с производительностью при большом количестве файлов в одном разделе.

Современные форматы таблиц, такие как Apache Iceberg, Apache Hudi и Delta Lake, решают проблемы Hive, определяя таблицы как канонический список файлов, а не директорий. Это позволяет реализовать функции, такие как транзакции ACID и "путешествие во времени". (Прям как у Snowflake😏)

- Apache Iceberg: Разработан в 2018 году в Netflix для обеспечения ACID-транзакций и улучшения производительности при работе с большими данными в озерах данных.

- Apache Hudi: Создан в 2016 году в Uber для поддержки инкрементных обновлений и предоставления ACID-гарантий в больших наборах данных. (Наиболее устаревший)

- Delta Lake: Создан Databricks в 2019 году для обеспечения надежных транзакций и управления данными в озерах данных, улучшая их производительность и надежность.

Преимущества современных форматов таблиц:
- Поддержка транзакций ACID.
- Безопасность транзакции при одновременной записи в файл
- Сбор статистики и метаданных для более эффективного планирования запросов.

Поэтому работая с данными сегодня, вы будете работать либо с аналитическим хранилищем данных (не важно, что у них внутри) BigQuery, Redshift, Snowflake и тп, либо использовать Lakehouse решения и один из 3х популярных открытых форматов данных. Таким образом scope инженера данных и не такой-то уж и большой.

Лучший вариант понять все это - сделать pet проекты. Взять один сценарий и реализовать его разными способами, даже если на входе всего 100 мб JSON файлов.

Мне кажется 30-40% типичного собеседования на дата инженера проходи за обсуждение плюсов и минусов того или иного решения.

в 20:00 начинаем

И на всякий случай!

Как казаться умным
- Спрашивайте "А будет ли это масштабироваться?" независимо от темы разговора
- Просите вернуться на один слайд назад без всякой причины
- Побуждайте всех "сделать шаг назад"
- Повторяйте последнюю фразу инженера, но очень медленно
- Спрашивайте, задаем ли мы правильные вопросы
- Ходите по комнате
- Выйдите и сделайте вид, что получили важный телефонный звонок
- Спрашивайте, не смешиваем ли мы несколько вопросов
- Перебивайте чье-то обновление, а затем дайте им закончить
- В онлайн звонке отправить emoji или reaction, и похвалить спикера
- Спросить про следующие шаги и action plan
- Уточнить сроки (dead line)
- Спросить есть ли у нас OKR и как мы будем их измерить?
- На всякие случай спросить, а результат точно имеет tangible output?


Дополните список!