1) Да, мы знаем про ограничения использования TIMESTAMP и поэтому используем представление даты-времени в STRING, как это указано в статье. Сама проблема заключается в том, что если писать в Parquet поля TIMESTAMP с помощью Hive, а потом читать Impala, то может возникнуть серьезное замедление запроса.
Но это не наш случай, так как мы не используем Hive.
2) Мы стараемся выбирать способы использования, для которых совместимость и работоспособность гарантируется. Практически во всех СУБД и особенно MPP-СУБД есть свои ограничения и вопрос только в том, умеет ли DWH-команда находить приемлемые способы борьбы с ними. Мы — нашли. Ну и задачи DWH пока не потребовали у нас хранения сложных типов данных — мы обходимся простыми.
С точки зрения производительности отсутствие индексов не сильно влияет на нас из-за наличия runtime bloom-фильтров в Impala. Также для нас важна не производительность на единичных запросах, а в условиях их конкурентности и ad hoc + ELT нагрузки. По нашим замерам, Impala не уступает в этом профиле нагрузки классическим MPP.
OLTP-like нагрузка это немного другой профиль и он тоже может быть интересен. Тут есть несколько решений: во-первых, первичные ключи в Kudu отчасти похожи на индексы и для ряда приложений мы исследуем возможность хранения данных в Kudu; во-вторых мы ждем реализации доработок Impala, которые также должны увеличить производительность для немассовых выборок данных (https://blog.cloudera.com/blog/2017/12/faster-performance-for-selective-queries/ и issues.apache.org/jira/browse/IMPALA-3430)
3) Имелось в виду обращение Spark к данным в HDFS через схемы Hive Metastore, который использует и Impala. Impala не имеет «своих» данных (если опустить оговорку про Kudu) и является SQL-движком для параллельного выполнения на кластере.
К управлению проектами и задачами стараемся подходить гибко. Описанный функционал создавался в рамках нескольких проектов и задач, подходы к управлению применялись различные.
Задача хранилища данных не сводится к накоплению максимального их объема. Нужно еще максимизировать конкурентность и производительность пользовательских и ELT-запросов, надежность системы и при этом минимизировать стоимость владения. Также можно уточнить, что в Hadoop данные можно хранить с использованием компрессии (например, Snappy). Если имеющиеся у нас в DRP данные представить в виде CSV без компрессии, то их объем был бы около 900 Тб. Без учета этих факторов хранилища на классических MPP тоже могут показаться недостаточно большими, хотя они и будут обеспечивать хорошую производительность. На текущий момент, вы абсолютно правы, у нас действительно серьезные задел по производительности.
Платежи, отправленные в рамках продукта РЦК, поступают в банк и передаются на согласование лицу имеющему право «акцепта» в режиме онлайн.
В случае, когда акцептантом выступает не заказчик, а банк, следует обращать внимание на сроки согласования платежей по договору и условия, при которых платеж может быть согласован для корректного урегулирования спорных ситуаций.
В данном пилотном решении нет модуля, который бы позволял выгружать обученные модели в продуктивную среду (deploy) и, соответственно, встраивать в модели метрики контроля качества. Это все планируется реализовать на следующем этапе.
В большинстве случаев ФКР разрабатываются на основе экспертных суждений, и впоследствии тестируются в рамках моделей прогнозирования дефолтов. Основной инструмент (алгоритм) для моделирования – обычная логрегресссия, что позволяет получить интерпретируемые результаты. Мы в рамках пилота пробовали различные алгоритмы (случайный лес, градиентный бустинг), которые позволяют улучшить качество моделей (+несколько пунктов Джини), но при этом модель теряет в интерпретируемости.
Модель базируется на ФКР (факторах кредитного риска), которые мы (как банк) раскрывать не можем. В посте же речь скорее об инфраструктуре для эффективного построения моделей data science аналитиками, которые работают в рисках.
Потому что у корпоративных клиентов нет в явном виде признаков, которые могут быть восприняты как дискриминационные (юридическое лицо не имеет пола, национальности, цвета кожи и пр.)
На этом этапе мы пытаемся предугадать заранее – кому из клиентов можно давать кредиты, а кому – не стоит. Соответственно коллекторский отдел пока в планах.
Мы понимаем под отчетной формой витрину данных, и в нее действительно отбираются миллионы строк из огромного количества таблиц. У нас в этом проекте таких отчетных форм было 20+. В случае с решением FLEXTERA BI сложностей, которые вы описываете, не возникает. В нашей системе перед отчетными витринами встроены, так называемые, «общие агрегаторы», в которые информация собирается из детального интеграционного слоя. Изменения в этом слое могут повлиять только на доработку слоя общих агрегаторов, поэтому нет необходимости вносить изменения в каждую отчетную форму.
Вы путаете разные вещи. VPN = удалённый доступ. Тут эффект от консолидации.
Насчёт безопасности. VPN – это безопасный транспорт, а не виртуальное рабочее место.
Куда же без граблей. Так не бывает. И не интересно …. хотя на подготовку к объединению, тестирование и pre-live было потрачено очень очень много ресурсов. А вот с АБС история только начинается.
Учитывая масштаб инфраструктуры ВТБ и экс-ВТБ24, подобные проекты по консолидации занимают далеко не один год. Этот вопрос будет ключевым в рамках стратегия инфраструктуры объединённого банка.
Но это не наш случай, так как мы не используем Hive.
2) Мы стараемся выбирать способы использования, для которых совместимость и работоспособность гарантируется. Практически во всех СУБД и особенно MPP-СУБД есть свои ограничения и вопрос только в том, умеет ли DWH-команда находить приемлемые способы борьбы с ними. Мы — нашли. Ну и задачи DWH пока не потребовали у нас хранения сложных типов данных — мы обходимся простыми.
С точки зрения производительности отсутствие индексов не сильно влияет на нас из-за наличия runtime bloom-фильтров в Impala. Также для нас важна не производительность на единичных запросах, а в условиях их конкурентности и ad hoc + ELT нагрузки. По нашим замерам, Impala не уступает в этом профиле нагрузки классическим MPP.
OLTP-like нагрузка это немного другой профиль и он тоже может быть интересен. Тут есть несколько решений: во-первых, первичные ключи в Kudu отчасти похожи на индексы и для ряда приложений мы исследуем возможность хранения данных в Kudu; во-вторых мы ждем реализации доработок Impala, которые также должны увеличить производительность для немассовых выборок данных (https://blog.cloudera.com/blog/2017/12/faster-performance-for-selective-queries/ и issues.apache.org/jira/browse/IMPALA-3430)
3) Имелось в виду обращение Spark к данным в HDFS через схемы Hive Metastore, который использует и Impala. Impala не имеет «своих» данных (если опустить оговорку про Kudu) и является SQL-движком для параллельного выполнения на кластере.
В случае, когда акцептантом выступает не заказчик, а банк, следует обращать внимание на сроки согласования платежей по договору и условия, при которых платеж может быть согласован для корректного урегулирования спорных ситуаций.
Насчёт безопасности. VPN – это безопасный транспорт, а не виртуальное рабочее место.