Belajar IoT Engineer - Data Ingestion & Pipeline

#Pendahuluan

Perangkat kalian sudah mengirim telemetry ke cloud di episode 7. Pertanyaan besarnya: setelah sampai, datanya mau diapakan? Di sinilah pipeline data bekerja — mengubah arus pesan mentah menjadi data yang bisa dianalisis, dimonitor, dan diambil keputusan.

Mengapa pipeline penting? IoT menghasilkan data dalam volume besar dan terus-menerus. Tanpa pipeline yang benar, data akan: hilang saat lonjakan, tersimpan mentah tanpa metadata, atau menumpuk dengan biaya penyimpanan yang membengkak. Pipeline yang baik menjawab tiga pertanyaan: bagaimana data masuk, bagaimana mengalir, dan di mana disimpan.

#Arsitektur Pipeline Data IoT

Pipeline klasik IoT memiliki tahapan:

1. Ingestion — platform menerima pesan MQTT dan memvalidasi identitas perangkat.
2. Transformation — rule engine menyaring, menormalkan, dan menambah metadata.
3. Streaming/Queue — buffer sementara agar data tidak hilang saat penerima lambat (SQS, Kafka, Pub/Sub).
4. Storage — data disimpan di media sesuai kebutuhan akses: cepat untuk dashboard, murah untuk arsip.
5. Consumption — dashboard, alerting, dan machine learning membaca dari storage.

#Hot vs Cold Storage

Telemetry IoT punya dua kebutuhan penyimpanan yang bertolak belakang:

Pola standar: data masuk ke hot storage untuk query cepat dan dashboard, lalu data yang sudah tua di-archived ke cold storage untuk kepatuhan dan analitik historis. Aturan praktis: simpan granular penuh hanya beberapa minggu, lalu turunkan resolusi (downsampling) dan arsipkan.

#Desain Skema Telemetry

Sebelum membangun pipeline, desain dulu skema datanya. Telemetry IoT punya tiga bagian penting: identitas, nilai, dan waktu.

{
  "device_id": "ruang-01",
  "site": "jakarta-utara",
  "sensor_type": "bme280",
  "values": {
    "temperature": 26.5,
    "humidity": 61.0,
    "pressure": 1009.2
  },
  "ts": 1786900000,
  "seq": 1042
}

Aturan desain skema:

• Satu pesan = satu pembacaan sensor — jangan mencampur banyak perangkat dalam satu payload.
• Sertakan timestamp — ts dihasilkan di perangkat, bukan di platform; koneksi yang lambat membuat waktu tiba ≠ waktu ukur.
• Sertakan sequence number — memudahkan mendeteksi pesan hilang/duplikat.
• Gunakan unit yang konsisten — tulis di metadata atau nama field (temperature_c).

#Praktik: Pipeline dengan AWS IoT + InfluxDB

Kita bangun pipeline: ESP32 → AWS IoT Core → Rule → InfluxDB. Aturan (rule) di AWS memakai SQL:

SELECT
  deviceid AS device_id,
  temperature,
  humidity,
  timestamp() AS ts
FROM 'sensor/+/telemetry'
WHERE temperature IS NOT NULL

Rule ini memvalidasi: hanya pesan yang punya temperature yang diteruskan. Action rule dikirim ke Amazon Timestream (time series native AWS) atau ke Lambda yang menulis ke InfluxDB/self-managed. Untuk belajar lokal, kita pakai InfluxDB:

services:
  influxdb:
    image: influxdb:2.7
    ports:
      - "8086:8086"
    environment:
      DOCKER_INFLUXDB_INIT_MODE: setup
      DOCKER_INFLUXDB_INIT_USERNAME: admin
      DOCKER_INFLUXDB_INIT_PASSWORD: admin123
      DOCKER_INFLUXDB_INIT_ORG: iot-lab
      DOCKER_INFLUXDB_INIT_BUCKET: telemetry

docker compose up -d

Setiap telemetry masuk, data ditulis sebagai point InfluxDB — kombinasi measurement, tag, dan field:

influx query 'from(bucket: "telemetry")
  |> range(start: -1h)
  |> filter(fn: (r) => r._measurement == "environment")
  |> filter(fn: (r) => r._field == "temperature")'

_result: environment,host=ruang-01 _field=temperature 26.5 2026-08-16T04:10:00Z
_result: environment,host=ruang-01 _field=temperature 26.9 2026-08-16T04:11:00Z

#Pola Streaming: Buffer dan Backpressure

Ketika volume besar, jangan tulis langsung ke storage dari rule. Selipkan queue/streaming sebagai buffer:

IoT Platform → SQS/Kafka → Consumer (batch) → InfluxDB/S3

Buffer menyerap lonjakan — jika InfluxDB melambat, pesan menunggu di queue, tidak hilang. Backpressure (tekanan balik) adalah mekanisme yang memberi tahu hulu untuk memperlambat saat hilir kewalahan. Di episode 12 dan 21 kita bahas scaling pipeline lebih dalam.

#Kesalahan Umum

1. Tanpa timestamp dari perangkat — waktu tiba cloud ≠ waktu kejadian; analitik jadi bias.
2. Menulis langsung ke storage tanpa buffer — lonjakan data membuat storage kewalahan dan data hilang.
3. Skema berubah-ubah — satu perangkat mengirim temp, perangkat lain temperature; normalkan di pipeline.
4. Menabung semua granularity selamanya — biaya membengkak; terapkan downsampling dan archiving.
5. Tanpa monitoring pipeline — kalian baru tahu pipeline mati setelah dashboard kosong berhari-hari; pantau lag dan error rate.

#Penutup

Inti yang harus dibawa pulang:

• Pipeline IoT: ingestion → transformation → streaming → storage → consumption.
• Gunakan hot storage (InfluxDB/TimescaleDB) untuk akses cepat, cold storage (S3) untuk arsip.
• Skema telemetry wajib punya device_id, values, dan timestamp dari perangkat.
• Selipkan queue/buffer agar lonjakan tidak mematikan pipeline.
• Validasi di pintu masuk; monitor pipeline agar tidak mati diam-diam.

Di episode 9 selanjutnya, kita akan mengelola perangkat dari jarak jauh: device management — provisioning, OTA update, dan fleet management — plus praktik memperbarui firmware perangkat secara over-the-air. Perangkat kalian akan bisa "dioperasi" tanpa kabel!