Как известно, Иннотех сейчас переводит банковское ПО ВТБ на микоросервисную архитектуру и при этом разрабатывает какие-то новые подсистемы.
Возникают вопросы
1. Почему разработчики ВТБ не заметили, что можно сделать декомпозицию подсистем и выделить для каждой из них отдельную базу данных.
2. Создается впечатление, что Иннотех режет ПО ВТБ по живому и разрывает связи между данными, которые могут потребоваться при обработке. Это может привести к существенному замедлению обработки данных.
3. Вообще вопрос декомпозиции сложной системы на независимые подсистемы раньше (20 лет назад) решался достаточно просто —достаточно было посмотреть модель данных сложной системы (например, реляционную модель). Если связей между данными нет, то можно делать декомпозицию. Сейчас это превратилось в религию.
4. Забавно то, что Иннотех соревнуется со Сбером (проект Гостех) в вопросах микросервисной архитектуры. Интересно, кто победит?
У меня возникли возможно риторические вопросы по трем фрагментам статьи.
“В проекте используется всего один инстанс БД PostgreSQL. А именно: Postgres Sber Edition (разработка Сбера), которую команда решила использовать в рамках импортозамещения. Заодно нужно было посмотреть, как эта БД будет работать с высоконагруженными данными и сможет ли заменить Spark, Hadoop, Kafka Streams и другие инструменты, которые обычно компании используют для работы с большими данными. Плюс это решение позволяло команде быстро выкатить MVP системы, которая, напомним, должна была стать первой на рынке — а значит работать надо быстро. »
«Знаете, пожалуй, пора перестать скромничать и сказать, что в проекте применяются самые передовые технологии и программы из сегодняшнего мира IT: микросервисы, контейнеры, ИИ, Big Data, речевые технологии, OpenShift, Kafka, Java Spring и другие. »
«В заключение хочется дать небольшое пояснение насчёт особенностей работы в IT-команде Сбера. Некоторое время назад в Департаменте корпоративной архитектуры Сбера произошли кардинальные изменения, которые поддерживают новые цели всей экосистемы: внедрение передовых IT-продуктов и сервисов, масштабные инновации, конкурирование с глобальными технологическими компаниями. Благодаря этому вектору, у разработчиков в Сбере есть возможность использовать почти любые технологии, пробовать любые методы. Что ж, это и делает работу над подобными сложными проектами в Сбере интересной и по-настоящему творческой! »
Лет пять назад Сбер пытался реализовать Единую фронтальную систему на базе NoSQL-продуктов Hadoop и Apache Ignite.
Сейчас Сбер пытается использовать реляционную БД, но «всего один инстанс БД PostgreSQL».
Даже не знаю, какой из этих подходов хуже при работе с «высоконагруженными данными»?
Однозначно, что в Сбере произошли кардинальные изменения. Неужели необратимые?
Вы действительно считаете, что приведенные Вами доводы являются вескими аргументами в обсуждении темы «Почему Сбербанк использовал для своей аналитической системы хранилище Hadoop, а не распределенные реляционные СУБД»?
Вы забавно приводите свои аргументы:
1. Сначала рассказываете, как Вам крупно повезло с экономией дискового пространства за счет использования формата parquet. И уже в следующем предложении рассуждаете о ненужности звезд и снежинок, которые как раз экономят дисковое пространство.
2. Утверждаете, что PostgreSQL хреново масштабируется. И тут же рассказываете про кластер на 100500 узлах, в котором для получения результата нужно выполнить полное их сканирование.
А это как раз пример плохо масштабируемого кластера.
Кластеры, создаваемые на основе реляционных СУБД, редко когда доходят до такого полного сканирования всех узлов.
Уже традиционно для крупных дата-центров информация о точном количестве серверов не разглашается, однако известно, что в 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
Как известно, Иннотех сейчас переводит банковское ПО ВТБ на микоросервисную архитектуру и при этом разрабатывает какие-то новые подсистемы.
Возникают вопросы
1. Почему разработчики ВТБ не заметили, что можно сделать декомпозицию подсистем и выделить для каждой из них отдельную базу данных.
2. Создается впечатление, что Иннотех режет ПО ВТБ по живому и разрывает связи между данными, которые могут потребоваться при обработке. Это может привести к существенному замедлению обработки данных.
3. Вообще вопрос декомпозиции сложной системы на независимые подсистемы раньше (20 лет назад) решался достаточно просто —достаточно было посмотреть модель данных сложной системы (например, реляционную модель). Если связей между данными нет, то можно делать декомпозицию. Сейчас это превратилось в религию.
4. Забавно то, что Иннотех соревнуется со Сбером (проект Гостех) в вопросах микросервисной архитектуры. Интересно, кто победит?
Самое "грандиозное" решение Сбера в области БД - это Единая фронтальная система, связанное с заменой реляционных БД на Hadoop и Apatch Ignite
У меня возникли возможно риторические вопросы по трем фрагментам статьи.
“В проекте используется всего один инстанс БД PostgreSQL. А именно: Postgres Sber Edition (разработка Сбера), которую команда решила использовать в рамках импортозамещения. Заодно нужно было посмотреть, как эта БД будет работать с высоконагруженными данными и сможет ли заменить Spark, Hadoop, Kafka Streams и другие инструменты, которые обычно компании используют для работы с большими данными. Плюс это решение позволяло команде быстро выкатить MVP системы, которая, напомним, должна была стать первой на рынке — а значит работать надо быстро. »
«Знаете, пожалуй, пора перестать скромничать и сказать, что в проекте применяются самые передовые технологии и программы из сегодняшнего мира IT: микросервисы, контейнеры, ИИ, Big Data, речевые технологии, OpenShift, Kafka, Java Spring и другие. »
«В заключение хочется дать небольшое пояснение насчёт особенностей работы в IT-команде Сбера. Некоторое время назад в Департаменте корпоративной архитектуры Сбера произошли кардинальные изменения, которые поддерживают новые цели всей экосистемы: внедрение передовых IT-продуктов и сервисов, масштабные инновации, конкурирование с глобальными технологическими компаниями. Благодаря этому вектору, у разработчиков в Сбере есть возможность использовать почти любые технологии, пробовать любые методы. Что ж, это и делает работу над подобными сложными проектами в Сбере интересной и по-настоящему творческой! »
Лет пять назад Сбер пытался реализовать Единую фронтальную систему на базе NoSQL-продуктов Hadoop и Apache Ignite.
Сейчас Сбер пытается использовать реляционную БД, но «всего один инстанс БД PostgreSQL».
Даже не знаю, какой из этих подходов хуже при работе с «высоконагруженными данными»?
Однозначно, что в Сбере произошли кардинальные изменения. Неужели необратимые?
1. Сначала рассказываете, как Вам крупно повезло с экономией дискового пространства за счет использования формата parquet. И уже в следующем предложении рассуждаете о ненужности звезд и снежинок, которые как раз экономят дисковое пространство.
2. Утверждаете, что PostgreSQL хреново масштабируется. И тут же рассказываете про кластер на 100500 узлах, в котором для получения результата нужно выполнить полное их сканирование.
А это как раз пример плохо масштабируемого кластера.
Кластеры, создаваемые на основе реляционных СУБД, редко когда доходят до такого полного сканирования всех узлов.
Это данные 2013 года
Понятно, что количество MySql-серверов меньше.
И никакаих проблем с масштабированием.
1. Посмотрел рекомендованное Вами выступление Алексея Курагина и Александра Перковского.
1.1. В основном выступлении они заявили, что отрабатывают возможность(и видимо скоро это закончат) полного отказа от реляционных СУБД и переход к нереляционным способам хранения, которые они обозначили Local Recoverable Store. Это хранилище будет работать в связке с GridGain
1.2. На вопрос «Вы совсем хотите отказаться от реляционных СУБД?» они ответили, что для построения отчетов все-таки будут использоваться реляционные СУБД. Больше вопросов на эту тему не было. Зоопарк какой-то.
2. Вадим Сурпин похоже расcказывал о извлечении данных напрямую из Hadoop. И это полностью согласуется с докладом Алексея Курагина и Александра Перковского.
3. Поэтому самый впечатляющий факт из Вашей статьи, что такой большой объем очень сложной работы по спецпроектам Сбербанка удалось проделать, не использую ни одного оператора Select.
4. Очень интересно, чем это все закончится.
Можно узнать много интересного. В частности, сколько тысяч серверов MySQL использует сейчас Facebook.
Также рекомендую набрать в поиске Google строку «Google использует MySQL»
Для тех, у кого мало времени, рекомендую прочитать очень короткую статью
habrahabr.ru/post/99884.
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. Почему не использовались распределенные реляционные СУБД для этих задач?
В данном интервью есть не убедительные и не понятные рассуждения на эту тему
В чем проблемы «подключения машинного обучения» к реляционным СУБД?
Почему нельзя использовать полнотекстовые индексы реляционных СУБД?
Почему нельзя поставить задачу (видимо, не простую) извлечения потоковых данных из реляционных СУБД?
www.linkedin.com/feed/update/urn:li:activity:6318054153390292992