h5i-db: బ్యాక్‌టెస్టింగ్ కోసం పాయింట్-ఇన్-టైమ్ డేటా

పాయింట్-ఇన్-టైమ్ డేటా మరియు బ్యాక్‌టెస్టింగ్

పాయింట్-ఇన్-టైమ్ డేటా అనేది గతంలోని ఒక నిర్దిష్ట తేదీన డేటాసెట్‌లో ఉన్న సమాచారానికి సంబంధించిన రికార్డు. బ్యాక్‌టెస్టింగ్‌లో, ఇది భవిష్యత్తులోని గణాంకాలను ముందే చూసి పొందే ఫలితాల నుండి, వాస్తవికమైన మరియు సమర్థించుకోదగిన ఫలితాలను వేరు చేస్తుంది. h5i-db అనేది ఒక కొత్త ఓపెన్-సోర్స్ టైమ్-సిరీస్ డేటాబేస్. ఇది Rust భాషలో రాయబడి, Python APIని కలిగి ఉంటుంది. ఇది ప్రతి రైట్ (write) ఆపరేషన్‌ను ఒక నంబర్ ఉన్న వెర్షన్‌గా భద్రపరుస్తుంది మరియు ఏదైనా రీడ్ (read) ఆపరేషన్ ద్వారా గతంలోని వెర్షన్‌ను పిన్ (pin) చేయడానికి అనుమతిస్తుంది. ఈ పిన్నింగ్ ప్రక్రియ డేటా లీకేజీని ఎలా అడ్డుకుంటుందో, వాస్తవ ఫైలింగ్ డేటాపై కొలిచిన ఫలితాలు మరియు మీ ల్యాప్‌టాప్‌లో మీరు రన్ చేయగల ఒక దృశ్యం కింద ఇవ్వబడ్డాయి.

డేటా లీకేజీని అడ్డుకోవడం

ఒక కంపెనీ తన ఆర్థిక ఫలితాలను SECకి సమర్పించినప్పుడు, ఆ డేటా వెంటనే అందుబాటులోకి రాదు. ఉదాహరణకు, ఒక కంపెనీ తన 2026-07-01 ఫలితాలను మార్చిలో ప్రకటించవచ్చు, కానీ ఆ డేటాలో డిసెంబర్ చివరి నాటి ఆర్థిక స్థితి ఉంటుంది. ఒకవేళ మీరు ఫిబ్రవరిలో ఒక మోడల్‌ను రన్ చేస్తే, ఆ మోడల్ మార్చిలో వచ్చే డేటాను చూడకూడదు. పాయింట్-ఇన్-టైమ్ డేటా లేకపోతే, మోడల్ తెలియకుండానే భవిష్యత్తులోని సమాచారాన్ని (అంటే మార్చిలో వచ్చిన ఫలితాలను) ఫిబ్రవరి నాటి నిర్ణయాలకు వాడుకుంటుంది. దీనినే డేటా లీకేజీ అంటారు.

h5i-db వంటి డేటాబేస్‌లు ప్రతి ఎంట్రీకి ఒక వెర్షన్ నంబర్‌ను కేటాయిస్తాయి. మీరు ఒక క్వెరీని రన్ చేసినప్పుడు, ఆ క్వెరీ ఏ వెర్షన్ వరకు ఉన్న డేటాను మాత్రమే చూడాలో మీరు నిర్ణయించవచ్చు. దీనివల్ల, మీరు గతంలోని ఒక తేదీని ఎంచుకుని, ఆ సమయానికి అందుబాటులో ఉన్న డేటాతో మాత్రమే మీ బ్యాక్‌టెస్టింగ్‌ను నిర్వహించవచ్చు.

లీకేజీని అడ్డుకోవడానికి అనుసరించాల్సిన పద్ధతులు:

• ప్రతి డేటా పాయింట్‌కు ఒక 'అందుబాటులోకి వచ్చిన తేదీ' (availability date)ని కేటాయించండి.
• బ్యాక్‌టెస్టింగ్ చేసేటప్పుడు, ఆ తేదీని బట్టి డేటాను ఫిల్టర్ చేయండి.
• h5i-dbలో as_of పారామీటర్‌ను ఉపయోగించి గతంలోని వెర్షన్‌లను పిన్ చేయండి.

డేటా లీకేజీని నివారించే విధానం గురించి మరింత సమాచారం కోసం ఇక్కడ క్లిక్ చేయండి.

ఈ విధానం ద్వారా, మీ మోడల్ ఫలితాలు వాస్తవిక మార్కెట్ పరిస్థితులకు అనుగుణంగా ఉంటాయి మరియు భవిష్యత్తులోని సమాచారం వల్ల కలిగే తప్పుడు లాభాల అంచనాలను నివారించవచ్చు.

ల్యాప్‌టాప్ దృశ్యం: ఒక ఉదాహరణ

NVDA: స్టాక్ డేటాను ఉపయోగించి ఒక చిన్న బ్యాక్‌టెస్ట్ దృశ్యాన్ని పరిశీలిద్దాం.

1. h5i-dbని ఇన్‌స్టాల్ చేయండి.
2. గత రెండు సంవత్సరాల డేటాను లోడ్ చేయండి.
3. ఒక నిర్దిష్ట తేదీని ఎంచుకుని, ఆ తేదీ నాటికి ఉన్న P/E మరియు EPS విలువలను మాత్రమే పరిగణనలోకి తీసుకోండి.
4. ఆ డేటాతో మీ వ్యూహాన్ని పరీక్షించండి.
5. ఇప్పుడు, భవిష్యత్తులోని డేటాను కలిపి అదే పరీక్షను మళ్ళీ చేయండి. ఫలితాల్లో వచ్చే వ్యత్యాసమే డేటా లీకేజీ ప్రభావం.

బ్యాక్‌టెస్ట్‌లో పాయింట్-ఇన్-టైమ్ డేటా అంటే ఏమిటి?

ప్రతి మార్కెట్ వాస్తవానికి రెండు టైమ్‌స్టాంపులు ఉంటాయి. ఈవెంట్ టైమ్ అంటే ఒక సంఘటన జరిగిన సమయం. అరైవల్ టైమ్ అంటే ఆ సమాచారం రిపోర్ట్ చేసిన సంస్థ వెలుపల ఉన్న ఎవరికైనా తెలిసే సమయం. ఒక త్రైమాసిక హోల్డింగ్స్ రిపోర్ట్, ఆ త్రైమాసికం చివరి రోజున ఉన్న పొజిషన్లను వివరిస్తుంది, కానీ అది ప్రజలకు చేరడానికి వారాల సమయం పడుతుంది. కాబట్టి, కేవలం ఈవెంట్ టైమ్ ఆధారంగా డేటాను కలిపే మోడల్‌కు, అప్పట్లో ఎవరికీ తెలియని సమాచారం అందుతుంది.

ఈ వ్యత్యాసాన్ని కొలవవచ్చు. ఇన్‌స్టిట్యూషనల్ మేనేజర్లు ప్రతి త్రైమాసికం ముగిసిన తర్వాత Form 13F ఫైల్ చేస్తారు. కింద ఉన్న ప్యానెల్, ఒక ఫైలింగ్ వివరించే త్రైమాసికానికి మరియు అది ఫైల్ చేసిన రోజుకు మధ్య ఉన్న రోజులను లెక్కిస్తుంది.

WITH per_filing AS
(
    SELECT
        accession_number,
        any(toDate(parseDateTimeBestEffortOrNull(toString(period)))) AS period_end,
        any(toDate(filing_date))                                     AS filed_on
    FROM global_markets.stocks_13f_filings
    WHERE filing_date >= '2023-01-01'
    GROUP BY accession_number
)
SELECT
    toString(period_end)                                 AS period_end_date,
    countDistinct(accession_number)                      AS filings_count,
    round(avg(dateDiff('day', period_end, filed_on)), 1) AS avg_days_to_public
FROM per_filing
WHERE period_end IS NOT NULL
  AND filed_on >= period_end
  AND filed_on <= period_end + 400
GROUP BY period_end
HAVING filings_count >= 100
ORDER BY period_end

2026-06-30తో ముగిసిన త్రైమాసికానికి సంబంధించి, 10688 ఫైలింగ్‌లు అవి కవర్ చేసే కాలం తర్వాత సగటున 34.1 రోజుల వ్యవధిలో అందాయి. ఈ ప్యానెల్ ఆ కొలతను 16 త్రైమాసికాల వరకు పునరావృతం చేస్తుంది. ఒక మేనేజర్ రిపోర్ట్ ఫైల్ చేసిన చాలా కాలం తర్వాత కూడా దానిని సవరించవచ్చు, కాబట్టి గత తేదీని వివరించే రికార్డు ఆ తేదీ గడిచిన తర్వాత కూడా మారుతూనే ఉంటుంది.

Look-ahead bias అనేది ఒక స్టోరేజ్ సమస్య

backtestingలో look-ahead biasపై మా గైడ్, డేటా లీకేజీని ఒక క్రమశిక్షణగా పరిగణిస్తుంది: ప్రతి ఫీచర్‌ను లాగ్ చేయండి మరియు ప్రచురణ తేదీలను గౌరవించండి. ఎవరైనా మర్చిపోయే వరకు ఈ క్రమశిక్షణ కొనసాగుతుంది, ఆ వైఫల్యం నిశ్శబ్దంగా ఉంటుంది. లీక్ అయిన backtest మెరుగైన Sharpe ratioను చూపిస్తుంది, కానీ ఎటువంటి లోపాన్ని చూపదు.

Point-in-time స్టోరేజ్ ఈ హామీని ఒక స్థాయి కిందికి మారుస్తుంది. ఒక వ్యూహానికి అందించిన డేటా ఫ్రేమ్, ఒక వెర్షన్‌కు పిన్ చేయబడిన రీడ్ నుండి వచ్చినప్పుడు, ఆ వెర్షన్ తర్వాత రాసిన రో (row) అందులో కనిపించదు, వ్యూహ కోడ్ తర్వాత ఏమి చేసినా సరే. ఈ తనిఖీ కోడ్ రివ్యూగా కాకుండా, రీడ్ యొక్క ఒక లక్షణంగా మారుతుంది.

డివిడెండ్లు ఈ టైమింగ్ గ్యాప్‌ను మరో కోణం నుండి చూపిస్తాయి. నగదు డివిడెండ్ మొదట ప్రకటించబడుతుంది మరియు తర్వాత ex-date వస్తుంది. ఈరోజు లోడ్ చేసిన టేబుల్‌లో ప్రతి చెల్లింపుకు రెండు తేదీలు ఉంటాయి, సిమ్యులేషన్ చేస్తున్న తేదీన ఇంకా ప్రకటించని డివిడెండ్లు కూడా అందులో ఉంటాయి.

SELECT
    toString(toStartOfMonth(ex_dividend_date))                         AS month,
    round(avg(dateDiff('day', declaration_date, ex_dividend_date)), 1) AS avg_days_announced_ahead,
    countDistinct(ticker)                                              AS payers_count
FROM global_markets.stocks_dividends
WHERE ex_dividend_date >= toStartOfMonth(today() - 730)
  AND ex_dividend_date <  toStartOfMonth(today())
  AND declaration_date >= '1990-01-01'
  AND declaration_date <= ex_dividend_date
GROUP BY month
ORDER BY month

2026-07-01లో ప్రారంభమైన నెలలో, డివిడెండ్ ప్రకటనలు ex-dividend date కంటే సగటున 88.2 రోజుల ముందు వచ్చాయి. ఈ ప్యానెల్ అదే కొలతకు సంబంధించిన 24 నెలల కాలాన్ని కవర్ చేస్తుంది. ఆ గ్యాప్ మధ్యలో ఉన్న ఒక సిమ్యులేటెడ్ తేదీన ఆధునిక డివిడెండ్ టేబుల్‌ను పరిశీలిస్తే, ప్రకటన రావడానికి కొన్ని వారాల ముందే ఆ చెల్లింపు వివరాలు అక్కడ కనిపిస్తాయి.

నిల్వ ఉన్న చరిత్ర తిరిగి రాయబడుతుంది

ఆలస్యంగా రావడం ఒక వైఫల్య మార్గం అయితే, పునఃప్రచురణ (restatement) మరొకటి. కార్పొరేట్ చర్యలు ఇప్పటికే నమోదైన ధరలను మారుస్తాయి: నాలుగు-కు-ఒకటి (4-for-1) స్ప్లిట్ జరిగిన తర్వాత, సర్దుబాటు చేసిన సిరీస్‌లోని ప్రతి పాత ధరను నాలుగుతో భాగిస్తారు. దీనివల్ల ఈరోజు డౌన్‌లోడ్ చేసిన సిరీస్, ఒక ట్రేడర్ గతంలో చూసిన ధరలతో సరిపోలదు. స్ప్లిట్-సర్దుబాటు చేసిన ధరల చరిత్రపై మా నోట్ ఈ గణితాన్ని వివరిస్తుంది. ఇక్కడ ముఖ్యమైనది దాని పౌనఃపున్యం (frequency).

SELECT
    toString(toStartOfQuarter(execution_date))    AS quarter_start_date,
    countDistinctIf(id, split_to > split_from)    AS forward_splits,
    countDistinctIf(id, split_to < split_from)    AS reverse_splits
FROM global_markets.stocks_splits
WHERE execution_date >= toStartOfQuarter(today() - 1460)
  AND execution_date <  toStartOfQuarter(today())
  AND split_from > 0
  AND split_to   > 0
GROUP BY quarter_start_date
ORDER BY quarter_start_date

2026-04-01లో ప్రారంభమైన త్రైమాసికంలో, 131 ఫార్వర్డ్ స్ప్లిట్లు మరియు 303 రివర్స్ స్ప్లిట్లు అమల్లోకి వచ్చాయి. ప్రతి ఒక్కటి పరిశోధనా పైప్‌లైన్‌లో ఇప్పటికే నిల్వ ఉన్న ధరల చరిత్రను మారుస్తుంది. వెర్షన్డ్ స్టోరేజ్ (versioned storage) ఈ పునఃప్రచురణను ఆపలేదు. ఇది కొత్త స్థితిని ఒక కొత్త వెర్షన్‌గా నమోదు చేసి, పాత దానిని చదవగలిగేలా ఉంచుతుంది. ఇదే పాత ఫలితాన్ని పునరుత్పత్తి చేయదగినదిగా మారుస్తుంది.

వార్తల టైమ్‌స్టాంపులు కూడా చిన్న స్థాయిలో ఇదే సమస్యను కలిగి ఉంటాయి.

SELECT
    formatDateTime(toTimeZone(published_utc, 'America/New_York'), '%H:00') AS et_hour,
    countDistinct(id)                                                     AS articles
FROM global_markets.stocks_news
WHERE published_utc >= today() - 90
GROUP BY et_hour
ORDER BY et_hour

న్యూయార్క్ రోజులోని మొత్తం 24 గంటల పాటు హెడ్‌లైన్లు నిరంతరం ప్రచురితమవుతాయి. గత 90 రోజులలో 09:00 గంటల సమయంలో 790 కథనాలు వచ్చాయి, అలాగే 20:00 గంటల సమయంలో 404 కథనాలు వచ్చాయి. సాయంత్రం వచ్చిన హెడ్‌లైన్‌ను ఆ రోజు సాయంత్రం 4:00 గంటల ముగింపు ధరతో జత చేయడం వల్ల, క్లోజ్ ట్రేడింగ్ చేసే వ్యూహానికి కొన్ని గంటల ముందస్తు సమాచారం (hindsight) అందినట్లు అవుతుంది.

మీరు అమలు చేయగల ఒక పాయింట్-ఇన్-టైమ్ దృశ్యం

ఇక్కడ ఉన్నవన్నీ పైథాన్ ప్యాకేజీపైనే ఉంటాయి. ఈ ప్రాజెక్ట్ ఒక రస్ట్ కమాండ్ లైన్ టూల్‌ను కూడా కలిగి ఉంది, ఇది ఒక ప్రత్యేక ఇన్‌స్టాల్, ఈ వాక్‌త్రూకి దాని అవసరం లేదు. నమూనా డేటా స్థానికంగానే రూపొందించబడుతుంది, ఎటువంటి డౌన్‌లోడ్ అవసరం లేదు.

1. పిన్ చేసిన రిలీజ్ pip install 'h5i-db==0.1.6'ని ఇన్‌స్టాల్ చేయండి, ఇది 4 ఆగస్టు 2026న ప్రచురించబడింది. దీనికి పైథాన్ 3.9 లేదా అంతకంటే కొత్త వెర్షన్ కావాలి మరియు ఇది pyarrow>=14ని తీసుకువస్తుంది. ముందే నిర్మించిన వీల్స్ (wheels) Linux (x86-64 మరియు arm64), ఆపిల్ సిలికాన్ macOS మరియు Windows (x86-64) లపై పనిచేస్తాయి.
2. import pyarrow as pa మరియు import pyarrow.parquet as pq తర్వాత డేటాను ఒకసారి వివరించండి: schema = pa.schema([('ts', pa.timestamp('us', tz='UTC')), ('symbol', pa.string()), ('price', pa.float64())]).
3. pq.write_table(pa.table({'ts': [d1, d2], 'symbol': ['ACME', 'ACME'], 'price': [10.0, 10.5]}, schema=schema), 'day1.parquet')ని ఉపయోగించి స్థానిక ఫైల్‌కు రెండు కల్పిత అడ్డు వరుసలను (rows) రాయండి, ఇక్కడ d1 మరియు d2 అనేవి టైమ్‌జోన్-అవేర్ డేట్‌టైమ్‌లు.
4. డేటాబేస్ మరియు టేబుల్‌ను సృష్టించండి, టైమ్ కాలమ్‌కు పేరు పెట్టండి: db = h5i_db.Database('pit.db', create=True) ఆపై db.create_table('prices', schema, time_column='ts').
5. ఒక కీ కింద ఫైల్‌ను ఇన్‌జెస్ట్ చేయండి: db.append('prices', pq.read_table('day1.parquet'), idempotency_key='load-day1'). ఈ కాల్ అది చేసిన కమిట్‌ను తిరిగి ఇస్తుంది.
6. అదే లైన్‌ను మళ్ళీ అమలు చేయండి. అదే కీని కలిగి ఉన్న రిపీట్, అది ఇప్పటికే సృష్టించిన కమిట్‌ను కనుగొని, రెండవసారి అడ్డు వరుసలను రాయడానికి బదులుగా "segments_added": 0తో దానిని తిరిగి ఇస్తుందని ప్రాజెక్ట్ డాక్యుమెంట్ చేస్తుంది. రీట్రైకి ఇరువైపులా db.versions('prices')ని ప్రింట్ చేయండి మరియు వెర్షన్ జాబితా మారకుండా ఉండటాన్ని గమనించండి.
7. idempotency_key='load-day2' కింద రెండవ రోజు డేటాను ఇన్‌జెస్ట్ చేయండి, ఆపై రెండింటిలోనూ క్వెరీ చేయండి: db.sql('SELECT symbol, count(*) AS n, avg(price) AS px FROM prices GROUP BY symbol').to_pandas().
8. రెండవ రోజు డేటా చేరకముందు టేబుల్ ఎలా ఉందో అలా చదవండి: db.read('prices', version=1). అదే పని కోసం ఈ పద్ధతి as_of= మరియు snapshot= ఆర్గ్యుమెంట్లను తీసుకుంటుంది.

స్టెప్ 6ని జాగ్రత్తగా గమనించాలి. డూప్లికేట్ అపెండ్ ఎటువంటి ఎర్రర్‌ను చూపదు. ఇది ఆ క్షణం నుండి టేబుల్‌ను తప్పుగా ఉంచుతుంది, మరియు ఆ తర్వాత జరిగే ప్రతి రన్ ఆ నష్టాన్ని నిశ్శబ్దంగా వారసత్వంగా పొందుతుంది. స్టెప్ 8 అనేది ఫలితం: మార్చిలో లెక్కించిన సంఖ్యను అదే పిన్ చేసిన వెర్షన్ నుండి ఆగస్టులో తిరిగి లెక్కించవచ్చు, ఇదే reproducible backtest గురించి మా వివరణ ఫ్రేమ్‌వర్క్ స్థాయిలో వాదించే అంశం.

ప్రాజెక్ట్ ఏమి చెబుతోంది, మేము ఏమి పరిశీలించాము

README ఒక బెంచ్‌మార్క్‌తో ప్రారంభమవుతుంది:

20 మిలియన్ల వరుసల OHLCV+VWAP రోలప్‌లపై DuckDB మరియు Polars కంటే 4.5 రెట్లు వేగవంతమైనది

ఈ గణాంకం ప్రాజెక్ట్ స్వయంగా కొలిచినది, ఇది ఆగస్టు 2026లో సేకరించిన h5i-db README నుండి ఉదహరించబడింది. మేము దీనిని పరీక్షించలేదు, పైన పేర్కొన్న ఏ అంశం కూడా దీనిపై ఆధారపడి లేదు.

ఇక్కడ వేగం కంటే పరిణతి (maturity) ముఖ్యం. ఈ వ్యాసం రాసే సమయానికి ఈ రిపోజిటరీకి 29 స్టార్‌లు ఉన్నాయి మరియు ఇది Apache-2.0 లైసెన్స్ కింద 0.1.6 వెర్షన్‌లో ఉంది. దీని అర్థం దీనిని నిర్వహించే వారి సంఖ్య తక్కువ మరియు పాయింట్ రిలీజ్‌ల మధ్య API మారే అవకాశం ఉంది. ఈ ఇంజిన్ భారీ లోడ్‌తో పనిచేసిన సుదీర్ఘమైన పబ్లిక్ రికార్డు ఏదీ లేదు. ఖచ్చితమైన వెర్షన్‌ను పిన్ చేయడం మరియు డేటాబేస్‌కు అందించిన parquet ఫైళ్లను భద్రపరచడం ద్వారా, ఏదైనా రిలీజ్ వల్ల పనితీరు మారితే తిరిగి పాత స్థితికి వెళ్లే అవకాశం ఉంటుంది. మీ వద్ద ముడి డేటా కాపీని ఉంచుకోవడం అనేది, వెండర్లు మీ డేటాను మార్చివేసే ప్రమాదం నుండి రక్షణ కల్పించే అలవాటు వంటిదే. స్టాక్ డేటాలో సర్వైవర్‌షిప్ బయాస్ అంతటా ఇదే అంశం కనిపిస్తుంది.

తరచుగా అడిగే ప్రశ్నలు (FAQ)

పాయింట్-ఇన్-టైమ్ (point-in-time) డేటా అంటే ఏమిటి?

పాయింట్-ఇన్-టైమ్ డేటా అనేది ప్రతి వాస్తవం ఎప్పుడు తెలిసిందో ఆ సమయ ముద్రలతో (timestamps) నిల్వ చేయబడిన డేటాసెట్. దీనివల్ల గతంలో ఏదైనా తేదీన ఏ సమాచారం అందుబాటులో ఉందో ఒక క్వెరీ ద్వారా తిరిగి తెలుసుకోవచ్చు. సాధారణ "లేటెస్ట్ వాల్యూ" టేబుల్ అలా చేయలేదు, ఎందుకంటే అది పాత డేటాను నేటి సవరించిన సంఖ్యలతో భర్తీ చేస్తుంది.

వెర్షన్డ్ స్టోరేజ్ (versioned storage) లుక్-అహెడ్ బయాస్‌ను తొలగిస్తుందా?

లేదు. వెర్షనింగ్ అనేది ఒక రకమైన డేటా లీకేజీని మాత్రమే సరిచేస్తుంది; అంటే సిమ్యులేటెడ్ నిర్ణయ సమయం తర్వాత రాసిన విలువలను చదవడం వంటివి. ఫీచర్ కన్‌స్ట్రక్షన్ ఇతర మార్గాల్లో కూడా లీకేజీకి దారితీయవచ్చు, ఉదాహరణకు ఒక శాంపిల్‌ను దాని పూర్తి చరిత్రపై లెక్కించిన గణాంకాలతో స్కేల్ చేయడం వంటివి.

ఇన్‌జెస్ట్ (ingest) సమయంలో ఐడెంపోటెన్సీ కీ (idempotency key) ఏమి చేస్తుంది?

ఇది ఒక రైట్ (write) ఆపరేషన్‌ను లేబుల్ చేస్తుంది, తద్వారా రీట్రై (retry) చేసినప్పుడు అది అదే రైట్ అని సిస్టమ్ గుర్తిస్తుంది. దీనివల్ల క్రాష్ తర్వాత లోడర్ మళ్లీ రన్ అయినప్పుడు, ఒకే వరుసలను రెండుసార్లు జోడించదు. ఇలా జరగకపోతే టేబుల్‌లో డేటా తప్పుగా నమోదయ్యే ప్రమాదం ఉంది.

h5i-db ప్రొడక్షన్‌కు సిద్ధంగా ఉందా?

ఇది వెర్షన్ 0.1.6, ఈ వ్యాసం రాసే సమయానికి GitHubలో 29 స్టార్లను కలిగి ఉంది మరియు Apache-2.0 లైసెన్స్ కింద ఉంది. ఆ పరిమాణంలో ఉన్న ప్రారంభ సాఫ్ట్‌వేర్‌లో API మార్పులు ఎక్కువగా ఉండవచ్చు మరియు పబ్లిక్ ట్రాక్ రికార్డ్ తక్కువగా ఉండవచ్చు. కాబట్టి, వెర్షన్ పిన్ చేయడం మరియు సోర్స్ ఫైల్స్ యొక్క సొంత కాపీని ఉంచుకోవడం ద్వారా మీ మూల్యాంకనాన్ని సురక్షితంగా ఉంచుకోవచ్చు.

పైన ఉన్న ప్రతి ప్యానెల్ దానిని రూపొందించిన SQLతో వస్తుంది, కాబట్టి ఒకదాన్ని తెరిచి ఆ సంఖ్యను ఎలా లెక్కించారో చదవండి. Strasmore టెర్మినల్‌లో సాధారణ ఆంగ్లంలో కూడా ఇలాంటి ప్రశ్నలనే అడగవచ్చు.