Opanowanie dynamiki rynku: Transformacja analizy kosztów transakcji dzięki ultraprecyzyjnej historii Tick – PCAP i Amazon Athena dla Apache Spark | Usługi internetowe Amazona

Opanowanie dynamiki rynku: Transformacja analizy kosztów transakcji dzięki ultraprecyzyjnej historii Tick – PCAP i Amazon Athena dla Apache Spark | Usługi internetowe Amazona

Węzeł źródłowy: 3091357

Ten post został napisany wspólnie z Pramodem Nayakiem, LakshmiKanthem Mannem i Vivekiem Aggarwalem z grupy Low Latency Group LSEG.

Analiza kosztów transakcyjnych (TCA) jest powszechnie stosowana przez traderów, zarządzających portfelami i brokerów do analiz przed i potransakcyjnych. Pomaga im mierzyć i optymalizować koszty transakcyjne oraz skuteczność ich strategii handlowych. W tym poście analizujemy spready kupna-sprzedaży opcji z Historia zaznaczeń LSEG – PCAP zbiór danych za pomocą Amazon Athena dla Apache Spark. Pokażemy Ci, jak uzyskać dostęp do danych, zdefiniować niestandardowe funkcje do zastosowania na danych, wykonać zapytania i filtrować zbiór danych oraz wizualizować wyniki analizy, a wszystko to bez konieczności martwienia się o konfigurowanie infrastruktury lub konfigurowanie Sparka, nawet w przypadku dużych zbiorów danych.

Tło

Urząd ds. raportowania cen opcji (OPRA) pełni rolę kluczowego podmiotu przetwarzającego informacje o papierach wartościowych, gromadzącego, konsolidującego i rozpowszechniającego raporty z ostatniej sprzedaży, notowania i istotne informacje dotyczące opcji amerykańskich. Dzięki 18 aktywnym giełdom opcji amerykańskich i ponad 1.5 milionowi kwalifikujących się kontraktów, OPRA odgrywa kluczową rolę w dostarczaniu kompleksowych danych rynkowych.

5 lutego 2024 r. firma Securities Industry Automation Corporation (SIAC) ma zamiar zmodernizować kanał OPRA z 48 do 96 kanałów multiemisji. To ulepszenie ma na celu optymalizację dystrybucji symboli i wykorzystania przepustowości linii w odpowiedzi na rosnącą aktywność handlową i zmienność na amerykańskim rynku opcji. SIAC zalecił firmom przygotowanie się na szczytowe prędkości transmisji danych do 37.3 GBitów na sekundę.

Mimo że aktualizacja nie zmienia od razu całkowitej ilości publikowanych danych, umożliwia OPRA rozpowszechnianie danych w znacznie szybszym tempie. To przejście ma kluczowe znaczenie dla zaspokojenia potrzeb rynku opcji dynamicznych.

OPRA wyróżnia się jako jeden z najbardziej obszernych kanałów, ze szczytem wynoszącym 150.4 miliarda wiadomości dziennie w trzecim kwartale 3 r. i zapotrzebowaniem na pojemność wynoszącym 2023 miliardów wiadomości w ciągu jednego dnia. Przechwycenie każdej pojedynczej wiadomości ma kluczowe znaczenie dla analizy kosztów transakcji, monitorowania płynności rynku, oceny strategii handlowej i badań rynku.

O danych

Historia zaznaczeń LSEG – PCAP to repozytorium w chmurze, o pojemności przekraczającej 30 PB, zawierające ultrawysokiej jakości dane z rynku światowego. Dane te są skrupulatnie przechwytywane bezpośrednio w centrach danych wymiany, przy wykorzystaniu redundantnych procesów przechwytywania, strategicznie rozmieszczonych w głównych głównych i zapasowych centrach danych wymiany danych na całym świecie. Technologia przechwytywania LSEG zapewnia bezstratne przechwytywanie danych i wykorzystuje źródło czasu GPS w celu uzyskania nanosekundowej precyzji znacznika czasu. Ponadto stosowane są zaawansowane techniki arbitrażu danych, aby płynnie wypełnić wszelkie luki w danych. Po przechwyceniu dane poddawane są skrupulatnemu przetwarzaniu i arbitrażowi, a następnie normalizowane do formatu Parquet Ultra Direct firmy LSEG w czasie rzeczywistym (RTUD) zajmujące się obsługą pasz.

Proces normalizacji, który jest integralną częścią przygotowania danych do analizy, generuje do 6 TB skompresowanych plików Parquet dziennie. Ogromną ilość danych przypisuje się wszechstronnemu charakterowi OPRA, obejmującemu wiele giełd i obejmującemu liczne kontrakty opcyjne charakteryzujące się różnorodnymi atrybutami. Zwiększona zmienność rynku i działalność animatora rynku na giełdach opcji dodatkowo przyczyniają się do wolumenu danych publikowanych w OPRA.

Atrybuty Tick History – PCAP umożliwiają firmom przeprowadzanie różnych analiz, w tym następujących:

  • Analiza przedtransakcyjna – Oceń potencjalny wpływ handlu i zbadaj różne strategie realizacji w oparciu o dane historyczne
  • Ocena potransakcyjna – Mierz rzeczywiste koszty realizacji w porównaniu z punktami odniesienia, aby ocenić skuteczność strategii realizacji
  • Zoptymalizowany egzekucja – Dostosuj strategie realizacji w oparciu o historyczne wzorce rynkowe, aby zminimalizować wpływ na rynek i zmniejszyć ogólne koszty transakcyjne
  • Zarządzanie ryzykiem – Identyfikuj wzorce poślizgów, identyfikuj wartości odstające i proaktywnie zarządzaj ryzykiem związanym z działalnością handlową
  • Atrybucja wyników – Analizując wyniki portfela, należy oddzielić wpływ decyzji handlowych od decyzji inwestycyjnych

Historia kleszczy LSEG – zbiór danych PCAP jest dostępny w Wymiana danych AWS i można uzyskać do nich dostęp Rynek AWS. Z Wymiana danych AWS dla Amazon S3, możesz uzyskać dostęp do danych PCAP bezpośrednio z LSEG Usługa Amazon Simple Storage (Amazon S3), eliminując potrzebę przechowywania przez firmy własnych kopii danych. Takie podejście usprawnia zarządzanie i przechowywanie danych, zapewniając klientom natychmiastowy dostęp do wysokiej jakości danych PCAP lub znormalizowanych, z łatwością użycia, integracji i znaczne oszczędności w zakresie przechowywania danych.

Atena dla Apache Spark

Do prac analitycznych Atena dla Apache Spark oferuje uproszczoną obsługę notebooka dostępną za pośrednictwem konsoli Athena lub interfejsów API Athena, umożliwiając tworzenie interaktywnych aplikacji Apache Spark. Dzięki zoptymalizowanemu środowisku wykonawczemu Spark, Athena pomaga w analizie petabajtów danych poprzez dynamiczne skalowanie liczby silników Spark w czasie krótszym niż sekunda. Co więcej, popularne biblioteki Pythona, takie jak pandas i NumPy, są płynnie zintegrowane, co pozwala na tworzenie skomplikowanej logiki aplikacji. Elastyczność obejmuje import niestandardowych bibliotek do użytku w notatnikach. Athena for Spark obsługuje większość formatów otwartych danych i jest płynnie zintegrowana z platformą Klej AWS Katalog danych.

Dataset

Do tej analizy wykorzystaliśmy zbiór danych LSEG Tick History – PCAP OPRA z 17 maja 2023 r. Ten zbiór danych składa się z następujących elementów:

  • Najlepsza oferta i oferta (BBO) – Raportuje najwyższą ofertę i najniższą ofertę zabezpieczenia na danej giełdzie
  • Najlepsza krajowa oferta i oferta (NBBO) – Zgłasza najwyższą ofertę i najniższą prośbę o zabezpieczenie na wszystkich giełdach
  • Transakcje – Rejestruje zakończone transakcje na wszystkich giełdach

Zbiór danych obejmuje następujące woluminy danych:

  • Transakcje – 160 MB rozproszone w około 60 skompresowanych plikach Parquet
  • BBO – 2.4 TB rozdzielone na około 300 skompresowanych plików Parquet
  • NBBO – 2.8 TB rozdzielone na około 200 skompresowanych plików Parquet

Przegląd analizy

Analizowanie danych historii zaznaczeń OPRA na potrzeby analizy kosztów transakcji (TCA) obejmuje analizę notowań rynkowych i transakcji związanych z konkretnym wydarzeniem handlowym. W ramach tego badania wykorzystujemy następujące wskaźniki:

  • Notowany spread (QS) – Obliczane jako różnica między zapytaniem BBO a ofertą BBO
  • Efektywny spread (ES) – Obliczana jako różnica między ceną transakcyjną a środkiem BBO (oferta BBO + (zapytanie BBO – oferta BBO)/2)
  • Efektywny/kwotowany spread (EQF) – Obliczane jako (ES / QS) * 100

Obliczamy te spready przed transakcją i dodatkowo w czterech odstępach czasu po transakcji (tuż po, 1 sekunda, 10 sekund i 60 sekund po transakcji).

Skonfiguruj usługę Athena dla Apache Spark

Aby skonfigurować usługę Athena dla Apache Spark, wykonaj następujące kroki:

  1. Na konsoli Athena, pod Rozpocznij, Wybierz Analizuj swoje dane za pomocą PySpark i Spark SQL.
  2. Jeśli po raz pierwszy korzystasz z Athena Spark, wybierz Utwórz grupę roboczą.
  3. W razie zamówieenia projektu Nazwa grupy roboczej¸ wprowadź nazwę grupy roboczej, np tca-analysis.
  4. W Silnik analityczny sekcja, wybierz Apache Spark.
  5. W Dodatkowe konfiguracje sekcję, możesz wybrać Użyj ustawień domyślnych lub podaj zwyczaj AWS Zarządzanie tożsamością i dostępem (IAM) i lokalizacja Amazon S3 dla wyników obliczeń.
  6. Dodaj Utwórz grupę roboczą.
  7. Po utworzeniu grupy roboczej przejdź do Notebooki kartę i wybierz Utwórz notatnik.
  8. Wprowadź nazwę swojego notesu, np tca-analysis-with-tick-history.
  9. Dodaj Stwórz aby stworzyć swój notatnik.

Uruchom swój notatnik

Jeśli utworzyłeś już grupę roboczą Spark, wybierz Uruchom edytor notatników dla Rozpocznij.


Po utworzeniu notatnika zostaniesz przekierowany do interaktywnego edytora notatników.


Teraz możemy dodać i uruchomić następujący kod w naszym notatniku.

Utwórz analizę

Aby utworzyć analizę, wykonaj następujące kroki:

  • Importuj wspólne biblioteki:
import pandas as pd
import plotly.express as px
import plotly.graph_objects as go

  • Utwórz nasze ramki danych dla BBO, NBBO i transakcji:
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")

  • Teraz możemy zidentyfikować branżę do wykorzystania w analizie kosztów transakcyjnych:
filtered_trades = spark.sql("select Product, Price,Quantity, ReceiptTimestamp, MarketParticipant from trades")

Otrzymujemy następujący wynik:

+---------------------+---------------------+---------------------+-------------------+-----------------+ 
|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|
+---------------------+---------------------+---------------------+-------------------+-----------------+

Używamy wyróżnionych informacji handlowych w przyszłości dla produktu handlowego (tp), ceny handlowej (tpr) i czasu transakcji (tt).

  • Tutaj tworzymy szereg funkcji pomocniczych do naszej analizy
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

  • W poniższej funkcji tworzymy zbiór danych zawierający wszystkie notowania przed i po transakcji. Athena Spark automatycznie określa, ile DPU należy uruchomić w celu przetworzenia naszego zbioru danych.
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

  • Wywołajmy teraz funkcję analizy TCA z informacjami z naszej wybranej transakcji:
tp = "QQQ 230518C00329000"
tpr = 1.16
tt = 1684338579104713924
c = get_tca_analysis_via_df_single_query(tp, tpr, tt)

Wizualizuj wyniki analizy

Utwórzmy teraz ramki danych, których będziemy używać do naszej wizualizacji. Każda ramka danych zawiera cytaty dla jednego z pięciu przedziałów czasowych dla każdego źródła danych (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)]

W poniższych sekcjach podajemy przykładowy kod umożliwiający tworzenie różnych wizualizacji.

Wykreśl QS i NBBO przed transakcją

Użyj poniższego kodu, aby wykreślić notowany spread i NBBO przed transakcją:

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

Wykreśl QS dla każdego rynku i NBBO po transakcji

Użyj poniższego kodu, aby wykreślić notowany spread dla każdego rynku i NBBO bezpośrednio po transakcji:

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

Wykreśl QS dla każdego przedziału czasowego i każdego rynku dla BBO

Użyj poniższego kodu, aby wykreślić podany spread dla każdego przedziału czasowego i każdego rynku dla 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

Wykreśl ES dla każdego przedziału czasowego i rynku dla BBO

Użyj poniższego kodu, aby wykreślić efektywny spread dla każdego przedziału czasowego i rynku dla 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

Narysuj EQF dla każdego przedziału czasowego i rynku dla BBO

Użyj poniższego kodu, aby wykreślić efektywny/kwotowany spread dla każdego przedziału czasowego i rynku dla 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

Wydajność obliczeń Athena Spark

Po uruchomieniu bloku kodu Athena Spark automatycznie określa, ile jednostek DPU wymaga do ukończenia obliczeń. W ostatnim bloku kodu, w którym wywołujemy metodę tca_analysis funkcji, tak naprawdę instruujemy Sparka, aby przetworzył dane, a następnie konwertujemy powstałe ramki danych Spark na ramki danych Pandy. Stanowi to najbardziej intensywną część analizy w zakresie przetwarzania, a kiedy Athena Spark uruchamia ten blok, pokazuje pasek postępu, upływający czas i liczbę DPU aktualnie przetwarzających dane. Na przykład w poniższym obliczeniu Athena Spark wykorzystuje 18 jednostek DPU.

Podczas konfigurowania notebooka Athena Spark masz możliwość ustawienia maksymalnej liczby jednostek DPU, z których może korzystać. Wartość domyślna to 20 DPU, ale przetestowaliśmy to obliczenie z 10, 20 i 40 DPU, aby zademonstrować, w jaki sposób Athena Spark automatycznie skaluje się w celu przeprowadzenia naszej analizy. Zaobserwowaliśmy, że Athena Spark skaluje się liniowo i zajmuje 15 minut i 21 sekund, gdy notebook został skonfigurowany z maksymalnie 10 jednostkami DPU, 8 minut i 23 sekundy, gdy notebook został skonfigurowany z 20 jednostkami DPU oraz 4 minuty i 44 sekundy, gdy notebook został skonfigurowany skonfigurowany z 40 jednostkami DPU. Ponieważ Athena Spark pobiera opłaty w oparciu o wykorzystanie DPU, z dokładnością do sekundy, koszt tych obliczeń jest podobny, ale jeśli ustawisz wyższą maksymalną wartość DPU, Athena Spark może zwrócić wynik analizy znacznie szybciej. Aby uzyskać więcej informacji na temat cennika Athena Spark, kliknij tutaj.

Wnioski

W tym poście pokazaliśmy, jak można wykorzystać wysokiej jakości dane OPRA z Tick History-PCAP firmy LSEG do przeprowadzania analiz kosztów transakcji za pomocą Athena Spark. Dostępność danych OPRA w odpowiednim czasie, uzupełniona innowacjami w zakresie dostępności AWS Data Exchange dla Amazon S3, strategicznie skraca czas analiz dla firm, które chcą uzyskać praktyczne spostrzeżenia potrzebne do kluczowych decyzji handlowych. OPRA generuje każdego dnia około 7 TB znormalizowanych danych Parquet, a zarządzanie infrastrukturą w celu zapewnienia analityki opartej na danych OPRA stanowi wyzwanie.

Skalowalność rozwiązania Athena w obsłudze wielkoskalowego przetwarzania danych na potrzeby Tick History – PCAP dla danych OPRA sprawia, że ​​jest to atrakcyjny wybór dla organizacji poszukujących szybkich i skalowalnych rozwiązań analitycznych w AWS. Ten post pokazuje płynną interakcję pomiędzy ekosystemem AWS a danymi Tick History-PCAP oraz pokazuje, w jaki sposób instytucje finansowe mogą wykorzystać tę synergię do podejmowania decyzji opartych na danych w przypadku kluczowych strategii handlowych i inwestycyjnych.


O autorach

Pramoda Nayaka jest dyrektorem ds. zarządzania produktami w grupie Low Latency w LSEG. Pramod ma ponad 10-letnie doświadczenie w branży technologii finansowych, koncentrując się na tworzeniu oprogramowania, analityce i zarządzaniu danymi. Pramod to były inżynier oprogramowania, pasjonat danych rynkowych i handlu ilościowego.

LakshmiKanth Mannem jest menedżerem produktu w grupie Low Latency Group firmy LSEG. Koncentruje się na produktach związanych z danymi i platformami dla branży danych rynkowych o małych opóźnieniach. LakshmiKanth pomaga klientom budować najbardziej optymalne rozwiązania dla ich potrzeb w zakresie danych rynkowych.

Wiwek Aggarwal jest starszym inżynierem danych w grupie małych opóźnień LSEG. Vivek pracuje nad rozwojem i utrzymaniem potoków danych do przetwarzania i dostarczania przechwyconych strumieni danych rynkowych i źródeł danych referencyjnych.

Alket Memushaj jest głównym architektem w zespole rozwoju rynku usług finansowych w AWS. Alket jest odpowiedzialny za strategię techniczną, współpracując z partnerami i klientami w celu wdrożenia nawet najbardziej wymagających obciążeń rynków kapitałowych w chmurze AWS.

Znak czasu:

Więcej z Duże zbiory danych AWS!