(Отметим, что несмотря на то, что данная схема выглядит достаточно просто, есть очень много «пограничных» случаев. Если они возникают, то мы прибегаем к экспертной оценке, чтобы оценить, нужны ли технологии Big Data для решения поступающих задач или можно обойтись решениями на базе «классических» технологий RDBMS).
В рамках этой статьи речь пойдет прежде всего об используемых технологиях и разрабатываемых с их помощью решений.
Для начала пару слов о предпосылках интереса к технологиям. К моменту начала работ по Big Data в банке имелось несколько решений по работе с данными:
- Data Warehouse (DWH, Корпоративное хранилище данных)
- Operational Data Store (ODS, Хранилище операционных данных)
Что заставило нас смотреть в сторону Big Data?
От нас в ИТ ждали универсального решения, которое позволило бы максимально эффективно анализировать все доступные для банка данные с целью создания цифровых продуктов и для улучшения клиентского опыта.
На тот момент у DWH и ODS имелись некоторые ограничения, которые не позволяли развивать эти решения в качестве универсальных инструментов для анализа всех данных:
- Жесткие требования к качеству данных, предъявляемые к DWH, сильно влияют на актуальность данных в хранилище (данные доступны для анализа на следующий день).
- Отсутствие исторических данных в ODS (по определению).
- Использование реляционных СУБД в ODS и DWH позволяет работать только со структурированными данными. Необходимость определять модель данных еще при записи в DWH/ODS (Schema on write) влечет дополнительные расходы на разработку.
- Отсутствие возможности горизонтального масштабирования решения, ограниченность вертикального масштабирования.
Когда мы осознали эти ограничения, то решили смотреть в сторону технологий Big Data. В тот момент было понятно, что компетенции в этой области в перспективе дают конкурентное преимущество, поэтому необходимо наращивать внутреннюю экспертизу. Так как практическая компетенция в Банке на тот момент отсутствовала, у нас фактически было два варианта:
— или сформировать команду с рынка (извне);
— или найти энтузиастов за счет внутренних переходов, без фактического расширения.
Мы выбрали второй вариант, т.к. он нам показался более консервативным.
Далее мы пришли к пониманию, что Big Data это всего лишь инструмент, а вариантов решения конкретной задачи с помощью этого инструмента может быть множество. Решаемая задача предъявляла следующие требования:
- Нужно иметь возможность вместе анализировать данные во всем многообразии их форм и форматов.
- Нужно иметь возможность решать широкий спектр аналитических задач – от плоских детерминированных отчетов до экзотических видов визуализации и предиктивной аналитики.
- Нужно найти компромисс между большими объемами данных и необходимостью анализировать их онлайн.
- Нужно иметь (в идеале) неограниченно масштабируемое решение, которое будет готово выполнять запросы от большого количества сотрудников.
Изучив литературу, почитав форумы и ознакомившись с доступной информацией, мы обнаружили, что решение, удовлетворяющее этим требованиям, уже существует в виде устоявшегося архитектурного шаблона и называется «Data Lake». Приняв решение о внедрении Data Lake, мы таким образом нацелились получить самодостаточную экосистему «DWH + ODS + Data Lake», способную решать любые задачи, связанные с данными, будь то управленческая отчетность, операционная интеграция или предиктивная аналитика.
Наш вариант Data Lake реализует типичную лямбда-архитектуру, в которой входные данные разделяются на два слоя:
— «быстрый» (speed) слой, в котором обрабатываются, в основном, потоковые данные, объемы данных небольшие, трансформации минимальные, но зато достигается минимальное время задержки (latency) между возникновением события и его отображением в аналитической системе. Для обработки данных мы используем Spark Streaming, а для хранения результата – Hbase.
— «пакетный» (batch) слой, в котором данные обрабатываются пакетами (батчами), которые могут включать несколько миллионов записей сразу (например, балансы по всем счетам по результатам закрытия операционного дня), это может занимать некоторое время, но зато мы можем обработать достаточно большие объемы данных (throughput). Данные в слое batch мы храним в HDFS, а для доступа к ним используем Hive или Spark, в зависимости от задачи.
Отдельно хочется отметить Spark. Мы широко его используем для обработки данных и для нас самые значимые преимущества – следующие:
- Можно использовать в качестве ETL средства.
- Более быстрый, чем стандартные джобы на MapReduce.
- Выше скорость написания кода по сравнению с Hive/ MapReduce, т.к. код получается менее многословный, в том числе за счет DataFrame’ов и библиотеки SparkSQL.
- Более гибкий, поддерживает более сложные пайплайны обработки, чем парадигма MapReduce.
- Поддерживается Python и JVM-языки.
- Встроенная библиотека машинного обучения.
Мы стараемся хранить данные в Data Lake в исходном, «сыром» виде, реализуя подход «schema on read». Для управления процессами в качестве планировщика задач мы используем Oozie.
Структурированные входные данные храним в формате AVRO. Это дает нам преимущества:
- Схема данных может меняться в ходе жизненного цикла, но это не будет нарушать работоспособность читающих эти файлы приложений.
- Схема данных хранится вместе с данными, не надо описывать отдельно.
- Встроенная поддержка многими фреймворками.
Для витрин данных, с которыми будут работать пользователи через BI-средства, планируем использовать форматы Parquet или ORC, т.к. это в большинстве случаев позволит ускорить выборку данных за счет колоночного хранения.
В качестве сборки Hadoop рассматривали Cloudera и Hortonworks. выбрали Hortonworks, потому что его дистрибутив не содерджит проприетарных компонентов. К тому же, у Hortonworks из коробки доступна 2-я версия Spark, а у Cloudera – только 1.6.
Среди аналитических приложений, которые используют данные Data Lake, отметим два.
Первое – Jupyter Hub с Python и установленным библиотеками машинного обучения, которое наши Data Scientist’ы используют для предиктивной аналитики и построения моделей.
На роль второго мы сейчас рассматриваем приложение класса Self-Service BI, с помощью которого пользователи самостоятельно смогут подготовить большинство стандартных ретроспективных отчетов – таблицы, графики, круговые диаграммы, гистограммы и т.д. При этом подразумевается, что роль ИТ будет заключаться в том, чтобы добавить данные в Data Lake, предоставить для приложения и пользователей доступ к данным, и … все. Остальное пользователи смогут делать сами, за счет чего, в частности, мы ожидаем уменьшения конечного времени поиска ответов на интересующие вопросы.
В заключение хотелось бы рассказать, чего мы достигли на данный момент:
- Вывели в Прод ветку Batch Layer, грузим данные, которые используются как для ретроспективного анализа (т.е. аналитики с помощью данных пытаются ответить на вопрос «как мы пришлю сюда»), так и предиктивного анализа: ежедневный прогноз на базе машинного обучения спроса на снятие наличных в банкоматах и оптимизация работы службы инкассации.
- Подняли Jupyter Hub, дали пользователям возможность анализировать данные самыми современными инструментами: scikit learn, XGBoost, Vowpal Wabbit.
- Активно разрабатываем и готовимся вывести в Прод ветку «Speed Layer», реализуя на Data Lake систему класса Real Time Decision Making.
- Составили продуктовый бэк-лог, реализация которого позволит наибыстрейшим темпом повысить зрелость решения. В числе запланированного:
- Катастрофоустойчивость. Сейчас решение развернуто в одном дата центре, и по сути мы не гарантируем непрерывность сервиса, а также можем необратимо потерять накопленные данные, случись что с дата-центром (такая вероятность мала, но все же существует). Мы столкнулись с проблемой: встроенными средствами HDFS нельзя добиться гарантированного хранения данных в разных дата-центрах. Есть доработка на этот счет, ее судьба пока непонятна, планируем реализовывать собственное решение.
- Обогащение метаданных (Atlas), Data Management / Governance на основе метаданных, ролевой доступ на основе метаданных.
- Исследовать альтернативы выбранным архитектурным компонентам. Первые кандидаты: Airflow как альтернатива Oozie, более продвинутые CDC как альтернатива Scoop для выгрузки данных из реляционных СУБД.
- Внедрение конвейера CI/CD. При всем разнообразии используемых технологий и инструментов мы хотим добиться, чтобы любое изменение кода можно было в автоматическом режиме максимально быстро выкатывать в продуктивную среду, и при этом гарантировать качество поставки.
Планов на использование Big Data в Райффайзенбанке еще очень много и мы обязательно расскажем об этом.
Спасибо за внимание!
Комментарии (44)
Triffids
05.07.2017 18:561. spark streeming 2.1 даже сами разработчики все еще позиционируют как экспериментальный, банку не страшно? были ли уже свои тесты под нагрузкой?
2. входные данные AVRO, это json/avro, не paquet/avro? источники сами занимаются ETL в avro?
3. для доступа используете Hive и Spark, а Hive с которым движком? Nez, MR, может тоже Spark?
msetkin
05.07.2017 19:13Приветствую!
1. Про Spark Streaming — да, мы пока в процессе вывода в прод, на тестах зарекомендовал себя хорошо. И цели, для которых мы используем Spark Streaming — realtime аналитика, это не настолько критичный сервис, чтобы было страшно;)
2. Не совсем понял вопрос. Данные берем из реляционных баз данных, в AVRO преобразует Scoop.
3. Для Hive используем Tez, т.к. он идет в поставке Hortonworks.
Subrisk
05.07.2017 22:11+5Какая-то прям декларативная статья, как будто пиаролог-маркетёр писал… Рассказали бы реальные кейсы применения бигдаты. А то говорить все говорят, а о том, как реально всё это в проектах крутится, один Сбер только написал. Эх( Из-за таких статей я перестаю верить в то, что большие данные работают в реальной среде. Небось такая же теория, как этот пост.
msetkin
05.07.2017 23:04-2Спасибо за пиаролога-маркетера, я польщен:)
Что касается реальных кейсов и того, кто что про них говорит.
Как показывают мои личные наблюдения, если кто-то о чем-то молчит, это не всегда значит, что он ничего не делает. И наоборот, если кто-то говорит о чем-то вслух, это не всегда значит, что так оно и есть.
Я в начале статьи сообщил, что текст будет про технологии. Мне такой уровень изложения показался более оптимальным, чем выкладывать конфиги и скриншоты.
Реальный кейс я тоже упомянул один — ежедневный прогноз на базе машинного обучения спроса на снятие наличных в банкоматах и оптимизация работы службы инкассации.
Есть и другие.
Но тут я хочу привести одну аналогию. В начале 20 века во многих международных журналах по физике энтузиасты охотно делились исследованиями по ядерной физике, проникая вглубь атома. А потом эти публикации резко пропали. Потому что все осознали, что кто первый научится управлять ядерной реакцией, тот получит весомый аргумент в разговорах на мировой арене. Как показывает история, так в итоге и получилось.
То же самое и с реальными кейсами по биг дате. Многие из них очень легко можно воссоздать по малейшей подсказке и они приносят слишком много пользы, чтобы о них можно было открыто говорить.
facha
06.07.2017 01:07выбрали Hortonworks, потому что его дистрибутив не содерджит проприетарных компонентов.
CDH тоже не содержит. За пределами HDP и CDH у обеих компаний есть не-opensource продукты.
К тому же, у Hortonworks из коробки доступна 2-я версия Spark, а у Cloudera – только 1.6.
Spark2 в CDH тоже есть. Он устанавливается отдельным пакетом.msetkin
06.07.2017 10:11+1Возможно. Но так часто бывает, что к итоговому результату приводит цепочка случайностей, которым довелось случиться в одно время. Когда мы начинали, как мы думали?
1. Что есть на рынке? Почитали интернет, почитали Гартнера, определились: Horton или Cloudera, MapR не рассматривали.
2. Как у них все устроено? Cloudera — есть EDH, есть Analytic DB, есть Operational DB… Ну хорошо, как насчет EDH.
3. Сразу же натыкаешься на 60-дневный триал для Cloudera Enterprise, полностьб бесплатный только Cloudera Express. Ну хорошо, допустим. А что там есть в нем?
4. Идем на страницу версий, видим там только Spark 1.6. И тут возникает вопрос — если мы покупаем у них лицензию, нам нужна от них поддержка. Будет ли она оказываться, если мы те компоненты, которые у них идут в поставке, будет апгрейдить на другие компоненты, которые у них не описаны?
С Horton все проще. Качаешь HDP и все. Хочешь поддержку — покупаешь. Не хочешь — не покупаешь. Никаких триалов. Там уже в 2016 году был HDP 2.5, в котором был Spark 2.0. Скачали, начали использовать, не жалеем.
Сейчас конечно разобраться с Cloudera не составило бы труда, но тогда ход мыслей был таким и цепочка случайностей именно такая.
Плюс сейчас появился HDF, мы его тоже используем.
Animegravitation
06.07.2017 11:56+1Я конечно извиниюсь что не по теме. Но вы бы свою разработку не в BigData направляли а скорее бы выпустили обновленное мобильное приложение
Ибо текущеее мягко говоря не катит по сравнению с конкурентами.
А то ради пополнения с2с постоянно проиходится лезть в мобильный браузер потому что шаблоны из ИБ в МБ не подгягиваются :)msetkin
06.07.2017 12:12+1Ну почему же, все по теме.
Мой ответ будет состоять из двух частей.
Часть первая, философская. Раньше человек, который работал на компьютере, назывался «Оператор ЭВМ» и умел справляться с любой задачей, от набивки перфокарт до замены высохшего конденсатора. По мере того, как технологии усложнялись, а требования к скорости разработки ужесточались, возникло разделение на специализации. В этой связи мы бы и рады помочь коллегам с мобильным приложением, но боюсь, если мы, привыкшие работать с Hadoop и Spark, начнем всесто них допиливать мобильное приложение, мы еще сильнее отстанем от конкурентов=)
Что касается второй части, практической. Наши коллеги, которые знают толк в мобильной разработке, уже работают над новым приложением. Обещаю, если им понадобится, мы всей биг датой придем им на помощь, чтобы приблизить долгожданный релиз.
Подписывайтесь на наш блог, чтобы быть в курсе и узнать одними из первых ;)Subrisk
06.07.2017 15:38+1Этот вот ответ ещё больше палит в вас гуманитария, который как-то (а точнее, кое-как) научился жонглировать айтишными словами. Очень непрофессионально. Кстати, с точки зрения пиара непрофессионально тоже.
Wolfas
07.07.2017 09:23Райф давно хотел на Хабре публиковаться, но желающих писать статьи не было. Я по своему опыту могу сказать. Что тут человек более менее адекватный. Хотя бы что то понимает. Сталкивался с горазда более неприятными ситуациями. Когда на предложение, что то сделать или улучшить, следовал забавный ответ
— У меня 258 часов разработки… Считаю что это не правильно. В итоге сроки срывались, а по шапке довали разработчикам.
А в целом Райфу просто не везет с мобильными разработчиками, но надо отдать должное условия они создают отличные для работы. Нужен мак, купят мак. Нужно два, купят два.
air_squirrel
06.07.2017 16:16Спасибо за статью! Реальных кейсов конечно не хватает, будем их ждать ;)
А так сколько читаю статей про Big Data (в наших росс реалиях) понимаю что это все в угоду целям IT директорам ну и нам для сатисфакции инженерных амбиций (интересов) в новых технологиях.msetkin
06.07.2017 16:58-1Спасибо за отзыв, рад, что вам понравилось!
Мы обязательно будем делиться интересными вещами, оставайтесь с нами!
haviras
06.07.2017 16:16Меня интересует чего Дреллинг, уходя из Райфайззена не захватил пальму, мангал и плазму?
msetkin
06.07.2017 20:34+1Ах, вы про Александра Дрелинга из «Райффазен Банка Аваль»…
Как я указывал выше, другие банки, в том числе Аваль, и мы — это разные организации. Осталось выяснить про пальму, мангал и плазму. Мы тут честно не в курсе, что произошло:)
arruzk
06.07.2017 19:04Спасибо за статью.
А какие претенденты на роль Self-Service BI рассматриваете?msetkin
06.07.2017 19:27Отличный вопрос, спасибо!
Нужно сделать важную оговорку, какой класс задач мы планируем отдавать на Self-Service BI.
У нас есть достаточно большое количество однотипных задач, суть которых сводится к тому, чтобы получить исторические данные (возможно, сджойнив несколько таблиц), группировать, покрутить в Pivot, аггрегировать, вывести результат, оформить или в виде таблицы, или в виде графика.
Сейчас такие отчеты разрабатывает отдельная ИТ команда.
Вот от таких задач мы могли бы эту команду разгрузить, дав польльзователям возможность управляться самим.
Прикол в том, что пользователи и сами умеют делать такие вещи в Excel, пересадить их на другое средство, которое не похоже на то, с чем они привыкли работать, достаточно сложно и не гуманно. И поэтому требование к такому инструменту — чтобы он был похож на Excel.
Поэтому в первую очередь смотрим на… MS Power BI. А там поглядим.
Ну и более сложные задачи, например, посчитать финансовые потоки, применить сглаживание, экстраполяцию, мы не будем пытаться решать с помощью Self-Service BI, потому что есть негативный опыт, связанный со сложностью отладки и трудоемкостью выявления ошибок.
Dmitry88
06.07.2017 19:04А кто заказчик внутри банка? Не айти же отдел сам себе ставил задание? Где произошел условный тормоз по сравнению с реляционными базами? Какой поток данных прямо-таки заставил смотреть в сторону big-data
p.s. мобильное приложение норм, мне нравитсяmsetkin
06.07.2017 20:07+1Очень качественный и злободневный вопрос.
В том-то и дело, что нельзя сказать, что где-то болело. Банк жил до определенного момента в своей реляционной парадигме, нагрузка была в пределах нормы, business as usual. Пожалуй, первыми, от кого пришел тревожный сигнал, что это стратегическое направление не развивалось, была Enterprise Архитектура, т.е. ИТ.
Зашевелились, начали обсуждать, породили хайп. Хайп подхватило Правление, почти одновременно Big Data попала в документ «Стратегия развития ИТ-2020», без конкретики, какую задачу решаем.
Дальше сыграли два фактора — высокая самоорганизация и свобода принятия решений на локальном уровне. Сами себе придумали Data Lake. По мере того, как он вызревал, архитектура начала позиционировать на него отдельные задачки. Так у нас появились первые заказчики. Параллельно ходили продавали решение бизнесу сами.
Сейчас имеем в клиентах Retail, в потенциальных клиентах — Risk Management, Compliance. Основное, что привлекает:
1. Низкое TCO по сравнению с коммерческими продуктами по хранению и обработке данных
2. Python — возможности по сравнению с коммерческими продуктами по анализу данных
3. Возможность анализировать данные с минимальной задержкой, вплоть до онлайн
4. Возможность хранить и анализировать неструктурированные данные
Знаю, что в разных умных статьях говорится, что если у Big Data-проекта, помимо всего прочего, изначально нет бизнес-заказчика и решаемой проблемы, то такой проект обречен на провал, но нам удалось пока избежать этой участи;)
P.S. Спасибо за вашу оценку мобильному приложению.
Animegravitation
06.07.2017 20:41Какое норм? :)
У них шаблоны из ИБ не подтягиваются в МБ.
Иногда есть отвалы кодов из PUSH уведомлений
Дизайн середина двухтысячных )
Даже вход по отпечатку странный
Чуть сместишь палец на экран и вход слетает, приходится снова на иконку отпечатка тапать
Учёт расходов не работает в МБ без подключенных СМС — О_о
Шаблоны МБ отдельно, ИБ отдельно
В ИБ глюк при заходе через браузер Opera начальную страницу корежит, но потом вроде всё норм
Пополение с карт другого банка не поддерживает ни NFC сканирование ни фотографирование карты :)
Mangiafuoco
06.07.2017 20:09я бы на этот огород названий технологий денег не давал… непонятно ни зачем это надо, ни как работает
msetkin
06.07.2017 20:14-1Согласен, я тоже когда смотрю на эту картинку, хочется назвать это огородом или зоопарком:
Но чтобы повысить привлекательность, пиарологи-маркетеры придумали название «экосистема» =)Triffids
07.07.2017 08:20это ты еще не видел древних экосистем, поглядел бы ты на оракловые продукты, они бы у тебя и в 4к экран не влезли.
msetkin
07.07.2017 08:51Точно! Это значит, не такая уж тут и уникальная ситуация, и нормальная в целом динамика.
А ещё подумалось, что с учётом нынешнего разнообразия типов данных, требуемых скоростей и сложности решаемых задач, если бы существовала одна, «стандартная» система для Big Data, она была бы слишком дорогой, слишком сложной и слишком не гибкой.
Так что то, что изображено на рисунке, это вполне натуральная эволюционная ситуация.
Wolfas
07.07.2017 09:05Михаил добрый день. Подскажите пожалуйста
1. Big Data. Вы уже перешли к продуктивному использованию? Или это все еще тестовый вариант. Я когда год назад в рамках подряда с Вами работал. Все было еще только в планах. Можно сказать даже не на бумаге. А в силу достаточно сложной архитектуры. Все это перевести в прод… Пожалуй на грани фантастики
2. На сколько успешно и трудозатратно проходила у Вас миграция SAS продуктов. Так как сейчас это пожалуй один из наиболее интересных продуктов в банковских секторах. FPS GRS MA.
msetkin
07.07.2017 10:35Сергей, добрый день!
1. Мы перешли к продуктивному использованию с начала июня, точнее, первые пилотные проекты (два) сейчас в продуктивной среде проходят так называемый стабилизационный период. Да, действительно, год назад все было не так. Почти никак. Действительно, архитектура в крупных банках как правило не отличается простотой, но на нас это фактически никак не влияло, мы же новый продукт внедряем с нуля (без костылей и технического долга=), и совокупная сложность ИТ-ландшафта на нас особо не влияла. Много времени ушло на изучение. По мере того, как стали набивать руку, определились с количеством серверов и где какие компоненты размещать, взяв за основу предлагаемую вендором архитектуру:
Создали сервера, убедились в работоспособности.
Пришлось помучиться со Scoop, он долго не хотел сохранять файлы в Avro.
Пришлось допилить Oozie, т.к. он умеет запускаться либо по таймеру, либо работая с файловой системой HDFS, а нам нужно было запускать джобы по событиям во внешних системах.
Для вывода такой конфигурации в Прод даже полгода более чем достаточно при наличии опыта. Впрочем, мы отдаем себе отчет в том, что нашему Data Lake'у еще очень далеко от законченного вида и нужно как наполнять его данными, так и добавлять новые продуктовые фичи.
2. По поводу миграции не очень понятно. Да, мы используем продукты SAS, но мы с них никуда не мигировали. имелась в виду миграция на них, т.е. их внедрение?Wolfas
07.07.2017 10:50Я имел ввиду был ли опыт перехода от DB2 и Oracle (которые используется в качестве ODS) к тому же ходупу. Именно на SAS продуктах.
msetkin
07.07.2017 12:24Мы сейчас проводим небольшое RnD на эту тему. Что уже сделано — установили коннектор «SAS/ACCESS Interface to Hadoop», научились видеть Data Lake из SAS. Сейчас пытаемся перенести данные и сравнить процессы расчетов — если данные SAS хранятся на DB2 и на Hadoop, и есть ли в этом выигрыш в скорости, удобстве и экономии. Если получится, то это будет еще один весомый плюс от Data Lake.
Что касается Oracle, есть аналогичные мысли посмотреть «Oracle Big Data Connector» и попробовать поискать, где это может быть применимо.
IvaYan
Добрый день, спасибо за статью. Не могли бы вы пояснить вот что. Корни бренда "Райффайзенбанк" исходят, если я не ошибаюсь, из Австрии. В связи с этим не вполне ясно, в какой мере российское отделение связано с австрийским?
И, как следствие, описанное в статье относится исключительно к российскому отделению банка, или ко всей полноте, независимо от страны?
msetkin
Добрый день!
АО «Райффайзенбанк» является российским акционерным обществом, зарегистрированным в России и действующим на территории России. При этом наш единственный акционер — австрийский Raiiffeisen Bank International. Описанное в статье относится исключельно к российскому Райффайзенбанку.
IvaYan
Ага, таким образом у австрийцев какие-то свои технологии? Взаимодействовали ли с ними, консультировались ли?
msetkin
С австрийцами есть разные аспекты. Если посмотреть на страничку на их сайте (напомню, речь про RBI), там говорится, что «Raiffeisen Bank International рассматривает Австрию и центральную и восточную Европу (ЦВЕ) как свой целевой рынок. В Австрии RBI это ведущий корпоративный и инвестиционный банк. В ЦВЕ дочерние банки покрывают целый регион...».
То есть понимаете, у австрийцев нет ритейла, они — не универсальный банк. При этом в масштабе всей банковской группы RBI в России самый большой банк по всем показателям. Поэтому задачи, которые перед нами стоят — уникальные в масштабе группы RBI.
Хотя в целом обмен опытом есть, и я не исключаю, что наши решения и опыт, если они хорошо себя зарекомендуют тут, будут тиражироваться на остальные банки группы.
И насколько мне известно, каких-то особых своих технологий у австрийцев нет, с Open Source'ом нет желания тягаться ни у кого;)
Плюс нам предоставлена достаточно большая свобода в принятии решений, мы вполне можем сами решить, куда развиваться.
А можно встречный вопрос — вы себе наше взаимодействие с Австрией представляли по-другому? Чего ожидали?
IvaYan
Честно говоря я не очень знаком с принципами работы международных организаций такого масштаба. Судя по вашему ответу я себе также иначе представлял деятельность вашего банка в целом, я почему-то думал, что его деятельность в целом одинакова во всех странах. Просто мне показалось странным, что столь масштабный проект делается филиалом, и стало интересно, как в этом участвует головная организация.
Я как-то думал, что вот есть головная организация в Австрии, а по другим странам распределены филиалы. Головная организация помимо основных задач, также разрабатывает ПО, а потом филиалы его у себя внедряют. Как-то не приходило в голову, что филиал будет такими амбициозными проектами заниматься отдельно от остальных. Но благодаря вашим пояснениям о роде деятельности RBI, и что услуги конечным пользователям они не предоставляют, стало яснее.
msetkin
Ну в случае со стандартными процессами и «коробочными» решениями так и есть, некоторые программы одинаковые во всей группе, Австрия ими охотно делится. Но тут просто не очень стандартный процесс, плюс наш уникальный опыт:)
Причем в европейских банках законодательство плюс/минус похожее, правила бухучета не меняются уже много лет, поэтому коробочных решений из Австрии больше.
А у нас все-таки национальная специфика, не каждое коробочное решение оттуда нам подойдет.
Плюс согласен, логотип у нас у всех общий, это вводит в заблуждение.
Когда кто-то в Австрии видит желто-черный логотип, думают, что это одно и то же:
На самом деле, если дело происходит в Австрии, то скорее всего вы видите один из земельных банков Райффайзен, тех, с которых все начиналось. Они владеют 59% акций Raiffeisen Bank International (остальной 41% акций находится в свободном обороте и торгуется на венской бирже), который сам по себе ведет корпоративный и инвестиционный бизнес, и является в свою очередь акционером всех банков за пределами Австрии, включая российский Райффайзенбанк.
IvaYan
Ой, как у вас всё сложно-то оказывается. Все друг-другу принадлежат.
P.S. Признайтесь, вы специально выбирали фото, соответствующее стереотипным австрийским улочкам, чего только повозка с тыквами стоит? :)
lexnekr
Можете для аналогии рассмотреть другую аналогичную связку — банк ВТБ и его дочки: банк ВТБ24, БМ банк (бывший банк Москвы).
Думаю, не ошибусь, если скажу, что задачи решаемые ВТБ24 несколько объёмнее, чем у головы…
IvaYan
Так ВТБ24 вроде как не голова, голова как раз просто ВТБ, а которая с 24, это для конечных клиентов сервис. Про БМ не знал, что они теперь у ВТБ, никогда их на улицах не видел. Впрочем, я не из Москвы.
Но оно и понятно, похоже практически любая сложная организация имеет хитрую структуру.
lexnekr
Так и тут голова меньше, чем дочка. И задачи дочки интереснее.
Wolfas
В Москве даже банкоматы стоят) В Метро. Красненькие такие. Банк Москвы приписка группа компаний ВТБ. Если не ошибаюсь Банк Москвы больше по бизнесам.
IvaYan
А я не москвич, так что с достопримечательностями вашего метро не знаком. У нас есть свой "городской банк", но насколько я знаю, он сам по себе.
msetkin
Это Rust (https://goo.gl/maps/ygFYi5Zd9NG2), туристический город на границе в Венгрией, там, похоже, все сделано для того, чтобы стереотипная австрийская мимимишность зашкаливала :)
msetkin
Хочется ответить такой картинкой:)
andreycha
Райффайзен изначально создавался с ориентацией на крестьян и обычных людей, поэтому до сих пор повсеместно присутствует в маленьких городках и селах. А в Австрии в какой маленький городок ни ткни — почти везде подобная милота.