Преимущественно о данных, описывающих взаимодействие клиента и Банка. Для начала мы уложили в Hadoop данные из нашего Хранилища, чтобы аналитики могли экспериментировать со своими моделями на реальных и обновляемых данных. Плюс добавили данные с сайта, с телефонии, в ближайшей перспективе — с банкоматов (логи), и Интернет- банка и т.д.
Чуть выше писал, что Oracle BDA = Оборудование Oracle + дистрибутив Cloudera + единая поддержка ПО и оборудования от Oracle. Можно все собрать самостоятельно и так же самостоятельно решать все вопросы поддержки и модернизации кластера. По стоимости отличия небольшие на самом деле, если смотреть на одинаковый класс оборудования.
Что касается SAS, то тут вопрос стратегии. Можно растить собственную разработку и использовать Python + R и другие open source инструменты. Долго наращивать компетенцию, но получить в итоге собственное уникальное решение. Можно использовать готовые аналитические модули и быстро получать эффект от внедрения за счет переиспользования чужого опыта, в том числе. Оптимум, как обычно, где-то между этими двумя крайностями. Мы ориентируемся на SAS, но при этом не забываем про Python и R. И такой подход в нашем случае себя полностью оправдывает.
Хм… пока не планировали публиковать руководство по созданию DataLake… Но вопросы правильные!
1. Пока исходим из того, что контур разработки моделей и применения моделей разные. Здесь много причин, но в первую очередь из-за совершенно разного профиля нагрузки и разных SLA для инфраструктуры «продуктивного контура исполнения моделей» и «контура разработки моделей». Ведь модели применяются к потоку новых данных (тут и не нужен DataLake, в общем случае), а разработка ведется на исторических массивах плюс на новых источниках, использование которых может дать (или не дать) эффект. А вот тут уже DataLake нужен в полный рост.
Вполне вероятно, что на горизонте 2-3 лет мы придем к тому, что модели будут поточно обучаться на вновь поступающих данных и историческом массиве в около реальном времени и применение их в этой же среде становится уже логичным продолжением процесса. По крайней мере Digital и стремление быстрее реагировать на потребности клиента логично двигает нас к этому.
2. Используется YARN. С его помощью настраивается распределение ресурсов кластера Hadoop для конкретных процессов (групп процессов).
Мы изначально ориентировались на многопользовательскую среду, помимо YARN-а, выбирали лучшие технологии для оптимальной многопользовательской обработки данных. По результатам нагрузочных тестов наш кластер ориентирован на работу 30 конкурентных пользователей с профилем «разработчик моделей».
3. При создании DataLake предусмотрена и модель защиты данных от несанкционированного доступа. Конфиденциальные данные доступны через систему ролевого доступа, которая в том числе поддерживает RLS (row level security), ведется аудит действий пользователя, выполнена интеграция с Active Directory.
На старте мы потратили очень много времени на отладку системы доступа, которая базируется на kerberos.
Вообще вопрос безопасности – вопрос отдельного большого поста…
Вся эта «машинерия» нужна, чтобы найти баланс между интересами Банка и интересами клиента. Вряд ли самая продвинутая математика заставит человека принять невыгодное предложение, поэтому вопрос подбора варианта с максимальной вероятностью удовлетворения интересов обоих участников и есть цель всего упражнения.
Oracle BigDataAppliance это всего лишь маркетинговое название программно-аппаратного комплекса, состоящего из серверов и дистрибутива Cloudera Hadoop. Так что «если развернут хадуп» и означает «развернут OracleBigDataAppliance». А пользователи работает всеми теми инструментами, которые входят в поставку Cloudera, либо которые установлены отдельно — будь то Oracle, SAS, Python и т.д.
Что касается SAS, то тут вопрос стратегии. Можно растить собственную разработку и использовать Python + R и другие open source инструменты. Долго наращивать компетенцию, но получить в итоге собственное уникальное решение. Можно использовать готовые аналитические модули и быстро получать эффект от внедрения за счет переиспользования чужого опыта, в том числе. Оптимум, как обычно, где-то между этими двумя крайностями. Мы ориентируемся на SAS, но при этом не забываем про Python и R. И такой подход в нашем случае себя полностью оправдывает.
1. Пока исходим из того, что контур разработки моделей и применения моделей разные. Здесь много причин, но в первую очередь из-за совершенно разного профиля нагрузки и разных SLA для инфраструктуры «продуктивного контура исполнения моделей» и «контура разработки моделей». Ведь модели применяются к потоку новых данных (тут и не нужен DataLake, в общем случае), а разработка ведется на исторических массивах плюс на новых источниках, использование которых может дать (или не дать) эффект. А вот тут уже DataLake нужен в полный рост.
Вполне вероятно, что на горизонте 2-3 лет мы придем к тому, что модели будут поточно обучаться на вновь поступающих данных и историческом массиве в около реальном времени и применение их в этой же среде становится уже логичным продолжением процесса. По крайней мере Digital и стремление быстрее реагировать на потребности клиента логично двигает нас к этому.
2. Используется YARN. С его помощью настраивается распределение ресурсов кластера Hadoop для конкретных процессов (групп процессов).
Мы изначально ориентировались на многопользовательскую среду, помимо YARN-а, выбирали лучшие технологии для оптимальной многопользовательской обработки данных. По результатам нагрузочных тестов наш кластер ориентирован на работу 30 конкурентных пользователей с профилем «разработчик моделей».
3. При создании DataLake предусмотрена и модель защиты данных от несанкционированного доступа. Конфиденциальные данные доступны через систему ролевого доступа, которая в том числе поддерживает RLS (row level security), ведется аудит действий пользователя, выполнена интеграция с Active Directory.
На старте мы потратили очень много времени на отладку системы доступа, которая базируется на kerberos.
Вообще вопрос безопасности – вопрос отдельного большого поста…