Forwarded from rzv Data Engineering
#реклама
С улыбкой делюсь перспективным каналом по DE с тобой.
Вспомнил, с каким трепетом сам писал первые посты (кстати, рекомендую пролистать наверх тем, кто недавно на канале).
"""
✋🏻 Всем привет, меня зовут Дмитрий, я работаю дата инженером.
Мне крайне интересна эта область, поскольку я очень любознательный.
В своем недавно созданном канале пишу про инженерию данных, рабочие кейсы и свои мысли.
Я учусь, поэтому могу где-то допускать ошибки.
Канал будет интересен и новичкам, и средним по уровню специалистам.
Присоединяйтесь, комментируйте, давайте обратную связь. Надеюсь, материал будет для вас полезным.
📝 Блог https://t.iss.one/kuzmin_dmitry91
"""
С улыбкой делюсь перспективным каналом по DE с тобой.
Вспомнил, с каким трепетом сам писал первые посты (кстати, рекомендую пролистать наверх тем, кто недавно на канале).
"""
✋🏻 Всем привет, меня зовут Дмитрий, я работаю дата инженером.
Мне крайне интересна эта область, поскольку я очень любознательный.
В своем недавно созданном канале пишу про инженерию данных, рабочие кейсы и свои мысли.
Я учусь, поэтому могу где-то допускать ошибки.
Канал будет интересен и новичкам, и средним по уровню специалистам.
Присоединяйтесь, комментируйте, давайте обратную связь. Надеюсь, материал будет для вас полезным.
📝 Блог https://t.iss.one/kuzmin_dmitry91
"""
Telegram
Дмитрий Кузьмин | Инженерия данных
Путь Data engineer от Junior до Lead.
Делюсь мыслями, рабочими кейсами, обучением. Блог для junior - middle DE.
Мой профиль: @dim4eg91
Сайт: https://kuzmin-dmitry.ru
Практикум Data engineer: https://kuzmin-dmitry.ru/de_practicum
Делюсь мыслями, рабочими кейсами, обучением. Блог для junior - middle DE.
Мой профиль: @dim4eg91
Сайт: https://kuzmin-dmitry.ru
Практикум Data engineer: https://kuzmin-dmitry.ru/de_practicum
Forwarded from rzv Data Engineering
#вести_с_полей
Как DE может решать задачи CI/CD 1/3
🔸 Представь, что есть некоторый сервис интеграции с источниками данных, который можно конфигурировать через JSON по API. И ещё у сервиса есть визуальный интерфейс, через который эти конфиги можно задавать напрямую, в обход гита, что и делали последние несколько месяцев, потому что так быстрее.
🔸 Какие минусы у ручного подхода? Нет истории изменений, проверки перед применением очередной версии конфига, ещё и параметры подключения к сервисам (credentials) могут храниться в обычном текстовом виде. Безопасники не будут дружить с такими дата инженерами. И, если контур один, эти изменения применяются напрямую на проде, что редко добавляет стабильности работе системы.
🔸 Такие проблемы можно решить через CI/CD: CI -- непрерывная интеграция (continuous integration), CD -- непрерывная доставка (delivery) или развёртывание (deploy). Объединяет и упрощает совместные изменения в команде и унифицирует способ "применения" изменений на разных контурах (дев, тест, прод). Для дев/тест среды обычно есть тесты перед авто-развёртыванием, а для для прода часто выбирают Continuous Delivery -- подготовку поставки, которую можно развернуть по нажатию кнопки человеком. Например, через approve pull request'a.
Как DE может решать задачи CI/CD 1/3
🔸 Представь, что есть некоторый сервис интеграции с источниками данных, который можно конфигурировать через JSON по API. И ещё у сервиса есть визуальный интерфейс, через который эти конфиги можно задавать напрямую, в обход гита, что и делали последние несколько месяцев, потому что так быстрее.
🔸 Какие минусы у ручного подхода? Нет истории изменений, проверки перед применением очередной версии конфига, ещё и параметры подключения к сервисам (credentials) могут храниться в обычном текстовом виде. Безопасники не будут дружить с такими дата инженерами. И, если контур один, эти изменения применяются напрямую на проде, что редко добавляет стабильности работе системы.
🔸 Такие проблемы можно решить через CI/CD: CI -- непрерывная интеграция (continuous integration), CD -- непрерывная доставка (delivery) или развёртывание (deploy). Объединяет и упрощает совместные изменения в команде и унифицирует способ "применения" изменений на разных контурах (дев, тест, прод). Для дев/тест среды обычно есть тесты перед авто-развёртыванием, а для для прода часто выбирают Continuous Delivery -- подготовку поставки, которую можно развернуть по нажатию кнопки человеком. Например, через approve pull request'a.
Forwarded from rzv Data Engineering
Как DE может решать задачи CI/CD 2/3
🔸 Итак, реализация. В 90+% случаев это или Gitlab CI, или Github Workflows, или Atlassian Bamboo (в дополнение к bitbucket). Код workflow (или pipeline) задаётся в YAML файле, где определяются атомарные действия (шаги, степы) и группы шагов (джобы). Внутри обычно встретишь или много bash кода, или готовые "actions" из маркетплейса (примерно как операторы в airflow).
🔸 У каждого шага и джоба есть статус выполнения, input, output, к которым можно обращаться в других шагах и джобах. Можно вешать условия на выполнение -- например, делать деплой только после успешного выполнения всех тестов.
🔸 Также удобно выносить часть кода в переиспользуемые действия, обращаясь к ним как к степам из маркетплейса. И, что мне как питонисту близко, -- выносить код взаимодействия с сервисом в набор .py скриптов. Поэтому в дополнение к главному YAML может быть ещё директория в гите, где лежат тесты и код деплоя, общающиеся с сервисом через API. А workflow склеивает это воедино и задаёт логику перехода между шагами. И отчёты формирует для чтения статуса людьми.
🔸 Итак, реализация. В 90+% случаев это или Gitlab CI, или Github Workflows, или Atlassian Bamboo (в дополнение к bitbucket). Код workflow (или pipeline) задаётся в YAML файле, где определяются атомарные действия (шаги, степы) и группы шагов (джобы). Внутри обычно встретишь или много bash кода, или готовые "actions" из маркетплейса (примерно как операторы в airflow).
🔸 У каждого шага и джоба есть статус выполнения, input, output, к которым можно обращаться в других шагах и джобах. Можно вешать условия на выполнение -- например, делать деплой только после успешного выполнения всех тестов.
🔸 Также удобно выносить часть кода в переиспользуемые действия, обращаясь к ним как к степам из маркетплейса. И, что мне как питонисту близко, -- выносить код взаимодействия с сервисом в набор .py скриптов. Поэтому в дополнение к главному YAML может быть ещё директория в гите, где лежат тесты и код деплоя, общающиеся с сервисом через API. А workflow склеивает это воедино и задаёт логику перехода между шагами. И отчёты формирует для чтения статуса людьми.
Forwarded from rzv Data Engineering
Как DE может решать задачи CI/CD 3/3
🔸 Первое время немного неуклюже выглядит интеграция python и bash. Для этого нужно пробрасывать параметры из workflow в python скрипт и передавать результат работы обратно, но GPT помогают с нюансами Bash, и со временем картинка выстраивается. Кстати, я недавно перешёл на Claude Sonet, пока нравится больше, чем Gemini. Приятно, этот инструмент становится привычным, и на дейликах разработчики больше не стесняются говорить о парной работе с таким помощником.
🔸 Немного про разделение ответственности. В компаниях, где я работал, обычно было так: девопсы поднимают сервисы в ВМ или в контейнерах, а как с ними будут работать DE -- дело последних. Например, пайплайн по перезапуску упавшего Airflow скорее напишет DevOps. Пайплайн по доставке дагов из гита и тесты для проверок кода скорее будут писать DE.
❕ Пиши в комментах, с какими нюансами CI/CD столкнули рабочие задачи тебя. Или пока ещё дикий запад и всё накатывается руками?
🔸 Первое время немного неуклюже выглядит интеграция python и bash. Для этого нужно пробрасывать параметры из workflow в python скрипт и передавать результат работы обратно, но GPT помогают с нюансами Bash, и со временем картинка выстраивается. Кстати, я недавно перешёл на Claude Sonet, пока нравится больше, чем Gemini. Приятно, этот инструмент становится привычным, и на дейликах разработчики больше не стесняются говорить о парной работе с таким помощником.
🔸 Немного про разделение ответственности. В компаниях, где я работал, обычно было так: девопсы поднимают сервисы в ВМ или в контейнерах, а как с ними будут работать DE -- дело последних. Например, пайплайн по перезапуску упавшего Airflow скорее напишет DevOps. Пайплайн по доставке дагов из гита и тесты для проверок кода скорее будут писать DE.
❕ Пиши в комментах, с какими нюансами CI/CD столкнули рабочие задачи тебя. Или пока ещё дикий запад и всё накатывается руками?
Forwarded from AI with Parissan 🤖🦾 (Pariss)
Data Engineering Cookbook.pdf
1.8 MB
Forwarded from Ivan Begtin (Ivan Begtin)
К вопросу о poor man data engineering, как обрабатывать данные в условиях ограниченных ресурсов с минимальными нагрузками на диск и на оперативную память, в первую очередь.
В работе в Dateno есть задача по добавлению стат. индикаторов в основной индекс и расширение фасетов на данными о частоте обновления индикаторов и временном промежутке который он охватывает (год начала и год окончания). Не у всех датасетов такие метаданные есть и есть особенность датасетов Европейского центрального банка (ECB) в том что для массовой выгрузки доступны сами данные, но не метаданные. Хотя обычно наоборот. А в данном случае можно скачать все значения, а метаданные из них надо извлечь.
Эти значения публикуются в виде коллекции из 108 CSV файлов общим объёмом в 93GB. Это не то чтобы много, но много для статистики и для обработки на десктопе. Первая мысль которая возникает, а не уменьшить ли эти данные в объёме. Можно их сжать, но ещё эффективнее преобразовать в parquet. После преобразования они занимают 664 MB. Это 0,7% от изначального объёма, итого сжатие в 140 раз! Такая эффективность редкость, обычно сжатие в 5-15 раз, но здесь накладывается эффект колоночного сжатия поскольку данные ECB денормализованные, эффективность хранения там уступает полноте публикации и простоте раскрытия.
Далее обработка. Чтобы получить метаданные каждого индикатора надо:
1. Получить список уникальных идентификаторов индикаторов
2. Для каждого ключа сделать запрос одной записи для извлечения метаданных
3. Получить минимальное и максимальное значения временного периода
4. Извлечь год из минимального и максимального значения если период не равен году.
Итого 3 запроса, которые, наверняка, можно было бы оптимизировать до 2-х и которые можно делать напрямую к файлам parquet. Однако ситуация осложняется тем что эти файлы parquet хотя и хорошо сжаты, но могут содержать до 570+ тысяч индикаторов, как это, например, происходит с датасетом Securities Issues Statistics, который в оригинале составляет 19GB CSV файл и содержит 30 миллионов строк.
При работе с этим датасетом, даже после преобразования в parquet, DuckDB "съедает" до 15GB RAM и работает, хотя и быстро, но не так быстро как хотелось бы.
Варианты решения:
1. Попробовать преобразовать данные в базу DuckDB, построить индексы и так обрабатывать. Минус: резко увеличивается объём хранения данных, не увеличивается скорость обработки.
2. Попробовать нормализовать данные и извлекать метаданные из нормализованных баз. Минус: время на преобразование многократно больше времени сбора метаданных из существующих parquet файлов, а также у разных датасетов разная схема данных и требуется потратить больше времени на их анализ.
Варианты с тем чтобы загрузить в какую-то другую СУБД или даже не рассматривались поскольку задача именно в обработке на среднемощном десктопе/ноутбуке и без резкого роста объёмов хранения.
Итоговое решение оказалось очень простым. Специфика запросов в том что они полностью локализованы внутри данных конкретного индикатора.
Но, так повезло, что в этих датасетах индикаторы разделены по группам являющихся странами или территориями, от 8 до 33 в одном датасете и разделять можно по ним. Данные отдельных индикаторов полностью попадают в один из разделённых файлов. И, одна из фишек DuckDB - это очень дешёвое разделение данных с точки зрения скорости и нагрузки на память. До обработки большого датасета через серию COPY TO операций из него создаются десятки меньших .parquet файлов каждый из которых обрабатывается по отдельности.
Итого:
- средняя скорость однопоточной обработки достигает 78 индикаторов в секунду
- потребление RAM не превышает 100MB, а в среднем держится менее 50MB
- потребление диска +664MB, теперь не в 140 раз меньше чем оригинальные CSV файлы, а только в 70 раз, но всё ещё очень и очень мало.
Понятно что перенеся всё это на серверную инфраструктуру, в несколько потоков и тд. можно многократно ускорить обработку данных, но и так с помощью DuckDB конвейеры данных можно запускать на очень дешёвом железе и получать приемлемый результат.
#data #thoughts #tech #duckdb #dataengineering
В работе в Dateno есть задача по добавлению стат. индикаторов в основной индекс и расширение фасетов на данными о частоте обновления индикаторов и временном промежутке который он охватывает (год начала и год окончания). Не у всех датасетов такие метаданные есть и есть особенность датасетов Европейского центрального банка (ECB) в том что для массовой выгрузки доступны сами данные, но не метаданные. Хотя обычно наоборот. А в данном случае можно скачать все значения, а метаданные из них надо извлечь.
Эти значения публикуются в виде коллекции из 108 CSV файлов общим объёмом в 93GB. Это не то чтобы много, но много для статистики и для обработки на десктопе. Первая мысль которая возникает, а не уменьшить ли эти данные в объёме. Можно их сжать, но ещё эффективнее преобразовать в parquet. После преобразования они занимают 664 MB. Это 0,7% от изначального объёма, итого сжатие в 140 раз! Такая эффективность редкость, обычно сжатие в 5-15 раз, но здесь накладывается эффект колоночного сжатия поскольку данные ECB денормализованные, эффективность хранения там уступает полноте публикации и простоте раскрытия.
Далее обработка. Чтобы получить метаданные каждого индикатора надо:
1. Получить список уникальных идентификаторов индикаторов
2. Для каждого ключа сделать запрос одной записи для извлечения метаданных
3. Получить минимальное и максимальное значения временного периода
4. Извлечь год из минимального и максимального значения если период не равен году.
Итого 3 запроса, которые, наверняка, можно было бы оптимизировать до 2-х и которые можно делать напрямую к файлам parquet. Однако ситуация осложняется тем что эти файлы parquet хотя и хорошо сжаты, но могут содержать до 570+ тысяч индикаторов, как это, например, происходит с датасетом Securities Issues Statistics, который в оригинале составляет 19GB CSV файл и содержит 30 миллионов строк.
При работе с этим датасетом, даже после преобразования в parquet, DuckDB "съедает" до 15GB RAM и работает, хотя и быстро, но не так быстро как хотелось бы.
Варианты решения:
1. Попробовать преобразовать данные в базу DuckDB, построить индексы и так обрабатывать. Минус: резко увеличивается объём хранения данных, не увеличивается скорость обработки.
2. Попробовать нормализовать данные и извлекать метаданные из нормализованных баз. Минус: время на преобразование многократно больше времени сбора метаданных из существующих parquet файлов, а также у разных датасетов разная схема данных и требуется потратить больше времени на их анализ.
Варианты с тем чтобы загрузить в какую-то другую СУБД или даже не рассматривались поскольку задача именно в обработке на среднемощном десктопе/ноутбуке и без резкого роста объёмов хранения.
Итоговое решение оказалось очень простым. Специфика запросов в том что они полностью локализованы внутри данных конкретного индикатора.
Но, так повезло, что в этих датасетах индикаторы разделены по группам являющихся странами или территориями, от 8 до 33 в одном датасете и разделять можно по ним. Данные отдельных индикаторов полностью попадают в один из разделённых файлов. И, одна из фишек DuckDB - это очень дешёвое разделение данных с точки зрения скорости и нагрузки на память. До обработки большого датасета через серию COPY TO операций из него создаются десятки меньших .parquet файлов каждый из которых обрабатывается по отдельности.
Итого:
- средняя скорость однопоточной обработки достигает 78 индикаторов в секунду
- потребление RAM не превышает 100MB, а в среднем держится менее 50MB
- потребление диска +664MB, теперь не в 140 раз меньше чем оригинальные CSV файлы, а только в 70 раз, но всё ещё очень и очень мало.
Понятно что перенеся всё это на серверную инфраструктуру, в несколько потоков и тд. можно многократно ускорить обработку данных, но и так с помощью DuckDB конвейеры данных можно запускать на очень дешёвом железе и получать приемлемый результат.
#data #thoughts #tech #duckdb #dataengineering
Forwarded from AI with Parissan 🤖🦾 (Pariss)
𝗣𝘆𝘁𝗵𝗼𝗻_𝗰𝗹𝗲𝗮𝗻_𝗖𝗼𝗱𝗲✅.pdf
601.2 KB
✅ Python Clean Code book 🚀🧨🚀🧨🚀🧨🚀
#python #programming #projecs #datascience #artificialinteligence
AIwithParissan | AI Tutorials
#python #programming #projecs #datascience #artificialinteligence
AIwithParissan | AI Tutorials
Think Python.pdf
857.8 KB
✅Python book 💥
✅ آموزش پایتون 💥💥
#python #programming #projecs #datascience
AIwithParissan | AI Tutorials
✅ آموزش پایتون 💥💥
#python #programming #projecs #datascience
AIwithParissan | AI Tutorials
Forwarded from AI with Parissan 🤖🦾 (Pariss)
Docker-15.pdf
337.1 KB
✅ Docker 🧨🧨🧨🧨
🐳🐳🐳🐳🐳🐳🐳🐳
✅ داکر زیبا 🐳🧨🐳🧨
#docker #cloudcomputing #cloud #kubernetes #containers #clusters
AIwithParissan | AI Tutorials
🐳🐳🐳🐳🐳🐳🐳🐳
✅ داکر زیبا 🐳🧨🐳🧨
#docker #cloudcomputing #cloud #kubernetes #containers #clusters
AIwithParissan | AI Tutorials
Think Python.pdf
857.8 KB
✅Python book 💥
✅ آموزش پایتون 💥💥
#python #programming #projecs #datascience
AIwithParissan | AI Tutorials
✅ آموزش پایتون 💥💥
#python #programming #projecs #datascience
AIwithParissan | AI Tutorials
Zero to Snowflake on Azure in 60 minutes.pdf
3.3 MB
✅ Snowflake on Azure in 60 minutes
#azure #cloud #snowflake
#cloudcomputing #dataengineer #bigdata
AIwithParissan | AI Tutorials
#azure #cloud #snowflake
#cloudcomputing #dataengineer #bigdata
AIwithParissan | AI Tutorials
Machine Learning-1.pdf
2.8 MB
✅Machine Learning for absolutely Beginners 🕊️🕊️🕊️
✅ماشین لرنینگ براي فوق مبتدیان به زبان بسیار ساده 💥💥💥
#machinelearning #statisticallearning #datascience #artificialinteligence #datacleaning
AIwithParissan | AI Tutorials
✅ماشین لرنینگ براي فوق مبتدیان به زبان بسیار ساده 💥💥💥
#machinelearning #statisticallearning #datascience #artificialinteligence #datacleaning
AIwithParissan | AI Tutorials
Large Language Models Use Cases-3.pdf
845.3 KB
✅ LLM models usecases 💥💥
✅کاربردهای مدل های LLM در دنیای واقعی 💥💥
#llm #artificialinteligence #machinelearning #deeplearning
AIwithParissan | AI Tutorials
✅کاربردهای مدل های LLM در دنیای واقعی 💥💥
#llm #artificialinteligence #machinelearning #deeplearning
AIwithParissan | AI Tutorials
Forwarded from Инжиниринг Данных (Dmitry)
Уже пару месяцев как закончил книгу "Freakonomics" (в русском переводе "Фрикономика"), написанная Стивеном Левиттом и Стивеном Дабнером, которая исследует экономические принципы в нестандартных ситуациях и предлагает неожиданные объяснения повседневных явлений.
Основные идеи книги включают анализ экономических и социальных проблем с применением нетрадиционных подходов и методов.
Основные идеи книги:
Экономика всего вокруг: Левитт и Дабнер показывают, что экономические принципы можно применить к любым аспектам жизни, от преступности до образования.
Влияние стимулов (incentives): Главная идея книги — поведение людей сильно зависит от стимулов, которые они получают.
Неожиданные связи: Выявляют неожиданные связи между, казалось бы, несвязанными явлениями, такими как снижение уровня преступности и легализация абортов.
Использование данных: Важность анализа данных и использования статистики для получения достоверных выводов.
Для меня книга особенно запомнилась примерами стимулов (incentives).
- Экономические стимулы: Это финансовые или материальные выгоды, которые мотивируют людей к определенным действиям.
- Социальные стимулы: Это общественные и культурные факторы, которые влияют на поведение.
- Моральные стимулы: Это внутренние убеждения и ценности, которые мотивируют людей к действиям, основанным на их этических принципах.
Стимулы очень хорошо ложатся на нашу работу.
Почему новые инженеры работают лучше, чем старые?(кто уже 1-2 года в команде, вот сегодня например уволили такого человека, хотя я сам был таким человеком в прошлом году и скоро расшарю свой PIP документ).
Почему одни инженеры работают хорошо, а другие плохо? (Ведь часто дело не в зарплате)
Почему одни активно учатся и развиваются, а другие нет?
Почему одни пишут хорошие комментарии, а другие пишут плохие?
У меня теперь на любой вопрос 1й ответ это incentive. Вообще вся движуха рабочая это про incentives. Либо они есть, либо нет.
Мне кажется менеджеры особенно тщательно стараются придумать “стимулы” для своих команд🚣
Основные идеи книги включают анализ экономических и социальных проблем с применением нетрадиционных подходов и методов.
Основные идеи книги:
Экономика всего вокруг: Левитт и Дабнер показывают, что экономические принципы можно применить к любым аспектам жизни, от преступности до образования.
Влияние стимулов (incentives): Главная идея книги — поведение людей сильно зависит от стимулов, которые они получают.
Неожиданные связи: Выявляют неожиданные связи между, казалось бы, несвязанными явлениями, такими как снижение уровня преступности и легализация абортов.
Использование данных: Важность анализа данных и использования статистики для получения достоверных выводов.
Для меня книга особенно запомнилась примерами стимулов (incentives).
- Экономические стимулы: Это финансовые или материальные выгоды, которые мотивируют людей к определенным действиям.
- Социальные стимулы: Это общественные и культурные факторы, которые влияют на поведение.
- Моральные стимулы: Это внутренние убеждения и ценности, которые мотивируют людей к действиям, основанным на их этических принципах.
Стимулы очень хорошо ложатся на нашу работу.
Почему новые инженеры работают лучше, чем старые?(кто уже 1-2 года в команде, вот сегодня например уволили такого человека, хотя я сам был таким человеком в прошлом году и скоро расшарю свой PIP документ).
Почему одни инженеры работают хорошо, а другие плохо? (Ведь часто дело не в зарплате)
Почему одни активно учатся и развиваются, а другие нет?
Почему одни пишут хорошие комментарии, а другие пишут плохие?
У меня теперь на любой вопрос 1й ответ это incentive. Вообще вся движуха рабочая это про incentives. Либо они есть, либо нет.
Мне кажется менеджеры особенно тщательно стараются придумать “стимулы” для своих команд
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Инжиниринг Данных (Dmitry)
Media is too big
VIEW IN TELEGRAM
Презентация sqlwagon новой книги Azure Data Factory Cookbook 2nd edition. (На английском, это вообще то будет для Linkedin)
Forwarded from Инжиниринг Данных (Dmitry)
Сегодня посмотрим на компоненты хранилища данных.
Хранилище данных это у нас просто большая база данных, часто это может быть распределенная (кластер из нескольких машин, чтобы они вместе все параллельно обрабатывали данные, ведь так быстрей и можно больше данных обработать - ну или просто 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 и знать их особенности.
Хранилище данных это у нас просто большая база данных, часто это может быть распределенная (кластер из нескольких машин, чтобы они вместе все параллельно обрабатывали данные, ведь так быстрей и можно больше данных обработать - ну или просто 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 и знать их особенности.