ออกแบบ pipeline ติดตาม event ปริมาณสูงสำหรับรายงานและ ML — เลือก stack ไหน?

Question

IT Interview Practice · Accepted Answer

ที่ระดับหลายร้อยล้าน event/วัน (~ไม่กี่พัน/วินาที สูงกว่านั้นในช่วงพีค) หมากที่ชนะคือ แยก ingestion ออกจาก serving: ดูดซับ write เข้าสู่ log ที่ทนทาน, ประมวลผล stream เพียงครั้งเดียว, แล้วกระจายออกไปยัง สอง store ที่จูนมาสำหรับงานตรงข้ามกัน — pre-aggregated สำหรับผู้ปกครอง (อ่านเร็ว) และแบบ raw ความละเอียดเต็มสำหรับ ML

ห้องรับส่งจดหมาย — collector รับจดหมาย, Kafka คือสายพานลำเลียง, และทุกชิ้นถูกคัดลอกลงสองชั้นวาง: ที่ผู้ปกครองเหลือบมอง และ ที่ทีม ML ขุดค้น

**แบบจำลองความคิด:** ห้องรับส่งจดหมาย — collector รับจดหมาย, Kafka คือสายพานลำเลียง, และทุกชิ้นถูกคัดลอกลงสองชั้นวาง: *กระดานสรุป* ที่ผู้ปกครองเหลือบมอง และ *คลังฉบับเต็ม* ที่ทีม ML ขุดค้น

## 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** รับ event ที่ถูก **batch** มาผ่าน HTTP — การ batch ที่ฝั่ง client เปลี่ยน write เล็ก ๆ หลายร้อยล้านครั้งให้เป็นจำนวน request ที่น้อยลงมาก
- **Kafka** คือ buffer ที่ทนทาน: มันดูดซับ spike, แยก producer ออกจาก consumer, และให้คุณ **replay** ประวัติได้เมื่อ ML เพิ่ม feature หรือคุณเพิ่ม rollup ใหม่
- **Stream processor** อ่าน Kafka ครั้งเดียวแล้วเขียนลงทั้งสอง sink — append raw ลง lake, upsert rollups สำหรับรายงาน

```js
// consumer ตัวเดียวอ่าน Kafka ครั้งเดียวและเขียนลงทั้งสอง sink
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)
```

ผู้ปกครองเข้าถึง **สรุปที่ pre-aggregated ไว้แล้ว** ดังนั้นรายงานหนึ่งจึงเป็นการ lookup ด้วย key ไม่ใช่การ scan ข้อมูลนับพันล้านแถว ML query จาก **raw lake** โดยเก็บทุกฟิลด์ไว้สำหรับ feature engineering

## Stack และเหตุผล
- **Kafka** — buffer, decouple, replay
- **ClickHouse / ตารางสรุปรายวัน** — จูนมาเพื่ออ่านสำหรับ dashboard ผู้ปกครอง
- **S3 + Parquet** — เก็บ raw แบบ columnar ราคาถูก ยืดหยุ่น สำหรับ ML
- **Schema registry** — บังคับ contract ของ event เพื่อไม่ให้ producer ทำ consumer พังเงียบ ๆ

## มุมมองของผู้สัมภาษณ์
ผู้สัมภาษณ์ตรวจว่าคุณแยก **ingest ที่จูนเพื่อ write ออกจาก serving ที่จูนเพื่อ read** หรือไม่, หลีกเลี่ยงการ scan raw event ทุกครั้งที่ทำรายงานให้ผู้ปกครอง, และเก็บ raw data ไว้สำหรับ ML **อ่อน:** "โยนทุกอย่างลง Postgres แล้ว query เอา" **แข็งแรง:** buffer ที่ทนทาน + สอง serving path + replay + schema contract พร้อมความเข้าใจในสเกล

## Trade-offs
Pre-aggregation ให้การอ่านทันทีแต่ตรึงมิติ (dimensions) ไว้ล่วงหน้า; raw lake ยืดหยุ่นแต่ช้า ให้เก็บ **ทั้งสอง** — การแยกแบบคลาสสิก write-once, read-many

Write path (ingest)

Read path (serving)

Stack และเหตุผล

มุมมองของผู้สัมภาษณ์

Trade-offs

คำถามที่เกี่ยวข้อง