Xin chào, tôi là Thinh, một kỹ sư chuyên về phát triển 3D.

Thông thường tôi chủ yếu làm việc với 3D và BIM, nhưng tuần trước, sếp bất ngờ nói với tôi:

“Hãy thử tìm hiểu về FIWARE (Future Internet WARE) nhé.”

…FIWARE là cái gì vậy?

Và đó là cách quá trình tìm hiểu lần này bắt đầu.

Sau khi tìm hiểu, tôi biết rằng FIWARE là một nền tảng mã nguồn mở được sử dụng trong các lĩnh vực như Smart City và IoT. Một trong những thành phần trung tâm của nó là Orion Context Broker.

Tuy nhiên, chỉ đọc tài liệu thì vẫn khá khó để hình dung FIWARE thực sự hoạt động như thế nào.

Vì vậy, lần này tôi đã sử dụng dữ liệu nhiệt độ thực tế để xây dựng một data pipeline như sau:

Open-Meteo
    ↓
weather_ingest.py
    ↓
Orion Context Broker
    ↓
QuantumLeap
    ↓
CrateDB
    ↓
Grafana

Qua đó, tôi thử kiểm tra cách FIWARE hoạt động trong thực tế.

Trong bài viết này, tôi sẽ chia sẻ những gì mình đã hiểu từ lúc còn tự hỏi “FIWARE là gì?” cho đến khi xây dựng được một PoC, bao gồm cả những vấn đề thực tế gặp phải trong quá trình triển khai.

1. FIWARE là gì?

Trước khi bắt tay vào code, điều đầu tiên tôi phải làm rõ là:

FIWARE thực sự là gì?

Nếu chỉ nhìn vào tên gọi, FIWARE khá dễ khiến người mới nghĩ rằng đây là một software hoặc một server duy nhất.

Nhưng thực tế không phải vậy.

FIWARE là một open-source platform ecosystem, bao gồm nhiều component có thể kết hợp với nhau để xây dựng các ứng dụng Smart City, IoT và context-aware applications.

Trong số đó, component mà tôi quan tâm nhất lần này là:

Orion Context Broker.

Và từ đây tôi bắt đầu đi sâu hơn vào câu hỏi:

Context Broker dùng để làm gì?

2. Orion Context Broker dùng để làm gì?

Nói đơn giản, Context Broker là nơi quản lý trạng thái hiện tại của các đối tượng trong hệ thống.

Ví dụ, trong PoC lần này, tôi có 5 thành phố:

Tokyo
Osaka
Kyoto
Nagoya
Sapporo

Mỗi thành phố có một entity tương ứng:

WeatherObserved:Tokyo
WeatherObserved:Osaka
WeatherObserved:Kyoto
WeatherObserved:Nagoya
WeatherObserved:Sapporo

Mỗi entity lưu thông tin về nhiệt độ hiện tại.

Ví dụ:

{
  "id": "WeatherObserved:Tokyo",
  "type": "WeatherObserved",
  "temperature": {
    "type": "Number",
    "value": 28.4
  }
}

Ở đây:

• WeatherObserved:Tokyo là Entity
• temperature là Attribute
• 28.4 là giá trị hiện tại của attribute đó

Điểm quan trọng là Orion không đơn giản chỉ là một database.

Nó quản lý context information và cho phép các hệ thống khác đăng ký nhận thông báo khi dữ liệu thay đổi.

3. NGSI-v2 là gì?

Trong quá trình tìm hiểu, tôi cũng gặp một thuật ngữ khác khá nhiều:

NGSI-v2.

Nếu FIWARE là ecosystem và Orion là Context Broker, thì NGSI-v2 có thể hiểu đơn giản là API/protocol được sử dụng để giao tiếp với Context Broker.

Ví dụ, để lấy danh sách entity:

GET /v2/entities

Để cập nhật attribute:

PATCH /v2/entities/WeatherObserved:Tokyo/attrs

Vì vậy, có thể hình dung mối quan hệ như sau:

FIWARE
  │
  └── Orion Context Broker
          │
          └── NGSI-v2 API

Điều này giúp tôi hiểu rõ hơn một điểm:

FIWARE không phải là Orion.

FIWARE là ecosystem, còn Orion là một implementation của Context Broker.

4. Entity và Attribute

Một trong những concept quan trọng nhất của FIWARE là Entity.

Nếu chúng ta làm một hệ thống IoT thông thường, có thể chúng ta sẽ nghĩ đến database table hoặc JSON object.

Trong FIWARE, cách tư duy có phần khác.

Một Entity đại diện cho một object hoặc một đối tượng trong thế giới thực.

Ví dụ:

WeatherObserved:Tokyo

Entity này có thể có nhiều attribute:

temperature
relativeHumidity
windSpeed
location
dateObserved

Trong PoC này, tôi chủ yếu tập trung vào temperature để pipeline đơn giản và dễ quan sát hơn.

Một attribute không chỉ là một giá trị đơn giản.

Ví dụ:

"temperature": {
  "type": "Number",
  "value": 28.4
}

Nó có:

• type
• value
• và có thể có thêm metadata

Cách tổ chức này là một trong những điểm khiến tôi thấy FIWARE khá khác với cách xây dựng REST API thông thường.

5. Smart Data Models

Một khái niệm khác tôi gặp trong quá trình tìm hiểu là Smart Data Models.

Nếu mỗi project tự định nghĩa Entity theo một cách khác nhau thì việc chia sẻ và tích hợp dữ liệu sẽ trở nên khó khăn.

Ví dụ, project A có thể đặt:

temperature

trong khi project B lại dùng:

temp

hoặc:

currentTemperature

Smart Data Models đưa ra các schema chuẩn hóa cho từng domain.

Trong PoC này, tôi sử dụng model:

WeatherObserved

Nhờ vậy, dữ liệu thời tiết không chỉ là một JSON object tùy ý mà tuân theo một structure đã được định nghĩa.

6. Bắt đầu xây dựng PoC

Sau khi hiểu được những concept cơ bản, tôi bắt đầu xây dựng một pipeline đơn giản.

Mục tiêu của PoC khá rõ ràng:

Lấy dữ liệu nhiệt độ thực tế → đưa vào Orion → lưu lại lịch sử → hiển thị trên dashboard.

Tôi chọn Open-Meteo làm nguồn dữ liệu.

Open-Meteo cung cấp weather API mà không yêu cầu API key cho trường hợp sử dụng của PoC này.

Tôi lấy dữ liệu cho 5 thành phố của Nhật Bản:

Tokyo
Osaka
Kyoto
Nagoya
Sapporo

Dữ liệu được cập nhật khoảng 5 phút một lần.

7. Open-Meteo → weather_ingest.py

Đầu tiên, một Python script có tên:

weather_ingest.py

sẽ gọi Open-Meteo API.

Thay vì gửi 5 request riêng biệt, script gửi một request chứa tọa độ của cả 5 thành phố.

Sau khi nhận được response, dữ liệu được chuyển sang format mà Orion có thể hiểu.

Conceptually:

Open-Meteo
    ↓
weather_ingest.py
    ↓
WeatherObserved entities

Ví dụ dữ liệu nhiệt độ của Tokyo:

{
  "id": "WeatherObserved:Tokyo",
  "type": "WeatherObserved",
  "temperature": {
    "type": "Number",
    "value": 28.4
  }
}

Sau đó entity này sẽ được gửi tới Orion.

8. Gửi dữ liệu vào Orion

Để cập nhật dữ liệu, script sử dụng Orion NGSI-v2 API.

Ví dụ:

PATCH /v2/entities/WeatherObserved:Tokyo/attrs

Nếu entity chưa tồn tại, script sẽ tạo entity mới.

Flow thực tế là:

Entity exists?
     │
 ┌───┴───┐
Yes      No
 │        │
PATCH    POST
 │        │
 └───┬────┘
     ↓
   Orion

Lần chạy đầu tiên, Orion sẽ tạo 5 entity.

Ở những lần tiếp theo, giá trị nhiệt độ của các entity này sẽ được cập nhật.

9. Một điều khá quan trọng: Orion chỉ giữ Current State

Đến đây tôi nhận ra một điểm khá quan trọng.

Nếu Tokyo có:

10:00 → 28.0°C
10:05 → 28.3°C
10:10 → 28.7°C
10:15 → 29.1°C

Orion chủ yếu quan tâm đến:

29.1°C

tức là current state.

Nó không phải là nơi tôi muốn lưu toàn bộ lịch sử:

28.0
28.3
28.7
29.1
...

Vậy câu hỏi tiếp theo là:

Nếu Orion không phải historical database, dữ liệu cũ sẽ đi đâu?

Đó là lúc QuantumLeap xuất hiện.

10. Orion → QuantumLeap

QuantumLeap là component được sử dụng để persist historical context data từ Context Broker vào một time-series database.

Tôi tạo một subscription trong Orion.

Conceptually:

Orion
  │
  │ data changed
  ↓
QuantumLeap

Khi temperature thay đổi, Orion gửi notification tới QuantumLeap.

Điều này có nghĩa là:

weather_ingest.py không cần gọi QuantumLeap trực tiếp.

Script chỉ cần:

Open-Meteo
    ↓
Orion

Sau đó Orion chịu trách nhiệm thông báo cho QuantumLeap.

Tôi khá thích cách này vì các component được tách biệt rõ ràng.

11. QuantumLeap → CrateDB

QuantumLeap tiếp tục ghi dữ liệu lịch sử vào CrateDB.

Lúc này pipeline bắt đầu trở nên hoàn chỉnh:

Open-Meteo
    ↓
weather_ingest.py
    ↓
Orion
    ↓
QuantumLeap
    ↓
CrateDB

Ví dụ, sau một khoảng thời gian, CrateDB có thể chứa:

Tokyo
10:00   28.0°C
10:05   28.3°C
10:10   28.7°C
10:15   29.1°C

Đây chính là phần mà Orion không tập trung xử lý:

historical data.

12. CrateDB → Grafana

Cuối cùng, tôi cần một cách để nhìn thấy dữ liệu.

Tôi sử dụng Grafana để query dữ liệu từ CrateDB và hiển thị nó dưới dạng dashboard.

Pipeline hoàn chỉnh lúc này là:

┌─────────────┐
│ Open-Meteo  │
└──────┬──────┘
       ↓
┌──────────────────┐
│ weather_ingest.py│
└────────┬─────────┘
         ↓
┌──────────────────┐
│ Orion Context    │
│ Broker           │
└────────┬─────────┘
         ↓
┌──────────────────┐
│ QuantumLeap      │
└────────┬─────────┘
         ↓
┌──────────────────┐
│ CrateDB          │
└────────┬─────────┘
         ↓
┌──────────────────┐
│ Grafana          │
└──────────────────┘

Grafana lúc này có thể hiển thị temperature history của 5 thành phố.

Từ một weather API đơn giản, cuối cùng tôi đã có một pipeline tương đối hoàn chỉnh:

Real-time data → Context Broker → Historical storage → Visualization.

13. Nhìn lại toàn bộ pipeline

Sau khi chạy thử, tôi có thể tóm tắt trách nhiệm của từng component như sau:

Và toàn bộ flow:

Open-Meteo
    ↓
weather_ingest.py
    ↓
Orion Context Broker
    ↓
QuantumLeap
    ↓
CrateDB
    ↓
Grafana

Đây có lẽ là phần quan trọng nhất tôi rút ra được từ PoC này.

Thay vì xem FIWARE như một "database", tôi bắt đầu nhìn nó như một data/context platform, nơi mỗi component đảm nhận một trách nhiệm khác nhau.

14. Một số vấn đề thực tế tôi gặp phải

Tất nhiên, đọc architecture diagram thì mọi thứ trông khá đơn giản.

Nhưng khi thực sự chạy hệ thống, tôi gặp một vài vấn đề thú vị.

14.1. Container start không có nghĩa là service đã ready

Trong Docker Compose, việc container đã start không đồng nghĩa với việc application bên trong container đã sẵn sàng nhận request.

Ví dụ:

MongoDB starts
      ↓
Orion container starts
      ↓
Orion chưa ready

Nếu service khác gọi Orion ngay lúc này, request có thể fail.

Vì vậy, tôi phải sử dụng health check và depends_on với trạng thái service_healthy để đảm bảo dependency thực sự sẵn sàng.

14.2. Grafana login session

Một vấn đề khác liên quan đến Grafana.

Sau khi sử dụng tài khoản mặc định và thay đổi password, session có thể bị invalidate.

Kết quả là một số request tiếp theo bị redirect về:

/login

Nếu chỉ nhìn vào frontend, lỗi này khá dễ bị hiểu nhầm là vấn đề với API hoặc datasource.

14.3. Subscription có thể hoạt động nhưng notification vẫn fail

Đây là một trong những vấn đề thú vị nhất.

Subscription trong Orion có thể trông như đang hoạt động bình thường, nhưng QuantumLeap vẫn có thể trả về:

HTTP 400

Nguyên nhân trong trường hợp của tôi liên quan đến format của notification.

Nếu attrsFormat sử dụng legacy NGSI-v1 format trong khi phía QuantumLeap mong đợi format phù hợp với NGSI-v2, subscription có thể tồn tại nhưng quá trình gửi dữ liệu vẫn thất bại.

Điều này cho tôi thấy rằng:

"Subscription exists" không đồng nghĩa với "data pipeline is working."

Phải kiểm tra cả notification flow thực tế.

15. PoC này chứng minh được điều gì?

PoC này tương đối nhỏ:

• 5 thành phố
• cập nhật khoảng 5 phút/lần
• một loại dữ liệu chính là temperature
• chạy local bằng Docker Compose

Nhưng nó đủ để tôi hiểu được cách các thành phần FIWARE kết hợp với nhau.

Đặc biệt, tôi hiểu rõ hơn vai trò của Orion:

Orion
  ↓
Manage current context
  ↓
Notify other systems

thay vì:

Orion
  ↓
Store everything forever

Đây là khác biệt khá quan trọng khi thiết kế architecture.

16. Những gì PoC này chưa giải quyết

PoC này mới chỉ là bước đầu.

Tôi chưa thử các vấn đề như:

• Hàng nghìn hoặc hàng triệu entities
• Tần suất cập nhật rất cao
• MQTT / LoRaWAN
• IoT Agents
• Message queues
• High availability
• Orion clustering
• MongoDB scaling và sharding

Ví dụ, với 5 thành phố cập nhật mỗi 5 phút, hệ thống hoạt động khá nhẹ nhàng.

Nhưng nếu chuyển thành:

100,000 sensors
      ↓
updates every few seconds

thì architecture sẽ cần được đánh giá lại.

Đó mới là câu hỏi thú vị tiếp theo.

17. Kết luận

Ban đầu, khi nghe câu:

“Hãy thử tìm hiểu về FIWARE.”

Tôi thực sự không biết FIWARE là gì.

Sau khi tự tìm hiểu và xây dựng PoC, cách tôi hình dung về nó đã rõ ràng hơn rất nhiều.

Tôi có thể tóm tắt những gì mình học được như sau:

FIWARE
  │
  ├── Orion
  │     └── Current Context
  │
  ├── QuantumLeap
  │     └── Historical Persistence
  │
  ├── CrateDB
  │     └── Historical Data
  │
  └── Grafana
        └── Visualization

Với một bài toán nhỏ như 5 thành phố và dữ liệu cập nhật mỗi 5 phút, FIWARE Orion cho thấy nó có thể đóng vai trò khá phù hợp như một central context broker.

Điều tôi thấy thú vị nhất không phải là việc lấy được dữ liệu nhiệt độ.

Mà là sau khi tự tay xây dựng pipeline, tôi bắt đầu hiểu được tại sao FIWARE được thiết kế theo cách này, và mỗi component giải quyết vấn đề gì.

Và có lẽ đây mới chỉ là bước đầu.

Câu hỏi tiếp theo tôi muốn thử nghiệm là:

Nếu từ 5 thành phố tăng lên hàng nghìn hoặc hàng trăm nghìn entities thì FIWARE Orion sẽ hoạt động như thế nào?