Я же вам говорил, что CLI знать надо, чтобы вот такие вот шутки понимать😅

Ответил еще на два вопроса:

1) заменит ли нас AI? 🤖
2) Что делать с опытом IBM DataStage 🦖

Leading Effective Engineering Teams - новая книжка по управлению инженерными командами!

The essential traits for engineering effectiveness and the pitfalls to avoid
How to cultivate trust, commitment, and accountability within your team
Strategies to minimize friction, optimize career growth, and deliver maximum value
The dynamics of highly successful engineering teams and how to replicate their achievements
How to implement a systems thinking approach for everyday problem-solving and decision-making
Self-advocacy techniques to enhance your team's visibility and recognition within the organization

Судя по отзывам в Linkedin, отлчная книга, у автора свой большой блог https://addyosmani.com/ и он уже успел написать много книг.

Apache Iceberg - What Is It - статья про Apache Iceberg, с картинками и объяснением

Кстати в Yandex и VK, как дела c Lakehouse обстоят да и в целом в РФ интересно куда сместился акцент. Раньше это было Clickhouse/Greenplum и обычно on-premise, а теперь?

Классная история про Clickhouse - The Fast and the Furious: How ClickHouse, the World’s Fastest Open-Source Database, is Creating the First Real-Time Data Warehouse

Мой самый популярный пост в 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 кто-нибудь заметил сбой?