Вы действительно считаете, что приведенные Вами доводы являются вескими аргументами в обсуждении темы «Почему Сбербанк использовал для своей аналитической системы хранилище Hadoop, а не распределенные реляционные СУБД»?

Вы забавно приводите свои аргументы:
1. Сначала рассказываете, как Вам крупно повезло с экономией дискового пространства за счет использования формата parquet. И уже в следующем предложении рассуждаете о ненужности звезд и снежинок, которые как раз экономят дисковое пространство.
2. Утверждаете, что PostgreSQL хреново масштабируется. И тут же рассказываете про кластер на 100500 узлах, в котором для получения результата нужно выполнить полное их сканирование.
А это как раз пример плохо масштабируемого кластера.
Кластеры, создаваемые на основе реляционных СУБД, редко когда доходят до такого полного сканирования всех узлов.

По поводу количества серверов MySQL в Facebook рекомендую посмотреть статью habrahabr.ru/company/mediagrus/blog/182966, в которой приводятся следующие данные

Уже традиционно для крупных дата-центров информация о точном количестве серверов не разглашается, однако известно, что в 2008 года эта цифра эта составила 10 тыс. серверов, в 2009-м — 30 тыс., в 2010-м — 60 тыс. Согласно сведениям из разных источников, сегодняшнее количество серверов составляет от 120 до 180 тыс

Это данные 2013 года
Понятно, что количество MySql-серверов меньше.
И никакаих проблем с масштабированием.

1. Посмотрел рекомендованное Вами выступление Алексея Курагина и Александра Перковского.
1.1. В основном выступлении они заявили, что отрабатывают возможность(и видимо скоро это закончат) полного отказа от реляционных СУБД и переход к нереляционным способам хранения, которые они обозначили Local Recoverable Store. Это хранилище будет работать в связке с GridGain
1.2. На вопрос «Вы совсем хотите отказаться от реляционных СУБД?» они ответили, что для построения отчетов все-таки будут использоваться реляционные СУБД. Больше вопросов на эту тему не было. Зоопарк какой-то.
2. Вадим Сурпин похоже расcказывал о извлечении данных напрямую из Hadoop. И это полностью согласуется с докладом Алексея Курагина и Александра Перковского.
3. Поэтому самый впечатляющий факт из Вашей статьи, что такой большой объем очень сложной работы по спецпроектам Сбербанка удалось проделать, не использую ни одного оператора Select.
4. Очень интересно, чем это все закончится.

Вы действительно считаете, что приведенные Вами статьи являются веским аргументом в обсуждении темы «Почему Сбербанк использовал для своей аналитической системы хранилище Hadoop, а не распределенные реляционные СУБД»?

Настоятельно рекомендую всех, кому интересно данное обсуждение, набрать в поиске Google строку «Facebook использует MySQL».
Можно узнать много интересного. В частности, сколько тысяч серверов MySQL использует сейчас Facebook.
Также рекомендую набрать в поиске Google строку «Google использует MySQL»

Для тех, у кого мало времени, рекомендую прочитать очень короткую статью
habrahabr.ru/post/99884.

Archi_Pro
1. У Hadoop нет подавляющего преимущества по скорости сохранения сгенерированных данных по сравнению распределенными реляционными СУБД(в два, три и более раз). Скорее всего эти показатели сопоставимы.
2. Также у Hadoop нет подавляющего преимущества по стоимости хранения информации
2.1. Имеются бесплатные реляционные СУБД
2.2. Реляционные СУБД очень оптимизированы в вопросах использования дискового пространства для хранения структурированной и не структурированной информации. При тщательном изучении этого вопроса вполне может оказаться, что Hadoop уступает
3. А вопрос собственно в том, что если заявлено, что нужно разработать аналитическую распределенную систему, то как это можно делать без полноценного высокоэффективного SQL? Неужели такие решения выглядят модно, молодежно и современно?

Есть вопросы.
Задайте их при следующем интервью с архитекторами Сбербанка, если это будет возможно.
1. Зачем для спецпроектов Сбербанка использовали key-value хранилище Hadoop? Чем обосновывался этот выбор?
2. Можно ли обойтись без эффективного SQL для задач аналитики спецпроектов?
3. Что можно сказать об эффективности SQL в Spark SQL(и в других аналогичных решениях, построенных поверх хранилища key-value) по сравнению с реализациями SQL в реляционных СУБД?
4. Почему не использовались распределенные реляционные СУБД для этих задач?

В данном интервью есть не убедительные и не понятные рассуждения на эту тему

После наполнения Hadoop данными, думаю, опять всё переключится на продвинутую аналитику. Суть перехода от традиционных SQL-хранилищ к Hadoop, в том числе, и в том, чтобы можно было применять и более продвинутые методы анализа данных. Не просто SELECT сделать, а всё-таки подключить машинное обучение, применять нереляционные способы поиска, хотя бы те же полнотекстовые индексы, которые позволяют проще найти информацию во всём этом объёме. Это всё пойдет в сторону более глубокой аналитики — раз. И второе, то, где технологический процесс интересный — это realtime-обработка на Hadoop. Которая, думаю, будет развиваться просто в силу того, что с точки зрения банка есть потребность в ускорении процессов и в ускорении выдачи кредитов. Сейчас идут соответствующие инициативы, и они закатывают все IT-системы, в том числе — наш Hadoop. Это и мировая тенденция — на Big Data делать потоковые и более быстрые решения. Первой была техническая масштабируемость, а сейчас уже идут в сторону скорости. Мне кажется, как-то так.

В чем проблемы «подключения машинного обучения» к реляционным СУБД?
Почему нельзя использовать полнотекстовые индексы реляционных СУБД?
Почему нельзя поставить задачу (видимо, не простую) извлечения потоковых данных из реляционных СУБД?

Посмотрите статью «Пути решения проблем централизации и масштабируемости майнинга Биткойна. От blockchain к blockchains»
www.linkedin.com/feed/update/urn:li:activity:6318054153390292992