PCAP சந்தை தரவு மற்றும் மார்க்கெட் ரீப்ளே செயல்முறை

PCAP சந்தை தரவு என்பது வட்டில் எழுதப்பட்ட மூல பரிமாற்றத் தரவு (raw exchange traffic) ஆகும்; இது நெட்வொர்க் கார்டை வந்தடைந்த அதே நிலையில், ஒவ்வொரு மல்டிகாஸ்ட் பாக்கெட்டும், பைட்டுக்கு பைட், கேப்சர் ஹோஸ்ட்டால் நேர முத்திரையிடப்பட்டு (timestamped) சேமிக்கப்படுகிறது. கோப்பில் உள்ள எதுவும் இயல்பாக்கப்படவோ (normalized) அல்லது பார் (bar) வடிவில் சுருக்கப்படவோ இல்லை. இதனால்தான் தாமதம் (latency) மற்றும் வரிசைமுறை (sequencing) குறித்த ஆய்வுகள் ஒரு கேப்சரில் தொடங்குகின்றன, மேலும் ஒரு பிஸியான நாளில் ஒரு குறியீடு (symbol) பல ஜிகாபைட் தரவை நிரப்ப முடியும்.

PCAP சந்தை தரவு என்றால் என்ன?

PCAP என்பது பாக்கெட் கேப்சர் (packet capture) என்பதன் சுருக்கம். இது 1990-களிலிருந்து libpcap மற்றும் tcpdump ஆகியவற்றால் எழுதப்படும் கோப்பு வடிவமாகும். இது ஃபீட் ஹேண்ட்லருக்கு (feed handler) அருகில் உள்ள நெட்வொர்க் டேப்பில் (network tap) அமர்ந்திருக்கும் ஒரு கேப்சர் ஹோஸ்ட் உருவாக்கும் தரவாகும். எக்ஸ்சேஞ்ச் ஃபீட்கள் மல்டிகாஸ்ட் UDP முறையில் இருப்பதால், ஃபீட் ஹேண்ட்லர் பார்க்கும் அதே பாக்கெட்டுகளை டேப் பார்க்கிறது, மேலும் கேப்சர் ஹோஸ்ட் அவற்றை எந்த விளக்கமும் இன்றி அப்படியே எழுதுகிறது.

இதன் அமைப்பு வேண்டுமென்றே எளிமையாக வைக்கப்பட்டுள்ளது, இதுவே தரவை லைன் ரேட்டில் (line rate) எழுத அனுமதிக்கிறது. ஒரு கோப்பு 24 பைட் கொண்ட குளோபல் ஹெடருடன் தொடங்குகிறது. அதன் பிறகு, கோப்பு முடியும் வரை 16 பைட் கொண்ட ரெக்கார்ட் ஹெடர் மற்றும் ஒரு பாக்கெட்டின் கேப்சர் செய்யப்பட்ட பைட்டுகள் மீண்டும் மீண்டும் வருகின்றன. இதில் குறியீட்டெண் (index) அல்லது பாக்கெட் எண்ணிக்கை எதுவும் இல்லை.

குளோபல் ஹெடர் தெரிந்துகொள்ள வேண்டிய புலங்களைக் கொண்டுள்ளது:

• மேஜிக் எண் (magic number), நான்கு பைட்டுகள். 0xa1b2c3d4 என்பது மைக்ரோசெகண்ட் நேர முத்திரைகளையும், 0xa1b23c4d என்பது நானோசெகண்ட் நேர முத்திரைகளையும் குறிக்கிறது. வட்டில் இது தோன்றும் பைட் வரிசை, எழுதும் ஹோஸ்ட் லிட்டில் எண்டியன் (little endian) முறையைப் பயன்படுத்துகிறதா என்பதையும் காட்டுகிறது.
• வெர்ஷன் மேஜர் மற்றும் வெர்ஷன் மைனர், தலா இரண்டு பைட்டுகள். இவை பல தசாப்தங்களாக 2 மற்றும் 4 என்றே உள்ளன.
• thiszone மற்றும் sigfigs, தலா நான்கு பைட்டுகள். நடைமுறையில் இவை இரண்டும் பூஜ்ஜியமாகும்.
• snaplen, நான்கு பைட்டுகள். ஒரு பாக்கெட்டுக்கு கேப்சர் ஹோஸ்ட் வைத்திருக்கும் அதிகபட்ச பைட்டுகளின் எண்ணிக்கை.
• லிங்க் வகை (link type), நான்கு பைட்டுகள். 1 என்பது ஈதர்நெட் (Ethernet) ஆகும்.

அதன்பின் வரும் ஒவ்வொரு ரெக்கார்ட் ஹெடரும் நான்கு புலங்களைக் கொண்டுள்ளது: ts_sec, Unix epoch-லிருந்து முழு வினாடிகள்; ts_usec, மேஜிக் எண்ணைப் பொறுத்து மைக்ரோசெகண்ட் அல்லது நானோசெகண்டுகளில் உள்ள பின்னப் பகுதி; incl_len, கேப்சர் நீளம், அதாவது இந்த பாக்கெட்டின் எத்தனை பைட்டுகள் கோப்பில் உள்ளன; மற்றும் orig_len, அசல் நீளம், அதாவது ஒயரில் எத்தனை பைட்டுகள் இருந்தன.

orig_len என்பது incl_len-ஐ விட அதிகமாக இருக்கும்போது, கேப்சர் ஹோஸ்ட் பாக்கெட்டை அதன் snaplen-ல் வெட்டியுள்ளது (clipped) என்று அர்த்தம், அதன் வால் பகுதி எழுதப்படவில்லை. அக்கோப்பை மீண்டும் இயக்கும்போது (replay), ஃபீட் ஹேண்ட்லருக்கு பாதியின் பாதியாக இருக்கும் செய்தி கிடைக்கிறது. யாராவது உங்களுக்கு ஒரு கேப்சரை வழங்கினால், இந்த இரண்டு நீளங்களை ஒப்பிட்டுப் பார்ப்பதே நீங்கள் செய்ய வேண்டிய முதல் சரிபார்ப்பு ஆகும்.

கேப்சர் நேர முத்திரை ஏன் முக்கியமானது

இயல்பாக்கப்பட்ட ஃபீட் (normalized feed) உங்களுக்கு நேர முத்திரையுடன் கூடிய ஒரு பதிவை வழங்குகிறது, அந்த முத்திரை விற்பனையாளருக்குச் சொந்தமானது: விற்பனையாளரின் பார்சர் (parser) செய்தியை முடித்த பிறகு அது பயன்படுத்தப்படுகிறது. ஒரு கேப்சர் நேர முத்திரை, பாக்கெட் வந்தடைந்தவுடன் கேப்சர் கார்டு அல்லது கர்னலால் (kernel) பயன்படுத்தப்படுகிறது, இது பொதுவாக பாக்கெட் வந்த ஒரு அல்லது இரண்டு மைக்ரோசெகண்டுகளுக்குள் நடக்கும், மேலும் பேலோட் (payload) பகுப்பாய்வு செய்யப்படுவதற்கு முன்பே இது எழுதப்படுகிறது. ஒன்று ஒரு பைப்லைனை அளவிடுகிறது. மற்றொன்று ஒயரை அளவிடுகிறது.

இதே கருத்து இயல்பாக்கப்பட்ட தரவுக்குள்ளும் காணப்படுகிறது. ஒவ்வொரு ஒருங்கிணைக்கப்பட்ட அமெரிக்க பங்கு மேற்கோளும் (US equity quote) இரண்டு கடிகாரங்களைக் கொண்டுள்ளது: எக்ஸ்சேஞ்சில் எழுதப்பட்ட பங்கேற்பாளர் நேர முத்திரை (participant timestamp) மற்றும் ஒருங்கிணைப்பாளர் (consolidator) செய்தியைச் செயலாக்கியபோது எழுதப்பட்ட SIP நேர முத்திரை. அவற்றுக்கு இடையேயான தூரம் என்பது நேரடி கேப்சர் தவிர்க்கும் ஒரு படியாகும். SIP மற்றும் நேரடி எக்ஸ்சேஞ்ச் ஃபீட்கள் அந்த ஒருங்கிணைப்பு எதைச் சேர்க்கிறது மற்றும் எதை நீக்குகிறது என்பதை விளக்குகிறது.

SELECT
    formatDateTime(toStartOfInterval(toTimeZone(sip_timestamp, 'America/New_York'), INTERVAL 10 MINUTE), '%H:%i') AS et_time,
    count()                                            AS quote_count,
    round(quantileDeterministic(0.5)(gap_us, det), 0)  AS median_gap_us,
    round(quantileDeterministic(0.9)(gap_us, det), 0)  AS p90_gap_us
FROM
(
    SELECT
        sip_timestamp,
        toUnixTimestamp64Micro(sip_timestamp) - toUnixTimestamp64Micro(participant_timestamp) AS gap_us,
        toUInt64(toUnixTimestamp64Micro(sip_timestamp))                                       AS det
    FROM global_markets.cache_stocks_quotes
    WHERE ticker = 'AAPL'
      AND sip_timestamp >= '2026-06-10 13:30:00'
      AND sip_timestamp <  '2026-06-10 15:00:00'
      AND participant_timestamp > '2020-01-01 00:00:00'
)
WHERE gap_us BETWEEN 0 AND 1000000
GROUP BY et_time
ORDER BY et_time

ஜூன் 10, 2026 அன்று வர்த்தகத்தின் முதல் தொண்ணூறு நிமிடங்களில், பத்து நிமிட இடைவெளிகளாகப் பிரிக்கும்போது, இந்த இடைவெளி தெளிவாகத் தெரிகிறது. 09:30 இடைவெளியில், 93041 AAPL மேற்கோள்கள் இரண்டு கடிகாரங்களையும் கொண்டிருந்தன, எக்ஸ்சேஞ்ச் முத்திரை ஒருங்கிணைப்பாளர் முத்திரைக்கு முன்னதாகவோ அல்லது அதே நேரத்திலோ இருந்தது, மேலும் அந்த இடைவெளியின் நடுப்பகுதி செய்தி இரண்டிற்கும் இடையே 178 மைக்ரோசெகண்ட் இடைவெளியைக் கொண்டிருந்தது. பத்தில் ஒரு செய்தி குறைந்தது 342 மைக்ரோசெகண்ட் இடைவெளியில் இருந்தது. அந்த தூரங்கள் ஒருங்கிணைப்புக்குப் பிறகு, இயல்பாக்கப்பட்ட பதிவில் அளவிடப்படுகின்றன. ஒரு கேப்சர் அதே பயணத்தை அந்தப் படி இல்லாமல் அளவிடுகிறது.

PCAP-ஐ கையால் உருவாக்குதல், பின் அதை வாசித்தல்

இந்த வடிவத்தை ஒரு பிளாக் பாக்ஸாகக் கருதுவதை நிறுத்துவதற்கான வேகமான வழி அதை உருவாக்குவதாகும். கீழே உள்ள ஸ்கிரிப்ட் எந்த தொகுப்புகளும் (packages) நிறுவப்படாத மற்றும் நெட்வொர்க் அணுகல் இல்லாத ஸ்டாக் பைதான் 3-ல் இயங்குகிறது. இதை pcap_demo.py எனச் சேமித்து இயக்கவும்.

# pcap_demo.py (standard library only)
from binascii import unhexlify
import struct

GLOBAL_HEADER = unhexlify(
    'd4c3b2a1'   # magic 0xa1b2c3d4, written by a little endian host
    '0200'       # version_major = 2
    '0400'       # version_minor = 4
    '00000000'   # thiszone
    '00000000'   # sigfigs
    '08000000'   # snaplen = 8 bytes (tiny on purpose, see below)
    '01000000'   # link type 1 = Ethernet
)

RECORDS = [
    unhexlify(
        '80e14e68'          # ts_sec   = 1750000000
        'a0860100'          # ts_usec  = 100000
        '08000000'          # incl_len = 8 bytes captured
        '08000000'          # orig_len = 8 bytes on the wire
        '4d53472d30303031'  # payload MSG-0001
    ),
    unhexlify(
        '80e14e68'          # ts_sec   = 1750000000
        '90d00300'          # ts_usec  = 250000
        '08000000'
        '08000000'
        '4d53472d30303032'  # payload MSG-0002
    ),
    unhexlify(
        '80e14e68'          # ts_sec   = 1750000000
        '801a0600'          # ts_usec  = 400000
        '08000000'          # incl_len = 8 bytes captured
        '40000000'          # orig_len = 64 bytes on the wire, clipped at snaplen
        '4d53472d30303033'  # payload MSG-0003
    ),
]

blob = GLOBAL_HEADER + b''.join(RECORDS)

magic, vmaj, vmin, tz, sigfigs, snaplen, link = struct.unpack('<IHHiIII', blob[:24])
assert magic == 0xa1b2c3d4, 'not a little endian microsecond pcap'
assert (vmaj, vmin) == (2, 4)
print('snaplen', snaplen, 'link type', link)

off = 24
while off < len(blob):
    ts_sec, ts_usec, incl_len, orig_len = struct.unpack('<IIII', blob[off:off + 16])
    payload = blob[off + 16:off + 16 + incl_len]
    off += 16 + incl_len
    state = 'clipped' if orig_len > incl_len else 'whole'
    print(f'{ts_sec}.{ts_usec:06d}  incl={incl_len} orig={orig_len} {state}  {payload!r}')

இது நான்கு வரிகளை அச்சிடுகிறது:

snaplen 8 link type 1
1750000000.100000  incl=8 orig=8 whole  b'MSG-0001'
1750000000.250000  incl=8 orig=8 whole  b'MSG-0002'
1750000000.400000  incl=8 orig=64 clipped  b'MSG-0003'

கவனிக்க வேண்டிய மூன்று விஷயங்கள். மேஜிக் எண்ணின் மீதான assert என்பது முழு கோப்பு வகை சரிபார்ப்பாகும்: அந்த நான்கு பைட்டுகளும் லிட்டில் எண்டியன் கையொப்பமிடப்படாத முழு எண்ணாக வாசிக்கப்பட்டு, வகையையும் பைட் வரிசையையும் அடையாளம் காட்டுகின்றன. வெர்ஷன் ஜோடி பெரும்பாலான வர்த்தக அமைப்புகள் எழுதப்படுவதற்கு முன்பிருந்தே 2.4 என உள்ளது, எனவே அதை அப்படியே வைத்திருப்பது பாதுகாப்பானது. மூன்றாவது ரெக்கார்டு ஒயரில் 64 பைட்டுகளுக்கு எதிராக 8 கேப்சர் செய்யப்பட்ட பைட்டுகளை அறிவிக்கிறது, இதுவே snaplen கிளிப் உள்ளே இருந்து எப்படி இருக்கும் என்பதைக் காட்டுகிறது. இங்கே snaplen 8 பைட்டுகளாக அமைக்கப்பட்டுள்ளது, இதை எந்த உண்மையான கேப்சர் ஹோஸ்ட்டும் செய்யாது. ஒரு ரெக்கார்டு கிளிப்பைக் காட்ட மட்டுமே இது சிறியதாக அமைக்கப்பட்டுள்ளது.

தவறான இணைப்பு (merge) ஏன் ரீப்ளேயை வரிசைப்படுத்துகிறது

கேப்சர்கள் துண்டுகளாக வருகின்றன. ஒரு கேப்சர் ஹோஸ்ட் ஒவ்வொரு சில நிமிடங்களுக்கும் அல்லது ஒவ்வொரு ஜிகாபைட்டிற்கும் ஒரு புதிய கோப்பை உருவாக்குகிறது, எனவே ஒரு அமர்வு capture-1.pcap முதல் capture-40.pcap வரை அமைகிறது, மேலும் ஒரு ரீப்ளேக்கு அவை ஒரே வரிசைப்படுத்தப்பட்ட ஸ்ட்ரீமாகத் தேவைப்படுகின்றன. இங்கே இரண்டு தோல்வி முறைகள் உள்ளன, அவற்றில் எதுவுமே பிழையை எழுப்புவதில்லை.

முதலாவது கோப்பு பெயர் வரிசை. ஷெல் குளோப் (shell glob) அகரவரிசைப்படி வரிசைப்படுத்துகிறது, இது capture-10.pcap-ஐ capture-2.pcap-க்கு முன்னால் வைக்கிறது. விற்பனையாளர் மெர்ஜ் ஸ்கிரிப்ட்கள் ls -1v-ஐ நம்பியிருப்பதற்கு இதுவே காரணம்: -v கொடி ஒரு பெயருக்குள் உள்ள இலக்கங்களை உரையாக இல்லாமல் எண்களாக வரிசைப்படுத்துகிறது. கோப்பு பெயர் வரிசை என்பது நேர வரிசைக்கு ஒரு பிரதிநிதி மட்டுமே, மேலும் கேப்சர் ஹோஸ்ட் மறுதொடக்கம் செய்யப்படும்போதோ அல்லது இரண்டு ஹோஸ்ட்கள் ஒரே அமர்வுக்கு பங்களிக்கும்போதோ அந்தப் பிரதிநிதி தோல்வியடைகிறது.

இரண்டாவது இணைப்பு (concatenation). cat a.pcap b.pcap > merged.pcap-ஐ இயக்குவது வேலை செய்வது போலத் தோன்றும் மற்றும் சிதைந்த கோப்பை உருவாக்குகிறது. இரண்டாவது கோப்பின் 24 பைட் குளோபல் ஹெடர் ஒரு ரெக்கார்ட் ஹெடர் இருக்க வேண்டிய இடத்தில் அமர்கிறது, மேலும் ஒரு பார்சர் அதன் மேஜிக் எண்ணை epoch-க்கு 2712847316 வினாடிகளுக்குப் பிறகு, அதாவது 2055-ல் முத்திரையிடப்பட்ட பாக்கெட்டாக வாசிக்கிறது. Wireshark தொகுப்பின் மெர்ஜ் டூலான Mergecap, கூடுதல் ஹெடர்களை நீக்கிவிட்டு பாக்கெட்டுகளை காலவரிசைப்படி எழுதுகிறது.

மேலே உருவாக்கப்பட்ட கோப்பில் வரிசைக்கு மாறான ஒரு ரெக்கார்டைச் சேர்த்தால், சிக்கல் இரண்டு வரிகளில் தெரியும்.

# add this to the bottom of pcap_demo.py
import tempfile

LATE = unhexlify(
    '80e14e68'          # ts_sec   = 1750000000
    'f0490200'          # ts_usec  = 150000, earlier than the record before it
    '08000000'
    '08000000'
    '4d53472d30303034'  # payload MSG-0004
)
blob += LATE

records, off = [], 24
while off < len(blob):
    ts_sec, ts_usec, incl_len, orig_len = struct.unpack('<IIII', blob[off:off + 16])
    payload = blob[off + 16:off + 16 + incl_len]
    records.append(((ts_sec, ts_usec), incl_len, orig_len, payload))
    off += 16 + incl_len

stamps = [r[0] for r in records]
print('file order:', [f'{s}.{u:06d}' for s, u in stamps])
print('monotonic:', all(a <= b for a, b in zip(stamps, stamps[1:])))

records.sort(key=lambda r: r[0])
with tempfile.NamedTemporaryFile(suffix='.pcap', delete=False) as fh:
    fh.write(GLOBAL_HEADER)
    for (ts_sec, ts_usec), incl_len, orig_len, payload in records:
        fh.write(struct.pack('<IIII', ts_sec, ts_usec, incl_len, orig_len))
        fh.write(payload)
    print('rewritten in timestamp order:', fh.name)

பார்ஸ் லூப் ரெக்கார்டுகளை கோப்பு வரிசையில் நடக்கிறது மற்றும் மோனோடோனிக் சரிபார்ப்பு தவறானது என்று வருகிறது. வேறு எதுவும் புகார் செய்யவில்லை. அந்த கோப்பிலிருந்து நேரடியாக இயக்கப்படும் ரீப்ளே, 400000 மைக்ரோசெகண்ட் செய்திக்குப் பிறகு 150000 மைக்ரோசெகண்ட் செய்தியை ஊட்டுகிறது, மேலும் நிலையைப் பராமரிக்கும் எந்தவொரு நுகர்வோரும் ஏற்கனவே மாற்றியமைக்கப்பட்ட அப்டேட்டுக்குப் பிறகு ஒரு மேற்கோள் அப்டேட் வருவதைப் பார்க்கிறார்கள். நாற்பது கோப்புகளைக் கொண்ட ஒரு உண்மையான அமர்வில், அந்த குறைபாடு ஒவ்வொரு கோப்பு எல்லையிலும் சில வரிசை மாறிய பாக்கெட்டுகளாகத் தெரிகிறது, இதுவே புக் ஸ்டேட் (book state) ஒன்றாக இணைக்கப்படும் இடமாகும். எழுதுவதற்கு முன் ரெக்கார்ட் நேர முத்திரையின்படி வரிசைப்படுத்துவதுதான் தீர்வு, அதனால்தான் கோப்பு பெயர் வரிசையை விட நேர முத்திரை வரிசையே சோதிக்க வேண்டிய மாறிலியாகும்.

செய்திகளை வரிசை மாற்றும் ஒரு ரீப்ளே என்பது வெவ்வேறு உடைகளை அணிந்த ஒரு 'லுக் அஹெட்' (look ahead) சிக்கலாகும்: நுகர்வோர் தான் இருக்கும் நேர முத்திரையில் இன்னும் இல்லாத ஒரு நிலையைப் பார்க்கிறார். பேக் டெஸ்டிங்கில் லுக் அஹெட் பயாஸ் பார் ரெசல்யூஷனில் இதே தோல்வியை உள்ளடக்கியது.

எவ்வளவு தரவு உண்மையில் உள்ளது

ஒரு குறியீட்டின் அறுபது வினாடிகள், வினாடிக்கு வினாடி, ஒரு கேப்சர் உறிஞ்சும் அளவைப் பற்றிய உணர்வைத் தருகிறது.

SELECT
    formatDateTime(toStartOfSecond(toTimeZone(sip_timestamp, 'America/New_York')), '%H:%i:%S') AS et_time,
    count()                                            AS quote_count,
    round(quantileDeterministic(0.5)(gap_us, det), 0)  AS median_gap_us
FROM
(
    SELECT
        sip_timestamp,
        toUnixTimestamp64Micro(sip_timestamp) - toUnixTimestamp64Micro(participant_timestamp) AS gap_us,
        toUInt64(toUnixTimestamp64Micro(sip_timestamp))                                       AS det
    FROM global_markets.cache_stocks_quotes
    WHERE ticker = 'AAPL'
      AND sip_timestamp >= '2026-06-10 13:30:00'
      AND sip_timestamp <  '2026-06-10 13:31:00'
      AND participant_timestamp > '2020-01-01 00:00:00'
)
WHERE gap_us BETWEEN 0 AND 1000000
GROUP BY et_time
ORDER BY et_time

பேனலில் உள்ள முதல் வினாடி, 09:30:00 ET, ஒருங்கிணைக்கப்பட்ட டேப்பில் மட்டும் 528 AAPL மேற்கோள் அப்டேட்டுகளைக் கொண்டிருந்தது, சராசரி கடிகார இடைவெளி 48 மைக்ரோசெகண்டுகள். நிமிடம் 60 வினாடிகளாக மேற்கோள் செயல்பாட்டுடன் பிரிகிறது. அதே நிமிடத்தின் நேரடி ஃபீட் கேப்சர் அதைவிட அதிகமாகக் கொண்டுள்ளது: எக்ஸ்சேஞ்ச் அனுப்பிய ஒவ்வொரு பாக்கெட்டும், ஒருங்கிணைப்பாளர் சுருக்கிய அப்டேட்டுகள் உட்பட, ஒவ்வொன்றும் ஈதர்நெட், IP மற்றும் UDP ஹெடர்களில் மூடப்பட்டிருக்கும்.

மேற்கோள் போக்குவரத்துதான் கேப்சர் டிஸ்க்கை நிரப்புகிறது, மேலும் இந்த விகிதம் பெயர்களுக்கு இடையே ஒரே மாதிரியாக இருப்பதில்லை.

SELECT
    q.symbol                                   AS symbol,
    q.quote_count                              AS quote_count,
    round(q.quote_count / t.trade_count, 1)    AS quotes_per_trade
FROM
(
    SELECT ticker AS symbol, count() AS quote_count
    FROM global_markets.cache_stocks_quotes
    WHERE ticker IN ('AAPL', 'MSFT', 'NVDA', 'SPY', 'KO')
      AND sip_timestamp >= '2026-06-10 13:30:00'
      AND sip_timestamp <  '2026-06-10 14:00:00'
    GROUP BY ticker
) AS q
INNER JOIN
(
    SELECT ticker AS symbol, count() AS trade_count
    FROM global_markets.stocks_trades
    WHERE ticker IN ('AAPL', 'MSFT', 'NVDA', 'SPY', 'KO')
      AND sip_timestamp >= '2026-06-10 13:30:00'
      AND sip_timestamp <  '2026-06-10 14:00:00'
    GROUP BY ticker
) AS t ON q.symbol = t.symbol
WHERE t.trade_count > 0
ORDER BY quotes_per_trade DESC

பேனலில் உள்ள 5 வீட்டுப் பெயர்களில், அதே அரை மணி நேரத்தில், SPY ஒவ்வொரு வர்த்தகத்திற்கும் 11.3 மேற்கோள் செய்திகளை அச்சிட்டது, இது குழுவின் மிக உயர்ந்த விகிதமாகும், 1035147 மேற்கோள் அப்டேட்டுகளில். MSFT பேனலின் மறுமுனையில் 0.8 உடன் இருந்தது. எந்தவொரு பங்கு கேப்சரிலும் மேற்கோள்களே பைட்டுகளின் பெரும்பகுதியாகும், இதனால்தான் புக் ஆழத்தை (depth of book) சேமிப்பது டாப் ஆஃப் புக்கை விட அதிக செலவாகும். லெவல் 1 மற்றும் லெவல் 2 சந்தை தரவு அந்த கூடுதல் செய்திகள் எதைக் கொண்டு செல்கின்றன என்பதை விளக்குகிறது.

ஒரு ரீப்ளே எதை மீண்டும் உருவாக்க வேண்டும்

ஒரு கேப்சர் நீங்கள் இயக்கும் வேகத்தில் ரீப்ளே ஆகிறது, மேலும் பாக்கெட் வாரியான நேர முத்திரைகள் மட்டுமே ரீப்ளேயை நேர்மையாக வைத்திருக்கின்றன. ஒரு அமர்வில் செய்தி விகிதம் நிலையானதாக இருப்பதில்லை.

SELECT
    formatDateTime(toStartOfInterval(toTimeZone(window_start, 'America/New_York'), INTERVAL 15 MINUTE), '%H:%i') AS et_time,
    round(sumIf(transactions, ticker = 'AAPL') / 900, 2) AS aapl_prints_per_sec,
    round(sumIf(transactions, ticker = 'SPY') / 900, 2)  AS spy_prints_per_sec
FROM global_markets.delayed_stocks_minute_aggs
WHERE ticker IN ('AAPL', 'SPY')
  AND window_start >= '2026-06-10 08:00:00'
  AND window_start <  '2026-06-11 00:00:00'
GROUP BY et_time
ORDER BY et_time

ஒரு பிரிண்ட் (print) என்பது பூர்த்தி செய்யப்பட்ட வர்த்தக அறிக்கையாகும். பேனல் ஒவ்வொரு AAPL மற்றும் SPY பிரிண்ட்டையும் நியூயார்க் கடிகாரத்தில் பதினைந்து நிமிட பக்கெட்டுகளாகப் பிரிக்கிறது, வழக்கமான அமர்வை விட முழு மின்னணு நாள் முழுவதும். எந்தவொரு செயல்பாடும் கொண்ட ஆரம்ப பக்கெட், 04:00 ET, 3.12 SPY-க்கு எதிராக 10.45 AAPL பிரிண்ட்டுகளை வினாடிக்கு இயக்கியது. சார்ட்டை வழக்கமான அமர்வுக்குள் வாசித்தால் அதன் வடிவம் கற்பிக்கிறது. ரீப்ளே என்ஜின்கள் பாக்கெட் வாரியான நேர முத்திரையை அடிப்படையாகக் கொண்டு செயல்படுகின்றன மற்றும் செய்திகளை எண்ணுவதற்குப் பதிலாக பாக்கெட்டுகளுக்கு இடையில் உறங்குகின்றன, மேலும் நிலையான விகிதத்தில் கடிகாரமிடப்பட்ட ரீப்ளே அந்த வளைவின் எந்தப் பகுதியையும் மீண்டும் உருவாக்காது.

கேப்சர் எப்போது பயனுள்ளது

நேரம் அல்லது வரிசை குறித்த கேள்வி எழும்போது ஒரு கேப்சர் அதன் சேமிப்பிற்குத் தகுதியானது:

• தாமத அளவீடு (Latency measurement), ஒயர், ஃபீட் ஹேண்ட்லர் மற்றும் ஆர்டர் கேட்வேக்கு இடையே மைக்ரோசெகண்டுகள் எங்கே செல்கின்றன என்பது. உங்கள் சொந்த மென்பொருள் பாக்கெட்டைத் தொடுவதற்கு முன்பு எடுக்கப்பட்ட நேர முத்திரையை ஒரு கேப்சர் மட்டுமே கொண்டுள்ளது.
• இடைவெளி மற்றும் நடுவர் ஆய்வு (Gap and arbitration research), ஒரு ஃபீட் எவ்வளவு அடிக்கடி பாக்கெட்டுகளை இழக்கிறது மற்றும் A மற்றும் B ஃபீட் ஜோடியின் B பக்கம் எவ்வளவு விரைவாக ஓட்டையை நிரப்புகிறது என்பது.
• ஃபீட் ஹேண்ட்லர் சோதனை, அதே புத்தகத்தை மீண்டும் உருவாக்குகிறதா என்று பார்க்க ஒரு புதிய பார்சருக்கு எதிராக உண்மையான அமர்வை மீண்டும் இயக்குவது.
• மறுசீரமைப்பு தகராறுகள், ஒரு குறிப்பிட்ட மைக்ரோசெகண்டில் புத்தகம் எப்படி இருந்தது என்பதை இரு தரப்பினரும் சுயாதீனமாகப் பகுப்பாய்வு செய்யக்கூடிய வடிவத்தில் நிரூபிப்பது.

இயல்பாக்கப்பட்ட ஃபீட் மற்ற எல்லா இடங்களிலும் சிறந்த கருவியாகும். இது இடங்களுக்கு இடையே ஒரு ஸ்கீமாவைக் கொண்டுள்ளது, கார்ப்பரேட் நடவடிக்கைகள் பயன்படுத்தப்படுகின்றன, குறியீடுகள் சுத்தம் செய்யப்படுகின்றன, மேலும் இது நினைவகத்தில் பொருந்துகிறது. பார் ரெசல்யூஷனில் ஆய்வு செய்ய பாக்கெட்டுகளே தேவையில்லை: OHLCV பார்கள் எப்படி உருவாக்கப்படுகின்றன என்பது திரட்டுதல் படியையும் அது விவரங்களை எங்கே மறைக்கிறது என்பதையும் விளக்குகிறது. கேப்சர்கள் டேப் போர்டுகளிலும், ஒவ்வொரு அமர்விலும் வளரும் சேமிப்பகத்திலும் உண்மையான கட்டணத்தைக் கொண்டுள்ளன, தரவு உரிமங்களுக்கு மேலாக, நிகழ்நேர சந்தை தரவு செலவு அதை உடைக்கிறது.

அடிக்கடி கேட்கப்படும் கேள்விகள்

சந்தை தரவில் PCAP கோப்பு என்றால் என்ன?

PCAP கோப்பு என்பது பாக்கெட் கேப்சர் ஆகும்: எக்ஸ்சேஞ்ச் ஃபீட்டின் மூல மல்டிகாஸ்ட் பாக்கெட்டுகள் வந்த வரிசையில் சேமிக்கப்படுகின்றன, ஒவ்வொன்றும் கேப்சர் நேர முத்திரை, சேமிக்கப்பட்ட பைட்டுகளின் எண்ணிக்கை மற்றும் ஒயரில் இருந்த பைட்டுகளின் எண்ணிக்கையைக் கொண்ட 16 பைட் ஹெடரால் முன்னரே குறிக்கப்படுகின்றன. இது ஃபீட்டின் சொந்த பைனரி புரோட்டோகால் கொண்டது, இயல்பாக்கப்பட்ட மேற்கோள் அல்லது வர்த்தகப் பதிவு அல்ல.

சந்தை தரவு PCAP கோப்புகள் ஏன் இவ்வளவு பெரியவை?

ஒவ்வொரு பாக்கெட்டும் ஈதர்நெட், IP மற்றும் UDP ஹெடர்கள் உட்பட முழுமையாக வைக்கப்படுகிறது, மேலும் திரவப் பெயர்களில் (liquid names) வர்த்தகங்களை விட மேற்கோள் அப்டேட்டுகள் அதிகமாக உள்ளன. மேலே உள்ள பேனல் ஒரு அரை மணி நேரத்தில் சில வீட்டுப் பெயர்களுக்கு அந்த விகிதத்தை அளவிட்டது.

கேப்சர் நீளம் மற்றும் அசல் நீளத்திற்கு என்ன வித்தியாசம்?

கேப்சர் நீளம் (incl_len) என்பது கோப்பில் பாக்கெட்டின் எத்தனை பைட்டுகள் உள்ளன என்பது. அசல் நீளம் (orig_len) என்பது ஒயரில் எத்தனை பைட்டுகள் இருந்தன என்பது. அசல் நீளம் அதிகமாக இருக்கும்போது, கேப்சர் ஹோஸ்ட் பாக்கெட்டை அதன் snaplen அமைப்பில் வெட்டியுள்ளது மற்றும் மீதமுள்ளவை வட்டில் எழுதப்படவில்லை.

PCAP கேப்சர்கள் ஏன் நேர முத்திரை வரிசையில் இணைக்கப்பட வேண்டும்?

ஒரு அமர்வு பொதுவாக பல ரோலிங் கோப்புகளாக வருகிறது, மேலும் கோப்பு பெயர் வரிசைப்படுத்துதல் மற்றும் சாதாரண இணைப்பு ஆகிய இரண்டும் பாக்கெட்டுகளை தவறான வரிசையில் வைக்கலாம். வரிசைக்கு மாறான ஸ்ட்ரீமை இயக்கும் நுகர்வோர், மாற்றியமைக்கப்பட்ட அப்டேட்டுகளுக்குப் பிறகு அப்டேட்டுகள் வருவதைப் பார்க்கிறார், சங்கிலியில் எங்கும் பிழை எழுப்பப்படுவதில்லை.

வர்த்தக உத்தியை பேக் டெஸ்ட் செய்ய எனக்கு PCAP தரவு தேவையா?

இல்லை. பார் தரவு மற்றும் இயல்பாக்கப்பட்ட டிக் தரவு பெரும்பாலான ஆராய்ச்சி கேள்விகளுக்குப் பதிலளிக்கின்றன மற்றும் சேமிப்பதற்கும் வினவுவதற்கும் மிகக் குறைந்த செலவே ஆகிறது. தாமதம், பாக்கெட் இழப்பு அல்லது ஒரு அமைப்பு அதன் செய்திகளைப் பார்த்த சரியான வரிசை குறித்து கேள்வி இருக்கும்போது கேப்சர்கள் முக்கியத்துவம் பெறுகின்றன.

இந்தப் பக்கத்தில் உள்ள ஒவ்வொரு பேனலும் அதை உருவாக்கிய SQL உடன் வருகிறது, சார்ட்டின் அடியில் விரிவுபடுத்தலாம். ஒரு அமர்வில் உள்ள செய்திகளை நீங்களே எண்ண, அல்லது ஒரு மேற்கோளில் உள்ள இரண்டு கடிகாரங்களை ஒப்பிட, ஸ்ட்ராஸ்மோர் டெர்மினலில் (Strasmore terminal) எளிய ஆங்கிலத்தில் கேள்வியைக் கேளுங்கள்.