Обсуждение хранилищ данных для индустрии финансовых услуг с Винсентом Райнарди

С запуском Astera Построитель хранилища данных Совсем скоро мы побеседуем с некоторыми из ведущих мыслителей отрасли, чтобы узнать их взгляд на отрасль в ее нынешнем состоянии, на то, как она развивается и где, по их мнению, автоматизация хранилищ данных вписывается в более широкую картину.

Для нашего второго интервью из этой серии мы встретились с Винсентом Райнарди, давним ветераном в области хранилищ данных. Он работал над проектами для таких клиентов, как Barclays, Lloyds Bank, Toyota и Avery Dennison. Винсент также много писал о хранилищах данных и бизнес-аналитике, написав книгу Создание хранилища данных: с примерами на SQL Server и популярный Блог на эту тему.

В этом обсуждении мы подробно изучили разнообразный опыт и идеи Винсента в области хранилищ данных, уделив особое внимание отрасли финансовых услуг, где за годы работы он накопил значительный опыт.

Не могли бы вы рассказать мне немного о своем участии в хранении данных? Когда вы впервые начали работать над этими проектами и какую роль вы играли в процессе разработки на протяжении многих лет?

Я начал работать в сфере хранилищ данных в 1996 году, создавая хранилище данных и BI для производителя автомобилей. В то время DW & BI называлась DSS и EIS/MIS (система поддержки принятия решений и информационная система для руководителей/управления). Затем я покинул DW/BI на несколько лет, но снова оказался в этой сфере в 2005 году, когда прочитал книгу Ральфа Кимбалла о хранилищах данных. (Data Warehouse Toolkit) и очень увлекся этим. После этого я написал множество статей на эту тему для различных сайтов и своего блога. В 2007 году я опубликовал книгу, в которой изложил многие мои идеи по хранению данных.

С 2005 года я работал над несколькими проектами по хранению данных, разрабатывая хранилища данных для банков, управляющих активами, страховщиков, производителей, поставщиков медицинских услуг, розничных продавцов и компаний электронной коммерции. Во время реализации мои основные обязанности — архитектор хранилища данных, т. е. проектирование архитектуры потока данных, моделей данных и физических платформ, включая SQL Server, Oracle, Teradata, Hadoop, Azure.

Я также работал на различных других должностях, в том числе в качестве бизнес-аналитика (бизнес-требования, функциональные спецификации), BI-дизайнера (определение информационных панелей и визуализаций), BI-разработчика (работа с такими платформами, как QlikView, Spotfire, Tableau, SSRS, SSAS). , ProClarity, Business Objects, Strategy Companion), разработчик ETL (SSIS, Informatica, утилиты Teradata, SQL), тестировщик и менеджер проектов.

Ранее вы немного говорили о различиях между хранилищами данных и BI – как, по вашему мнению, эти две концепции дополняют друг друга, а в чем они принципиально различаются?

На практике они взаимозаменяемы, но на самом деле они разные. BI — это интерфейс (панели мониторинга, отчеты, визуализации), а хранилище данных — это серверная часть (база данных, хранилище, ETL, файлы). Однако они дополняют друг друга и на практике используются вместе. Сегодня серверная часть не обязательно должна быть хранилищем данных; это может быть озеро данных. И интерфейсная часть не обязательно должна быть BI; это может быть машинное обучение.

У вас богатый опыт работы в сфере финансовых услуг. Какие, по вашему мнению, наиболее распространенные варианты использования вы видите в организациях из таких отраслей, как страхование или инвестиционно-банковская деятельность?

Варианты использования в страховании включают в себя множество сложных анализов. Поэтому, как правило, организации стремятся ответить на вопросы о типах заработанных валовых премий более высокого уровня, письменных премий, покрытии рисков, стоимости риска, корректировках претензий, сроках претензий, каналах продаж, прибыльности клиентов, андеррайтинге, актуарных ставках, рисках перестрахования, и денежный поток.

В инвестиционно-банковской сфере этот анализ будет охватывать рыночные риски, подверженность позициям, торговую деятельность, нормативную отчетность, исследования рынка, ликвидность, обеспечение, конвейеры сделок, клиентские счета, борьбу с отмыванием денег, контрагентов, обнаружение мошенничества, управление портфелем и стресс-тестирование капитала. .

За последнее десятилетие мы стали свидетелями значительного увеличения объема и разнообразия данных, проходящих через предприятия. Как, по вашему мнению, так называемое традиционное хранилище данных будет развиваться для удовлетворения этих требований?

Таким образом, традиционные хранилища данных эволюционировали, включив в себя озера данных и технологии больших данных. Неструктурированные данные хранятся в озерах данных, включая документы, изображения, видео, Интернет вещей и каналы социальных сетей, а структурированные данные (данные, хранящиеся в табличном формате) хранятся в хранилище данных. Озера данных обычно создаются на базе файловой системы Hadoop, а не хранилища данных, которые обычно строятся на основе реляционных баз данных. Современные хранилища данных также включают NoSQL, например базы данных графиков и документов, поскольку некоторые данные больше подходят для этих типов форматов. Это немного покрывает разнообразие.

Что касается объема, то в первые годы существования хранилищ данных базы данных MPP, такие как Teradata, Oracle Exadata и Microsoft PDW, были популярным способом обработки больших объемов данных, сохраняя при этом реляционность данных. Но в настоящее время технологии больших данных используются гораздо шире.

Что вы думаете об озере данных? Есть ли ему место в современной BI-системе? Дополняет ли оно хранилище данных или является жизнеспособной альтернативой?

Да, это так. Современные хранилища данных используют озера данных в качестве промежуточной области, которая позволяет пользователям и внешним технологиям машинного обучения получать доступ к необработанным данным. Если вы не хотите интегрировать данные, озеро данных является жизнеспособной альтернативой. Этот тип использования часто встречается в проектах, где данные разрознены (отделены от других функций) и время разработки минимально, и в этом случае озера данных очень эффективны. Хорошими примерами могут служить проект по обнаружению мошенничества на основе машинного обучения в банке или проект, в котором в течение трех месяцев необходимо выполнить определенные требования к нормативной отчетности. Когда эти разрозненные элементы будут впоследствии удалены (т. е. когда другим функциям предприятия потребуется доступ к результатам прогнозирования), выходные данные модели можно будет сохранить в хранилище данных для последующих пользователей.

Однако в большинстве корпоративных сценариев вам потребуется интегрировать данные. Например, страховщику или управляющему активами потребуется создать единый взгляд на основе данных о ценных бумагах, эмитентах, политиках и клиентах, чтобы составить точную картину своего предприятия.

Раньше вы говорили, что понимание бизнеса может быть наиболее важной частью разработки хранилища данных. Как бы вы обеспечили точное отражение бизнес-требований в архитектуре данных?

Да, понимание бизнеса очень важно. Вы не сможете разработать хорошую модель данных без хорошего понимания бизнеса. Представьте себе, что вам поручили разработать хранилище данных ESG (экологической, социальной и управленческой сферы), но вы понятия не имели, что такое ESG. Или киоск данных по андеррайтингу, но вы никогда не работали в сфере страхования. Вы не можете знать, как должны выглядеть таблицы фактов и измерений. Хороший архитектор данных должен быть заинтересован в мельчайших деталях бизнеса. Допустим, вы разрабатываете систему атрибуции эффективности для инвестиционного менеджера. Очень важно, чтобы вы узнали о разнице между арифметической и геометрической доходностью, кривыми доходности и факторами взаимодействия. К сожалению, некоторые архитекторы данных не интересуются этими важными деталями бизнеса. Их больше интересуют технические моменты.

Лучший способ убедиться, что бизнес-требования хорошо включены в модель данных, — запустить различные бизнес-сценарии и проверить, может ли каждый сценарий быть удовлетворен, путем запроса модели данных с помощью простого запроса SQL. Если для этого вам нужен сложный запрос, модель данных спроектирована недостаточно хорошо. Обычно это крах озера данных; они не удовлетворяют сложным бизнес-сценариям. И в этом вся суть: хорошо написать эти сценарии; вам нужно хорошо разбираться в бизнесе.

В более раннем сообщении в блоге вы писали о том, сколько организаций финансовых услуг до сих пор используют Excel для создания отчетов и анализа. Видите ли вы, что эта практика изменится, когда более сложные инструменты визуализации станут обычным явлением, или мы продолжим наблюдать этот процесс в обозримом будущем?

Компании, предоставляющие финансовые услуги, продолжат использовать Excel для анализа и отчетности. Это человеческая природа, поскольку сотрудники в этой области, как правило, обладают хорошими навыками работы с Excel. Я испытал это предпочтение на собственном опыте в различных банках и инвестиционных компаниях. Даже организации, использующие такие платформы, как Tableau, Qlik или Power BI, просили предоставить возможность «экспорта в Excel» для дальнейшего анализа.

Хотя стандартные отчеты и информационные панели, создаваемые средствами визуализации, важны (они содержат формализованные данные в легко усваиваемом формате), во многих случаях пользователям необходимо выполнять собственный анализ. Для этого они запрашивают необработанные данные для этих информационных панелей в инструменте, с которым они гораздо более знакомы — Excel. Имея под рукой необработанные данные, они могут по-разному группировать данные, применять определенные фильтры и т. д. — все в соответствии со своими потребностями.

Помните, что это финансовые аналитики, разбирающиеся в цифрах, умные люди. Они анализируют данные и обрабатывают цифры. Использование статических отчетов никогда не удовлетворит их все потребности, поэтому, как правило, не рекомендуется пытаться удовлетворить все возможные потребности в инструменте BI.

В последние годы наблюдается большой толчок к перемещению хранилищ данных в облако на таких платформах, как Google BigQuery или Amazon Redshift. Что вы думаете о преимуществах развертывания в облаке? Рекомендуете ли вы в некоторых случаях придерживаться локальных баз данных?

Основными преимуществами являются аутсорсинг человеческих ресурсов и гибкость вычислительных ресурсов. Благодаря облачному хранилищу данных вам не нужно платить множеству сотрудников за обслуживание серверов, хранилища, сети, безопасности, резервного копирования и процессов аварийного восстановления. Если вам нужен новый сервер базы данных, вам не придется ждать три недели, чтобы приобрести, настроить, установить, подключить хранилище и т. д. Вместо этого вы получаете увеличенную мощность сервера по требованию и платите почасово.

Это ценностное предложение интересно не только небольшим компаниям, но и крупным корпорациям, которые часто задаются вопросом: «На каком бизнесе мне следует сосредоточиться?» Независимо от того, являетесь ли вы розничным торговцем, телекоммуникационной или финансовой компанией, ответ определенно не будет «серверным бизнесом» или «бизнесом ИТ-инфраструктуры». Итак, вы передаете на аутсорсинг. Благодаря облачной инфраструктуре вы можете увеличивать и уменьшать вычислительную мощность и объем памяти по мере необходимости. Вы отключаете серверы тестирования и разработки, когда они не используются в ночное время, и платите почасово.

Когда дело доходит до мощных серверов хранилища данных, стоимость установки их собственными силами (локально) непомерно высока. Требуемые навыки сотрудников также непомерно высоки, поскольку требуется множество различных специальных навыков, от SAN до безопасности, от Docker до Yarn. Поэтому я бы рекомендовал развертывание в облаке, а не в локальном хранилище данных. Это аргумент в пользу использования Google BigQuery, Amazon Redshift и выделенного пула SQL Azure (ранее SQL DW, PDW, APS).

Однако предположим, что это не новый проект, и вам необходимо улучшить существующее локальное хранилище данных с множеством подключенных к нему локальных систем. В этом случае стоимость миграции всех этих систем/приложений в облако будет огромной. Допустим, в качестве аргумента, что завершение такого рода проекта будет стоить дополнительно 2 миллиона долларов и три года. Нет смысла тратить эти 2 миллиона долларов на отсутствие дополнительных бизнес-функций. Держите его локально, вносите улучшения локально, а тем временем постепенно создавайте новую систему в облаке. В настоящее время примерно 25% ИТ-бюджетов идут на поддержание существующих систем и инфраструктуры. Это пул, который вам следует использовать для медленной миграции в облако.

Я уже видел, как вы затронули большую дискуссию об ETL и ELT. Когда дело доходит до загрузки данных в хранилище данных, какой подход вы предпочитаете? Или это нужно решать индивидуально в каждом конкретном случае?

Это необходимо решать в каждом конкретном случае. Это зависит от инфраструктуры. Это зависит от озера данных. Это зависит от инструмента приема данных. И это зависит от платформы хранилища данных. В конечном счете, не имеет значения, используете ли вы ETL, ELT или ELTLT; вы можете осуществлять прием данных различными способами. Вы можете поставить его один, два раза или ни разу. Преобразуйте его один, два или ни разу. Вам просто нужно выбрать наиболее подходящий подход для каждого конвейера и каждой ситуации.

Будь то ETL или ELT, обязательным условием при приеме данных является автоматическое тестирование. Нимрод Ависар это хорошо объясняет. здесь. Это подход, который я предпочитаю в ETL/ELT: подход к автоматизированному тестированию.

Что касается самого процесса разработки хранилища данных, считаете ли вы, что гибкая или каскадная технология лучше соответствует постоянно меняющимся требованиям BI?

Речь идет не об Agile или водопаде (Agile, конечно, кто хочет сделать большой кусок за один раз?). Процесс разработки хранилища данных представляет собой операции разработки. Эта инженерная дисциплина сейчас достигла зрелости. Вам необходим конвейер релизов, доска спринтов, журнал невыполненных работ, контроль версий, контроль изменений, регистрация ошибок и управление инцидентами. Команда разработчиков хранилища данных должна иметь автоматизацию DevOps, т. е. процесс выпуска должен быть автоматизирован: от системы управления версиями, запроса на включение в ветку выпуска, развертывания в тест, запуска автоматического тестирования и развертывания в производство.

Раньше CI/CD ассоциировалась с разработкой приложений, а не с разработкой хранилищ данных. Но сейчас это необходимость. Если вы управляете командой разработчиков хранилища данных без него, вы каждый месяц несете множество дополнительных расходов. Или, что еще хуже, пожертвовать качеством сборки хранилища данных.

В своем блоге вы написали о некоторых ключевых элементах, которые определяют эффективность вашего хранилища данных, включая доступность данных, безопасность данных, качество данных и, конечно же, производительность запросов/загрузок. Какой фактор, по вашему мнению, является наиболее важным?

Наиболее важным элементом, определяющим эффективность хранилища данных, является то, решает ли оно бизнес-задачи и варианты использования. В конце концов, вы можете использовать свое хранилище данных для создания отчетов для клиентов, информационных панелей управления, нормативных отчетов или общего бизнес-анализа. Тем не менее, если он не может решить вашу бизнес-проблему, то он просто не эффективен. В этом случае неудачу обычно можно связать с одной из трех причин:

1. Отсутствие конкретных данных, например, данных о важном продукте или клиенте,
2. Проблемы с качеством данных, например, неверные данные,
3. Сложность запроса данных, например, данные находятся в хранилище, но не отображаются в отчетах.

Я бы сказал, что неправильные данные особенно вредны для бизнеса, особенно когда они предприняли действия на основе этих данных. Например, если вы использовали данные о производительности склада для создания информационного бюллетеня и исказили результаты деятельности фонда, это представляет собой как репутационный риск, так и огромный финансовый риск. Это может не только привести к существенному штрафу со стороны финансовых властей, но и ваши клиенты могут отправиться к выходу на основании приведенных вами вводящих в заблуждение цифр, что приведет к массовому оттоку капитала и общему мрачному будущему бизнеса.

Для сравнения: если часовой запрос выполнялся целый день, это пустяки, почти никакого финансового ущерба. То же самое и с отсутствием конкретных данных (доступностью данных), это не такой большой риск по сравнению с публикацией/отправкой неверных данных властям или клиентам. С другой стороны, если данные ваших клиентов будут украдены, это также может подорвать доверие клиентов, вызвав их отток, что может оставить вас без бизнеса в обозримом будущем.

Я бы сказал, что качество данных и безопасность данных — это две основные проблемы, от которых вам нужно защищаться.

Вы также обсудили некоторые важные этапы построения хранилища данных, т. е. моделирование данных, создание процессов загрузки и доставки данных, а затем разработку архитектуры этих процессов для обеспечения максимальной эффективности. Что, по вашему мнению, является наиболее сложной частью разработки хранилища данных?

Самая сложная часть разработки хранилища данных — это не моделирование данных, загрузка данных или эффективность процессов, а определение того, что архитектура самый подходящий.

Если вы решили построить озеро данных, а на самом деле вам нужно многомерное хранилище данных (из-за его интегрированной природы), то вы с самого начала шли в неправильном направлении. Если вы решили использовать определенную технологию приема данных, которой ни один из ваших сотрудников не обладал навыками работы, вы сделали значительные инвестиции, которые увеличили ваш риск и создали предотвратимые задержки в реализации. Если вы решили купить заранее спроектированное хранилище данных, но модель данных вас не устраивала, это было похоже на строительство небоскреба на слабом фундаменте.

 Чего мы не видим за кулисами, так это того, что обычно обеспечивает успех склада, то есть выбора архитектуры, операций по разработке и Качество данных проверки.

Где, по вашему мнению, здесь можно использовать автоматизацию хранилища данных? Как это может помочь сократить усилия и время, затрачиваемые на некоторые из этих задач? В чем вы видите большую ценность специализированного инструмента?

Ценность автоматизации хранилища данных заключается в автоматической загрузке. Например, многие компании по управлению активами используют широко используемые готовые системы управления инвестициями для управления своими портфелями. Хранилище многомерных данных, которое может автоматически загружать из них данные, имеет большую ценность. Многие крупные производственные компании используют SAP в качестве основной операционной системы. Хранилище данных, которое может автоматически загружать данные из SAP, ценно тем, что вам не нужно разрабатывать конвейеры для загрузки данных, что занимает много времени. В любом случае вы должны иметь возможность изменять размерную модель по своему усмотрению.

Следующий лучший вариант — попытаться автоматизировать прием данных. Интеграция нескольких источников данных в одно измерение является сложной задачей (например, измерение клиента, измерение компании, измерение безопасности), а автоматизировать ее еще сложнее. Мы можем иметь дело с вертикальными файлами или инкрементными файлами, файлами CSV или Excel. Нам нужна возможность поворачивать, агрегировать и объединять эти данные.

Кроме того, мы не должны предполагать, что источником данных является файл, готовый к обработке; возможно, его сначала потребуется расшифровать, разархивировать, переименовать или загрузить. В основе интеграции данных из нескольких источников лежит процесс, называемый «сопоставлением данных», который может представлять собой каскадное сопоставление по нескольким критериям. Второй основной процесс называется «обогащением данных», например, если ценная бумага не имеет рейтинга S&P, страны риска или сектора GICS, то мы пополняем ее из внешнего источника, такого как Bloomberg или FactSet.

Основная ценность хранилища данных — это интегрированное измерение, которое создается из многих источников. Инструмент автоматизации хранилища данных должен иметь возможность создавать это измерение, но не измерение страны или валюты, а измерение клиента или безопасности, состоящее из нескольких исходных таблиц.

Какие функции и возможности, по вашему мнению, абсолютно необходимы для эффективного инструмента автоматизации хранилища данных?

Функциональные возможности, которые абсолютно необходимы для эффективного инструмента автоматизации хранилища данных:

1. Он должен быть в курсе ERP, CRM или IMS (например, SAP, Salesforce или ThinkFolio) по мере их изменения версий.
2. Он должен иметь возможность интегрировать несколько источников для создания сложных измерений, т. е. измерения клиента.
3. Он должен иметь возможность предварительной обработки файлов данных, например, для извлечения или загрузки файлов для обработки.
4. Он должен позволять автоматическое тестирование и развертывание.

Наконец, каким вы видите будущее хранилища данных? Какие значительные достижения (если таковые имеются) вы предвидите в этой области?

Некоторые люди думают, что они могут заменить два года разработки хранилища данных трехмесячной разработкой озера данных. Это обман, поскольку данные о клиентах или продуктах, загружаемые в последнюю архитектуру, не интегрированы, поэтому их нельзя запрашивать. И они могут забыть включить в систему проверки качества данных или эксплуатационной готовности (например, инструменты мониторинга), что в противном случае заняло бы 30% всех усилий. Конечно, некоторые проекты не нуждаются в интеграции, и в этом случае можно использовать озеро данных, но проверки качества данных и эксплуатационной готовности все равно нужно выстроить.

В будущем я вижу автоматизацию тестирования и автоматизацию проверок качества данных. Не так уж сложно создать инструмент, который отслеживает каждый входящий файл и проверяет указанные столбцы, сравнивая их с данными за последние несколько дней. Другая вещь, которую можно было бы создать, — это инструмент бизнес-аналитики, дружественный к CI/CD, например, основанный на XML, поэтому его можно автоматически развертывать из системы управления версиями в производство, поскольку он основан на тексте.

И, наконец, до сих пор на рынке не существует единого инструмента управления данными, который мог бы сканировать базы данных, ETL и инструменты BI и автоматически создавать происхождение данных из исходных файлов в отчет. Возможно, невозможно создать этот инструмент для каждой отдельной базы данных, ETL и BI-инструмента, но основные из них можно создать. Ключом к управлению данными является автоматизация.

Astera DW Builder — гибкий ответ на ваши проблемы разработки хранилищ данных

Astera DW Builder — это унифицированная платформа, которая позволяет быстро развертывать и использовать модели данных, обогащенные метаданными, в соответствии с требованиями конечных пользователей.

Продукт предоставляет ряд готовых функций, которые вы можете использовать для создания гибкого хранилища данных, которое действительно отвечает потребностям вашего бизнеса. От реализации бизнес-правил и соглашений об именах на логическом уровне до создания сложных конвейеров данных, которые могут автоматически извлекать данные из выбранных вами исходных систем, преобразовывать их в соответствии с вашими требованиями к качеству данных и загружать их в облако или локальную базу данных по вашему выбору. , все это стало возможным благодаря нашему решению без кода.

Теперь мы даем вам возможность получить эксклюзивный первый взгляд на скорость и интуитивность ADWB на комплексном мероприятии, посвященном запуску, которое обещает изменить ваше представление о хранилищах данных. Смотри эксклюзивное мероприятие по запуску здесь.