Size: a a a

Архитектура данных

2020 December 30

e

er@essbase.ru in Архитектура данных
Переслано от Renarde
есть логическая разница между data lake / delta lake.

вкратце - data lake обычно - это append-only хранилище для данных в их исходном формате (приходит JSON из источника - храним JSON, приходит Avro - храним Avro). Физически это просто набор бакетов в S3-like системе, внутри которых лежат данные с источника.

Дальше обычно на данных из лейка собирают отдельные витрины и отгружают их куда-нибудь в аналитическое хранилище.

Это работающий подход, и много кто так делает, но у него есть минусы, например:
1. перевычитка сырых данных для ML может быть долгой/неэффективной
2. GDPR-related проблемы (удаление данных по where условию)
3. изменение схемы данных (актуально когда данные льются из микросервисов и внутри организации нет контрактов между дев-командами и дата-командами)
4. Мелкие технические проблемы - msck repair table, small files problem

Delta Lake собственно и нацелен решать такие проблемы за счет нового OSS формата, который называется delta . Идея в следующем - мы продолжаем хранить данные в S3-like FS, но к этому добавляется новый функционал:
1. MERGE (UPSERT) / DELETE - возможность обновлять и/или удалять данные по where условию, например - ключу
2. time travel - возможность откатить версию таблицы (или просто прочитать version as of от какой-то даты или timestamp)
3. schema evolution для таблиц
4. OPTIMIZE решает проблему маленьких файлов
5. Таблицы допускают concurrent writes / concurrent reads в т.ч. в стримах
6. Удобное API для стриминга, включая возможности читать с заданной версии / таймстампа

Важно заметить что:
- часть озвученного функционала есть только внутри Databricks
- есть и другие файловые форматы которые похожи по смыслу, самые популярные - Hudi и Iceberg. Вот тут и тут сравнения.

Про то, каким образом устроена дельта и дельта лог можно почитать вот эту статью с VLDB.
источник

e

er@essbase.ru in Архитектура данных
er@essbase.ru
Переслано от Renarde
есть логическая разница между data lake / delta lake.

вкратце - data lake обычно - это append-only хранилище для данных в их исходном формате (приходит JSON из источника - храним JSON, приходит Avro - храним Avro). Физически это просто набор бакетов в S3-like системе, внутри которых лежат данные с источника.

Дальше обычно на данных из лейка собирают отдельные витрины и отгружают их куда-нибудь в аналитическое хранилище.

Это работающий подход, и много кто так делает, но у него есть минусы, например:
1. перевычитка сырых данных для ML может быть долгой/неэффективной
2. GDPR-related проблемы (удаление данных по where условию)
3. изменение схемы данных (актуально когда данные льются из микросервисов и внутри организации нет контрактов между дев-командами и дата-командами)
4. Мелкие технические проблемы - msck repair table, small files problem

Delta Lake собственно и нацелен решать такие проблемы за счет нового OSS формата, который называется delta . Идея в следующем - мы продолжаем хранить данные в S3-like FS, но к этому добавляется новый функционал:
1. MERGE (UPSERT) / DELETE - возможность обновлять и/или удалять данные по where условию, например - ключу
2. time travel - возможность откатить версию таблицы (или просто прочитать version as of от какой-то даты или timestamp)
3. schema evolution для таблиц
4. OPTIMIZE решает проблему маленьких файлов
5. Таблицы допускают concurrent writes / concurrent reads в т.ч. в стримах
6. Удобное API для стриминга, включая возможности читать с заданной версии / таймстампа

Важно заметить что:
- часть озвученного функционала есть только внутри Databricks
- есть и другие файловые форматы которые похожи по смыслу, самые популярные - Hudi и Iceberg. Вот тут и тут сравнения.

Про то, каким образом устроена дельта и дельта лог можно почитать вот эту статью с VLDB.
источник
2021 February 03

С

Сергей in Архитектура данных
Ребят, привет, у меня тут несколько вопросов - интересно ваше мнение: ( про microsoft SSIS )

__________________________________

1. на сколько хорошо работает SSIS с потоковыми данными? (например запросы через API на складирование или обработку данных )

2. на сколько хорошо работает SSIS с порционной догрузкой данных  (например есть 1000 строк в БД, но нужно обновлять по 10 записей и для них догружать данные по HTTP) — при том только для тех строк, для которых данные не дополнены.

3. поддерживает ли ETL в SSIS распаковку архивов в память? (когда есть архивЫ с файлами, и нам нужно распаковать, и затем пробежаться маской внутри архива)

4. на сколько хорошо SSIS работает с JSON?

5. сложно ли делать ETL в котором мы отправляем запрос на получение токена, затем вторым запросом уже получаем сами данные?

5.1. возможно ли запоминать этот токен в БД?
источник

A

Alex in Архитектура данных
Запросы к API и SSIS плохо дружат. Там сть встренный механизм веб-вызова - весьма скудный, в остальном надо кодить компонент на .Net, сложно переиспользовать библиотеки, их надо добавлять в GAC. В общем, одна морока.
источник

A

Alex in Архитектура данных
Я для запросов к API использую CLR
источник

С

Сергей in Архитектура данных
Alex
Запросы к API и SSIS плохо дружат. Там сть встренный механизм веб-вызова - весьма скудный, в остальном надо кодить компонент на .Net, сложно переиспользовать библиотеки, их надо добавлять в GAC. В общем, одна морока.
Apache NiFi

https://habr.com/ru/company/rostelecom/blog/432166/

вот эта штука еще выглядит многообещающе и в принципе так понимаю, её будет проще и дешевле поставить на сервер/сервера
источник

S

Shadilan R16 MU Rost... in Архитектура данных
Сергей
Apache NiFi

https://habr.com/ru/company/rostelecom/blog/432166/

вот эта штука еще выглядит многообещающе и в принципе так понимаю, её будет проще и дешевле поставить на сервер/сервера
По тем же вопросам в приходи к нам расскажу :) (в найфайный чатик :) ты там вроде есть)
источник

С

Сергей in Архитектура данных
Shadilan R16 MU Rostov
По тем же вопросам в приходи к нам расскажу :) (в найфайный чатик :) ты там вроде есть)
Хорошо, спасибо
источник

S

Shadilan R16 MU Rost... in Архитектура данных
у нас судя по всему все описанные тобой кейсы есть в проде
источник
2021 February 27

PG

Paul Golubev in Архитектура данных
Без рекламы, особенно непрошеной
источник

PP

Prabhat Palko in Архитектура данных
"обсуждаем, ссылки на статьи, конференции, полезные каналы" - это разве не у вас написано?
источник

PG

Paul Golubev in Архитектура данных
Просто заходить на канал и сразу вбрасывать ссылки без повода и призыва к обсуждению - выглядит нежелательно
источник

PP

Prabhat Palko in Архитектура данных
Понял, простите.
источник
2021 March 03

S

Sergey in Архитектура данных
Всем привет!
Коллеги, возможно мой вопрос не в тему сообщества. Но, очень хочется узнать, кто какими инструментами пользуются.
надеюсь админы меня не будут сильно ругать.
У нас SQL Server используется как основной источник данных системы - по сути это хранилище данных, которое питается из внешних систем.
Чтобы данные из разных систем подгружались в хранилище, нужен ETL-инструмент, который будет данные брать, возможно немного изменять и кидать по расписанию в таблицу SQL.

Из всех инструментов, которые были на рынке бесплатных выбрали SSIS. После знакомства с ним, у меня сразу возникло куча вопросов.
Будет ли MS его поддерживать, или SSDT 2017 это последняя версия продукта? Как работать с веб-системами (например, по REST API с интернет-магазинами)?
Бесплатные компоненты - это Excel, SQL Server, XML, почта. Все остальное - на маркетплейсе VS за мани. А системы все разные - естественно платить за каждый компонент под каждую систему это ужас - что в плане денег, что в плане оформления и покупки в организации.

В связи с вышеописанным - какие инструменты ETL кто использует? какие плюсы минусы инструментов? Был бы рад, если поделились опытом - на рынке этих инструментов использовал SSIS только и то на уровне "эксельки подгрузить".
источник

Ц

Цонстантин in Архитектура данных
Sergey
Всем привет!
Коллеги, возможно мой вопрос не в тему сообщества. Но, очень хочется узнать, кто какими инструментами пользуются.
надеюсь админы меня не будут сильно ругать.
У нас SQL Server используется как основной источник данных системы - по сути это хранилище данных, которое питается из внешних систем.
Чтобы данные из разных систем подгружались в хранилище, нужен ETL-инструмент, который будет данные брать, возможно немного изменять и кидать по расписанию в таблицу SQL.

Из всех инструментов, которые были на рынке бесплатных выбрали SSIS. После знакомства с ним, у меня сразу возникло куча вопросов.
Будет ли MS его поддерживать, или SSDT 2017 это последняя версия продукта? Как работать с веб-системами (например, по REST API с интернет-магазинами)?
Бесплатные компоненты - это Excel, SQL Server, XML, почта. Все остальное - на маркетплейсе VS за мани. А системы все разные - естественно платить за каждый компонент под каждую систему это ужас - что в плане денег, что в плане оформления и покупки в организации.

В связи с вышеописанным - какие инструменты ETL кто использует? какие плюсы минусы инструментов? Был бы рад, если поделились опытом - на рынке этих инструментов использовал SSIS только и то на уровне "эксельки подгрузить".
apache nifi
источник

S

Sergey in Архитектура данных
в нем сложно разобраться? он бесплатный?
источник

S

Sergey in Архитектура данных
у нас по мощностям много меньше хадупа, обычный sql server который работает под аналитику данных
источник

Ц

Цонстантин in Архитектура данных
бесплатный, сложность - хз, кому как зайдет
источник

Ц

Цонстантин in Архитектура данных
а зачем хадуп
источник

S

Sergey in Архитектура данных
самих данных до 700 ГБ максимум будет в хранилище.
там нужно какой-то код писать? или это визуальный инструмент?
источник