Об’єднайте транзакційні, потокові та сторонні дані на Amazon Redshift для фінансових послуг | Веб-сервіси Amazon

Об’єднайте транзакційні, потокові та сторонні дані на Amazon Redshift для фінансових послуг | Веб-сервіси Amazon

Мітка часу: 1 лютого 2024 1:07
Вихідний вузол: 3093106

Клієнти фінансових послуг використовують дані з різних джерел, які надходять з різною частотою, зокрема набори даних у режимі реального часу, пакетні та архівні. Крім того, їм потрібні потокові архітектури, щоб справлятися зі зростаючими обсягами торгівлі, нестабільністю ринку та нормативними вимогами. Нижче наведено деякі з ключових бізнес-випадків використання, які підкреслюють цю потребу:

  • Торгова звітність – Після світової фінансової кризи 2007–2008 рр. регуляторні органи посилили свої вимоги та перевірку регуляторної звітності. Регулятори приділили підвищену увагу як захисту споживача через звітування про транзакції (зазвичай T+1, тобто 1 робочий день після дати угоди), так і підвищенню прозорості ринків через вимоги до звітності про операції майже в реальному часі.
  • Управління ризиками – Оскільки ринки капіталу стають більш складними, а регулятори запускають нові системи ризиків, наприклад Фундаментальний огляд торгової книги (FRTB) і Базель III, фінансові установи прагнуть збільшити частоту розрахунків загального ринкового ризику, ризику ліквідності, ризику контрагента та інших вимірювань ризику, і хочуть наблизитися до розрахунків у реальному часі, наскільки це можливо.
  • Якість торгівлі та оптимізація – Щоб відстежувати та оптимізувати якість торгівлі, вам потрібно постійно оцінювати такі характеристики ринку, як обсяг, напрямок, глибина ринку, рівень заповнення та інші контрольні показники, пов’язані із завершенням торгів. Якість торгівлі пов’язана не лише з роботою брокера, але й є вимогою регуляторів, починаючи з MiFID II.

Завдання полягає в тому, щоб знайти рішення, яке зможе впоратися з цими розрізненими джерелами, різними частотами та вимогами до споживання з низькою затримкою. Рішення має бути масштабованим, економічно ефективним і простим у застосуванні та експлуатації. Амазонська червона зміна такі функції, як трансляція, Амазонська Аврора інтеграція з нульовим ETLі обмін даними з Обмін даними AWS увімкнути обробку звітів про торгівлю, управління ризиками та оптимізацію торгівлі майже в реальному часі.

У цій публікації ми надаємо архітектуру рішення, яка описує, як можна обробляти дані з трьох різних типів джерел — потокові, транзакційні та сторонні довідкові дані — і агрегувати їх у звітності Amazon Redshift для бізнес-аналітики (BI).

Огляд рішення

Ця архітектура рішення створена з пріоритетом підходу з низьким кодом/без коду з такими керівними принципами:

  • Простота використання – Це має бути менш складним для впровадження та роботи з інтуїтивно зрозумілим інтерфейсом користувача
  • Масштабованість – Ви повинні мати можливість плавно збільшувати та зменшувати ємність за вимогою
  • Нативна інтеграція – Компоненти мають інтегруватися без додаткових роз’ємів чи програмного забезпечення
  • Витратоефективний – Він повинен забезпечувати збалансовану ціну/продуктивність
  • Низькі витрати – Це повинно вимагати менше управлінських та операційних витрат

На наступній діаграмі показано архітектуру рішення та те, як ці керівні принципи застосовувалися до компонентів прийому, агрегації та звітності.

Розгорніть рішення

Ви можете використовувати наступне AWS CloudFormation шаблон для розгортання рішення.

Запустіть Cloudformation Stack

Цей стек створює такі ресурси та необхідні дозволи для інтеграції служб:

Засмічення

Щоб отримати дані, ви використовуєте Amazon Redshift Streaming Ingesting щоб завантажити потокові дані з потоку даних Kinesis. Для транзакційних даних ви використовуєте Інтеграція Redshift з нульовим ETL з Amazon Aurora MySQL. Для довідкових даних третіх сторін ви можете скористатися перевагами Обмін даними AWS Data Exchange. Ці можливості дозволяють швидко створювати масштабовані конвеєри даних, оскільки ви можете збільшити ємність шардів Kinesis Data Streams, обчислювати для джерел і цілей з нульовим ETL і обчислювати Redshift для спільних даних, коли ваші дані збільшаться. Потокове введення Redshift та інтеграція з нульовим ETL – це рішення з низьким кодом/без коду, які можна створювати за допомогою простих SQL, не витрачаючи значних коштів і часу на розробку складного спеціального коду.

Для даних, які використовуються для створення цього рішення, ми співпрацюємо з Набір фактів, провідний постачальник фінансових даних, аналітики та відкритих технологій. FactSet має декілька набори даних доступний на ринку AWS Data Exchange, який ми використовували для довідкових даних. Ми також використовували FactSet рішення для ринкових даних для історичних і поточних ринкових котирувань і торгів.

Обробка

Дані обробляються в Amazon Redshift відповідно до методології вилучення, завантаження та трансформації (ELT). Завдяки практично необмеженому масштабу та ізоляції робочого навантаження ELT більше підходить для рішень хмарних сховищ даних.

Ви використовуєте потокову передачу Redshift для передачі в режимі реального часу потокових котирувань (пропозиція/пропозиція) з потоку даних Kinesis безпосередньо в потокове матеріалізоване подання та обробляєте дані на наступному кроці за допомогою PartiQL для аналізу вхідних даних потоку даних. Зауважте, що потокові матеріалізовані представлення відрізняються від звичайних матеріалізованих представлень з точки зору того, як працює автоматичне оновлення та використовуваних команд SQL для керування даними. Відноситься до Потокове передавання міркувань for details.

Ви використовуєте інтеграцію Aurora з нульовим ETL для отримання транзакційних даних (угод) із джерел OLTP. Відноситься до Робота з нульовою інтеграцією ETL для джерел, які наразі підтримуються. Ви можете поєднувати дані з усіх цих джерел за допомогою представлень і використовувати збережені процедури для впровадження правил трансформації бізнесу, як-от обчислення середньозважених значень для секторів і бірж.

Історичні обсяги даних про торгівлю та котирування величезні, і часто запити не надходять часто. Ви можете використовувати Спектр червоного зсуву Amazon щоб отримати доступ до цих даних на місці, не завантажуючи їх в Amazon Redshift. Ви створюєте зовнішні таблиці, що вказують на дані в Служба простого зберігання Amazon (Amazon S3) і надсилайте запит так само, як ви надсилаєте запит до будь-якої іншої локальної таблиці в Amazon Redshift. Кілька сховищ даних Redshift можуть одночасно запитувати ті самі набори даних в Amazon S3 без необхідності робити копії даних для кожного сховища даних. Ця функція спрощує доступ до зовнішніх даних без написання складних процесів ETL і підвищує простоту використання загального рішення.

Давайте розглянемо кілька прикладів запитів, які використовуються для аналізу котирувань і угод. У зразках запитів ми використовуємо такі таблиці:

  • dt_hist_quote – Історичні дані про котирування, що містять ціну й обсяг пропозиції, ціну й обсяг пропозиції, а також біржі та сектори. У вашій організації слід використовувати відповідні набори даних, які містять ці атрибути даних.
  • dt_hist_trades – Історичні дані про угоди, що містять дані про ціну, обсяг, сектор і біржу. У вашій організації слід використовувати відповідні набори даних, які містять ці атрибути даних.
  • factset_sector_map – Відображення між секторами та біржами. Ви можете отримати це з Набір даних FactSet Fundamentals ADX.

Зразок запиту для аналізу історичних котирувань

Ви можете використовувати наступний запит, щоб знайти середньозважені спреди котирувань:

select
date_dt :: date,
case
when exchange_name like 'Cboe%' then 'CBOE'
when (exchange_name) like 'NYSE%' then 'NYSE'
when (exchange_name) like 'New York Stock Exchange' then 'NYSE'
when (exchange_name) like 'Nasdaq%' then 'NASDAQ'
end as parent_exchange_name,
sector_name,
sum(spread * weight)/sum(weight) :: decimal (30,5) as weighted_average_spread
from
(
select date_dt,exchange_name,
factset_sector_desc sector_name,
((bid_price*bid_volume) + (ask_price*ask_volume))as weight,
((ask_price - bid_price)/ask_price) as spread
from
dt_hist_quotes a
join
fds_adx_fundamentals_db.ref_v2.factset_sector_map b
on(a.sector_code = b.factset_sector_code)
where ask_price <> 0 and bid_price <> 0
)
group by 1,2,3

Зразок запиту для аналізу історичних угод

Для пошуку можна використати наступний запит $-volume щодо угод за детальною біржею, за сектором і за основною біржею (NYSE та Nasdaq):

select
cast(date_dt as date) as date_dt,
case
when exchange_name like 'Cboe%' then 'CBOE'
when (exchange_name) like 'NYSE%' then 'NYSE'
when (exchange_name) like 'New York Stock Exchange' then 'NYSE'
when (exchange_name) like 'Nasdaq%' then 'NASDAQ'
end as parent_exchange_name,
factset_sector_desc sector_name,
sum((price * volume):: decimal(30,4)) total_transaction_amt
from
dt_hist_trades a
join
fds_adx_fundamentals_db.ref_v2.factset_sector_map b
on(a.sector_code = b.factset_sector_code)
group by 1,2,3

Звітність

Ви можете використовувати Amazon QuickSight та Grafana під керуванням Amazon для BI та звітності в реальному часі відповідно. Ці служби безпосередньо інтегруються з Amazon Redshift без необхідності використання додаткових з’єднувачів або програмного забезпечення між ними.

Ви можете запустити прямий запит із QuickSight для звітів BI та інформаційних панелей. За допомогою QuickSight ви також можете локально зберігати дані в кеші SPICE із автоматичним оновленням для низької затримки. Відноситься до Авторизація підключень від Amazon QuickSight до кластерів Amazon Redshift для детальної інформації про те, як інтегрувати QuickSight з Amazon Redshift.

Ви можете використовувати Amazon Managed Grafana для торгових інформаційних панелей майже в реальному часі, які оновлюються кожні кілька секунд. Інформаційні панелі в режимі реального часу для моніторингу затримок передавання торгівлі створюються за допомогою Grafana, а дані надходять із системних переглядів в Amazon Redshift. Відноситься до Використання джерела даних Amazon Redshift щоб дізнатися, як налаштувати Amazon Redshift як джерело даних для Grafana.

Користувачі, які взаємодіють із системами регулятивної звітності, включають аналітиків, менеджерів із ризиків, операторів та інших осіб, які підтримують бізнес і технологічні операції. Крім створення регулятивних звітів, ці команди потребують видимості стану систем звітності.

Аналіз історичних цитат

У цьому розділі ми досліджуємо деякі приклади аналізу історичних цитат з Amazon QuickSight приладова панель.

Середньозважений спред за секторами

На наступній діаграмі показано щоденне агрегування за секторами середньозважених спредів між пропозицією та пропозицією для всіх окремих угод на NASDAQ і NYSE за 3 місяці. Щоб обчислити середньоденний спред, кожен спред зважується за сумою обсягу пропозиції та пропозиції в доларах. Запит для створення цієї діаграми загалом обробляє 103 мільярди точок даних, поєднує кожну угоду з довідковою таблицею секторів і виконується менш ніж за 10 секунд.

Середньозважений спред за біржами

На наступній діаграмі показано щоденне агрегування середньозважених спредів між пропозицією та пропозицією для всіх окремих угод на NASDAQ і NYSE за 3 місяці. Методологія обчислення та показники продуктивності запитів подібні до тих, що наведені на попередній діаграмі.

Історичний аналіз торгів

У цьому розділі ми досліджуємо деякі приклади аналізу історичних угод з Amazon QuickSight приладова панель.

Обсяги торгівлі по секторах

На наступній діаграмі показано щоденне узагальнення за секторами всіх окремих угод на NASDAQ і NYSE за 3 місяці. Запит для створення цієї діаграми загалом обробляє 3.6 мільярда угод, поєднує кожну угоду з довідковою таблицею секторів і виконується менше ніж за 5 секунд.

Обсяги торгів на основних біржах

На наступній діаграмі показано щоденне агрегування за групами бірж усіх окремих угод за 3 місяці. Запит для створення цієї діаграми має такі ж показники продуктивності, як і попередня діаграма.

Інформаційні панелі в реальному часі

Моніторинг і спостережливість є важливою вимогою для будь-якого критично важливого бізнес-додатку, такого як торговельні звіти, управління ризиками та системи управління торгівлею. Окрім показників системного рівня, також важливо відстежувати ключові показники ефективності в режимі реального часу, щоб оператори могли бути попереджені та якомога швидше реагувати на події, що впливають на бізнес. Для цієї демонстрації ми створили інформаційні панелі в Grafana, які відстежують затримку котирувань і торгових даних із потоку даних Kinesis і Aurora відповідно.

Інформаційна панель затримки прийому котирувань показує час, потрібний для того, щоб кожен запис котирування був отриманий із потоку даних і став доступним для запитів в Amazon Redshift.

Інформаційна панель затримки прийому торгів показує час, потрібний для того, щоб транзакція в Aurora стала доступною в Amazon Redshift для запитів.

Прибирати

Щоб очистити свої ресурси, видаліть стек, який ви розгорнули за допомогою AWS CloudFormation. Інструкції див Видалення стека на консолі AWS CloudFormation.

Висновок

Збільшення обсягів торговельної діяльності, більш складне управління ризиками та посилені нормативні вимоги спонукають фірми на ринках капіталу використовувати обробку даних у режимі реального часу та майже в режимі реального часу, навіть на платформах у середині та бек-офісах, де обробка здійснюється в кінці дня та ввечері. був стандартом. У цій публікації ми продемонстрували, як ви можете використовувати можливості Amazon Redshift для простоти використання, низьких витрат на обслуговування та економічності. Ми також обговорили міжсервісну інтеграцію для прийому потокових ринкових даних, обробки оновлень із баз даних OLTP і використання довідкових даних сторонніх розробників без необхідності виконувати складну та дорогу обробку ETL або ELT перед тим, як зробити дані доступними для аналізу та звітності.

Зв’яжіться з нами, якщо вам потрібні вказівки щодо впровадження цього рішення. Відноситься до Аналітика в реальному часі за допомогою Amazon Redshift, Посібник із початку роботи для операційної аналітики майже в реальному часі за допомогою інтеграції Amazon Aurora zero-ETL з Amazon Redshift та Робота з обміном даними AWS Data Exchange як виробник для отримання додаткової інформації.

Про авторів

Сатеш Сонті є старшим архітектором аналітичних рішень, що працює в Атланті, і спеціалізується на розробці корпоративних платформ даних, сховищ даних і аналітичних рішень. Він має понад 18 років досвіду створення активів даних і ведення комплексних програм платформ даних для банківських і страхових клієнтів по всьому світу.

Алкет Мемушай працює головним архітектором у команді розвитку ринку фінансових послуг в AWS. Alket відповідає за технічну стратегію для ринків капіталу, співпрацює з партнерами та клієнтами для розгортання додатків упродовж життєвого циклу торгівлі в хмарі AWS, включаючи підключення до ринку, торгові системи, аналітичні та дослідницькі платформи до та після торгів.

Рубен Фальк є спеціалістом з ринків капіталу, який спеціалізується на ШІ, даних і аналітиці. Рубен консультує учасників ринків капіталу щодо сучасної архітектури даних і системних процесів інвестування. Він приєднався до AWS із S&P Global Market Intelligence, де він був глобальним керівником рішень з управління інвестиціями.

Джефф Вілсон є міжнародним спеціалістом з виходу на ринок із 15-річним досвідом роботи з аналітичними платформами. Зараз він зосереджений на тому, щоб поділитися перевагами використання Amazon Redshift, рідного хмарного сховища даних Amazon. Джефф живе у Флориді та працює в AWS з 2019 року.

Часова мітка:

Більше від Великі дані AWS