reports மற்றும் ML-க்கான high-volume event-tracking pipeline வடிவமைக்கவும் — எந்த stack?

Question

IT Interview Practice · Accepted Answer

நாளொன்றுக்கு நூற்றுக்கணக்கான மில்லியன் events (~ஒரு சில ஆயிரம்/வினாடி, peaks-இல் அதிகம்) என்ற அளவில் வெற்றிகரமான நகர்வு என்னவென்றால் **ingestion-ஐ serving-இலிருந்து decouple செய்வது**: writes-ஐ ஒரு durable log-க்குள் உள்வாங்கி, stream-ஐ **ஒருமுறை** process செய்து, **எதிரெதிர் வேலைகளுக்குத் tune செய்யப்பட்ட இரண்டு stores-க்கு** fan out செய்வது — parents-க்குப் pre-aggregated (fast reads), ML-க்கு raw மற்றும் full-fidelity.

**சிந்தனை மாதிரி:** ஒரு mailroom — collector அஞ்சலைப் பெறுகிறது, Kafka என்பது conveyor belt, மேலும் ஒவ்வொரு பொருளும் இரண்டு shelves-க்குள் நகல் எடுக்கப்படுகிறது: parents பார்க்கும் *summary board*, மற்றும் ML குழு தோண்டும் *full archive*.

## Write path (ingest)

```text
Client ─(batch)─▶ Collector ─▶ Kafka ─▶ Stream proc ─┬─▶ OLAP rollup  (daily summaries)
 (learning app)    (HTTP)     (buffer,   (read once)  └─▶ S3 / Parquet (raw events)
                              replay)
```

- **Collector** HTTP வழியாக **batched** events-ஐப் பெறுகிறது — client-இல் batching செய்வது நூற்றுக்கணக்கான மில்லியன் சிறிய writes-ஐ மிகக் குறைவான requests-ஆக மாற்றுகிறது.
- **Kafka** என்பது durable buffer: அது spikes-ஐ உள்வாங்கி, producers-ஐ consumers-இலிருந்து decouple செய்து, ML ஒரு feature சேர்க்கும்போது அல்லது நீங்கள் புதிய rollup அறிமுகப்படுத்தும்போது history-ஐ **replay** செய்ய அனுமதிக்கிறது.
- **Stream processor** Kafka-ஐ ஒருமுறை படித்து இரண்டு sinks-க்கும் எழுதுகிறது — lake-க்கு raw-ஐ append செய்து, reports-க்கு rollups-ஐ upsert செய்கிறது.

```js
// ஒரு consumer Kafka-ஐ ஒருமுறை படித்து இரண்டு sinks-க்கும் எழுதுகிறது
for await (const batch of kafka.consume('events')) {
  await lake.appendParquet(batch);                      // raw -> S3/Parquet (ML)
  for (const e of batch)
    rollup.add({ childId: e.childId, day: dayOf(e.ts) },// aggregate -> OLAP (reports)
               { lessons: 1, studiedMs: e.studiedMs ?? 0 });
  await rollup.flush();
}
```

## Read path (serving)

```text
Parent app ─▶ API ─▶ OLAP rollup                 (pre-aggregated: report = O(1), no scan)
ML / Data  ─▶ Spark / warehouse ─▶ S3 / Parquet  (raw, flexible, ad-hoc)
```

Parents **pre-aggregated summaries**-ஐ hit செய்கிறார்கள், எனவே ஒரு report என்பது ஒரு key lookup, ஒருபோதும் பில்லியன் கணக்கான rows மேல் scan அல்ல. ML **raw lake**-ஐ query செய்கிறது, feature engineering-க்காக ஒவ்வொரு field-ஐயும் வைத்துக்கொள்கிறது.

## Stack & ஏன்
- **Kafka** — buffer, decouple, replay.
- **ClickHouse / daily summary tables** — parent dashboards-க்கு read-optimized.
- **S3 + Parquet** — ML-க்கு மலிவான, columnar, நெகிழ்வான raw storage.
- **Schema registry** — event contract-ஐ enforce செய்கிறது, எனவே producers consumers-ஐ அமைதியாக break செய்ய முடியாது.

## நேர்காணல் பார்வை
**Write-optimized ingest-ஐ read-optimized serving-இலிருந்து** நீங்கள் பிரிக்கிறீர்களா, ஒவ்வொரு parent report-க்கும் raw events-ஐ scan செய்வதைத் தவிர்க்கிறீர்களா, மேலும் ML-க்காக raw data-ஐ வைத்துக்கொள்கிறீர்களா என்பதை நேர்காணல் செய்பவர் ஆராய்கிறார். **பலவீனம்:** "எல்லாவற்றையும் Postgres-இல் போட்டு query செய்." **வலிமை:** durable buffer + இரண்டு serving paths + replay + ஒரு schema contract, அளவைப் பற்றிய உணர்வுடன்.

## Trade-offs
Pre-aggregation உடனடி reads தருகிறது ஆனால் dimensions-ஐ முன்கூட்டியே நிர்ணயிக்கிறது; raw lake நெகிழ்வானது ஆனால் மெதுவானது. **இரண்டையும்** வைத்துக்கொள்ளுங்கள் — classic write-once, read-many பிரிவு.

Write path (ingest)

Read path (serving)

Stack & ஏன்

நேர்காணல் பார்வை

Trade-offs

தொடர்புடைய கேள்விகள்