Отдельно выделю знание языка. Не очень понятно, на каком уровне и каким именно языком, помимо родного, владеет автор.
Высокие (относительно соответствующего рынка) зарплатные ожидания
Высокая конкуренция на рынке труда. В целом US/EU это понятие растяжимое. Возможно, в тех странах и в тех компаниях, куда подавался автор, слишком высокая конкуренция труда. Знаю также массу компаний, где вся разработка вынесена в Индию, а в головном офисе только менеджеры.
Многие EU компании принципиально не готовы брать иностранцев (и дело не в том, что автор русский или нет, имеет значение принадлежность к EU или нет) не из EU, так как бумажной волокиты много и далеко не факт, что в итоге получишь желаемый residence permit (законодательство в сфере труда в EU знаменито сильными протекционисткими мерами) , да и уходит с момента акцепта оффера до выхода сотрудника на работу от 4 месяцев, а многим нужен сотрудник здесь и сейчас. Часто бывает проще и быстрее нанять местного специалиста, который может выйти на работу через 1-1.5 месяца (в зависимости от того, какой у него/нее прописан notice period на текущем месте)
Всё-таки бренд компании, в которой сейчас трудится автор, может сыграть свою определенную (отрицательную) роль, если текущий работодатель как-то негативно известен за пределами страны.
Смущает заголовок: "Шпаргалка по SQL, которая выручает меня на собесах".
В идеале, хорошая шпаргалка должна выручить ровно один раз, после чего вы получите желаемую работу, после года которой, опять же, в идеале, ваш уровень знания SQL должен вырасти настолько, что указанная шпаргалка перестанет быть актуальной. А если она прям постоянно выручает, то стоит задуматься, а точно ли она помогает достичь цели собесов...
Вы правы, я скорее всего ошибся при наборе тескта, я бы Trifacta перенес бы в раздел Self Service BI.
Logical DWH — это по сути еще одно название для data virtualisation, я почитал про Cisco Information Server (я так понял, их весь бизнес по виртуализации данных приобрела компания Tibco, которая тоже была на конференции, но я на нее не обратил внимания), да, похоже это Logical DWH в терминологии Gartner и есть.
Ключевое отличие от классического DWH заключается в том, что то место, через которое осуществляются все запросы к данным, не является физически тяжеловесным централизованным хранилищем данных, я представляет собой лишь тонкий слой метаданных (ну может еще и кэш), который знает, где в Enterprise какие данные лежат.
Причем для пользователя такая архитектура является абсолютно прозрачной, т.е. он все так же работает с данными, как до этого привык, и не замечает никакой разницы. Всю работу по прокидыванию запросов пользователя к реальным данным, хранящимся, вообще говоря, в разных технологиях, осуществляет под капотом софт этого самого Logical DWH.
И что самое главное, это может быть не просто проксирование запросов к месту хранения данных, это может быть и джойн нескольких физических источников в одном запросе на Logical DWH. То есть я, как пользователь, захожу на Logical DWH и вижу, что мне доступны «таблицы» Client и Transactions, я определяю витрину, содержащую join этих таблиц, а Logical DWH сам определяет, как бы ему пооптимальней отдать мне результат этого запроса, учитывая, что, например, история Transactions это петабайтный файл на Hadoop, а Client это 100-тысячная таблица на неком слабеньком mySQL.
Все вендоры в один голос утверждали, что их софт обработает такую ситуацию корректно, а именно, разобьет один логический запрос на два (для Hadoop и mySQL), соптимизирует каждый из запросов, отправит на источники, и потом склеит (где-то) результат и вернет его мне, причем сделает это достаточно быстро.
Мы сейчас проводим небольшое RnD на эту тему. Что уже сделано — установили коннектор «SAS/ACCESS Interface to Hadoop», научились видеть Data Lake из SAS. Сейчас пытаемся перенести данные и сравнить процессы расчетов — если данные SAS хранятся на DB2 и на Hadoop, и есть ли в этом выигрыш в скорости, удобстве и экономии. Если получится, то это будет еще один весомый плюс от Data Lake.
Что касается Oracle, есть аналогичные мысли посмотреть «Oracle Big Data Connector» и попробовать поискать, где это может быть применимо.
Сергей, добрый день!
1. Мы перешли к продуктивному использованию с начала июня, точнее, первые пилотные проекты (два) сейчас в продуктивной среде проходят так называемый стабилизационный период. Да, действительно, год назад все было не так. Почти никак. Действительно, архитектура в крупных банках как правило не отличается простотой, но на нас это фактически никак не влияло, мы же новый продукт внедряем с нуля (без костылей и технического долга=), и совокупная сложность ИТ-ландшафта на нас особо не влияла. Много времени ушло на изучение. По мере того, как стали набивать руку, определились с количеством серверов и где какие компоненты размещать, взяв за основу предлагаемую вендором архитектуру:
Создали сервера, убедились в работоспособности.
Пришлось помучиться со Scoop, он долго не хотел сохранять файлы в Avro.
Пришлось допилить Oozie, т.к. он умеет запускаться либо по таймеру, либо работая с файловой системой HDFS, а нам нужно было запускать джобы по событиям во внешних системах.
Для вывода такой конфигурации в Прод даже полгода более чем достаточно при наличии опыта. Впрочем, мы отдаем себе отчет в том, что нашему Data Lake'у еще очень далеко от законченного вида и нужно как наполнять его данными, так и добавлять новые продуктовые фичи.
2. По поводу миграции не очень понятно. Да, мы используем продукты SAS, но мы с них никуда не мигировали. имелась в виду миграция на них, т.е. их внедрение?
Точно! Это значит, не такая уж тут и уникальная ситуация, и нормальная в целом динамика.
А ещё подумалось, что с учётом нынешнего разнообразия типов данных, требуемых скоростей и сложности решаемых задач, если бы существовала одна, «стандартная» система для Big Data, она была бы слишком дорогой, слишком сложной и слишком не гибкой.
Так что то, что изображено на рисунке, это вполне натуральная эволюционная ситуация.
Ах, вы про Александра Дрелинга из «Райффазен Банка Аваль»…
Как я указывал выше, другие банки, в том числе Аваль, и мы — это разные организации. Осталось выяснить про пальму, мангал и плазму. Мы тут честно не в курсе, что произошло:)
Очень качественный и злободневный вопрос.
В том-то и дело, что нельзя сказать, что где-то болело. Банк жил до определенного момента в своей реляционной парадигме, нагрузка была в пределах нормы, business as usual. Пожалуй, первыми, от кого пришел тревожный сигнал, что это стратегическое направление не развивалось, была Enterprise Архитектура, т.е. ИТ.
Зашевелились, начали обсуждать, породили хайп. Хайп подхватило Правление, почти одновременно Big Data попала в документ «Стратегия развития ИТ-2020», без конкретики, какую задачу решаем.
Дальше сыграли два фактора — высокая самоорганизация и свобода принятия решений на локальном уровне. Сами себе придумали Data Lake. По мере того, как он вызревал, архитектура начала позиционировать на него отдельные задачки. Так у нас появились первые заказчики. Параллельно ходили продавали решение бизнесу сами.
Сейчас имеем в клиентах Retail, в потенциальных клиентах — Risk Management, Compliance. Основное, что привлекает:
1. Низкое TCO по сравнению с коммерческими продуктами по хранению и обработке данных
2. Python — возможности по сравнению с коммерческими продуктами по анализу данных
3. Возможность анализировать данные с минимальной задержкой, вплоть до онлайн
4. Возможность хранить и анализировать неструктурированные данные
Знаю, что в разных умных статьях говорится, что если у Big Data-проекта, помимо всего прочего, изначально нет бизнес-заказчика и решаемой проблемы, то такой проект обречен на провал, но нам удалось пока избежать этой участи;)
P.S. Спасибо за вашу оценку мобильному приложению.
Отличный вопрос, спасибо!
Нужно сделать важную оговорку, какой класс задач мы планируем отдавать на Self-Service BI.
У нас есть достаточно большое количество однотипных задач, суть которых сводится к тому, чтобы получить исторические данные (возможно, сджойнив несколько таблиц), группировать, покрутить в Pivot, аггрегировать, вывести результат, оформить или в виде таблицы, или в виде графика.
Сейчас такие отчеты разрабатывает отдельная ИТ команда.
Вот от таких задач мы могли бы эту команду разгрузить, дав польльзователям возможность управляться самим.
Прикол в том, что пользователи и сами умеют делать такие вещи в Excel, пересадить их на другое средство, которое не похоже на то, с чем они привыкли работать, достаточно сложно и не гуманно. И поэтому требование к такому инструменту — чтобы он был похож на Excel.
Поэтому в первую очередь смотрим на… MS Power BI. А там поглядим.
Ну и более сложные задачи, например, посчитать финансовые потоки, применить сглаживание, экстраполяцию, мы не будем пытаться решать с помощью Self-Service BI, потому что есть негативный опыт, связанный со сложностью отладки и трудоемкостью выявления ошибок.
Ну почему же, все по теме.
Мой ответ будет состоять из двух частей.
Часть первая, философская. Раньше человек, который работал на компьютере, назывался «Оператор ЭВМ» и умел справляться с любой задачей, от набивки перфокарт до замены высохшего конденсатора. По мере того, как технологии усложнялись, а требования к скорости разработки ужесточались, возникло разделение на специализации. В этой связи мы бы и рады помочь коллегам с мобильным приложением, но боюсь, если мы, привыкшие работать с Hadoop и Spark, начнем всесто них допиливать мобильное приложение, мы еще сильнее отстанем от конкурентов=)
Что касается второй части, практической. Наши коллеги, которые знают толк в мобильной разработке, уже работают над новым приложением. Обещаю, если им понадобится, мы всей биг датой придем им на помощь, чтобы приблизить долгожданный релиз.
Подписывайтесь на наш блог, чтобы быть в курсе и узнать одними из первых ;)
Возможно. Но так часто бывает, что к итоговому результату приводит цепочка случайностей, которым довелось случиться в одно время. Когда мы начинали, как мы думали?
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 не составило бы труда, но тогда ход мыслей был таким и цепочка случайностей именно такая.
Это Rust (https://goo.gl/maps/ygFYi5Zd9NG2), туристический город на границе в Венгрией, там, похоже, все сделано для того, чтобы стереотипная австрийская мимимишность зашкаливала :)
Спасибо за пиаролога-маркетера, я польщен:)
Что касается реальных кейсов и того, кто что про них говорит.
Как показывают мои личные наблюдения, если кто-то о чем-то молчит, это не всегда значит, что он ничего не делает. И наоборот, если кто-то говорит о чем-то вслух, это не всегда значит, что так оно и есть.
Я в начале статьи сообщил, что текст будет про технологии. Мне такой уровень изложения показался более оптимальным, чем выкладывать конфиги и скриншоты.
Реальный кейс я тоже упомянул один — ежедневный прогноз на базе машинного обучения спроса на снятие наличных в банкоматах и оптимизация работы службы инкассации.
Есть и другие.
Но тут я хочу привести одну аналогию. В начале 20 века во многих международных журналах по физике энтузиасты охотно делились исследованиями по ядерной физике, проникая вглубь атома. А потом эти публикации резко пропали. Потому что все осознали, что кто первый научится управлять ядерной реакцией, тот получит весомый аргумент в разговорах на мировой арене. Как показывает история, так в итоге и получилось.
То же самое и с реальными кейсами по биг дате. Многие из них очень легко можно воссоздать по малейшей подсказке и они приносят слишком много пользы, чтобы о них можно было открыто говорить.
Ну в случае со стандартными процессами и «коробочными» решениями так и есть, некоторые программы одинаковые во всей группе, Австрия ими охотно делится. Но тут просто не очень стандартный процесс, плюс наш уникальный опыт:)
Причем в европейских банках законодательство плюс/минус похожее, правила бухучета не меняются уже много лет, поэтому коробочных решений из Австрии больше.
А у нас все-таки национальная специфика, не каждое коробочное решение оттуда нам подойдет.
Плюс согласен, логотип у нас у всех общий, это вводит в заблуждение.
Когда кто-то в Австрии видит желто-черный логотип, думают, что это одно и то же:
На самом деле, если дело происходит в Австрии, то скорее всего вы видите один из земельных банков Райффайзен, тех, с которых все начиналось. Они владеют 59% акций Raiffeisen Bank International (остальной 41% акций находится в свободном обороте и торгуется на венской бирже), который сам по себе ведет корпоративный и инвестиционный бизнес, и является в свою очередь акционером всех банков за пределами Австрии, включая российский Райффайзенбанк.
Первый кейс - что может быть:
Софт скиллс
Отдельно выделю знание языка. Не очень понятно, на каком уровне и каким именно языком, помимо родного, владеет автор.
Высокие (относительно соответствующего рынка) зарплатные ожидания
Высокая конкуренция на рынке труда. В целом US/EU это понятие растяжимое. Возможно, в тех странах и в тех компаниях, куда подавался автор, слишком высокая конкуренция труда. Знаю также массу компаний, где вся разработка вынесена в Индию, а в головном офисе только менеджеры.
Многие EU компании принципиально не готовы брать иностранцев (и дело не в том, что автор русский или нет, имеет значение принадлежность к EU или нет) не из EU, так как бумажной волокиты много и далеко не факт, что в итоге получишь желаемый residence permit (законодательство в сфере труда в EU знаменито сильными протекционисткими мерами) , да и уходит с момента акцепта оффера до выхода сотрудника на работу от 4 месяцев, а многим нужен сотрудник здесь и сейчас. Часто бывает проще и быстрее нанять местного специалиста, который может выйти на работу через 1-1.5 месяца (в зависимости от того, какой у него/нее прописан notice period на текущем месте)
Всё-таки бренд компании, в которой сейчас трудится автор, может сыграть свою определенную (отрицательную) роль, если текущий работодатель как-то негативно известен за пределами страны.
Смущает заголовок: "Шпаргалка по SQL, которая выручает меня на собесах".
В идеале, хорошая шпаргалка должна выручить ровно один раз, после чего вы получите желаемую работу, после года которой, опять же, в идеале, ваш уровень знания SQL должен вырасти настолько, что указанная шпаргалка перестанет быть актуальной. А если она прям постоянно выручает, то стоит задуматься, а точно ли она помогает достичь цели собесов...
Logical DWH — это по сути еще одно название для data virtualisation, я почитал про Cisco Information Server (я так понял, их весь бизнес по виртуализации данных приобрела компания Tibco, которая тоже была на конференции, но я на нее не обратил внимания), да, похоже это Logical DWH в терминологии Gartner и есть.
Ключевое отличие от классического DWH заключается в том, что то место, через которое осуществляются все запросы к данным, не является физически тяжеловесным централизованным хранилищем данных, я представляет собой лишь тонкий слой метаданных (ну может еще и кэш), который знает, где в Enterprise какие данные лежат.
Причем для пользователя такая архитектура является абсолютно прозрачной, т.е. он все так же работает с данными, как до этого привык, и не замечает никакой разницы. Всю работу по прокидыванию запросов пользователя к реальным данным, хранящимся, вообще говоря, в разных технологиях, осуществляет под капотом софт этого самого Logical DWH.
И что самое главное, это может быть не просто проксирование запросов к месту хранения данных, это может быть и джойн нескольких физических источников в одном запросе на Logical DWH. То есть я, как пользователь, захожу на Logical DWH и вижу, что мне доступны «таблицы» Client и Transactions, я определяю витрину, содержащую join этих таблиц, а Logical DWH сам определяет, как бы ему пооптимальней отдать мне результат этого запроса, учитывая, что, например, история Transactions это петабайтный файл на Hadoop, а Client это 100-тысячная таблица на неком слабеньком mySQL.
Все вендоры в один голос утверждали, что их софт обработает такую ситуацию корректно, а именно, разобьет один логический запрос на два (для Hadoop и mySQL), соптимизирует каждый из запросов, отправит на источники, и потом склеит (где-то) результат и вернет его мне, причем сделает это достаточно быстро.
http://m.imdb.com/title/tt0196229/
Что касается Oracle, есть аналогичные мысли посмотреть «Oracle Big Data Connector» и попробовать поискать, где это может быть применимо.
1. Мы перешли к продуктивному использованию с начала июня, точнее, первые пилотные проекты (два) сейчас в продуктивной среде проходят так называемый стабилизационный период. Да, действительно, год назад все было не так. Почти никак. Действительно, архитектура в крупных банках как правило не отличается простотой, но на нас это фактически никак не влияло, мы же новый продукт внедряем с нуля (без костылей и технического долга=), и совокупная сложность ИТ-ландшафта на нас особо не влияла. Много времени ушло на изучение. По мере того, как стали набивать руку, определились с количеством серверов и где какие компоненты размещать, взяв за основу предлагаемую вендором архитектуру:
Создали сервера, убедились в работоспособности.
Пришлось помучиться со Scoop, он долго не хотел сохранять файлы в Avro.
Пришлось допилить Oozie, т.к. он умеет запускаться либо по таймеру, либо работая с файловой системой HDFS, а нам нужно было запускать джобы по событиям во внешних системах.
Для вывода такой конфигурации в Прод даже полгода более чем достаточно при наличии опыта. Впрочем, мы отдаем себе отчет в том, что нашему Data Lake'у еще очень далеко от законченного вида и нужно как наполнять его данными, так и добавлять новые продуктовые фичи.
2. По поводу миграции не очень понятно. Да, мы используем продукты SAS, но мы с них никуда не мигировали. имелась в виду миграция на них, т.е. их внедрение?
А ещё подумалось, что с учётом нынешнего разнообразия типов данных, требуемых скоростей и сложности решаемых задач, если бы существовала одна, «стандартная» система для Big Data, она была бы слишком дорогой, слишком сложной и слишком не гибкой.
Так что то, что изображено на рисунке, это вполне натуральная эволюционная ситуация.
Как я указывал выше, другие банки, в том числе Аваль, и мы — это разные организации. Осталось выяснить про пальму, мангал и плазму. Мы тут честно не в курсе, что произошло:)
Но чтобы повысить привлекательность, пиарологи-маркетеры придумали название «экосистема» =)
В том-то и дело, что нельзя сказать, что где-то болело. Банк жил до определенного момента в своей реляционной парадигме, нагрузка была в пределах нормы, business as usual. Пожалуй, первыми, от кого пришел тревожный сигнал, что это стратегическое направление не развивалось, была Enterprise Архитектура, т.е. ИТ.
Зашевелились, начали обсуждать, породили хайп. Хайп подхватило Правление, почти одновременно Big Data попала в документ «Стратегия развития ИТ-2020», без конкретики, какую задачу решаем.
Дальше сыграли два фактора — высокая самоорганизация и свобода принятия решений на локальном уровне. Сами себе придумали Data Lake. По мере того, как он вызревал, архитектура начала позиционировать на него отдельные задачки. Так у нас появились первые заказчики. Параллельно ходили продавали решение бизнесу сами.
Сейчас имеем в клиентах Retail, в потенциальных клиентах — Risk Management, Compliance. Основное, что привлекает:
1. Низкое TCO по сравнению с коммерческими продуктами по хранению и обработке данных
2. Python — возможности по сравнению с коммерческими продуктами по анализу данных
3. Возможность анализировать данные с минимальной задержкой, вплоть до онлайн
4. Возможность хранить и анализировать неструктурированные данные
Знаю, что в разных умных статьях говорится, что если у Big Data-проекта, помимо всего прочего, изначально нет бизнес-заказчика и решаемой проблемы, то такой проект обречен на провал, но нам удалось пока избежать этой участи;)
P.S. Спасибо за вашу оценку мобильному приложению.
Нужно сделать важную оговорку, какой класс задач мы планируем отдавать на Self-Service BI.
У нас есть достаточно большое количество однотипных задач, суть которых сводится к тому, чтобы получить исторические данные (возможно, сджойнив несколько таблиц), группировать, покрутить в Pivot, аггрегировать, вывести результат, оформить или в виде таблицы, или в виде графика.
Сейчас такие отчеты разрабатывает отдельная ИТ команда.
Вот от таких задач мы могли бы эту команду разгрузить, дав польльзователям возможность управляться самим.
Прикол в том, что пользователи и сами умеют делать такие вещи в Excel, пересадить их на другое средство, которое не похоже на то, с чем они привыкли работать, достаточно сложно и не гуманно. И поэтому требование к такому инструменту — чтобы он был похож на Excel.
Поэтому в первую очередь смотрим на… MS Power BI. А там поглядим.
Ну и более сложные задачи, например, посчитать финансовые потоки, применить сглаживание, экстраполяцию, мы не будем пытаться решать с помощью Self-Service BI, потому что есть негативный опыт, связанный со сложностью отладки и трудоемкостью выявления ошибок.
Мы обязательно будем делиться интересными вещами, оставайтесь с нами!
Мой ответ будет состоять из двух частей.
Часть первая, философская. Раньше человек, который работал на компьютере, назывался «Оператор ЭВМ» и умел справляться с любой задачей, от набивки перфокарт до замены высохшего конденсатора. По мере того, как технологии усложнялись, а требования к скорости разработки ужесточались, возникло разделение на специализации. В этой связи мы бы и рады помочь коллегам с мобильным приложением, но боюсь, если мы, привыкшие работать с Hadoop и Spark, начнем всесто них допиливать мобильное приложение, мы еще сильнее отстанем от конкурентов=)
Что касается второй части, практической. Наши коллеги, которые знают толк в мобильной разработке, уже работают над новым приложением. Обещаю, если им понадобится, мы всей биг датой придем им на помощь, чтобы приблизить долгожданный релиз.
Подписывайтесь на наш блог, чтобы быть в курсе и узнать одними из первых ;)
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, мы его тоже используем.
Хочется ответить такой картинкой:)
Что касается реальных кейсов и того, кто что про них говорит.
Как показывают мои личные наблюдения, если кто-то о чем-то молчит, это не всегда значит, что он ничего не делает. И наоборот, если кто-то говорит о чем-то вслух, это не всегда значит, что так оно и есть.
Я в начале статьи сообщил, что текст будет про технологии. Мне такой уровень изложения показался более оптимальным, чем выкладывать конфиги и скриншоты.
Реальный кейс я тоже упомянул один — ежедневный прогноз на базе машинного обучения спроса на снятие наличных в банкоматах и оптимизация работы службы инкассации.
Есть и другие.
Но тут я хочу привести одну аналогию. В начале 20 века во многих международных журналах по физике энтузиасты охотно делились исследованиями по ядерной физике, проникая вглубь атома. А потом эти публикации резко пропали. Потому что все осознали, что кто первый научится управлять ядерной реакцией, тот получит весомый аргумент в разговорах на мировой арене. Как показывает история, так в итоге и получилось.
То же самое и с реальными кейсами по биг дате. Многие из них очень легко можно воссоздать по малейшей подсказке и они приносят слишком много пользы, чтобы о них можно было открыто говорить.
Причем в европейских банках законодательство плюс/минус похожее, правила бухучета не меняются уже много лет, поэтому коробочных решений из Австрии больше.
А у нас все-таки национальная специфика, не каждое коробочное решение оттуда нам подойдет.
Плюс согласен, логотип у нас у всех общий, это вводит в заблуждение.
Когда кто-то в Австрии видит желто-черный логотип, думают, что это одно и то же:
На самом деле, если дело происходит в Австрии, то скорее всего вы видите один из земельных банков Райффайзен, тех, с которых все начиналось. Они владеют 59% акций Raiffeisen Bank International (остальной 41% акций находится в свободном обороте и торгуется на венской бирже), который сам по себе ведет корпоративный и инвестиционный бизнес, и является в свою очередь акционером всех банков за пределами Австрии, включая российский Райффайзенбанк.