Нужно ли нам озеро данных? А что делать с хранилищем данных?

Это статья перевод моей статьи на medium — Getting Started with Data Lake, которая оказалась довольно популярной, наверное из-за своей простоты. Поэтому я решил написать ее на русском языке и немного дополнить, чтобы простому человеку, который не является специалистом по работе с данными стало понятно, что такое хранилище данных (DW), а что такое озеро данных (Data Lake), и как они вместе уживаются.

Почему я захотел написать про озеро данных? Я работаю с данными и аналитикой больше 10 лет, и сейчас я точно работаю с большими данными в Amazon Alexa AI в Кембридже, который в Бостоне, хотя сам живу в Виктории на острове Ванкувер и часто бываю и в Бостоне, и в Сиэтле, и в Ванкувере, а иногда даже и в Москве выступаю на конференциях. Так же время от времени я пишу, но пишу в основном на английском, и написал уже несколько книг, так же у меня есть потребность делиться трендами аналитики из Северной Америке, и я иногда пишу в телеграмм.

Я всегда работал с хранилищами данных, и с 2015 года стал плотно работать с Amazon Web Services, да и вообще переключился на облачную аналитику (AWS, Azure, GCP). Я наблюдал эволюцию решений для аналитики с 2007 года и сам даже поработал в вендоре хранилищ данных Терадата и внедрял ее в Сбербанке, тогда-то и появилась Big Data с Hadoop. Все стали говорить, что прошла эра хранилищ и теперь все на Hadoop, а потом уже стали говорить про Data Lake, опять же, что теперь уж точно хранилищу данных пришел конец. Но к счастью (может для кого и к несчастью, кто зарабатывал много денег на настройке Hadoop), хранилище данных не ушло.

В этой статье мы и рассмотрим, что такое озеро данных. Статья рассчитана на людей, у которых мало опыта с хранилищами данными или вовсе нет.

image

На картинке озеро Блед, это одно из моих любимых озер, хотя я там был всего один раз, но запомнил его на всю жизнь. Но мы поговорим о другом типе озера — озеро данных. Возможно многие из вас уже не раз слышали про это этот термин, но еще одно определение никому не повредит.

Прежде всего вот самые популярные определения Озера Данных:
«файловое хранилище всех типов сырых данных, которые доступны для анализа кем-угодно в организации» — Мартин Фовлер.
«Если вы думаете, что витрина данных это бутылка воды — очищенной, запакованной и расфасованной для удобного употребления, то озеро данных это у нас огромный резервуар с водой в ее естественном виде. Пользователи, могу набирать воды для себя, нырять на глубину, исследовать» — Джеймс Диксон.
Теперь мы точно знаем, что озеро данных это про аналитику, оно позволяет нам хранить большие объемы данных в их первоначальной форме и у нас есть необходимый и удобный доступ к данным.

Я часто люблю упрощать вещи, если я могу рассказать сложный термин простыми словами, значит для себя я понял, как это работает и для чего это нужно. Как то, я ковырялся в iPhone в фотогалерее, и меня осенило, так это же настоящее озеро данных, я даже сделал слайд для конференций:

image

Все очень просто. Мы делаем фотографию на телефон, фотография сохраняется на телефон и может быть сохранено в iCloud (файловое хранилище в облаке). Также телефон собирает мета-данные фотографии: что изображено, гео метка, время. Как результат, мы может использовать удобный интерфейс iPhone, чтобы найти нашу фотографию и при этому мы даже видим показатели, например, когда я ищу фотографии со словом огонь (fire), то я нахожу 3 фотографии с изображение костра. Для меня это прям как Business Intelligence инструмент, который работает очень быстро и четко.

И конечно, нам нельзя забывать про безопасность (авторизацию и аутентификацию), иначе наши данных, могут легко попасть в открытый доступ. Очень много новостей, про крупные корпорации и стартапы, у которых данные попали в открытый доступ из-за халатности разработчиков и не соблюдения простых правил.

Даже такая простая картинка, помогает нам представить, что такое озеро данных, его отличия от традиционного хранилища данных и его основные элементы:

  1. Загрузка данных (Ingestion) — ключевой компонент озера данных. Данные могут попадать в хранилище данных двумя способами — batch (загрузка с интервалами) и streaming (поток данных).
  2. Файловое хранилище (Storage) — главный компонент Озера Данных. Нам необходимо, что хранилище было легко масштабируемое, чрезвычайно надежное и обладало низкой стоимостью. Например, в AWS это S3.
  3. Каталог и Поиск (Catalog and Search) — для того чтобы нам избежать Болота Данных (это когда мы сваливаем все данные в одну кучу, и потом невозможно с ними работать), нам необходимо создать слой мета-данных для классификации данных, чтобы пользователи легко могли найти данные, которые им необходимы для анализа. Дополнительно, можно использовать дополнительные решения для поиска, например ElasticSearch. Поиск помогает пользователю искать нужные данные через удобные интерфейс.
  4. Обработка (Process) — это шаг отвечает за обработку и трансформацию данных. Мы можем трансформировать данные, изменять их структуры, очищать и много другое.
  5. Безопасность (Security) — важно потратить время на дизайн безопасности решения. Например, шифрование данных во время хранения, обработки и загрузки. Важно использовать методы аутентификации и авторизации. В заключение, нужен инструмент аудита.

С практической точки зрения, мы можем характеризовать озеро данных тремя атрибутами:

  1. Собирайте и храните все что угодно — озеро данных содержит все данные, как сырые необработанные данные за любой период времени, так и обработанных/очищенные данные.
  2. Глубокий анализ — озеро данных позволяет пользователям исследовать и анализировать данные.
  3. Гибкий доступ — озеро данных обеспечивает гибкий доступ для различных данных и различных сценариев.

Теперь можно поговорить о разнице между хранилищем данных и озером данных. Обычно люди спрашивают:

  • А как же хранилище данных?
  • Мы заменяем хранилище данных на озеро данных или мы его расширяем?
  • Можно ли все таки обойтись без озера данных?

Если кратко, то четкого ответа нет. Все зависит от конкретной ситуации, навыков в команде и бюджета. Например миграция хранилища данных на Oracle в AWS и создание озера данных дочерней компанией Амазон — Woot — Our data lake story: How Woot.com built a serverless data lake on AWS.

С другой стороны, вендор Snowflake заявляет, что вам больше не нужно думать про озеро данных, так как их платформа данных (до 2020 это было хранилище данных), позволяет вам совместить и озеро данных и хранилище данных. Я работал не много со Snowflake, и это действительно уникальный продукт, который может так делать. Цена вопроса, это другой вопрос.

В заключении, мое личное мнение, что нам все еще нужно хранилище данных как основной источник данных для нашей отчетности, и все, что не помещается, мы храним в озере данных. Вся роль аналитики — это предоставить удобный доступ бизнесу для принятия решений. Как ни крути, но бизнес пользователи работаю эффективней с хранилищем данных, чем озером данных, например в Amazon — есть Redshift (аналитическое хранилище данных) и есть Redshift Spectrum/Athena (SQL интерфейс для озера данных в S3 на базе Hive/Presto). Тоже самое относится к другим современным аналитическим хранилищам данных.

Давайте рассмотрим типичную архитектура хранилища данных:

image

Это классическое решение. У нас есть системы источники, с помощью ETL/ELT мы копируем данные в аналитическое хранилище данных и подключаем к Business Intelligence решению (мое любимое Tableau, а ваше?).

Такое решение имеет следующие недостатки:

  • ETL/ELT операции требуют время и ресурсов.
  • Как правило память для хранения данных в аналитическом хранилище данных не дешевая (например Redshift, BigQuery, Teradata), так как нам надо покупать целый кластер.
  • Бизнес пользователи имеют доступ к очищенным и часто агрегированным данным и у них нет возможность получить сырые данные.

Конечно, все зависит от ваше кейса. Если у вас нет проблем с вашим хранилищем данных, то вам совершенно не нужно озеро данных. Но когда появляются проблемы с нехваткой места, мощности или цена вопроса имеет ключевую роль, то можно рассмотреть вариант озера данных. Именно поэтому, озеро данных очень популярно. Вот пример архитектуры озера данных:
image
Используя подход озера данных, мы загружаем сырые данные в наше озеро данных (batch или streaming), далее мы обрабатываем данные по необходимости. Озеро данных позволяет бизнес пользователям создавать свои собственные трансформации данных (ETL/ELT) или анализировать данные в решениях Business Intelligence (если есть нужный драйвер).
Цель любого аналитического решения — служить бизнес пользователям. Поэтому мы всегда должны работать от требований бизнеса. (В Амазон это один из принципов — working backwards).
Работая и с хранилищем данных и с озером данных, мы можем сравнить оба решения:

image

Главный вывод, который можно сделать, что хранилище данных, никак не соревнуется с озером данных, а больше дополняет. Но это вам решать, что подходит для вашего случая. Всегда интересно, попробовать самому, и сделать правильные выводы.

Я хотел бы также рассказать по один из кейсов, когда я стал использовать подход озера данных. Все довольно банально, я попытался использовать инструмент ELT (у нас был Matillion ETL) и Amazon Redshift, мое решение работала, но не укладывалось в требования.

Мне необходимо было взять веб логи, трансформировать их и агрегировать, чтобы предоставить данные для 2х кейсов:

  1. Команда маркетинга хотела анализировать активность ботов для SEO
  2. IT хотело смотреть метрики по работе сайтов

Очень простой, очень простые логи. Вот пример:

https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188 
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57 
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"

Один файл весил 1-4 мегабайта.

Но была одна трудность. У нас было 7 доменов по всему миру, и за один день создавалось 7 тысяч файлов. Это не очень больше объем, всего 50 гигабайт. Но размер нашего кластера Redshift был тоже небольшим (4 ноды). Загрузка традиционным способом одного файла занимала около минуты. То есть, в лоб задача не решалась. И это был тот случай, когда я решил использовать подход озера данных. Решение выглядело примерно так:

image

Оно достаточно простое (я хочу заметить, что преимущество работы в облаке это простота). Я использовал:

  • AWS Elastic Map Reduce (Hadoop) как вычислительную мощность
  • AWS S3 как файловой хранилище с возможность шифрования данных и разограничения доступа
  • Spark как InMemory вычислительную мощность и PySpark для логики и трансформации данных
  • Parquet как результат работы Spark
  • AWS Glue Crawler как сборщик метаданных о новых данных и партициях
  • Redshift Spectrum как SQL интерфейс к озеру данных для существующих пользователей Redshift

Самый маленький кластер EMR+Spark обрабатывал все пачку файлов за 30 минут. Есть и другие кейсы для AWS, особенно много связанных с Alexa, где данных очень много.

Совсем недавно я узнал один из недостатков озера данных — это GDPR. Проблема в том, когда клиент просит его удалить, а данные находятся в одном из файлов, мы не можем использовать Data Manipulation Language и операцию DELETE как в базе данных.

Надеюсь, статья прояснила разнице между хранилищем данных и озером данных. Если было интересно, то могу перевести еще свои статьи или статье профессионалов, которых читаю. А также рассказать про решения, с которыми работаю, и их архитектуру.
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 28

    +2
    Как ни крути, но бизнес пользователи работаю эффективней с хранилищем данных, чем озером данных

    Бизнес-пользователи работают с BI инструментами, а не с хранилищами/озерами. Им (бизнес-пользователям), в большинстве своем, все равно, что там в бекенде…
    P.S. устал от вашей рекламы облаков (на канале в том числе), особенно, когда обоснование не проанализировано с финансовой точки зрения на реальных масштабах работы бизнеса…
      0
      Точно, я это и имел ввиду, мне кажется BI инструменты лучше работают с DW, чем с Big Data. Безусловно, они все могут подключаться к Hive, Athena и тп, но сложней контролировать производительность. Раз на то пошло, бизнес пользователи могут вообще не понимать разницу между BI,DW,DL. Им просто нужен удобный интерфейс к данным.

      Что-то, а рекламы облаков у меня точно нет. Я с ними работаю в Amazon (AWS) и в консалтинге rockyourdata.cloud. Я пишу о том, что происходит вокруг меня в Северной Америке, и я вижу рост популярности облаков и их преимуществ. Можно меня упрекнуть в рекламе Matillion или Tableau как вендоров, но врят ли в рекламе облаков.

      Канал я использую для того, чтобы скидывать интересные мне материалы, это мое видение ситуации вокруг аналитики данных и инжиниринга данных.
        0
        Так или иначе для нужд бизнеса и аналитиков создаётся staging слой данных, который вполне можно вынести в субд вроде clickhouse. Hive в этих целях можно использовать разве что для каких-то ad-hoc задач и то удовольствие сомнительное.
        0

        "Бизнес-пользователи работают с BI инструментами, а не с хранилищами/озерами."
        Очень серьёзное заблуждение, особенно надоедает его слышать от новеньких, которые попали в ИТ департамент :)

          0
          Вы меня извините, но судя по вашему резюме, в IT я попал чуть-чуть раньше вас, как и в DWH. И я конечно не знаю, как там в ВТБ и Банке Москвы, но я точно знаю, что в банках/телекомах всех бизнес-пользователей на прямую в хранилище уже давно никто не пускает, по многим факторам…
            0

            Я рад что у вас такие обширные знания :)
            Только сначала следует определить кто такие эти самые бизнес-пользователи, т.к. классификация штука нестабильная, а ad-hoc-и через "настоящее ИТ"…
            В принципе ввиду того что бизнес очень быстро меняется классическое деление местами отступает :)

              0
              Вопрос про специфику это хороший вопрос. Но в целом у каждого свое мировозрение и восприятие. Когда я говорю, что бизнес пользователи работают с BI/DW я имею ввиду свой опыт работы с бизнес пользователями, которые обычно знают как работает Excel и пытаются всеми средствами выгрузить данные из DW и BI в эксель.

              Хороший бизнес пользователь, это тот, кто знает SQL и может сам писать запросы. И тут уже не важно Data Lake (Athena/Spectrum в AWS) или DW. Но самая большая проблема для меня, что Custom SQL отчеты, с кучей подзапросов и непонятной логикой плодятся очень быстро, и никто, кроме бизнес пользователя не сможет сказать, что этот отчет делает, а потом он увольняется и как было недавно, оставляет вам 200 отчетов на SQL, и финансы говорят, на все нужно, хотя никто не понимает чего внутри и какие есть альтернативы (например в DW есть Star Schema со всеми метриками и она подключена к Tableau).

              Deep dive — это уже меньше про бизнес пользователей, это про аналитиков, тут может и python понадобиться и Spark, и shell. То есть уже очень продвинутый уровень пользователя. И им вообще все-равно где данные и в каком формате, например JSON и доступ через API.

              В любом случае, я за то, что у каждого свое мнение, и оно зависит от среды, в которой мы работает. И правильного ответа возможно и не существует. В посте я написал, главное это польза для бизнеса, а как уже 2ой приоритет, и зависит от нашего опыта технологий.
                0

                В вашем описании одновременно несколько проблем, и самая основная — передача знаний, вероятно пока ещё не везде руководство такого "квазибизнеса" (как раз финансы самый лучший пример, т.к. изменения в системах часто происходят без детального учёта их потребностей, а им "это всё" разгребать по факту в сжатые сроки) имеет чёткую картину того, как организовать передачу информации, в т.ч. потому что её намного сложнее формализовать, особенно с учётом того что набор необходимой информации может меняться на ходу (запросы аудиторов это здесь и сейчас иначе мы не уложимся в срок).
                и это порождает ситуации когда передаётся функционал а смысл теряется (через 1 уволившегося это уже серьёзная проблема, а требования никто не отменяет, и иногда приходится устраивать опросы вида — "а это ещё кто-то использует" с дополнением вида "а как вы понимаете эти данные".
                Про Excel, так сложилось что этот инструмент наиболее распостранён, удобен для передачи людям, и не требует согласования доступа в хранилище "через bi/dw" новому контрагенту для того чтобы он этот отчёт увидел без выгрузки. Также частая проблема место в схемах, т.к. одно дело сохранить метаданные, другое данные чтобы гарантировать неизменность, ведь очень часто доступ дают исключительно на чтение без(или с сильно ограниченной) песочницей.
                Но прогресс не стоит на месте, современные bi/dw очень сильно продвинулись, взять тот же oracle то что они сделали за последние годы это очень большой прогресс, также сейчас приходит понимание что по умолчанию доступ(сильно обрезанный) и базовое обучение нужно давать всем, кто хоть как-то работает с данными, что управление доступом должно быть на уровне сейчас запросил, начальник подтвердил через час права(по доступным ролям) получены. И постепенно бизнес будет уходить от excel но только когда альтернатива не будет отнимать в разы больше усилий на простенькую "разовую" задачу :)

                  0

                  Я вот думаю создать вебинары на телеграм канале. Было бы интересно послушать вашу презентацию на этом примере, чтобы и другие смогли поучиться. У каждого человека уникальный опыт, и было бы хорошо им поделиться.

        0
        Например миграциия хранилища данных на Oracle в AWS
        Простите, что это? Оракл своё облако мигрировал в 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 до сих пор не видел ни одного инструмента или гайда, как вытащить свои данные из облака, когда ценник за месяц становится слишком высок и стоимость аренды за год приближается к стоимости покупки своего кластера.
          0
          Я имел ввиду миграцию Oracle DW на Amazon Redshift. Oracle изначально был в собственном датацентре, то есть много ресурсов на обслуживание (патчи, бекапы и тп), если погуглить, то этот проект назывался Rolling Stone. Он состял из двух элементов:
          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 и работы бизнес пользователей.

          У меня нет задачи вытаскивать данные из облака, все происходит там. Какой кейс вы имеете ввиду?
            0
            Мой поинт про облака — небольшие проекты действительно проще запускать в облаках (попробуйте сейчас на рынке найти Big Data Admin'a/Engeneer'a на старте за вменяемые деньги ) и какие-то тесты с разработкой гонять тоже проще в облаках: залили данные, прогнали тесты, потушили облако для экономии.
            Но прод — уже локально держать, или хотя бы в гибридных/приватных облаках — пара кластеров (прод + резерв) на десяток-полтора нод с 1.5-2 Пб хранилищем за 7-10 месяцев в облаках стоят столько же, сколько новый кластер целиком.
            Или за такие объемы уже идут облачные скидки?
            PS Собственно, кейс — когда ценник за облако уходит к $30000/мес — дешевле купить своё железо и нанять свою команду, а заодно прекратить терроризировать юристов с обоснованием законности трансграничной передачей данных, но при этом нужно как-то выкачать все данные из облака.
              0

              У оракла есть всё это(в т.ч. частное облако когда вам ставят в датацентр всё тоже самое что в public, но за вашим firewall-ом), просто кто-то решил переехать на aws

                0
                Действительно Амазон не в очень хороших отношения с Oracle. Но самое главное, зачем платить кому-то, если есть собственные решения, которые созданы для этой задачи.

                Про цену тоже хороший комментарий, в амазоне все расслабляются, так как скидка на AWS, и косты начинают мониторить, когда речь о МЛН долларов. Так же выбор технологий внутри AWS зависит на 100% от команды. Например, мое предпочтение — это максимально использовать готовые сервисы, и не использовать open source и кастомизацию по возможности из-за time to market и поддержки такого решения.
                  0
                  Действительно Амазон не в очень хороших отношения с Oracle.

                  А кто в хороших???
                  Несколько лет назад работал с одной автомобильной компанией. Проекты связанные с read only near real time synchronisation с Oracle в GCP… Видимо, не от хорошей жизни это было придумано.
                    0
                    MS в хороших: объединились и взаимодействуют облаками.
                    Только надолго ли?
            0
            Как правило память для хранения данных в аналитическом хранилище данных не дешевая (например Redshift, BigQuery, Teradata), так как нам надо покупать целый кластер.

            Это не совсем правда. Вернее, в случае BigQuery, это ложь.
              0
              А можно поподробней, как работает BigQuery? Я думаю всем будет полезно. Я точно знаю про Redshift, Azure DW и Snowflake.
                0
                Это очень большая тема. И в одном абзаце не напишешь пожалуй. Там, как и везде наверное, огромное количество нюансов, ограничений и прочих тонкостей.
                Если очень обобщённо и упрощённо, то платить нужно за хранение данных и за чтение данных (во время запросов). На самом деле там ещё куча всего, за что нужно платить (и куча всего бесплатно), но эти две вещи на поверхности.
                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. Я ежедневно его просматриваю, и, если могу помочь, то отвечаю.
                  0
                  Спасибо, полезная информация, пригодиться многим;
              0
              А как же хранилище данных?
              Мы заменяем хранилище данных на озеро данных или мы его расширяем?
              Можно ли все таки обойтись без озера данных?

              Если кратко, то мы можем ответить на все вопросы положительно, и будем правы.


              Отвечаем положительно, на все три вопроса?

              — А как же хранилище данных?
              — Да.

              — Мы заменяем хранилище данных на озеро данных или мы его расширяем?
              — Да.

              Серьезно?
                0
                Почти как ребус, серьезно. А вообще, хорошее замечание, нужно вопросы перефразировать. Положительно не обязательно «Да» для меня.

                -А как же хранилище данных?
                -Хранилище нужно, без него никуда. (Это положительный ответ?)

                В любом случае смысл я старался заложить, что можно и только с озером данных или только с хранилищем или хранилище + озеро данных.
                  0
                  Ну, проблема в том, что вопрос А как же… не предполагает бинарного ответа. Или не обязательно предполагает. Отсюда и мой вопрос. Да, лучше бы перефразировать немного.
                    0
                    Поправил, спасибо за фидбек.
                0
                по большому счету сплошная ерунда в тексте. реально озера вполне себе конкурируют с DWH и все больше задач отгрызают у классики. у нас вот DWH уже просто зеркало реляционных табличек из озера и живо лишь потому что Impala жрет много памяти при большим кол-вое параллельных пользователей. при этом пресловутый GDPR именно облако делает. при этом писать в parquet вполе получается с avro схемой. а еще в последних версиях parquet (delta lake надстройка поверх parquet от датабриксов) и orc вполне и DELETE говорят что работают.
                  0

                  Я ни разу не сказал, что Data Lake это плохо. Я привел примеры что можно использовать только Data Lake, а можно и DW и Data Lake. Я можно только DW, если Snowflake.


                  Типа данных parquet, был выбран для моего проекта. Цель статья показать не техническим людям, что такое data lake.


                  Про delta lake я много видел у data bricks, было бы интересно узнать больше. GDPR проблема, эта та, которая сейчас у нас в Алекса с текущим решением на AWS.


                  "Сплошная ерунда в тексте" — это больше про менталитет людей, из разряда, я самый умный, у меня лучше чем у других и тп. Я написал на основе своего опыта. С удовольствие послушаю дельные советы, и новую информацию, которая будет всем полезна.

                    0
                    у вас странный опыт и более напоминает компиляцию предрассудков из эпохи map reduce.
                    если хотите дельный совет — почитайте книжку Била Инмона Data Lake Architecture: Designing the Data Lake and Avoiding the Garbage Dump
                    у него там описывается лейк — четкая противоположность вашим представлениям. особливо вокруг applications pond.
                      0
                      Несмотря на то что ваши комментарии больше напоминают комментарии про фильмы на rutracker, аля «под пиво зайдет» или «тема сисек не раскрыта», все равно спасибо за рекомендацию книги, я ее не читал, но обязательно прочитаю.

                      Я заметил в вашей публикации от 27 июня 2018 года такую фразу " DWH массово движется в сторону DataLake и Hadoop". Примерно о том же я слышал, когда работал в Терадата в 2011 году, я думаю можно и сейчас написать тоже самое, и найдется аудитория, которая будет кивать головой и которая скажет «по большому счету сплошная ерунда в тексте». Еще я понял что вы топите за Oracle судя по блогу и постам на хабре. Я бы так же топил за Teradata, если так и остался там работать или не работал ни с чем, кроме нее. Я хотел посмотреть где вы работаете, но к сожалению не нашел. Целью спорить с тролями умниками не преследовал. Кстати это поэтому карма такая низкая?

                      Скоро лето, удачи с озерами и прудами!

                Only users with full accounts can post comments. Log in, please.