Опанування ринкової динаміки: трансформація аналізу транзакційних витрат за допомогою надточної історії тиків – PCAP і Amazon Athena для Apache Spark | Веб-сервіси Amazon

Опанування ринкової динаміки: трансформація аналізу транзакційних витрат за допомогою надточної історії тиків – PCAP і Amazon Athena для Apache Spark | Веб-сервіси Amazon

Мітка часу: 31 січня 2024 р. 12:20
Вихідний вузол: 3091357

Цей допис написано спільно з Прамодом Наяком, ЛакшміКантхом Маннемом і Вівеком Аггарвалом із групи низької затримки LSEG.

Аналіз транзакційних витрат (TCA) широко використовується трейдерами, портфельними менеджерами та брокерами для попереднього та постторгового аналізу та допомагає їм вимірювати й оптимізувати транзакційні витрати та ефективність їхніх торгових стратегій. У цьому дописі ми проаналізуємо спред опціонів між цінами та цінами Історія тиків LSEG – PCAP використання набору даних Amazon Athena для Apache Spark. Ми покажемо вам, як отримати доступ до даних, визначити спеціальні функції для застосування до даних, запитувати та фільтрувати набір даних, а також візуалізувати результати аналізу, і все це без необхідності турбуватися про налаштування інфраструктури чи налаштування Spark, навіть для великих наборів даних.

фон

Options Price Reporting Authority (OPRA) виконує функції важливого процесора інформації про цінні папери, збираючи, об’єднуючи та розповсюджуючи звіти про останні продажі, котирування та відповідну інформацію для опціонів США. Завдяки 18 активним біржам опціонів США та понад 1.5 мільйонам відповідних контрактів OPRA відіграє ключову роль у наданні вичерпних ринкових даних.

5 лютого 2024 року Securities Industry Automation Corporation (SIAC) збирається оновити канал OPRA з 48 до 96 багатоадресних каналів. Це вдосконалення спрямоване на оптимізацію розподілу символів і використання ємності лінії у відповідь на ескалацію торгової активності та нестабільність на ринку опціонів США. SIAC рекомендував компаніям підготуватися до пікових швидкостей передачі даних до 37.3 ГБіт на секунду.

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

OPRA виділяється як одна з найоб’ємніших інформаційних версій з піком у 150.4 мільярда повідомлень за один день у 3 кварталі 2023 року та вимогою до 400 мільярдів повідомлень за один день. Отримання кожного окремого повідомлення має вирішальне значення для аналізу транзакційних витрат, моніторингу ліквідності ринку, оцінки торгової стратегії та дослідження ринку.

Про дані

Історія тиків LSEG – PCAP це хмарне сховище, що перевищує 30 ПБ, у якому зберігаються надвисокоякісні глобальні ринкові дані. Ці дані ретельно збираються безпосередньо в центрах обробки даних обміну з використанням резервних процесів збору даних, стратегічно розташованих у основних основних і резервних центрах обробки даних обміну по всьому світу. Технологія захоплення LSEG забезпечує захоплення даних без втрат і використовує джерело часу GPS для наносекундної точності позначки часу. Крім того, використовуються складні методи арбітражу даних, щоб безперешкодно заповнити будь-які прогалини в даних. Після збору дані проходять ретельну обробку та арбітраж, а потім нормалізуються у форматі Parquet за допомогою Ультрапрямий режим реального часу LSEG (RTUD) обробники кормів.

Процес нормалізації, який є невід’ємною частиною підготовки даних для аналізу, генерує до 6 ТБ стиснутих файлів Parquet на день. Величезний обсяг даних пояснюється всеосяжною природою OPRA, яка охоплює кілька бірж і містить численні опціонні контракти, що характеризуються різними атрибутами. Підвищена волатильність ринку та активність створення ринку на опціонних біржах ще більше сприяють об’єму даних, опублікованих на OPRA.

Атрибути Tick History – PCAP дозволяють компаніям проводити різні аналізи, зокрема:

  • Передторговий аналіз – Оцініть потенційний вплив на торгівлю та вивчіть різні стратегії виконання на основі історичних даних
  • Постторгова оцінка – Вимірюйте фактичні витрати на виконання порівняно з контрольними показниками для оцінки ефективності стратегій виконання
  • Оптимізований виконання – Точне налаштування стратегій виконання на основі історичних моделей ринку, щоб мінімізувати вплив на ринок і зменшити загальні витрати на торгівлю
  • Управління ризиками – Визначайте моделі прослизання, визначайте викиди та проактивно керуйте ризиками, пов’язаними з торговою діяльністю
  • Атрибуція продуктивності – Відокремлюйте вплив торгових рішень від інвестиційних рішень під час аналізу продуктивності портфеля

Набір даних LSEG Tick History – PCAP доступний у Обмін даними AWS і доступний на Торговий майданчик AWS. З Обмін даними AWS для Amazon S3, ви можете отримати доступ до даних PCAP безпосередньо з LSEG Служба простого зберігання Amazon (Amazon S3), що позбавляє фірм від необхідності зберігати власні копії даних. Цей підхід оптимізує керування та зберігання даних, надаючи клієнтам миттєвий доступ до високоякісного PCAP або нормалізованих даних із простотою використання, інтеграції та істотна економія при зберіганні даних.

Афіна для Apache Spark

Для аналітичних зусиль, Афіна для Apache Spark пропонує спрощену роботу ноутбука, доступну через консоль Athena або API Athena, що дозволяє створювати інтерактивні програми Apache Spark. Завдяки оптимізованому часу виконання Spark Athena допомагає аналізувати петабайти даних шляхом динамічного масштабування кількості механізмів Spark менш ніж за секунду. Крім того, загальні бібліотеки Python, такі як pandas і NumPy, легко інтегровані, що дозволяє створювати складну логіку додатків. Гнучкість поширюється на імпорт користувальницьких бібліотек для використання в блокнотах. Athena для Spark підтримує більшість відкритих форматів даних і повністю інтегрована з Клей AWS Каталог даних.

Набір даних

Для цього аналізу ми використали набір даних LSEG Tick History – PCAP OPRA від 17 травня 2023 року. Цей набір даних містить такі компоненти:

  • Найкраща ставка та пропозиція (BBO) – Повідомляє про найвищу ставку та найнижчий запит на цінний папір на певній біржі
  • Національна найкраща ставка та пропозиція (NBBO) – Повідомляє про найвищу ставку та найнижчий запит на цінний папір на всіх біржах
  • Торги – Записує завершені операції на всіх біржах

Набір даних містить такі обсяги даних:

  • Торги – 160 МБ, розподілених між приблизно 60 стисненими файлами Parquet
  • ВВО – 2.4 ТБ, розподілених між приблизно 300 стисненими файлами Parquet
  • НББО – 2.8 ТБ, розподілених між приблизно 200 стисненими файлами Parquet

Огляд аналізу

Аналіз даних OPRA Tick History для Transaction Cost Analysis (TCA) передбачає ретельний аналіз ринкових котирувань і торгів навколо конкретної торгової події. У рамках цього дослідження ми використовуємо такі показники:

  • Котирований спред (QS) – Розраховується як різниця між запитом BBO та пропозицією BBO
  • Ефективний спред (ES) – Розраховується як різниця між торговою ціною та серединою BBO (BBO bid + (BBO ask – BBO bid)/2)
  • Ефективний/котирований спред (EQF) – Розраховується як (ES / QS) * 100

Ми обчислюємо ці спреди до угоди та додатково через чотири інтервали після угоди (відразу після, 1 секунду, 10 секунд і 60 секунд після угоди).

Налаштуйте Athena для Apache Spark

Щоб налаштувати Athena для Apache Spark, виконайте такі дії:

  1. На консолі Athena, під ПОЧАТИвиберіть Аналізуйте свої дані за допомогою PySpark і Spark SQL.
  2. Якщо ви вперше використовуєте Athena Spark, виберіть Створити робочу групу.
  3. для Назва робочої групи¸ введіть назву для робочої групи, наприклад tca-analysis.
  4. У Двигун аналітики розділ, виберіть Apache Spark.
  5. У Додаткові конфігурації розділ, ви можете вибрати Використовуйте параметри за замовчуванням або надати звичай Управління ідентифікацією та доступом AWS (IAM) і розташування Amazon S3 для результатів обчислень.
  6. Вибирати Створити робочу групу.
  7. Після створення робочої групи перейдіть до Ноутбуки та виберіть Створити блокнот.
  8. Введіть назву свого блокнота, наприклад tca-analysis-with-tick-history.
  9. Вибирати Створювати щоб створити свій блокнот.

Запустіть блокнот

Виберіть, якщо ви вже створили робочу групу Spark Запустіть редактор блокнота при ПОЧАТИ.


Після створення блокнота ви будете перенаправлені до інтерактивного редактора блокнотів.


Тепер ми можемо додати та запустити наступний код до нашого блокнота.

Створіть аналіз

Щоб створити аналіз, виконайте такі кроки:

  • Імпорт загальних бібліотек:
import pandas as pd
import plotly.express as px
import plotly.graph_objects as go

  • Створіть наші кадри даних для BBO, NBBO та угод:
bbo_quote = spark.read.parquet(f"s3://<bucket>/mt=bbo_quote/f=opra/dt=2023-05-17/*")
bbo_quote.createOrReplaceTempView("bbo_quote")
nbbo_quote = spark.read.parquet(f"s3://<bucket>/mt=nbbo_quote/f=opra/dt=2023-05-17/*")
nbbo_quote.createOrReplaceTempView("nbbo_quote")
trades = spark.read.parquet(f"s3://<bucket>/mt=trade/f=opra/dt=2023-05-17/29_1.parquet")
trades.createOrReplaceTempView("trades")

  • Тепер ми можемо визначити угоду для аналізу транзакційних витрат:
filtered_trades = spark.sql("select Product, Price,Quantity, ReceiptTimestamp, MarketParticipant from trades")

Ми отримуємо наступний результат:

+---------------------+---------------------+---------------------+-------------------+-----------------+ 
|Product |Price |Quantity |ReceiptTimestamp |MarketParticipant| 
+---------------------+---------------------+---------------------+-------------------+-----------------+ 
|QQQ 230518C00329000|1.1700000000000000000|10.0000000000000000000|1684338565538021907,NYSEArca|
|QQQ 230518C00329000|1.1700000000000000000|20.0000000000000000000|1684338576071397557,NASDAQOMXPHLX|
|QQQ 230518C00329000|1.1600000000000000000|1.0000000000000000000|1684338579104713924,ISE|
|QQQ 230518C00329000|1.1400000000000000000|1.0000000000000000000|1684338580263307057,NASDAQOMXBX_Options|
|QQQ 230518C00329000|1.1200000000000000000|1.0000000000000000000|1684338581025332599,ISE|
+---------------------+---------------------+---------------------+-------------------+-----------------+

Ми використовуємо виділену торгову інформацію надалі для торгового продукту (tp), торгової ціни (tpr) і часу торгівлі (tt).

  • Тут ми створюємо ряд допоміжних функцій для нашого аналізу
def calculate_es_qs_eqf(df, trade_price):
    df['BidPrice'] = df['BidPrice'].astype('double')
    df['AskPrice'] = df['AskPrice'].astype('double')
    df["ES"] = ((df["AskPrice"]-df["BidPrice"])/2) - trade_price
    df["QS"] = df["AskPrice"]-df["BidPrice"]
    df["EQF"] = (df["ES"]/df["QS"])*100
    return df

def get_trade_before_n_seconds(trade_time, df, seconds=0, groupby_col = None):
    nseconds=seconds*1000000000
    nseconds += trade_time
    ret_df = df[df['ReceiptTimestamp'] < nseconds].groupby(groupby_col).last()
    ret_df['BidPrice'] = ret_df['BidPrice'].astype('double')
    ret_df['AskPrice'] = ret_df['AskPrice'].astype('double')
    ret_df = ret_df.reset_index()
    return ret_df

def get_trade_after_n_seconds(trade_time, df, seconds=0, groupby_col = None):
    nseconds=seconds*1000000000
    nseconds += trade_time
    ret_df = df[df['ReceiptTimestamp'] > nseconds].groupby(groupby_col).first()
    ret_df['BidPrice'] = ret_df['BidPrice'].astype('double')
    ret_df['AskPrice'] = ret_df['AskPrice'].astype('double')
    ret_df = ret_df.reset_index()
    return ret_df

def get_nbbo_trade_before_n_seconds(trade_time, df, seconds=0):
    nseconds=seconds*1000000000
    nseconds += trade_time
    ret_df = df[df['ReceiptTimestamp'] < nseconds].iloc[-1:]
    ret_df['BidPrice'] = ret_df['BidPrice'].astype('double')
    ret_df['AskPrice'] = ret_df['AskPrice'].astype('double')
    return ret_df

def get_nbbo_trade_after_n_seconds(trade_time, df, seconds=0):
    nseconds=seconds*1000000000
    nseconds += trade_time
    ret_df = df[df['ReceiptTimestamp'] > nseconds].iloc[:1]
    ret_df['BidPrice'] = ret_df['BidPrice'].astype('double')
    ret_df['AskPrice'] = ret_df['AskPrice'].astype('double')
    return ret_df

  • У наступній функції ми створюємо набір даних, який містить усі котирування до та після угоди. Athena Spark автоматично визначає, скільки DPU запускати для обробки нашого набору даних.
def get_tca_analysis_via_df_single_query(trade_product, trade_price, trade_time):
    # BBO quotes
    bbos = spark.sql(f"SELECT Product, ReceiptTimestamp, AskPrice, BidPrice, MarketParticipant FROM bbo_quote where Product = '{trade_product}';")
    bbos = bbos.toPandas()

    bbo_just_before = get_trade_before_n_seconds(trade_time, bbos, seconds=0, groupby_col='MarketParticipant')
    bbo_just_after = get_trade_after_n_seconds(trade_time, bbos, seconds=0, groupby_col='MarketParticipant')
    bbo_1s_after = get_trade_after_n_seconds(trade_time, bbos, seconds=1, groupby_col='MarketParticipant')
    bbo_10s_after = get_trade_after_n_seconds(trade_time, bbos, seconds=10, groupby_col='MarketParticipant')
    bbo_60s_after = get_trade_after_n_seconds(trade_time, bbos, seconds=60, groupby_col='MarketParticipant')
    
    all_bbos = pd.concat([bbo_just_before, bbo_just_after, bbo_1s_after, bbo_10s_after, bbo_60s_after], ignore_index=True, sort=False)
    bbos_calculated = calculate_es_qs_eqf(all_bbos, trade_price)

    #NBBO quotes
    nbbos = spark.sql(f"SELECT Product, ReceiptTimestamp, AskPrice, BidPrice, BestBidParticipant, BestAskParticipant FROM nbbo_quote where Product = '{trade_product}';")
    nbbos = nbbos.toPandas()

    nbbo_just_before = get_nbbo_trade_before_n_seconds(trade_time,nbbos, seconds=0)
    nbbo_just_after = get_nbbo_trade_after_n_seconds(trade_time, nbbos, seconds=0)
    nbbo_1s_after = get_nbbo_trade_after_n_seconds(trade_time, nbbos, seconds=1)
    nbbo_10s_after = get_nbbo_trade_after_n_seconds(trade_time, nbbos, seconds=10)
    nbbo_60s_after = get_nbbo_trade_after_n_seconds(trade_time, nbbos, seconds=60)

    all_nbbos = pd.concat([nbbo_just_before, nbbo_just_after, nbbo_1s_after, nbbo_10s_after, nbbo_60s_after], ignore_index=True, sort=False)
    nbbos_calculated = calculate_es_qs_eqf(all_nbbos, trade_price)

    calc = pd.concat([bbos_calculated, nbbos_calculated], ignore_index=True, sort=False)
    
    return calc

  • Тепер давайте викличемо функцію аналізу TCA з інформацією з вибраної нами торгівлі:
tp = "QQQ 230518C00329000"
tpr = 1.16
tt = 1684338579104713924
c = get_tca_analysis_via_df_single_query(tp, tpr, tt)

Візуалізуйте результати аналізу

Тепер давайте створимо кадри даних, які ми використовуємо для візуалізації. Кожен кадр даних містить котирування для одного з п’яти часових інтервалів для кожного каналу даних (BBO, NBBO):

bbo = c[c['MarketParticipant'].isin(['BBO'])]
bbo_bef = bbo[bbo['ReceiptTimestamp'] < tt]
bbo_aft_0 = bbo[bbo['ReceiptTimestamp'].between(tt,tt+1000000000)]
bbo_aft_1 = bbo[bbo['ReceiptTimestamp'].between(tt+1000000000,tt+10000000000)]
bbo_aft_10 = bbo[bbo['ReceiptTimestamp'].between(tt+10000000000,tt+60000000000)]
bbo_aft_60 = bbo[bbo['ReceiptTimestamp'] > (tt+60000000000)]

nbbo = c[~c['MarketParticipant'].isin(['BBO'])]
nbbo_bef = nbbo[nbbo['ReceiptTimestamp'] < tt]
nbbo_aft_0 = nbbo[nbbo['ReceiptTimestamp'].between(tt,tt+1000000000)]
nbbo_aft_1 = nbbo[nbbo['ReceiptTimestamp'].between(tt+1000000000,tt+10000000000)]
nbbo_aft_10 = nbbo[nbbo['ReceiptTimestamp'].between(tt+10000000000,tt+60000000000)]
nbbo_aft_60 = nbbo[nbbo['ReceiptTimestamp'] > (tt+60000000000)]

У наступних розділах ми надаємо приклад коду для створення різних візуалізацій.

Побудуйте QS і NBBO перед угодою

Використовуйте наступний код, щоб побудувати котирування спреду та NBBO перед угодою:

fig = px.bar(title="Quoted Spread Before The Trade",
    x=bbo_bef.MarketParticipant,
    y=bbo_bef['QS'],
    labels={'x': 'Market', 'y':'Quoted Spread'})
fig.add_hline(y=nbbo_bef.iloc[0]['QS'],
    line_width=1, line_dash="dash", line_color="red",
    annotation_text="NBBO", annotation_font_color="red")
%plotly fig

Побудуйте графік QS для кожного ринку та NBBO після угоди

Використовуйте наведений нижче код, щоб побудувати котирувальний спред для кожного ринку та NBBO одразу після угоди:

fig = px.bar(title="Quoted Spread After The Trade",
    x=bbo_aft_0.MarketParticipant,
    y=bbo_aft_0['QS'],
    labels={'x': 'Market', 'y':'Quoted Spread'})
fig.add_hline(
    y=nbbo_aft_0.iloc[0]['QS'],
    line_width=1, line_dash="dash", line_color="red",
    annotation_text="NBBO", annotation_font_color="red")
%plotly fig

Побудуйте графік QS для кожного інтервалу часу та кожного ринку для BBO

Використовуйте наведений нижче код, щоб побудувати спред котирувань для кожного інтервалу часу та кожного ринку для BBO:

fig = go.Figure(data=[
    go.Bar(name="before trade", x=bbo_bef.MarketParticipant.unique(), y=bbo_bef['QS']),
    go.Bar(name="0s after trade", x=bbo_aft_0.MarketParticipant.unique(), y=bbo_aft_0['QS']),
    go.Bar(name="1s after trade", x=bbo_aft_1.MarketParticipant.unique(), y=bbo_aft_1['QS']),
    go.Bar(name="10s after trade", x=bbo_aft_10.MarketParticipant.unique(), y=bbo_aft_10['QS']),
    go.Bar(name="60s after trade", x=bbo_aft_60.MarketParticipant.unique(), y=bbo_aft_60['QS'])])
fig.update_layout(barmode='group',title="BBO Quoted Spread Per Market/TimeFrame",
    xaxis={'title':'Market'},
    yaxis={'title':'Quoted Spread'})
%plotly fig

Побудуйте ES для кожного інтервалу часу та ринку для BBO

Використовуйте наступний код, щоб побудувати ефективний спред для кожного інтервалу часу та ринку для BBO:

fig = go.Figure(data=[
    go.Bar(name="before trade", x=bbo_bef.MarketParticipant.unique(), y=bbo_bef['ES']),
    go.Bar(name="0s after trade", x=bbo_aft_0.MarketParticipant.unique(), y=bbo_aft_0['ES']),
    go.Bar(name="1s after trade", x=bbo_aft_1.MarketParticipant.unique(), y=bbo_aft_1['ES']),
    go.Bar(name="10s after trade", x=bbo_aft_10.MarketParticipant.unique(), y=bbo_aft_10['ES']),
    go.Bar(name="60s after trade", x=bbo_aft_60.MarketParticipant.unique(), y=bbo_aft_60['ES'])])
fig.update_layout(barmode='group',title="BBO Effective Spread Per Market/TimeFrame",
    xaxis={'title':'Market'}, 
    yaxis={'title':'Effective Spread'})
%plotly fig

Побудуйте EQF для кожного інтервалу часу та ринку для BBO

Використовуйте наведений нижче код, щоб побудувати ефективний/котирований спред для кожного інтервалу часу та ринку для BBO:

fig = go.Figure(data=[
    go.Bar(name="before trade", x=bbo_bef.MarketParticipant.unique(), y=bbo_bef['EQF']),
    go.Bar(name="0s after trade", x=bbo_aft_0.MarketParticipant.unique(), y=bbo_aft_0['EQF']),
    go.Bar(name="1s after trade", x=bbo_aft_1.MarketParticipant.unique(), y=bbo_aft_1['EQF']),
    go.Bar(name="10s after trade", x=bbo_aft_10.MarketParticipant.unique(), y=bbo_aft_10['EQF']),
    go.Bar(name="60s after trade", x=bbo_aft_60.MarketParticipant.unique(), y=bbo_aft_60['EQF'])])
fig.update_layout(barmode='group',title="BBO Effective/Quoted Spread Per Market/TimeFrame",
    xaxis={'title':'Market'}, 
    yaxis={'title':'Effective/Quoted Spread'})
%plotly fig

Продуктивність розрахунку Athena Spark

Коли ви запускаєте блок коду, Athena Spark автоматично визначає, скільки DPU потрібно для завершення обчислення. В останньому блоці коду, де ми викликаємо tca_analysis ми фактично наказуємо Spark обробити дані, а потім перетворюємо отримані кадри даних Spark у кадри даних Pandas. Це частина аналізу, пов’язана з найінтенсивнішою обробкою, і коли Athena Spark запускає цей блок, він показує індикатор виконання, час, що минув, і кількість DPU, які зараз обробляють дані. Наприклад, у наступному розрахунку Athena Spark використовує 18 DPU.

Під час налаштування ноутбука Athena Spark у вас є можливість установити максимальну кількість DPU, які він може використовувати. За замовчуванням 20 DPU, але ми протестували цей розрахунок із 10, 20 і 40 DPU, щоб продемонструвати, як Athena Spark автоматично масштабується для виконання нашого аналізу. Ми спостерігали, що Athena Spark лінійно масштабується, займаючи 15 хвилин і 21 секунду, коли ноутбук було налаштовано з максимум 10 DPU, 8 хвилин і 23 секунди, коли ноутбук було налаштовано з 20 DPU, і 4 хвилини і 44 секунди, коли ноутбук був налаштований. налаштований з 40 DPU. Оскільки Athena Spark стягує плату на основі використання DPU з деталізацією за секунду, вартість цих обчислень подібна, але якщо ви встановите більше максимальне значення DPU, Athena Spark може повернути результат аналізу набагато швидше. Щоб дізнатися більше про ціни на Athena Spark, натисніть тут.

Висновок

У цій публікації ми продемонстрували, як можна використовувати високоточні дані OPRA з Tick History-PCAP LSEG для проведення аналізу транзакційних витрат за допомогою Athena Spark. Своєчасна доступність даних OPRA, доповнена інноваціями доступності AWS Data Exchange для Amazon S3, стратегічно скорочує час на аналітику для компаній, які прагнуть створити практичну інформацію для критичних торгових рішень. OPRA щодня генерує близько 7 ТБ нормалізованих даних Parquet, і керування інфраструктурою для надання аналітики на основі даних OPRA є складним завданням.

Масштабованість Athena в обробці великомасштабних даних для Tick History – PCAP для даних OPRA робить її переконливим вибором для організацій, яким потрібні швидкі та масштабовані аналітичні рішення в AWS. У цьому дописі показано безперебійну взаємодію між екосистемою AWS і даними Tick History-PCAP, а також те, як фінансові установи можуть скористатися цією синергією для прийняття рішень на основі даних для критично важливих торгових та інвестиційних стратегій.

Про авторів

Прамод Наяк є директором з управління продуктами групи низьких затримок у LSEG. Прамод має понад 10 років досвіду роботи в галузі фінансових технологій, зосереджуючись на розробці програмного забезпечення, аналітиці та управлінні даними. Прамод — колишній інженер програмного забезпечення, який захоплюється ринковими даними та кількісною торгівлею.

Лакшмі Кант Маннем є менеджером із продуктів у групі низьких затримок LSEG. Він зосереджується на даних і продуктах платформи для галузі ринкових даних з низькою затримкою. LakshmiKanth допомагає клієнтам створювати найбільш оптимальні рішення для їхніх потреб у ринкових даних.

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

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

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

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