Membina Sistem Pengumpul Data Kereta: Pengalaman, Cabaran, dan Penyelesaian

https://hilux.azmi.my

Sebuah cerita tentang bagaimana saya membina sistem automatik untuk mengumpul dan menganalisis data kereta dari Mudah.my menggunakan teknologi cloud.


Pendahuluan

Sebagai seseorang yang minat dengan kereta, terutamanya Toyota Hilux, saya selalu tertanya-tanya: berapa banyak kereta yang ada di pasaran? Berapa harga purata? Berapa mileage yang normal untuk kereta umur tertentu?

Daripada tengok manual satu-satu iklan, saya fikir kenapa tak buat sistem yang boleh kumpul semua maklumat ni secara automatik dan analisis untuk saya?

Jadi, saya mula membina sistem web scraper yang boleh:

  • Kumpul data kereta dari Mudah.my secara automatik
  • Simpan dalam database cloud
  • Papar dalam dashboard dengan chart dan filter
  • Update setiap hari tanpa perlu buat manual

Ini adalah cerita pengalaman saya, masalah yang dihadapi, dan bagaimana saya menyelesaikannya.


Teknologi yang Digunakan

Sebelum masuk kepada masalah, biar saya cerita teknologi yang saya guna. Saya pilih teknologi cloud dari Amazon Web Services (AWS) kerana beberapa sebab:

1. Infrastructure as Code dengan Terraform

Daripada setup server dan database manual, saya guna Terraform – satu cara untuk “tulis” infrastruktur dalam kod. Macam blueprint untuk bangunan, tapi untuk sistem IT. Kalau nak buat perubahan atau setup baru, cuma run script je.

Kelebihan:

  • Setup sekali, guna banyak kali
  • Kalau ada masalah, boleh rollback
  • Boleh version control (simpan sejarah perubahan)

2. AWS Lambda (Serverless Computing)

Ini macam “pekerja” yang buat kerja bila diperlukan, tanpa perlu server yang sentiasa hidup. Bayar ikut guna je – kalau tak guna, tak bayar.

Kelebihan:

  • Tak perlu maintain server
  • Auto scale – kalau banyak kerja, tambah worker sendiri
  • Cost effective untuk kerja yang tak selalu

3. DynamoDB (NoSQL Database)

Database untuk simpan data kereta. Macam fail cabinet digital yang boleh cari cepat.

Kelebihan:

  • Cepat untuk baca/tulis data
  • Auto scale – kalau data banyak, tak perlu upgrade server
  • Reliable – AWS jaga backup dan maintenance

4. S3 (Simple Storage Service)

Tempat simpan fail dan archive data lama. Macam Google Drive tapi untuk sistem.

5. AppSync (GraphQL API)

API untuk frontend ambil data dari database. Macam “jambatan” antara website dan database.

6. CloudFront (CDN)

Untuk serve website dengan cepat dari lokasi terdekat. Macam ada banyak salinan website di tempat berbeza, jadi user dapat content cepat.


Cabaran dan Penyelesaian

Cabaran 1: Cloudflare Security Block

Masalah: Website Mudah.my ada sistem keselamatan Cloudflare yang detect dan block bot atau program automatik. Macam security guard yang tengok siapa yang masuk. Kalau dia rasa kita bot, dia akan tunjuk halaman “validate if you’re a human” dan block akses.

Apa yang berlaku:

  • Scraper saya kena block
  • Tak boleh dapat data
  • Loop infiniti – cuba refresh tapi masih kena block

Penyelesaian:

Saya implement beberapa “anti-detection” measures:

  1. Realistic User-Agent
    • User-agent adalah “ID card” untuk browser. Saya set supaya kelihatan macam Chrome browser biasa, bukan bot.
  2. Stealth JavaScript
    • Saya inject JavaScript untuk sembunyikan tanda-tanda automasi. Macam “menyamar” supaya kelihatan macam manusia biasa.
  3. Smart Detection Logic
    • Awal-awal, detection saya terlalu sensitif – detect “cloudflare” text dalam page walaupun bukan challenge page. Saya perbaiki supaya hanya detect actual challenge page, bukan sekadar mention “cloudflare” dalam scripts.
  4. Better Waiting Strategy
    • Daripada refresh setiap saat (yang buat loop infiniti), saya buat supaya refresh setiap 6 saat dan check dengan lebih bijak. Kalau page dah ada content Mudah.my, terus proceed, jangan loop lagi.

Hasil: ✅ Scraper boleh bypass Cloudflare challenge ✅ Tak loop infiniti lagi ✅ Boleh dapat data dengan konsisten


Cabaran 2: Mileage Extraction yang Tidak Konsisten

Masalah: Mileage (jarak tempuh) kereta tak selalu ada dalam tempat yang sama dalam website. Kadang-kadang ada dalam description, kadang-kadang dalam detail section, kadang-kadang takde langsung.

Apa yang berlaku:

  • Data yang dikumpul tak lengkap
  • Ada kereta yang ada mileage, ada yang tak
  • Format berbeza-beza – ada “42,000 km”, ada “42k km”, ada “42000 km”

Penyelesaian:

Saya buat “multi-strategy” approach – cuba beberapa cara untuk cari mileage:

  1. Strategy 1: Cari dalam detail page
    • Cari dalam section yang ada maklumat kereta
    • Pattern matching untuk “XX,XXX km” atau “XXk km”
  2. Strategy 2: Cari dalam description text
    • Parse semua text dalam page
    • Cari pattern mileage dengan regex
  3. Strategy 3: Cari dalam specific HTML elements
    • Cari dalam div/span yang biasanya ada mileage info
  4. Strategy 4: Fallback ke section text
    • Kalau semua tak jumpa, cari dalam semua section text

Hasil: ✅ Lebih banyak kereta yang dapat mileage ✅ Format standardization – semua convert ke format yang sama (nombor sahaja) ✅ Better data quality untuk analisis


Cabaran 3: Data Format dan Consistency

Masalah: Bila simpan data dalam DynamoDB, format kena betul. Kalau tak, bila nak papar dalam frontend atau query melalui API, data tak keluar atau keluar salah.

Apa yang berlaku:

  • Ada field yang null padahal sepatutnya ada nilai
  • String fields keluar sebagai literal variable (contoh: “$item.title.S” instead of actual title)
  • Number fields tak betul format

Penyelesaian:

  1. Fix Lambda Processor
    • Pastikan semua field yang penting sentiasa ada nilai
    • Handle null values dengan betul
    • Convert format dengan betul (string ke number, etc.)
  2. Fix AppSync Resolvers
    • AppSync resolver adalah “translator” antara database dan API
    • Saya kena manually map setiap field dari DynamoDB format ke GraphQL format
    • Handle null checks untuk semua fields
    • Pastikan non-nullable fields sentiasa ada default value
  3. Data Validation
    • Validate data sebelum simpan
    • Pastikan mileage dalam range yang munasabah (1000-999999 km)
    • Pastikan price dalam format yang betul

Hasil: ✅ Data konsisten dalam database ✅ API return data dengan betul ✅ Frontend boleh papar semua data tanpa error


Cabaran 4: Frontend Display Issues

Masalah: Bila papar data dalam frontend, ada beberapa issues:

  • Price distribution chart tak betul (hanya extract first digit)
  • Mileage categories wording redundant
  • Posting date tak user-friendly

Penyelesaian:

  1. Fix Price Regex
    • Awal-awal regex hanya extract first digit (contoh: “48” dari “RM 48,000”)
    • Saya perbaiki untuk capture semua digits dengan commas, then remove commas sebelum parse
  2. Improve Mileage Categories
    • Buat categories dengan label yang jelas: “Sangat Rendah”, “Rendah”, “Sederhana”, “Tinggi”, “Sangat Tinggi”
    • Display sebagai badge dengan warna dan status
    • Format: “Tinggi – Perlu semakan” (bukan “⚠️ Perlu semakan Tinggi”)
  3. Human-Readable Dates
    • Convert timestamp ke format yang mudah dibaca
    • “Hari ini”, “2 hari lalu”, “6 Nov 2025”
    • Lebih user-friendly untuk non-technical users

Hasil: ✅ Charts accurate dan informative ✅ UI lebih clean dan mudah difahami ✅ Better user experience


Cabaran 5: CloudFront Cache

Masalah: Bila update frontend, perubahan tak keluar kerana CloudFront cache content lama.

Penyelesaian:

  • Buat CloudFront invalidation untuk clear cache
  • Boleh automate dalam deployment process

Hasil Akhir

Selepas semua masalah diselesaikan, sistem sekarang boleh:

Automated Scraping

  • Kumpul data kereta setiap hari secara automatik
  • Handle Cloudflare challenges
  • Extract data dengan konsisten

Data Storage

  • Simpan dalam DynamoDB dengan format yang betul
  • Archive data lama dalam S3
  • Query cepat melalui AppSync API

Data Visualization

  • Dashboard dengan interactive charts
  • Price distribution
  • Mileage distribution
  • Car age distribution
  • Filter by price, mileage, age, location

User-Friendly Interface

  • Clean, modern UI
  • Mobile responsive
  • Easy to understand untuk non-technical users

Pengajaran dan Tips

1. Start Simple, Iterate

Jangan cuba buat perfect dari mula. Buat versi basic dulu, test, then improve step by step.

2. Cloud Computing is Cost-Effective

Untuk project macam ni, cloud computing sangat cost-effective. Tak perlu beli server, maintain server, atau worry tentang scaling.

3. Problem Solving Mindset

Setiap masalah ada penyelesaian. Kadang-kadang kena try beberapa approach sebelum jumpa yang betul.

4. Documentation is Important

Tulis apa yang dibuat, kenapa dibuat, dan bagaimana. Nanti kalau ada masalah atau nak improve, senang refer balik.

5. Test Thoroughly

Test setiap perubahan dengan teliti. Kadang-kadang fix satu masalah, create masalah lain.


Kesimpulan

Membina sistem ni memang banyak cabaran, tapi sangat rewarding bila dah siap dan berfungsi dengan baik. Teknologi cloud memudahkan banyak benda – tak perlu worry tentang infrastructure, boleh fokus pada logic dan features.

Untuk yang nak mula buat sistem macam ni, saya cadangkan:

  1. Start dengan local testing dulu
  2. Deploy ke cloud step by step
  3. Test setiap component dengan teliti
  4. Document everything
  5. Be patient – problem solving takes time

Kalau ada soalan atau nak tahu lebih lanjut, boleh tanya! 😊


Teknologi Stack:

  • AWS (DynamoDB, S3, Lambda, SQS, AppSync, CloudFront)
  • Terraform (Infrastructure as Code)
  • Python (Selenium, BeautifulSoup)
  • HTML/CSS/JavaScript (Frontend)
  • Chart.js (Data Visualization)

Kos: ~RM12-15/bulan Time to Build: ~2-3 weeks (part-time) Lines of Code: ~3000+


Artikel ini ditulis berdasarkan pengalaman sebenar membina sistem web scraper untuk Mudah.my. Semua teknologi dan tools yang disebut adalah real dan digunakan dalam production.

Leave a Comment