Chương 1. Thu thập dữ liệu lịch sử thời tiết

1.1. Mục đích, yêu cầu

Dữ liệu lịch sử đáng tin cậy là nền tảng cốt lõi để huấn luyện bất kỳ mô hình dự báo nào, đặc biệt là các mô hình chuỗi thời gian như LSTM, ARIMA/SARIMA, Prophet, RNN…., vốn học các mẫu và quy luật từ quá khứ. Yêu cầu của bài toán là sử dụng dữ liệu lịch sử của các năm trước đó để dự báo.

1.2.  Nguồn dữ liệu World Weather Online (WWO)

World Weather Online (WWO) cung cấp các API cho phép truy cập dữ liệu thời tiết, bao gồm cả dữ liệu lịch sử.

●       API Dữ liệu Lịch sử:

○       API Lịch sử Địa phương (Local History API): Cung cấp quyền truy cập vào dữ liệu thời tiết quá khứ cho các địa điểm trên đất liền từ ngày 1 tháng 7 năm 2008 đến nay. API này trả về các yếu tố như nhiệt độ, lượng mưa, mô tả thời tiết, biểu tượng thời tiết và tốc độ gió.

○       API Lịch sử Hàng hải (Marine History API): Cung cấp dữ liệu thời tiết biển, bao gồm cả dữ liệu thủy triều, từ ngày 1 tháng 1 năm 2015. API này trả về các yếu tố như nhiệt độ, lượng mưa, mô tả thời tiết, biểu tượng thời tiết, tốc độ gió, dữ liệu thủy triều, chiều cao sóng đáng kể, chiều cao sóng lừng, hướng sóng lừng và chu kỳ sóng lừng.

○       Lưu ý quan trọng: Tài liệu của WWO chỉ rõ rằng dữ liệu lịch sử được cung cấp qua API Lịch sử Địa phương là dữ liệu dự báo cho các ngày trong quá khứ, chứ không phải dữ liệu quan trắc thực tế. Một nguồn khác cũng đề cập đến việc dịch vụ này tạo ra dữ liệu thời tiết dự đoán.

●       Độ phân giải Thời gian: Dữ liệu lịch sử có thể được truy xuất theo các khoảng thời gian: 1 giờ, 3 giờ (mặc định), 6 giờ, 12 giờ (ngày/đêm) hoặc 24 giờ (trung bình ngày).

●       Phương thức Truy cập:

○       Dữ liệu được truy cập thông qua API bằng phương thức GET HTTP.

○       Yêu cầu khóa API (API key) để xác thực, được cung cấp sau khi đăng ký tài khoản.

○       WWO cung cấp các gói dịch vụ khác nhau, bao gồm gói miễn phí hoặc dùng thử với số lượng yêu cầu giới hạn (ví dụ: 100 hoặc 250 yêu cầu/ngày) và có thể chỉ dành cho mục đích cá nhân/giáo dục/nghiên cứu và yêu cầu ghi công. Các gói trả phí cung cấp giới hạn yêu cầu cao hơn và các tính năng bổ sung.

●       Định dạng Dữ liệu: API có thể trả về dữ liệu ở các định dạng phổ biến như XML (mặc định), JSON, CSV và TAB. JSON và CSV là các định dạng dễ dàng xử lý bằng các thư viện phân tích dữ liệu như Pandas trong Python.

●       Truy vấn Vị trí: Có thể yêu cầu dữ liệu cho một vị trí cụ thể bằng cách sử dụng:

○       Tên thành phố/thị trấn (ví dụ: q=New+York, q=London,united+kingdom)

○       Địa chỉ IP (ví dụ: q=101.25.32.325)

○       Mã bưu điện (Anh, Canada, Mỹ - ví dụ: q=SW1, q=90201)

○       Mã bưu chính Canada (ví dụ: q=H3A)

○       Vĩ độ và Kinh độ (hệ thập phân - ví dụ: q=48.834,2.394)

●       Các Tham số Dữ liệu Có sẵn (Ví dụ từ API Lịch sử Địa phương): API lịch sử cung cấp nhiều thông số:

○       Nhiệt độ: Tối đa (maxtempC, maxtempF), tối thiểu (mintempC, mintempF), theo giờ (tempC, tempF), cảm giác như (FeelsLikeC, FeelsLikeF), chỉ số nhiệt (HeatIndexC, HeatIndexF), điểm sương (DewPointC, DewPointF), nhiệt độ gió lạnh (WindChillC, WindChillF).

○       Gió: Tốc độ (nhiều đơn vị: windspeedMiles, windspeedKmph, windspeedKnots, windspeedMeterSec), hướng (độ winddirDegree và 16 điểm la bàn winddir16Point), gió giật (WindGustMiles, WindGustKmph).

○       Lượng mưa: Lượng mưa (precipMM, precipInches).

○       Độ ẩm: Phần trăm (humidity).

○       Tầm nhìn: Kilomet (visibility), dặm (visibilityMiles).

○       Áp suất: Millibar (pressure), inches (pressureInches).

○       Mây che phủ: Phần trăm (cloudcover).

○       Thiên văn: Giờ mặt trời mọc/lặn (sunrise, sunset), mặt trăng mọc/lặn (moonrise, moonset), pha mặt trăng (moon_phase), độ chiếu sáng mặt trăng (moon_illumination).

○       Chỉ số UV: uvIndex.

○       Mô tả thời tiết: Văn bản mô tả (weatherDesc) và mã điều kiện thời tiết (weatherCode).

○       Thời gian quan sát: observation_time (có thể định dạng lại bằng date_format).

○       Thông tin bổ sung: Có thể yêu cầu thêm thông tin như múi giờ (showlocaltime), thời gian quan sát địa phương (localObsTime), thời gian UTC (utcDateTime) thông qua tham số extra.

●       Cân nhắc khi Sử dụng WWO:

○       Loại dữ liệu: Cần lưu ý rằng dữ liệu lịch sử địa phương là dữ liệu dự báo cho quá khứ, không phải quan trắc thực tế. Điều này có thể ảnh hưởng đến độ chính xác nếu mục tiêu là mô hình hóa dựa trên các sự kiện đã xảy ra chính xác.

○       Giới hạn API: Các gói miễn phí có giới hạn về số lượng yêu cầu hàng ngày/hàng tháng và có thể không đủ để tải xuống dữ liệu hàng giờ trong một năm. Cần xem xét nâng cấp lên gói trả phí nếu cần nhiều dữ liệu hơn.

○       Độ phân giải: API cho phép lấy dữ liệu hàng giờ, phù hợp với yêu cầu phân tích chi tiết và mô hình LSTM.

○       Độ sâu lịch sử: Dữ liệu có sẵn từ năm 2008 (địa phương) hoặc 2015 (hàng hải), đủ để lấy dữ liệu một năm trước đó.

Việc lựa chọn định dạng dữ liệu (ví dụ: CSV, JSON) và cách tổ chức lưu trữ sau khi thu thập sẽ ảnh hưởng đến hiệu quả của các bước tiền xử lý và huấn luyện mô hình tiếp theo.

Chương 2. Quá trình làm sạch dữ liệu thời tiết

2.

2.1. Phân tích vấn đề về dữ liệu và chuẩn bị dữ liệu

Sự cần thiết của việc Làm sạch: Dữ liệu thực tế, đặc biệt là dữ liệu từ cảm biến như quan sát thời tiết, thường không hoàn hảo. Việc làm sạch và tiền xử lý là rất quan trọng đối với hiệu suất của mô hình, đôi khi chiếm một phần đáng kể nỗ lực. Mặc dù các mô hình học máy khá mạnh mẽ, chúng vẫn hưởng lợi rất nhiều từ dữ liệu đầu vào sạch sẽ và có cấu trúc tốt.

Xử lý Dữ liệu Thiếu (Missing Values):

●       Nhận dạng: Phát hiện các mục bị thiếu (ví dụ: NaN, null, các mã cụ thể như 9999 ). Dữ liệu thiếu có thể phát sinh trong quá trình thu thập.

●       Chiến lược:

○       Xóa bỏ:

■       Xóa theo danh sách (Listwise/Casewise Deletion): Loại bỏ toàn bộ bản ghi (ngày/giờ) có bất kỳ giá trị nào bị thiếu. Cảnh báo: Thường không được khuyến khích cho chuỗi thời gian vì nó phá vỡ tính liên tục của chuỗi và có thể dẫn đến mất dữ liệu đáng kể.

■       Xóa cột: Loại bỏ toàn bộ đặc trưng (ví dụ: độ ẩm) nếu dữ liệu bị thiếu quá nhiều. Cảnh báo: Có nguy cơ mất thông tin có giá trị tiềm năng.

○       Gán giá trị thay thế (Imputation): Phương pháp được ưu tiên cho chuỗi thời gian.

■       Gán giá trị Trung bình/Trung vị/Mode: Thay thế các giá trị bị thiếu bằng giá trị trung bình, trung vị hoặc mode của cột. Hạn chế: Bỏ qua các mẫu thời gian (xu hướng, tính mùa vụ).

■       Điền Tiến/Lùi (Forward/Backward Fill - LOCF): Sử dụng giá trị đã biết cuối cùng hoặc giá trị đã biết tiếp theo. Đơn giản, bảo tồn trạng thái cuối cùng, nhưng có thể tạo ra các đoạn phẳng nhân tạo.

■       Nội suy Tuyến tính (Linear Interpolation): Ước tính các giá trị bị thiếu bằng cách vẽ một đường thẳng giữa các điểm đã biết gần nhất trước và sau khoảng trống. Tính đến các xu hướng tuyến tính tốt hơn so với gán giá trị trung bình. Hàm interpolate() của Pandas cung cấp chức năng này.

■       Gán giá trị dựa trên Phân rã theo Mùa (Seasonal Decomposition Imputation): Phân rã chuỗi thành các thành phần xu hướng, mùa vụ và phần dư, sau đó gán giá trị dựa trên các thành phần này. Phức tạp hơn nhưng tôn trọng tính mùa vụ.

■       Gán giá trị dựa trên Mô hình (KNN, Hồi quy): Sử dụng các đặc trưng khác hoặc các điểm thời gian lân cận để dự đoán giá trị bị thiếu bằng các mô hình như K-Nearest Neighbors hoặc Hồi quy. Có thể chính xác hơn nhưng tốn kém về mặt tính toán.

■       Gán giá trị Mở rộng (Extended Imputation): Tạo thêm các cột nhị phân chỉ ra giá trị nào ban đầu bị thiếu, có khả năng cho phép mô hình học các mẫu liên quan đến sự thiếu hụt.

●       Cân nhắc: Lựa chọn phụ thuộc vào bản chất của dữ liệu (ví dụ: tần suất thiếu hụt, các mẫu cơ bản như tính mùa vụ ). Nội suy hoặc điền tiến/lùi thường là điểm khởi đầu tốt cho chuỗi thời gian thời tiết.

Phát hiện và Xử lý Ngoại lệ (Outliers):

●       Nhận dạng: Dữ liệu thời tiết có thể có các giá trị ngoại lệ do lỗi cảm biến hoặc các sự kiện cực đoan (nhưng có thật). Xác định các giá trị lệch đáng kể so với chuẩn (ví dụ: sử dụng ngưỡng độ lệch chuẩn, biểu đồ hộp hoặc kiến thức chuyên môn).

●       Xử lý: Quyết định xem các giá trị ngoại lệ là lỗi hay các sự kiện cực đoan hợp lệ. Lỗi có thể được xử lý như dữ liệu bị thiếu và được gán giá trị thay thế. Các sự kiện cực đoan hợp lệ có thể được giữ lại hoặc giới hạn (winsorization) tùy thuộc vào mục tiêu mô hình hóa. Cảnh báo: Việc loại bỏ các sự kiện thời tiết cực đoan hợp lệ có thể cản trở khả năng dự đoán chúng của mô hình.

Chuẩn hóa và Scaling:

●       Tầm quan trọng đối với LSTM: Mạng nơ-ron, đặc biệt là LSTM với các hàm kích hoạt sigmoid/tanh, hoạt động tốt hơn khi các đặc trưng đầu vào được điều chỉnh về một phạm vi chung. Điều này giúp quá trình hội tụ của gradient descent và ngăn các đặc trưng có giá trị lớn hơn chi phối quá trình học.

●       Kỹ thuật:

○       Scaling Min-Max (Normalization): Điều chỉnh lại dữ liệu về một phạm vi cố định, thường là hoặc [-1, 1]. Công thức: Xscaled​=(X−min(X))/(max(X)−min(X)). Nhạy cảm với các giá trị ngoại lệ.

○       Standardization (Z-score Scaling): Điều chỉnh lại dữ liệu để có giá trị trung bình là 0 và độ lệch chuẩn là 1. Công thức: Xscaled​=(X−mean(X))/stddev(X). Ít nhạy cảm với các giá trị ngoại lệ hơn Min-Max scaling.

●       Ứng dụng: Quan trọng là phải "khớp" (fit) scaler (tính toán min/max hoặc mean/stddev) chỉ trên dữ liệu huấn luyện, sau đó sử dụng scaler đã khớp đó để biến đổi tập xác thực và tập kiểm tra. Điều này ngăn chặn rò rỉ dữ liệu từ tập kiểm tra vào quá trình huấn luyện. Các giá trị dự đoán sẽ cần được biến đổi ngược lại về thang đo ban đầu để diễn giải.

Kỹ thuật Đặc trưng (Feature Engineering - Tùy chọn nhưng có thể hữu ích):

●       Tạo các đặc trưng dựa trên thời gian: Trích xuất tháng, ngày trong tuần, giờ trong ngày, mùa, hoặc các cờ cho ngày lễ/sự kiện đặc biệt có thể giúp mô hình nắm bắt các mẫu chu kỳ một cách rõ ràng.

●       Đặc trưng Độ trễ (Lag Features): Bao gồm rõ ràng các giá trị trong quá khứ (độ trễ) của biến mục tiêu hoặc các đặc trưng khác làm cột đầu vào. Mặc dù LSTM vốn xử lý chuỗi, việc cung cấp các độ trễ cụ thể đôi khi có thể hỗ trợ việc học.

Làm sạch Dữ liệu Cụ thể theo Trường (từ World Weather Online):

Dựa trên các trường dữ liệu bạn cung cấp và thông tin từ WWO API, đây là các bước làm sạch cụ thể có thể áp dụng:

●       Nhiệt độ (°C) (tempC, maxtempC, mintempC, FeelsLikeC, v.v.):

○       Thiếu giá trị: Sử dụng nội suy tuyến tính  hoặc điền tiến/lùi  vì nhiệt độ thường thay đổi tương đối mượt mà. Gán giá trị trung bình/trung vị cũng là một lựa chọn.

○       Ngoại lệ: Kiểm tra các giá trị nằm ngoài phạm vi hợp lý cho địa điểm và thời gian (ví dụ: nhiệt độ âm ở vùng nhiệt đới vào mùa hè, hoặc nhiệt độ > 60°C). Xử lý như giá trị thiếu hoặc giới hạn giá trị (winsorization).

○       Scaling: Chuẩn hóa Min-Max về hoặc [-1, 1], hoặc Standardization.

●       Tốc độ gió (km/h) (windspeedKmph):

○       Thiếu giá trị: Sử dụng các phương pháp gán giá trị như trung bình, trung vị, nội suy, hoặc điền tiến/lùi.

○       Ngoại lệ: Kiểm tra giá trị âm (không thể). Kiểm tra các giá trị cực cao (ví dụ > 200 km/h) - có thể là lỗi hoặc bão thực sự. Xử lý như giá trị thiếu hoặc giới hạn.

○       Scaling: Chuẩn hóa Min-Max hoặc Standardization.

●       Hướng gió (winddirDegree, winddir16Point):

○       Thiếu giá trị: Gán giá trị mode (hướng gió phổ biến nhất) hoặc điền tiến/lùi nếu hướng gió thay đổi chậm. Có thể tạo một hạng mục "không xác định".

○       Ngoại lệ: Kiểm tra winddirDegree có nằm trong khoảng không. Kiểm tra winddir16Point có phải là một trong 16 hướng hợp lệ không. Xử lý như giá trị thiếu.

○       Encoding/Scaling: Nếu dùng winddirDegree, xử lý như đặc trưng chu kỳ (ví dụ: sin(θ),cos(θ)) trước khi scaling. Nếu dùng winddir16Point, sử dụng one-hot encoding.

●       Giật gió (km/h) (WindGustKmph):

○       Thiếu giá trị: Tương tự tốc độ gió, hoặc có thể dùng hồi quy dựa trên tốc độ gió để gán giá trị.

○       Ngoại lệ: Kiểm tra giá trị âm. Kiểm tra giá trị cực cao. Đảm bảo Giật gió >= Tốc độ gió. Xử lý như giá trị thiếu hoặc giới hạn.

○       Scaling: Chuẩn hóa Min-Max hoặc Standardization.

●       Lượng mây (%) (cloudcover):

○       Thiếu giá trị: Gán giá trị trung bình/trung vị, nội suy, hoặc điền tiến/lùi.

○       Ngoại lệ: Kiểm tra giá trị có nằm ngoài khoảng không. Xử lý như giá trị thiếu hoặc giới hạn (0 hoặc 100).

○       Scaling: Chuẩn hóa Min-Max về .

●       Lượng mưa (mm) (precipMM):

○       Thiếu giá trị: Lượng mưa thường bằng 0. Gán giá trị 0 có thể là lựa chọn hợp lý. Các phương pháp khác như điền tiến/lùi hoặc nội suy cũng có thể được xem xét.

○       Ngoại lệ: Kiểm tra giá trị âm (không thể). Kiểm tra các giá trị cực cao (có thể là lỗi hoặc mưa lớn thực sự). Xử lý như giá trị thiếu hoặc giới hạn.

○       Scaling: Chuẩn hóa Min-Max hoặc Standardization. Do dữ liệu có thể bị lệch nhiều về giá trị 0, có thể xem xét biến đổi logarit (ví dụ: log(x+1)) trước khi scaling.

●       Áp suất khí quyển (hPa) (pressure - đơn vị là mb, tương đương hPa):

○       Thiếu giá trị: Nội suy tuyến tính thường phù hợp vì áp suất thay đổi khá mượt mà. Điền tiến/lùi hoặc gán giá trị trung bình/trung vị cũng là lựa chọn.

○       Ngoại lệ: Kiểm tra các giá trị nằm ngoài phạm vi thông thường (ví dụ: 950-1050 hPa ở mực nước biển). Điều chỉnh theo độ cao nếu cần. Xử lý như giá trị thiếu hoặc giới hạn.

○       Scaling: Chuẩn hóa Min-Max hoặc Standardization.

●       Tình trạng thời tiết (weatherDesc, weatherCode):

○       Thiếu giá trị: Gán giá trị mode (tình trạng phổ biến nhất) hoặc tạo một hạng mục "không xác định".

○       Ngoại lệ: Kiểm tra xem weatherCode hoặc weatherDesc có hợp lệ theo tài liệu của WWO không. Xử lý như giá trị thiếu.

○       Encoding: Đây là dữ liệu hạng mục. Sử dụng one-hot encoding hoặc embedding layer. Không nên coi weatherCode là giá trị số liên tục.

2.2.  Các bước thực hiện làm sạch dữ liệu thông qua ứng dụng Weka

Bước 1: Chuẩn bị file dữ liệu

Lưu file với tên ví dụ: weather_data.csv

Bước 2: Tải dữ liệu vào Weka

1.    Mở Weka Explorer.

2.    Nhấp vào tab Preprocess.

3.    Chọn Open file và tải file weather_data.csv.

o   Weka sẽ tự động nhận diện các cột (attributes) như location, from, to, temperature, humidity, condition, retrieved_at.

Bước 3: Kiểm tra và xử lý dữ liệu thiếu

• Vị trí trong WEKA: Tab Preprocess.
• Cách thực hiện:

1.    Tải file .csv vào WEKA (đã chuyển đổi từ dữ liệu phân cách bằng tab).

2.    Trong phần Attributes (bên trái), nhìn vào thông tin của từng thuộc tính. WEKA sẽ hiển thị số lượng giá trị thiếu (Missing) nếu có (ví dụ: "Missing: 5 (2%)").

• Nếu có giá trị thiếu:
  • Filter > Choose > NumericCleaner:
    • Loại: Unsupervised (không cần thuộc tính mục tiêu).
    • Chi tiết: Dùng để xử lý các giá trị số bất thường (ví dụ: precipitation < 0). Trong cửa sổ cấu hình:
      • Chọn thuộc tính cần áp dụng (ví dụ: "precipitation").
      • Đặt ngưỡng (threshold) để thay thế hoặc loại bỏ (ví dụ: thay tất cả giá trị < 0 bằng 0).
      • Nhấn Apply.
    • Ví dụ: Nếu precipitation có giá trị âm (không hợp lý), bạn có thể thay bằng 0.
  • Filter > Choose > ReplaceMissingValues:
  • Loại: Unsupervised (mặc định) hoặc Supervised (nếu chọn chế độ theo class).
  • Chi tiết: Thay giá trị thiếu bằng trung bình (mean) hoặc trung vị (median) của cột:
    • Nhấn Choose > filters > unsupervised > attribute > ReplaceMissingValues.
    • Trong cửa sổ cấu hình, để mặc định (thay bằng mean cho thuộc tính số, mode cho thuộc tính danh nghĩa).
    • Nếu muốn theo class (Supervised), chọn "class" là "weather" trong phần Current relation trước, rồi vào More options để bật chế độ thay thế theo giá trị trung bình của từng nhóm class.
    • Nhấn Apply.
  • Ví dụ: Nếu cột "humidity" thiếu giá trị, WEKA sẽ thay bằng trung bình của toàn bộ cột (Unsupervised) hoặc trung bình theo từng loại thời tiết (Supervised).
• Kết quả: Dữ liệu không còn giá trị thiếu.

Bước 4: Xử lý dữ liệu không nhất quán

• Vị trí trong WEKA: Tab Preprocess.
• Cách thực hiện:

1.    Chọn cột "direction" và "weather" trong danh sách Attributes.

2.    Nhìn vào phần "Selected attribute" (bên phải) để xem danh sách các giá trị duy nhất (Distinct values). Kiểm tra xem có giá trị nào bất thường không (ví dụ: "N " thay vì "N", hoặc "Partly Cloudy" và "Partly cloudy" cùng tồn tại).

• Nếu có giá trị không nhất quán:
  • Filter > Choose > StandardizeNominal:
    • Loại: Unsupervised.
    • Chi tiết: Chuẩn hóa các giá trị danh nghĩa bằng cách loại bỏ khoảng trắng thừa hoặc chuẩn hóa định dạng:
      • Nhấn Choose > filters > unsupervised > attribute > StandardizeNominal.
      • Chọn thuộc tính cần xử lý (ví dụ: "direction" hoặc "weather").
      • Nhấn Apply.
    • Ví dụ: "N " sẽ được chuẩn hóa thành "N".

Bước 5: Chuyển đổi định dạng cột "time"

• Vị trí trong WEKA: Tab Preprocess.
• Cách thực hiện:
  • Cột "time" hiện là chuỗi (string, ví dụ: "00:00", "03:00"). WEKA mặc định nhận diện nó là nominal nếu không xử lý thêm.
• Phương án 1: Chuyển thành thuộc tính danh nghĩa (Nominal):
• Filter > Choose > StringToNominal:
  • Loại: Unsupervised.
  • Chi tiết: Giữ nguyên các giá trị như "00:00", "03:00" nhưng chuyển thành kiểu nominal:
    • Nhấn Choose > filters > unsupervised > attribute > StringToNominal.
    • Chọn thuộc tính "time".
    • Nhấn Apply.
  • Ví dụ: "time" sẽ được giữ nguyên dạng chuỗi nhưng WEKA coi nó như một thuộc tính danh nghĩa.

Bước 6: Loại bỏ dữ liệu dư thừa

• Vị trí trong WEKA: Tab Preprocess.
• Filter > Choose > RemoveDuplicates:
  • Loại: Unsupervised.
  • Chi tiết: Xóa các hàng trùng lặp hoàn toàn:
    • Nhấn Choose > filters > unsupervised > instance > RemoveDuplicates.
    • Để mặc định (xóa các hàng giống nhau ở tất cả các thuộc tính).
    • Nhấn Apply.
  • Ví dụ: Nếu có hai dòng giống hệt nhau (ví dụ: "00:00,1,27.0,..."), một dòng sẽ bị xóa.
• Kết quả: Tập dữ liệu không còn bản sao dư thừa.

Bước 7: Kiểm tra và xử lý outlier

• Vị trí trong WEKA: Tab Preprocess.
• Cách thực hiện:

1.    Chọn từng thuộc tính số (temperature, wind, precipitation, v.v.) trong danh sách Attributes.

2.    Nhìn vào biểu đồ phân bố (histogram) ở phần "Selected attribute" để phát hiện outlier (ví dụ: precipitation = 9.9 trong khi đa số là 0 hoặc rất nhỏ).

• Filter > Choose > InterquartileRange:
  • Loại: Unsupervised.
  • Chi tiết: Phát hiện và loại bỏ outlier dựa trên khoảng tứ phân vị (IQR):
    • Nhấn Choose > filters > unsupervised > attribute > InterquartileRange.
    • Trong cửa sổ cấu hình:
      • Chọn các thuộc tính cần kiểm tra (ví dụ: "temperature", "wind", "precipitation").
      • Để ngưỡng mặc định (1.5 lần IQR) hoặc điều chỉnh (ví dụ: 3.0 nếu muốn giữ nhiều dữ liệu hơn).
      • Tích "Remove outliers" để xóa các dòng chứa outlier.
      • Nhấn Apply.
  • Ví dụ: Nếu precipitation = 9.9 nằm ngoài khoảng IQR, dòng đó sẽ bị xóa.
• Kết quả: Dữ liệu không còn các giá trị bất thường (outlier).

Bước 8: Lưu dữ liệu đã làm sạch

• Sau khi hoàn tất các bước trên, nhấn Save trong tab Preprocess để lưu file mới (ví dụ: weather_data_cleaned.csv hoặc .arff).

Bước 9: Kiểm tra lại dữ liệu

• Tải lại file đã làm sạch vào WEKA và kiểm tra xem các vấn đề đã được giải quyết chưa (không còn giá trị thiếu, outlier, dữ liệu không nhất quán, v.v.).

Chương 3 Tổ chức và lưu trữ dữ liệu thời tiết sau khi xử lý phân tán trên MongoDB và SQL Server

3.  

3.1.  Giới thiệu về lưu trữ dữ liệu phân tán với MongoDB và SQL Server

Trong bối cảnh công nghệ thông tin hiện đại, việc quản lý và lưu trữ dữ liệu ngày càng trở nên phức tạp, đòi hỏi các giải pháp linh hoạt, có khả năng mở rộng và hiệu suất cao. Kiến trúc lưu trữ dữ liệu phân tán, đặc biệt là các mô hình lai kết hợp thế mạnh của nhiều hệ quản trị cơ sở dữ liệu (CSDL) khác nhau, đang nổi lên như một xu hướng tất yếu. Báo cáo này sẽ đi sâu vào các khía cạnh kỹ thuật của việc triển khai một hệ thống lưu trữ dữ liệu phân tán sử dụng MongoDB và SQL Server, hai nền tảng CSDL hàng đầu với những đặc điểm và khả năng riêng biệt.

3.1.1.    Cơ sở lý luận cho việc sử dụng phương pháp phân tán kết hợp

Cả MongoDB và SQL Server đều cung cấp các cơ chế mạnh mẽ để hỗ trợ triển khai phân tán, tuy nhiên cách tiếp cận và các tính năng cốt lõi của chúng có những khác biệt đáng kể.

MongoDB: Nền tảng MongoDB được xây dựng ngay từ đầu với kiến trúc hệ thống phân tán, điều này mang lại lợi thế tự nhiên trong việc mở rộng quy mô và địa phương hóa dữ liệu thông qua các cơ chế như sharding tự động và replica set để duy trì tính sẵn sàng cao. Khả năng sharding của MongoDB cho phép phân phối dữ liệu theo chiều ngang trên nhiều máy chủ, giúp hệ thống xử lý hiệu quả khối lượng dữ liệu khổng lồ và thông lượng hoạt động cao. Bên cạnh đó, replica set đóng vai trò then chốt trong việc đảm bảo tính sẵn sàng cao và khả năng chịu lỗi, bằng cách duy trì nhiều bản sao dữ liệu trên các máy chủ khác nhau.  

SQL Server: SQL Server, một hệ quản trị CSDL quan hệ kỳ cựu, cũng đã phát triển và tích hợp nhiều tính năng mạnh mẽ để hỗ trợ các kịch bản phân tán, tính sẵn sàng cao và tích hợp dữ liệu không đồng nhất. Các tính năng nổi bật bao gồm Replication, Always On Availability Groups, Distributed Partitioned Views, PolyBase và Linked Servers. Always On Availability Groups là một giải pháp toàn diện cho tính sẵn sàng cao (High Availability - HA) và khắc phục thảm họa (Disaster Recovery - DR). Tính năng Replication cho phép phân phối và đồng bộ hóa dữ liệu giữa các máy chủ SQL Server. Trong khi đó, PolyBase và Linked Servers mở ra khả năng truy vấn dữ liệu từ các nguồn bên ngoài, bao gồm cả các nguồn NoSQL, ngay từ bên trong SQL Server.  

Sự khác biệt cơ bản trong triết lý thiết kế giữa hai hệ thống này ảnh hưởng sâu sắc đến cách chúng tiếp cận kiến trúc phân tán và các trường hợp sử dụng phù hợp nhất trong một hệ thống lai. MongoDB, được thiết kế từ đầu cho môi trường phân tán , thường ưu tiên tính sẵn sàng và khả năng mở rộng phân vùng, phù hợp với các nguyên tắc của định lý CAP. Ngược lại, SQL Server, với nền tảng quan hệ vững chắc , đã phát triển các tính năng phân tán nhưng vẫn duy trì sự tập trung mạnh mẽ vào tính nhất quán giao dịch theo nguyên tắc ACID. Do đó, MongoDB thường linh hoạt hơn trong việc xử lý dữ liệu phi cấu trúc và các thay đổi schema thường xuyên , trong khi SQL Server thể hiện sức mạnh vượt trội về tính toàn vẹn giao dịch trên dữ liệu có cấu trúc. Trong một kiến trúc lai, điều này có nghĩa là MongoDB có thể đảm nhận các phần của ứng dụng đòi hỏi khả năng mở rộng linh hoạt và xử lý dữ liệu đa dạng, còn SQL Server sẽ phù hợp hơn với các thành phần yêu cầu tính toàn vẹn giao dịch nghiêm ngặt.  

3.1.2.   Tổng quan về các khái niệm của kiến trúc cơ sở dữ liệu phân tán

Trước khi đi sâu vào chi tiết triển khai cụ thể với MongoDB và SQL Server, điều quan trọng là phải nắm vững các khái niệm và nguyên tắc nền tảng của kiến trúc CSDL phân tán.

A. Các Nguyên tắc Chính (ví dụ: tính trong suốt, tự chủ, khả năng mở rộng, tính sẵn sàng)

Một CSDL phân tán được định nghĩa là một tập hợp dữ liệu có liên quan về mặt logic, được dùng chung và phân tán về mặt vật lý trên một mạng máy tính. Hệ quản trị CSDL phân tán (HQTCSDLPT) có nhiệm vụ quản lý CSDL này và làm cho người dùng không nhận thấy sự phân tán về lưu trữ dữ liệu, đây chính là tính trong suốt của phân tán. Người dùng tương tác với hệ thống như thể đó là một CSDL tập trung duy nhất.  

Các nguyên tắc quan trọng khác bao gồm:

Khả năng mở rộng (Scalability): Đây là khả năng của hệ thống để xử lý khối lượng công việc ngày càng tăng bằng cách bổ sung tài nguyên một cách hiệu quả. Khả năng mở rộng có thể theo chiều dọc (tăng cường sức mạnh của một máy chủ hiện có) hoặc theo chiều ngang (thêm nhiều máy chủ hơn vào hệ thống).  

Tính sẵn sàng cao (High Availability): Đảm bảo rằng hệ thống vẫn duy trì hoạt động và dữ liệu vẫn có thể truy cập được ngay cả khi một hoặc nhiều thành phần của nó gặp sự cố. Điều này thường đạt được thông qua dự phòng dữ liệu và cơ chế chuyển đổi dự phòng tự động.  

Tính tự chủ cục bộ (Local Autonomy): Cho phép mỗi nút hoặc trạm trong hệ thống phân tán có một mức độ kiểm soát và quản lý nhất định đối với dữ liệu được lưu trữ tại đó. Điều này có thể quan trọng đối với các yêu cầu về tuân thủ hoặc quản trị dữ liệu theo vùng địa lý.  

Việc đạt được tất cả các nguyên tắc này một cách hoàn hảo thường liên quan đến những sự đánh đổi nhất định. Ví dụ, việc duy trì tính nhất quán mạnh mẽ (strong consistency) trên một hệ thống phân tán rộng lớn có thể ảnh hưởng tiêu cực đến độ trễ (latency) và tính sẵn sàng của hệ thống. Đây là một khía cạnh của định lý CAP (Consistency, Availability, Partition tolerance), một định lý nền tảng trong lĩnh vực hệ thống phân tán. Tính trong suốt giúp đơn giản hóa quá trình phát triển ứng dụng vì các nhà phát triển không cần phải lo lắng về vị trí vật lý của dữ liệu. Khả năng mở rộng cho phép hệ thống phát triển song hành cùng với sự tăng trưởng của nhu cầu kinh doanh , trong khi tính sẵn sàng cao đảm bảo hoạt động kinh doanh được liên tục. Tuy nhiên, việc đồng bộ hóa dữ liệu trên nhiều nút để đảm bảo tính nhất quán – một khía cạnh quan trọng của tính trong suốt và độ tin cậy – có thể gây ra độ trễ. Trong trường hợp xảy ra phân vùng mạng (network partition), nơi các nút không thể giao tiếp với nhau, hệ thống phải đối mặt với một lựa chọn khó khăn: hoặc tiếp tục hoạt động nhưng có nguy cơ dữ liệu trở nên không nhất quán (ưu tiên tính sẵn sàng), hoặc ngừng hoạt động để tránh tình trạng dữ liệu không nhất quán (ưu tiên tính nhất quán). Sự đánh đổi này chính là cốt lõi của Định lý CAP.  

B. Các Mẫu Kiến trúc Phổ biến (ví dụ: client-server, n-tier, peer-to-peer trong ngữ cảnh)

Nhiều mẫu kiến trúc đã được phát triển để tổ chức các hệ thống phân tán, mỗi mẫu có những ưu và nhược điểm riêng.

Kiến trúc Client-Server: Đây là mô hình phổ biến nhất trong điện toán phân tán. Trong mô hình này, một hoặc nhiều client (máy khách) gửi yêu cầu đến một hoặc nhiều server (máy chủ). Server xử lý yêu cầu và trả kết quả về cho client. Chức năng hệ thống được phân phối giữa hai loại mô-đun này.  

Kiến trúc N-Tier (N tầng): Kiến trúc ba tầng (three-tier) và N tầng (N-tier) là sự mở rộng của mô hình client-server, nhằm mục đích tách biệt rõ ràng các mối quan tâm: tầng trình bày (giao diện người dùng), tầng ứng dụng (logic nghiệp vụ) và tầng dữ liệu (lưu trữ và truy cập dữ liệu). Kiến trúc N-tier cho phép bổ sung thêm các tầng chức năng tùy thuộc vào yêu cầu của ứng dụng, mang lại sự linh hoạt và thường được ứng dụng làm cơ sở kiến trúc cho các dịch vụ web và hệ thống dữ liệu lớn.  

Phân phối Ngang (Horizontal Distribution): Trong kiến trúc này, một client hoặc server có thể được phân chia vật lý thành các phần bằng nhau, mỗi phần hoạt động trên một tập con của dữ liệu được chia sẻ từ một tập dữ liệu hoàn chỉnh. Đây là một cơ chế thường được sử dụng để cân bằng tải.  

Kiến trúc Peer-to-Peer (P2P - Mạng ngang hàng): Trong mô hình P2P, các nút (peers) có vai trò tương đương nhau, vừa có thể hoạt động như client vừa như server. Dữ liệu và tài nguyên được chia sẻ trực tiếp giữa các peer mà không cần thông qua một máy chủ trung tâm.  

Trong một kiến trúc lai kết hợp MongoDB và SQL Server, các mẫu kiến trúc này có thể được áp dụng và phối hợp một cách linh hoạt. Các ứng dụng hiện đại thường được xây dựng dựa trên kiến trúc nhiều tầng. Trong một hệ thống lai, các tầng khác nhau của ứng dụng có thể cần truy cập các loại dữ liệu khác nhau, được lưu trữ trong các CSDL chuyên biệt. Ví dụ, tầng trình bày (client) có thể gửi yêu cầu đến tầng ứng dụng. Tầng ứng dụng, tùy thuộc vào bản chất của yêu cầu, có thể cần lấy thông tin sản phẩm (thường xuyên thay đổi, nhiều thuộc tính đa dạng, phù hợp với MongoDB) từ MongoDB, đồng thời xử lý các đơn hàng (yêu cầu giao dịch ACID nghiêm ngặt, phù hợp với SQL Server) với SQL Server. Điều này đòi hỏi sự tồn tại của một lớp truy cập dữ liệu hoặc lớp dịch vụ có khả năng tương tác hiệu quả với cả hai loại CSDL. Lớp này có thể được triển khai thông qua các API riêng biệt cho từng CSDL hoặc thông qua một cổng dữ liệu (data gateway) thống nhất có khả năng điều phối các truy vấn đến đúng nguồn dữ liệu. Quyết định về cách các tầng tương tác với từng CSDL sẽ phụ thuộc mật thiết vào logic nghiệp vụ cụ thể của ứng dụng, cũng như các yêu cầu về tính nhất quán và hiệu suất đối với từng loại dữ liệu. Sự lựa chọn này sẽ ảnh hưởng trực tiếp đến độ phức tạp của tầng ứng dụng và cách thức quản lý các giao dịch và đảm bảo tính nhất quán dữ liệu giữa hai hệ thống CSDL.  

3.2.  Khả năng phân tán của MongoDB

MongoDB được thiết kế với các tính năng phân tán mạnh mẽ, chủ yếu là sharding để mở rộng quy mô và replica set để đảm bảo tính sẵn sàng cao.

A. Sharding trong MongoDB: Kiến trúc, Shard Keys, Balancer và Các Phương pháp Hay nhất

Sharding là phương pháp chính của MongoDB để đạt được khả năng mở rộng theo chiều ngang, cho phép phân phối dữ liệu trên nhiều máy chủ, được gọi là các shard. Mỗi shard lưu trữ một tập con của dữ liệu tổng thể.  

• Kiến trúc Sharded Cluster: Một cụm sharded MongoDB (sharded cluster) bao gồm ba thành phần chính:
  • Shards: Mỗi shard là một replica set độc lập, chứa một phần dữ liệu của cụm. Việc triển khai shard dưới dạng replica set là bắt buộc để đảm bảo tính sẵn sàng cao và dự phòng dữ liệu.  
  • Config Servers: Lưu trữ metadata của cụm, bao gồm thông tin về cách dữ liệu được phân phối trên các shard (ví dụ: ánh xạ chunk tới shard) và cấu hình của cụm. Config server cũng phải được triển khai dưới dạng replica set (CSRS) để đảm bảo tính nhất quán và sẵn sàng của metadata.  
  • Query Routers (mongos): Các tiến trình mongos hoạt động như giao diện giữa ứng dụng client và sharded cluster. Client gửi truy vấn đến mongos, mongos sẽ định tuyến truy vấn đến các shard thích hợp dựa trên shard key và metadata từ config server, sau đó tổng hợp kết quả (nếu cần) và trả về cho client.  
• Shard Key: Người dùng chọn một trường hoặc tập hợp các trường trong tài liệu làm shard key. Shard key quyết định cách dữ liệu trong một collection được phân chia thành các chunk và phân phối trên các shard. Việc lựa chọn shard key phù hợp là yếu tố cực kỳ quan trọng để đảm bảo phân phối dữ liệu đồng đều, hiệu suất truy vấn tốt và khả năng mở rộng hiệu quả.  
• Chunks: MongoDB chia dữ liệu của một sharded collection thành các dải (range) liên tục dựa trên giá trị của shard key, gọi là các chunk. Mỗi chunk đại diện cho một khoảng giá trị của shard key.  
• Balancer: Balancer là một tiến trình chạy ngầm, có nhiệm vụ theo dõi sự phân bố của các chunk trên các shard và tự động di chuyển (migrate) các chunk giữa các shard để đảm bảo dữ liệu được phân phối đồng đều, tránh tình trạng một số shard bị quá tải trong khi các shard khác lại ít tải.  
• Chiến lược Sharding: MongoDB hỗ trợ hai chiến lược sharding chính :  
• Ranged Sharding: Phân chia dữ liệu thành các dải dựa trên giá trị thực của shard key. Các tài liệu có giá trị shard key gần nhau có khả năng được lưu trữ trên cùng một chunk và do đó trên cùng một shard. Chiến lược này hiệu quả cho các truy vấn phạm vi (range queries) trên shard key.
• Hashed Sharding: Tính toán giá trị hash của shard key và phân phối dữ liệu dựa trên giá trị hash này. Chiến lược này giúp phân phối dữ liệu đồng đều hơn, đặc biệt hữu ích khi shard key có xu hướng tăng hoặc giảm đơn điệu (monotonically increasing/decreasing). Tuy nhiên, nó có thể làm giảm hiệu quả của các truy vấn phạm vi.

Việc lựa chọn shard key không chỉ ảnh hưởng đến hiệu suất ghi và đọc mà còn tác động đến khả năng thực hiện các hoạt động nhắm mục tiêu (targeted operations) so với các hoạt động quảng bá (broadcast operations). Mục tiêu của sharding là phân phối tải đều trên các shard. Tuy nhiên, một shard key được thiết kế không tốt có thể dẫn đến các "điểm nóng" (hotspots), nơi một shard cụ thể phải xử lý một lượng lớn yêu cầu đọc/ghi, hoặc tạo ra các "đoạn lớn" (jumbo chunks) không thể chia nhỏ và di chuyển, làm suy giảm nghiêm trọng lợi ích của sharding. Ví dụ, nếu shard key có độ đặc trưng (cardinality) thấp hoặc tăng đơn điệu và sử dụng ranged sharding, tất cả các bản ghi mới có thể tập trung vào một shard duy nhất, tạo ra điểm nóng. Hashed sharding có thể giúp phân phối đồng đều hơn nhưng lại làm cho các truy vấn phạm vi kém hiệu quả hơn. Do đó, việc hiểu rõ mẫu truy cập dữ liệu và đặc điểm của dữ liệu là tối quan trọng trước khi chọn shard key. Mặc dù MongoDB cho phép thay đổi shard key sau này (resharding), quá trình này thường phức tạp và tốn kém tài nguyên.  

Dưới đây là bảng tổng hợp các yếu tố cần cân nhắc và phương pháp hay nhất khi lựa chọn shard key trong MongoDB:

Bảng 1: Lựa chọn Shard Key trong MongoDB - Những Cân nhắc và Phương pháp Hay nhất

B. Replica Sets cho Tính Sẵn sàng Cao và Dự phòng Dữ liệu trong MongoDB

Replica set là một nhóm các tiến trình mongod duy trì cùng một tập dữ liệu, cung cấp tính dự phòng và tăng tính sẵn sàng của dữ liệu.  

• Kiến trúc Replica Set:
  • Primary Node: Trong một replica set, chỉ có một node được bầu làm primary. Primary node nhận tất cả các thao tác ghi (write operations) từ client.  
  • Secondary Nodes: Tất cả các node khác trong replica set là secondary node. Các secondary node sao chép (replicate) oplog (operation log - nhật ký hoạt động) từ primary node và áp dụng các thay đổi vào bản sao dữ liệu của chúng. Điều này đảm bảo rằng dữ liệu trên các secondary node là bản sao của dữ liệu trên primary node.  
  • Automatic Failover (Chuyển đổi dự phòng tự động): Nếu primary node trở nên không khả dụng (ví dụ: do lỗi phần cứng, lỗi mạng), các secondary node còn lại sẽ tự động tiến hành một cuộc bầu cử (election) để chọn ra một primary node mới từ trong số chúng. Quá trình này giúp giảm thiểu thời gian chết của hệ thống.  
  • Arbiter Node: Một arbiter là một tiến trình mongod không lưu trữ dữ liệu nhưng tham gia vào các cuộc bầu cử. Arbiter có thể được thêm vào replica set để giúp đạt được đa số phiếu trong cuộc bầu cử khi số lượng node dữ liệu là số chẵn. Tuy nhiên, việc sử dụng arbiter có những hạn chế và cần được cân nhắc kỹ lưỡng. Thông thường, một replica set nên có ít nhất ba node dữ liệu để đảm bảo tính sẵn sàng cao và khả năng chịu lỗi tốt.  
• Read Operations on Secondaries: Các secondary node có thể được cấu hình để phục vụ các thao tác đọc (read operations). Điều này giúp giảm tải cho primary node và có thể cải thiện hiệu suất đọc tổng thể của hệ thống. Tuy nhiên, dữ liệu đọc từ secondary node có thể không phải là dữ liệu mới nhất (eventual consistency) theo mặc định, vì có một độ trễ nhỏ trong quá trình sao chép từ primary sang secondary. Client có thể cấu hình "read preference" để chỉ định cách các truy vấn đọc được định tuyến (ví dụ: đọc từ primary, đọc từ secondary gần nhất, v.v.).  

Mặc dù replica set cung cấp tính sẵn sàng cao, cấu hình của "read preference" và "write concern" có tác động đáng kể đến tính nhất quán dữ liệu và hiệu suất ứng dụng. Replica set đảm bảo rằng dữ liệu sẽ không bị mất khi một node gặp sự cố , và cơ chế failover tự động giúp giảm thiểu thời gian hệ thống ngừng hoạt động. Việc cho phép đọc từ các secondary node có thể giảm tải cho primary node, nhưng cần lưu ý rằng dữ liệu đọc từ secondary có thể không phải là phiên bản mới nhất do tính nhất 

XEM THÊM ==> Hướng dẫn cài đặt chi tiết

HÌNH ẢNH DEMO

Nguồn: Sharecode.vn

Chạy chương trình bằng lệnh trong terminal node weather-app.js

Sau đó mở host: http://localhost:3000