Комментарии 31
Как ни крути, но бизнес пользователи работаю эффективней с хранилищем данных, чем озером данных
Бизнес-пользователи работают с BI инструментами, а не с хранилищами/озерами. Им (бизнес-пользователям), в большинстве своем, все равно, что там в бекенде…
P.S. устал от вашей рекламы облаков (на канале в том числе), особенно, когда обоснование не проанализировано с финансовой точки зрения на реальных масштабах работы бизнеса…
Что-то, а рекламы облаков у меня точно нет. Я с ними работаю в Amazon (AWS) и в консалтинге rockyourdata.cloud. Я пишу о том, что происходит вокруг меня в Северной Америке, и я вижу рост популярности облаков и их преимуществ. Можно меня упрекнуть в рекламе Matillion или Tableau как вендоров, но врят ли в рекламе облаков.
Канал я использую для того, чтобы скидывать интересные мне материалы, это мое видение ситуации вокруг аналитики данных и инжиниринга данных.
"Бизнес-пользователи работают с BI инструментами, а не с хранилищами/озерами."
Очень серьёзное заблуждение, особенно надоедает его слышать от новеньких, которые попали в ИТ департамент :)
Я рад что у вас такие обширные знания :)
Только сначала следует определить кто такие эти самые бизнес-пользователи, т.к. классификация штука нестабильная, а ad-hoc-и через "настоящее ИТ"…
В принципе ввиду того что бизнес очень быстро меняется классическое деление местами отступает :)
Хороший бизнес пользователь, это тот, кто знает SQL и может сам писать запросы. И тут уже не важно Data Lake (Athena/Spectrum в AWS) или DW. Но самая большая проблема для меня, что Custom SQL отчеты, с кучей подзапросов и непонятной логикой плодятся очень быстро, и никто, кроме бизнес пользователя не сможет сказать, что этот отчет делает, а потом он увольняется и как было недавно, оставляет вам 200 отчетов на SQL, и финансы говорят, на все нужно, хотя никто не понимает чего внутри и какие есть альтернативы (например в DW есть Star Schema со всеми метриками и она подключена к Tableau).
Deep dive — это уже меньше про бизнес пользователей, это про аналитиков, тут может и python понадобиться и Spark, и shell. То есть уже очень продвинутый уровень пользователя. И им вообще все-равно где данные и в каком формате, например JSON и доступ через API.
В любом случае, я за то, что у каждого свое мнение, и оно зависит от среды, в которой мы работает. И правильного ответа возможно и не существует. В посте я написал, главное это польза для бизнеса, а как уже 2ой приоритет, и зависит от нашего опыта технологий.
В вашем описании одновременно несколько проблем, и самая основная — передача знаний, вероятно пока ещё не везде руководство такого "квазибизнеса" (как раз финансы самый лучший пример, т.к. изменения в системах часто происходят без детального учёта их потребностей, а им "это всё" разгребать по факту в сжатые сроки) имеет чёткую картину того, как организовать передачу информации, в т.ч. потому что её намного сложнее формализовать, особенно с учётом того что набор необходимой информации может меняться на ходу (запросы аудиторов это здесь и сейчас иначе мы не уложимся в срок).
и это порождает ситуации когда передаётся функционал а смысл теряется (через 1 уволившегося это уже серьёзная проблема, а требования никто не отменяет, и иногда приходится устраивать опросы вида — "а это ещё кто-то использует" с дополнением вида "а как вы понимаете эти данные".
Про Excel, так сложилось что этот инструмент наиболее распостранён, удобен для передачи людям, и не требует согласования доступа в хранилище "через bi/dw" новому контрагенту для того чтобы он этот отчёт увидел без выгрузки. Также частая проблема место в схемах, т.к. одно дело сохранить метаданные, другое данные чтобы гарантировать неизменность, ведь очень часто доступ дают исключительно на чтение без(или с сильно ограниченной) песочницей.
Но прогресс не стоит на месте, современные bi/dw очень сильно продвинулись, взять тот же oracle то что они сделали за последние годы это очень большой прогресс, также сейчас приходит понимание что по умолчанию доступ(сильно обрезанный) и базовое обучение нужно давать всем, кто хоть как-то работает с данными, что управление доступом должно быть на уровне сейчас запросил, начальник подтвердил через час права(по доступным ролям) получены. И постепенно бизнес будет уходить от excel но только когда альтернатива не будет отнимать в разы больше усилий на простенькую "разовую" задачу :)
Простите, что это? Оракл своё облако мигрировал в AWS? С помощью софта оракла (goldengate?) произошла миграция данных в AWS? Экзадаты привезли и поставили на площадку с AWS?
Сравнение DWH / DL тоже не совсем корректно: в озере можно хранить и агрегаты, и при желании — витрины данных (хотя чаще всего витрины перегружают в OLTP или реляционные БД для скорости, случаи, когда витрина лежит в datalake и запросы к ней идут через impala тоже видел в крупных продах), туда же schema on read в datalake: если сохранили в avro — то да, parquet/orc — нет, в этих форматах schema on write.
Tl;DR: для big data существуют только облака, а AWS — их пророк /irony
PS до сих пор не видел ни одного инструмента или гайда, как вытащить свои данные из облака, когда ценник за месяц становится слишком высок и стоимость аренды за год приближается к стоимости покупки своего кластера.
1) Это OLTP Oracle -> DynamoDB
2) Oracle DW -> Amazon Redshift (я как раз делал 2ой, и в контексте темы, я это и имел ввиду).
«Tl;DR: для big data существуют только облака, а AWS — их пророк /irony» — мой point, что Big Data легче делать на облаках (и не важно AWS, Azure, GCP. Просто я работал больше с AWS, и пишу про него, можно то же самое расписать про Azure, просто заменить Redshift на Azure SQL DW и тп). В облаках мы используем PaaS и SaaS, это сокращает время на создание инфраструктуры.
Полностью согласен про хранение агрегатов и метрик. В мое случае я использую DW для этого из-за удобства подключения к BI и работы бизнес пользователей.
У меня нет задачи вытаскивать данные из облака, все происходит там. Какой кейс вы имеете ввиду?
Но прод — уже локально держать, или хотя бы в гибридных/приватных облаках — пара кластеров (прод + резерв) на десяток-полтора нод с 1.5-2 Пб хранилищем за 7-10 месяцев в облаках стоят столько же, сколько новый кластер целиком.
Или за такие объемы уже идут облачные скидки?
PS Собственно, кейс — когда ценник за облако уходит к $30000/мес — дешевле купить своё железо и нанять свою команду, а заодно прекратить терроризировать юристов с обоснованием законности трансграничной передачей данных, но при этом нужно как-то выкачать все данные из облака.
У оракла есть всё это(в т.ч. частное облако когда вам ставят в датацентр всё тоже самое что в public, но за вашим firewall-ом), просто кто-то решил переехать на aws
Про цену тоже хороший комментарий, в амазоне все расслабляются, так как скидка на AWS, и косты начинают мониторить, когда речь о МЛН долларов. Так же выбор технологий внутри AWS зависит на 100% от команды. Например, мое предпочтение — это максимально использовать готовые сервисы, и не использовать open source и кастомизацию по возможности из-за time to market и поддержки такого решения.
Как правило память для хранения данных в аналитическом хранилище данных не дешевая (например Redshift, BigQuery, Teradata), так как нам надо покупать целый кластер.
Это не совсем правда. Вернее, в случае BigQuery, это ложь.
Если очень обобщённо и упрощённо, то платить нужно за хранение данных и за чтение данных (во время запросов). На самом деле там ещё куча всего, за что нужно платить (и куча всего бесплатно), но эти две вещи на поверхности.
cloud.google.com/bigquery/pricing
Если говорить о хранении данных (тупо, глупо и в лоб), то
cloud.google.com/bigquery/pricing
и
cloud.google.com/storage/pricing
И, взяв первый же вариант (US Multi Region), то хранение будет стоить (в месяц)
BigQuery — $0.020 per GB
Standard Storage — $0.026 per GB
То есть BigQuery как бы дешевле…
Запросы — $5.00 per TB прочитанных данных
У меня получались запросы, которые стоили по несколько десятков долларов, но это редкость.
На тему скорости — если интерактивный запрос выполняется дольше 30 — 40 секунд (независимо от объёма данных), то я бы остановил его и стал бы думать, а что я собственно делаю (не так).
Что касается того, что можно покупать заранее (в BigQuery) — то это слоты (для запросов) — cloud.google.com/bigquery/docs/slots — но это для больших потребителей (сам никогда не использовал, но наверное кто-то использует).
И ещё нужно помнить про ограничения — cloud.google.com/bigquery/quotas
Если у вас более конкретные вопросы — напишите в googlecloud-community.slack #bigquery channel. Я ежедневно его просматриваю, и, если могу помочь, то отвечаю.
А как же хранилище данных?
Мы заменяем хранилище данных на озеро данных или мы его расширяем?
Можно ли все таки обойтись без озера данных?
Если кратко, то мы можем ответить на все вопросы положительно, и будем правы.
Отвечаем положительно, на все три вопроса?
— А как же хранилище данных?
— Да.
— Мы заменяем хранилище данных на озеро данных или мы его расширяем?
— Да.
Серьезно?
-А как же хранилище данных?
-Хранилище нужно, без него никуда. (Это положительный ответ?)
В любом случае смысл я старался заложить, что можно и только с озером данных или только с хранилищем или хранилище + озеро данных.
Я ни разу не сказал, что Data Lake это плохо. Я привел примеры что можно использовать только Data Lake, а можно и DW и Data Lake. Я можно только DW, если Snowflake.
Типа данных parquet, был выбран для моего проекта. Цель статья показать не техническим людям, что такое data lake.
Про delta lake я много видел у data bricks, было бы интересно узнать больше. GDPR проблема, эта та, которая сейчас у нас в Алекса с текущим решением на AWS.
"Сплошная ерунда в тексте" — это больше про менталитет людей, из разряда, я самый умный, у меня лучше чем у других и тп. Я написал на основе своего опыта. С удовольствие послушаю дельные советы, и новую информацию, которая будет всем полезна.
если хотите дельный совет — почитайте книжку Била Инмона Data Lake Architecture: Designing the Data Lake and Avoiding the Garbage Dump
у него там описывается лейк — четкая противоположность вашим представлениям. особливо вокруг applications pond.
Я заметил в вашей публикации от 27 июня 2018 года такую фразу " DWH массово движется в сторону DataLake и Hadoop". Примерно о том же я слышал, когда работал в Терадата в 2011 году, я думаю можно и сейчас написать тоже самое, и найдется аудитория, которая будет кивать головой и которая скажет «по большому счету сплошная ерунда в тексте». Еще я понял что вы топите за Oracle судя по блогу и постам на хабре. Я бы так же топил за Teradata, если так и остался там работать или не работал ни с чем, кроме нее. Я хотел посмотреть где вы работаете, но к сожалению не нашел. Целью спорить с
Скоро лето, удачи с озерами и прудами!
«файловое хранилище всех типов сырых данных, которые доступны для анализа кем-угодно в организации» — Мартин Фовлер.
«Если вы думаете, что витрина данных это бутылка воды — очищенной, запакованной и расфасованной для удобного употребления, то озеро данных это у нас огромный резервуар с водой в ее естественном виде. Пользователи, могу набирать воды для себя, нырять на глубину, исследовать» — Джеймс Диксон.
Для этого давно название придумано "Файлопомойка".
Рискуя показаться недалёким, я так и не понял чем озера принципиально отличаются от хранилищ. Тем, что в озёрах хранятся разнотипные данные? Ну так и в хранилище можно поместить что угодно. Может мне кто-то в двух словах пояснить, пожалуйста, уже давно этот вопрос меня беспокоит :-)
Upd. Нашел чудесное определение: A data lake is a vast pool of raw data, the purpose for which is not yet defined. A data warehouse is a repository for structured, filtered data that has already been processed for a specific purpose. ... In fact, the only real similarity between them is their high-level purpose of storing data.
Но что это значит на практике? Если я складываю на жёсткий диск файлики с логами из разных систем с целью "на всякий случай", диск превращается в озеро?
Ещё одно определение: Идея озера данных состоит в том, чтобы хранить необработанные данные в их оригинальном формате до тех пор, пока они не понадобятся. У меня на компе есть папочка /temp/, которая работает ровно по этому принципу. Является ли она маленьким озером?
Да вроде проще:
Хранилище данных = база данных (хранения и обработка в одном лице)
Озеро данных = файловое хранилище + вычислительные мощности. Эти 2 вещи не связаны и могут быть независимы.
Сейчас уже появился lakehouse - продукт смесь 2х вещей сверху. Я часто пишу в своем канале Инжиниринг Данных про это.
Нужно ли нам озеро данных? А что делать с хранилищем данных?