Forwarded from Архитектор Данных
3 основных кейса применений Лейкхаусов
По наблюдениям, сегодня доминируют эти три основных кейса внедрения домика у озера.
1. КХД+. У нас уже есть достаточно развитое хранилище данных. У нас есть команда в 30-50 человек специалистов по данным. Мы хорошо умеем извлекать из них ценность. И вот у нас появляются данные, которые все еще ценные для бизнеса, но которые уже нецелесообразно загружать в КХД. Логи, события, кликстримы. Нужно решение, которое сохранит простоту и привычность доступа к данным, при этом не разорит нас. Тут и появляется гибко масштабируемый ДатаЛейк[Хаус].
2. Next Gen DataLake. И здесь же миграция с хадупа. Вы не поверите, сколько сейчас хадупов на бесплатном Хортоне, который застыл в развитии в 2016 году. Куда-то надо это везти в перспективе. Менять старый хадуп на более новый - ну такое, это все же очень архаичная система. А что есть современнее? (Желательно не очень дорогое)
3. Технологии+. Некоторые не хотят Мерседес, некоторые фанаты Теслы. Причем, с пониманием, что Тесле нет того и этого, и вообще как машина она, мягко говоря, уступает. Но вот хочется быть на острие прогресса.
Стыдливо опускаем кейс номер три-с-половиной, где нам всем очень хочется поиграться с новой технологией и записать ее себе в CV.
По наблюдениям, сегодня доминируют эти три основных кейса внедрения домика у озера.
1. КХД+. У нас уже есть достаточно развитое хранилище данных. У нас есть команда в 30-50 человек специалистов по данным. Мы хорошо умеем извлекать из них ценность. И вот у нас появляются данные, которые все еще ценные для бизнеса, но которые уже нецелесообразно загружать в КХД. Логи, события, кликстримы. Нужно решение, которое сохранит простоту и привычность доступа к данным, при этом не разорит нас. Тут и появляется гибко масштабируемый ДатаЛейк[Хаус].
2. Next Gen DataLake. И здесь же миграция с хадупа. Вы не поверите, сколько сейчас хадупов на бесплатном Хортоне, который застыл в развитии в 2016 году. Куда-то надо это везти в перспективе. Менять старый хадуп на более новый - ну такое, это все же очень архаичная система. А что есть современнее? (Желательно не очень дорогое)
3. Технологии+. Некоторые не хотят Мерседес, некоторые фанаты Теслы. Причем, с пониманием, что Тесле нет того и этого, и вообще как машина она, мягко говоря, уступает. Но вот хочется быть на острие прогресса.
Стыдливо опускаем кейс номер три-с-половиной, где нам всем очень хочется поиграться с новой технологией и записать ее себе в CV.
👍4
Forwarded from DataJourney
Кто такой Apache Iceberg
В последнее время вокруг ввсе больше и больше информации про озера данных и какое-то слово «Iceberg», которое позволяет строить такие хранилища. До ознакомления с вопросом, я ошибочно полагал, что Icebrg - это просто новый формат файла по аналогии с Parquet или Avro, которй предлагает какие-то новые фичи, которых не было до него.
На самом же деле, Iceberg - это некий протокол, который описывает договоренность по укладке файлов в хранилище, чтобы потом эти файлы можно было удобно с хранилища поднимать и выполнять к ним запросы. При этом сами файлы, которые физичеки находятся на диске, имеют уже знакомые форматы: Parquet, Avro или ORC. Рядом с файлами данных лежат статистики - отдельные файлы, в которых описано их содержимое: максимумы, распределения, количество и т.п.
Команда Icebreg написала реализацию протокола для некоторых движков (вот, например, jar для Apache Spark 3), что позволило достаточно комформтно начать работать работать с новым форматом на имеющихся инсталяциях этих самых движков. По сути, администратору нужно добавить пару библиотек и дать доступ к бакету S3, чтоб начать использование.
Пошупать Iceberg локально в связке со с Spark можно с помощью Docker и нехитрой инструкции из официальной документации: https://iceberg.apache.org/spark-quickstart/
В последнее время вокруг ввсе больше и больше информации про озера данных и какое-то слово «Iceberg», которое позволяет строить такие хранилища. До ознакомления с вопросом, я ошибочно полагал, что Icebrg - это просто новый формат файла по аналогии с Parquet или Avro, которй предлагает какие-то новые фичи, которых не было до него.
На самом же деле, Iceberg - это некий протокол, который описывает договоренность по укладке файлов в хранилище, чтобы потом эти файлы можно было удобно с хранилища поднимать и выполнять к ним запросы. При этом сами файлы, которые физичеки находятся на диске, имеют уже знакомые форматы: Parquet, Avro или ORC. Рядом с файлами данных лежат статистики - отдельные файлы, в которых описано их содержимое: максимумы, распределения, количество и т.п.
Команда Icebreg написала реализацию протокола для некоторых движков (вот, например, jar для Apache Spark 3), что позволило достаточно комформтно начать работать работать с новым форматом на имеющихся инсталяциях этих самых движков. По сути, администратору нужно добавить пару библиотек и дать доступ к бакету S3, чтоб начать использование.
Пошупать Iceberg локально в связке со с Spark можно с помощью Docker и нехитрой инструкции из официальной документации: https://iceberg.apache.org/spark-quickstart/
👍7
Forwarded from DataJourney
…продолжаю про Iceberg
Попробую вкратце описать фичи протокола, который делает его таким популярным. Первое, о чем хочется поговорить и самое главное, на мой взгляд, - это пачка статистики и описаний, которая лежит рядом с дата файлами и содержит информацию, которую используют движки расчета для того, чтоб поднимать данные из S3. Несмотря на все свершения человечества, одной из самых медленных операций по прежнему остаётся подъем данных с диска и все системы, которые оперируют с данными, стараются уменьшать количество байт, которые читаются в память. У Iceberg эти принципы вшиты прямо в протокол.
На картинке к посту изображена схема хранения из документации Iceberg (github link). Условно, протокол делит все данные на три большие части (снизу-вверх):
1️⃣ Собственно сами данные. Это файлы в форматах Parquet, Avro или ORC. Тут никакой магии. Просто данные, просто на хранилище.
2️⃣ Слой метаданных. Тут уже начинается магия связи верхнеуровнего объекта «таблица» с множеством файлов из первого пункта. Имеем три группы файлов:
файлы манифеста, который описывает файлы с данными: их расположение, статистики столбцов и партиции;
файлы со списком файлов манифеста, который описывает обобщенные статисткии уже файлов манифестов и их перечень;
файлы метаданных, который описывает «таблицу» в целом, списки манифестов для каждого конкретного снэпшота. Эти же файлы обеспечивают изоляции по принципам MVCC. Если два процесса одновременно собираются читать и писать данные, то создается копия файлов, достаточная для того, чтобы каждый процесс получил доступ к данным изолированно. Каждая такая копия - это снапшот. О них детальнее поговорим позже, но даже на этой схеме уже видны две версии таблицы db1.table1: S0 и S1, для которых хранятся отдельные наборы файлы манифестов, метаданных и данных. При этом, для обеспечения изоляции, в моменте файлы с данными будут дублироваться, что приведет к повышенному потребелению ресурсов дискового пространства.
3️⃣ Каталог. Некая сущность, которая умеет хранить информацию о связи «объект таблица» - «набор метаданных». Единственное требование к каталогу - уметь инфомрацию перезаписывать атомарно. Так, чтобы два процесса одновременно не смогли создать конкурирующие наборы файлов. Поговорим о каталогах чуть поздней.
Таким образом, получается, что для записи информации в формате Iceberg движок должен последоватльно создать записи в трёх местах:
1. Записать данные на хранилище.
2. Посчитать агрегаты и записать их в слой метаданных.
3. Записать информацию о привязке новых метаданных в каталог.
При этом есть одна вещь, про которую следует помнить. Информация, которая указана в манифесте - даётся под «честное слово». Так как Iceberg это не управляющая программа, то никто не проверяет действительно ли есть файл данных, если он указан в манифесте. Действительно ли существуют ограничения (uniq, not null, order) если они указаны в манифесте.
Попробую вкратце описать фичи протокола, который делает его таким популярным. Первое, о чем хочется поговорить и самое главное, на мой взгляд, - это пачка статистики и описаний, которая лежит рядом с дата файлами и содержит информацию, которую используют движки расчета для того, чтоб поднимать данные из S3. Несмотря на все свершения человечества, одной из самых медленных операций по прежнему остаётся подъем данных с диска и все системы, которые оперируют с данными, стараются уменьшать количество байт, которые читаются в память. У Iceberg эти принципы вшиты прямо в протокол.
На картинке к посту изображена схема хранения из документации Iceberg (github link). Условно, протокол делит все данные на три большие части (снизу-вверх):
файлы манифеста, который описывает файлы с данными: их расположение, статистики столбцов и партиции;
файлы со списком файлов манифеста, который описывает обобщенные статисткии уже файлов манифестов и их перечень;
файлы метаданных, который описывает «таблицу» в целом, списки манифестов для каждого конкретного снэпшота. Эти же файлы обеспечивают изоляции по принципам MVCC. Если два процесса одновременно собираются читать и писать данные, то создается копия файлов, достаточная для того, чтобы каждый процесс получил доступ к данным изолированно. Каждая такая копия - это снапшот. О них детальнее поговорим позже, но даже на этой схеме уже видны две версии таблицы db1.table1: S0 и S1, для которых хранятся отдельные наборы файлы манифестов, метаданных и данных. При этом, для обеспечения изоляции, в моменте файлы с данными будут дублироваться, что приведет к повышенному потребелению ресурсов дискового пространства.
Таким образом, получается, что для записи информации в формате Iceberg движок должен последоватльно создать записи в трёх местах:
1. Записать данные на хранилище.
2. Посчитать агрегаты и записать их в слой метаданных.
3. Записать информацию о привязке новых метаданных в каталог.
При этом есть одна вещь, про которую следует помнить. Информация, которая указана в манифесте - даётся под «честное слово». Так как Iceberg это не управляющая программа, то никто не проверяет действительно ли есть файл данных, если он указан в манифесте. Действительно ли существуют ограничения (uniq, not null, order) если они указаны в манифесте.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Еще не читал, но уже рекомендую. Ибо статья от первопроходца, начавшего внедрять Data Mesh на отечественных просторах, "у берез и сосен", так сказать, задолго до того как это стало мейнстримом, обязательна к прочтению, на мой взгляд.
Дима - топчик!
https://medium.com/adeo-tech/samurais-journey-mashup-of-data-mesh-and-other-data-approaches-1286a2a5c72d
Дима - топчик!
https://medium.com/adeo-tech/samurais-journey-mashup-of-data-mesh-and-other-data-approaches-1286a2a5c72d
Medium
Samurai’s Journey: Mashup of Data Mesh and Other Data Approaches
This article explores our ongoing transition from a centralized data management and governance approach, which began in 2019, to an…
👍2
#заметкинаполях #introducingmlops
В последние три недели с головой упал в омут типичных трудовых будней среднестатистического отечественного «руками водителя». Времени #напочитать не было практически совсем. Ну, как совсем… Просто в пятом томе великой «Махабхараты» про данные нет ни единого слова. Зато много чего интересного есть про ведение сложных переговоров, разрешение конфликтных ситуаций и последствиях потакания токсичным персонажам… Но это так, лирическое отступление. Время возвращаться к делам нашим MLOps-ным.
Третья глава - самая полезная в книге, на мой взгляд, ибо в ней дается вехнеуровневое описание жизненного цикла машинного обучения (development, deployment, monitoring, iteration, and governance) достаточное для понимания человеком от ML довольно далекого, что является бесценным для «руками водителя», просто сверяйся с книгой, «все уже украдено до нас».
В последующих главах каждый компонент цикла рассматривается подробнее.
продолжение следует...
В последние три недели с головой упал в омут типичных трудовых будней среднестатистического отечественного «руками водителя». Времени #напочитать не было практически совсем. Ну, как совсем… Просто в пятом томе великой «Махабхараты» про данные нет ни единого слова. Зато много чего интересного есть про ведение сложных переговоров, разрешение конфликтных ситуаций и последствиях потакания токсичным персонажам… Но это так, лирическое отступление. Время возвращаться к делам нашим MLOps-ным.
Третья глава - самая полезная в книге, на мой взгляд, ибо в ней дается вехнеуровневое описание жизненного цикла машинного обучения (development, deployment, monitoring, iteration, and governance) достаточное для понимания человеком от ML довольно далекого, что является бесценным для «руками водителя», просто сверяйся с книгой, «все уже украдено до нас».
В последующих главах каждый компонент цикла рассматривается подробнее.
продолжение следует...
👍2
Forwarded from BigData info
Apache iceberg: tips and trics
https://www.youtube.com/watch?v=VbAqsLHfrqs&ab_channel=sql-ninja
https://www.youtube.com/watch?v=VbAqsLHfrqs&ab_channel=sql-ninja
YouTube
Apache iceberg: tips and tricks
Из этого доклада вы узнаете про наш опыт эксплуатации apache iceberg на петабайтных таблицах, о том с какими проблемами столкнулись и как решали. Бонусом набор полезных советов.
#заметкинаполях #introducingmlops
Закончил чтение «Introducing MLOps». Еще одна понравившаяся глава рассказывает про управление моделями, если кратко, то - это очередное «наше все», без которого ничего работать не будет нормально.
В общем, относитесь к руководству моделями серьезно, не откладывайте в долгий ящик, планируйте процесс заранее, продумывайте политики, найдите инструменты для централизованного их представления и распространения на всю организацию ради.
Это займет много времени, понадобится не одна итерация, но в конце пути, оглянувшись назад, вы будете гордиться собой, подобно Александру Овечкину, давеча перекрывшему великое достижение товарища Ивана Грецкого.
За сим на этом все. А коль скоро так, самое время открыть новую книгу, надеюсь, не менее интересную.
Закончил чтение «Introducing MLOps». Еще одна понравившаяся глава рассказывает про управление моделями, если кратко, то - это очередное «наше все», без которого ничего работать не будет нормально.
В общем, относитесь к руководству моделями серьезно, не откладывайте в долгий ящик, планируйте процесс заранее, продумывайте политики, найдите инструменты для централизованного их представления и распространения на всю организацию ради.
Это займет много времени, понадобится не одна итерация, но в конце пути, оглянувшись назад, вы будете гордиться собой, подобно Александру Овечкину, давеча перекрывшему великое достижение товарища Ивана Грецкого.
За сим на этом все. А коль скоро так, самое время открыть новую книгу, надеюсь, не менее интересную.
👍4
#заметкинаполях #C4model #напочитать
Simon Brown, автор книги «C4 Model for Visualising Software Architecture», в которой он вводит лаконичную, но мощную нотацию для построения архитектурных диаграмм, оказал сильное влияние на авторов «Data Mesh in Action», коей, в свою очередь, вдохновляюсь я при решении рабочих задач, а коль скоро так, то мимо пройти я никак не мог. Тем более, что о данной методологии был наслышан, но вот случая ознакомиться не представлялось. А сейчас словно звезды сошлись…
Зачем нужна еще одна методология визуализации архитектуры? Автор отвечает на это следующим образом:
➕ C4 model - это простой способ «увидеть всю картинку целиком» (кто помнит героя популярного сериала, сделавшего эту фразу легендарной?), показать, как все устроено и как составные части «упаковываются» в картину еще большего размера
➕Создает единое видение разрабатываемого «нечто» у каждого члена команды и помогает им оставаться в фокусе, объясняет суть происходящего в том числе и людям без технического бэкграунда
➕ Быстрее вводит в курс дела новых членов команды
➕ При всей своей простоте и лаконичности данный вид диаграмм прекрасно отражает реальность
продолжение следует…
Simon Brown, автор книги «C4 Model for Visualising Software Architecture», в которой он вводит лаконичную, но мощную нотацию для построения архитектурных диаграмм, оказал сильное влияние на авторов «Data Mesh in Action», коей, в свою очередь, вдохновляюсь я при решении рабочих задач, а коль скоро так, то мимо пройти я никак не мог. Тем более, что о данной методологии был наслышан, но вот случая ознакомиться не представлялось. А сейчас словно звезды сошлись…
Зачем нужна еще одна методология визуализации архитектуры? Автор отвечает на это следующим образом:
➕ C4 model - это простой способ «увидеть всю картинку целиком» (кто помнит героя популярного сериала, сделавшего эту фразу легендарной?), показать, как все устроено и как составные части «упаковываются» в картину еще большего размера
➕Создает единое видение разрабатываемого «нечто» у каждого члена команды и помогает им оставаться в фокусе, объясняет суть происходящего в том числе и людям без технического бэкграунда
➕ Быстрее вводит в курс дела новых членов команды
➕ При всей своей простоте и лаконичности данный вид диаграмм прекрасно отражает реальность
продолжение следует…
👍6
#напочитать
Неожиданный и весьма приятный подарок на ДР пополнил коллекцию бумажных книг. Хочется немедленно приступить к чтению, но "порядок превыше всего".
Неожиданный и весьма приятный подарок на ДР пополнил коллекцию бумажных книг. Хочется немедленно приступить к чтению, но "порядок превыше всего".
👍7
#заметкинаполях #C4model
Душа радуется и настрой на будень трудовой резко повышается, когда с утра накатил быстрых повторов по Джеку Дэниэлсу: 600м - 2'5'', 500м - 1'41'', 400м - 1'19'', 300м - 52''. Но, как поет глубокоуважаемый мною Роман Суслов: «Не о том речь».
Итак, свое название методология С4 получила по первым буквам названий четырех уровней абстракции, коими она оперирует:
1️⃣ Context - отправная точка, показывает, как система вписывается в окружающую ее среду и как с ней взаимодействует. «К черту подробности, город какой?», - в общем.
2️⃣ Containers - Раскрывает основные «строительные блоки» системы и связи между ними.
3️⃣ Components - Переходит в отдельный компонент и демонстрирует его составные части
4️⃣ Code - детали реализации компонента, некоторые считают, что «он нам и нафиг не нужон».
продолжение следует…
Душа радуется и настрой на будень трудовой резко повышается, когда с утра накатил быстрых повторов по Джеку Дэниэлсу: 600м - 2'5'', 500м - 1'41'', 400м - 1'19'', 300м - 52''. Но, как поет глубокоуважаемый мною Роман Суслов: «Не о том речь».
Итак, свое название методология С4 получила по первым буквам названий четырех уровней абстракции, коими она оперирует:
1️⃣ Context - отправная точка, показывает, как система вписывается в окружающую ее среду и как с ней взаимодействует. «К черту подробности, город какой?», - в общем.
2️⃣ Containers - Раскрывает основные «строительные блоки» системы и связи между ними.
3️⃣ Components - Переходит в отдельный компонент и демонстрирует его составные части
4️⃣ Code - детали реализации компонента, некоторые считают, что «он нам и нафиг не нужон».
продолжение следует…
👍4
Forwarded from Сорока пишет | Об ИТ и менеджменте
Накопилось у меня тут материалов по иишнице, но открою эту тему с пятничного 😄
😁7
Forwarded from DataJourney
SCD - slowly changing dimension (медленно меняющиеся измерения)
Любимый вопрос на собеседования рядом с базами данных (от больших хранилищ до маленьких баз) - это вопрос про SCD. Если кратко, то это приёмы хранения различных справочников объектов, атрибуты которых меняются, но не так часто как таблицы фактов. В рускоязычной вики описаны три типа SCD, но на самом деле различают до семи типов.
0️⃣ вырожденный случай, в котором атрибуты не меняются никогда.
Пример: справочник химических элементов.
1️⃣ тип хранения, в котором не хранится историчность, а значения атрибута перезаписываются при его обновлении.
Пример: Состояние табло аэропорта, отображающего время и место вылета самолётов.
2️⃣ тип хранения, в котором уже сохраняются предыдущие значения справочника. Для того, чтобы выбрать актуальное состояние добавляется поле с версией объекта или флаг того, что строка актуальная и смотреть нужно именно на неё или же описываются даты начала и окончания действия строки.
Пример: справочник тарифов за коммуналку. Там важно знать именно периоды действия тарифа, чтобы иметь возможность делать перерасчеты.
3️⃣тип хранения, при котором добавляется новая колонка для нового состояния атрибута и, в некоторых случаях, дата смены атрибута.
Пример: справочник специалистов, которые ведут приём. Может статься так, что периодически специалист меняет кабент, но клиенту важно знать в каком кабинете он был в прошлый раз.
… продолжение следует
Любимый вопрос на собеседования рядом с базами данных (от больших хранилищ до маленьких баз) - это вопрос про SCD. Если кратко, то это приёмы хранения различных справочников объектов, атрибуты которых меняются, но не так часто как таблицы фактов. В рускоязычной вики описаны три типа SCD, но на самом деле различают до семи типов.
0️⃣ вырожденный случай, в котором атрибуты не меняются никогда.
Пример: справочник химических элементов.
1️⃣ тип хранения, в котором не хранится историчность, а значения атрибута перезаписываются при его обновлении.
Пример: Состояние табло аэропорта, отображающего время и место вылета самолётов.
2️⃣ тип хранения, в котором уже сохраняются предыдущие значения справочника. Для того, чтобы выбрать актуальное состояние добавляется поле с версией объекта или флаг того, что строка актуальная и смотреть нужно именно на неё или же описываются даты начала и окончания действия строки.
Пример: справочник тарифов за коммуналку. Там важно знать именно периоды действия тарифа, чтобы иметь возможность делать перерасчеты.
3️⃣тип хранения, при котором добавляется новая колонка для нового состояния атрибута и, в некоторых случаях, дата смены атрибута.
Пример: справочник специалистов, которые ведут приём. Может статься так, что периодически специалист меняет кабент, но клиенту важно знать в каком кабинете он был в прошлый раз.
… продолжение следует
👍5