前端玩轉大資料 - 家庭溫溼度資料採集與分析

語言: CN / TW / HK

時間 2022-06-10 12:44:05 Alibaba F2E

夏日已至，氣溫升高，又到了一年難熬的梅雨季節。作為一名技術宅，我望了眼藏在角落裡吃灰的樹莓派，便萌生了通過樹莓派完成資料採集，經過大資料處理，得到視覺化家庭溫溼度報表的想法。

最終的效果如下，我產出了兩個看版，第一個可以看到最近1小時每分鐘的溫溼度情況，第二個可以看到一天每小時的溫溼度情況。

大資料處理流程概覽

首先，我們先來了解一下大資料處理的主要步驟，主要為資料產生、資料採集與儲存、資料分析與處理、資料應用4個步驟，通過訪問阿里雲大資料產品官網，可以瞭解到這些資訊：

資料產生：業務系統每天產生的大量業務資料、日誌，儲存在各自獨立的資料來源裡。
資料採集與儲存：通過DataWorks提供資料整合服務，可以將多種資料來源型別，根據設定的排程任務，定時同步系統的資料至MaxCompute。
資料分析與處理：完成資料採集後，可以在MaxCompute中對資料進行離線處理（俗稱ETL過程，Extract-Transform-Load）；也可以結合Flink和Hologres對資料進行實時處理。
資料應用：資料加工完成後，可以通過報表進行視覺化展示與分享。

圖片來源： http://www.aliyun.com/product/bigdata/ide

我整理出了本次實現案例的資料開發方案，如下圖所示：

資料產生：樹莓派連線溫溼度感測器，間隔2秒讀取資料，並實時上報到SLS日誌服務進行儲存。
資料採集與儲存：使用資料整合工具，將SLS日誌服務的資料同步至MaxCompute。
資料分析與處理：遵循數倉規範，在DataWorks裡完成資料開發。
資料應用：將開發完成的資料關聯到QuickBI，進行視覺化報表搭建。

接下來，我們按照這個流程逐步實現。

一、資料產生

概覽：使用樹莓派連線溫溼度感測器，基於JavaScript我們可以快捷完成資料的讀取，隨後基於阿里雲SLS服務，將採集到的資料實時上報並存儲。

什麼是樹莓派

圖片來源： http://www.raspberrypi.com/products/raspberry-pi-4-model-b/

樹莓派於2012年問世，外形只有信用卡大小，它是一款基於ARM的微型電腦主機板，卻具有電腦的所有基本功能，此外還具有GPIO介面能力，可以很方便完成與硬體的通訊。

它出現的本意並非撼動消費者市場，而是以低廉的價格去促進計算機教育，做出好玩的實驗，這是樹莓派流行的主要原因。

什麼是GPIO程式設計

GPIO(General-Purpose IO Ports)，即通用IO介面。GPIO主要分為輸入和輸出兩種功能。可以實現一些簡單裝置的控制。比如在輸入模式下，將該IO連線感測器，可以用於檢測外部狀態；當作為輸出時，可以通過輸出高/低電平來控制外部裝置的運轉。

樹莓派天然支援GPIO程式設計，以樹莓派4B為例，它提供了40個介面，其中21個為GPIO介面，見下圖圈出來的位置。

圖片來源： http://pinout.xyz/

樹莓派目前提供多種程式語言的開發SDK，這極大地降低了我們操作硬體的成本，我們不需要掌握電位變化的基礎知識，只需要呼叫API便可以輕鬆讀取資料，接下來我們來介紹本文的核心 -- DHT11溫溼度感測器。

DHT11溫溼度感測器

DHT11溫溼度感測器，可以測量20-90%的溼度區間， 0~50℃的溫度區間，取樣週期 >= 1秒/次，外觀如下圖所示：

圖片來源： http://developer.aliyun.com/ article/843529

它包含三個針腳，分別是電源正負極、一個數據針腳。通過將訊號針腳與樹莓派的某一個GPIO針腳連線，便可以源源不斷的讀取資訊。

採集與上報資料

我們按照下圖將樹莓派與感測器進行連線，其中感測器的資料針腳連線到樹莓派的編號為21的GPIO針腳。

連線成功後，我們基於開源專案 node-dth-sensor 來完成感測器資料的獲取，只需要編寫簡單的JavaScript程式碼，呼叫 read 方法，就可以獲取到溫溼度資料，如下所示：

const sensor = require("node-dht-sensor");
const SENSOR_TYPE = 11; // 感測器型別，本例為DHT11型號感測器，因此賦值為11
const GPIO_PIN = 21;// GPIO針腳編號，本例中連線到了21編號，這裡根據實際連線情況需要變化引數。
sensor.read(SENSOR_TYPE, GPIO_PIN, function (err, temperature, humidity) {
    if (!err) {
      console.log("temperature", temperature, "humidity", humidity);
    }
  });

隨後，我們結合阿里雲SLS日誌服務，每隔2秒，做一次資料上報，示意程式碼如下：

const sensor = require("node-dht-sensor");
const SLS = require("./sls"); // 基於sls日誌服務的sdk做簡單封裝
const projectName = "自定義";
const logStoreName = "自定義";
const reporter = new SLS(projectName);
const SENSOR_TYPE = 11; // 感測器型別，本例為DHT11型號感測器，因此賦值為11
const GPIO_PIN = 21; // GPIO針腳編號，本例中連線到了21編號，這裡根據實際連線情況需要變化引數。
setInterval(() => {
  sensor.read(SENSOR_TYPE, GPIO_PIN, function (err, temperature, humidity) {
    if (!err) {
      reporter.put(logStoreName, {
        temperature,
        humidity,
      });
    }
  });
}, 2000);

最後，我們使用pm2執行該段指令碼，使其在後臺常駐執行：

$ pm2 start dht11.js

進入SLS日誌服務控制檯，檢查是否有資料上報成功：

二、資料採集與儲存

概覽：這一節我們的目標是將SLS的日誌資料採集並存儲到MaxCompute裡，本案例中我們為了儘可能實時地看到資料情況，將資料採集的頻率設定為5分鐘/次，實現近實時資料採集，也可以大致滿足我們的需求。

第一步：建立需要儲存同步後的資料的表，按照數倉規範，存放業務源頭資料的表，我們需要將其命名為ods_字首，其英文全稱為Operational Data Store，在資料分析與處理章節，我們會詳細介紹。

第二步： 使用資料整合工具完成資料同步，獲取SLS裡的上報時間需要將採集欄位命名為 __receive_time__ 。

第三步： 設定任務排程時間，每5分鐘執行一次，每次獲取執行時向前5分鐘的資料，在排程配置裡使用 $[yyyymmddhh24miss] 引數表達當前時間（精確到秒），使用 $[yyyymmddhh24miss-1/24/60*5] 引數表達當前時間的前5分，提交任務，進入到運維中心後，便可以看到排程任務已經在等待中了。

第四步： 使用臨時查詢工具，檢查資料是否成功同步。

三、資料分析與處理

概覽：在Dataworks裡進行資料處理，依據數倉建設規範分別構建ODS層、DWD層、DWS層、ADS層。根據上報的溫溼度明細資料，計算出最近1小時每分鐘的溫溼度資料、每天每小時的溫溼度資料。

首先，在資料分析處理之前，需要先明確最終需要產出的結果是什麼：

最近1小時每分鐘的溫溼度情況
每小時的溫溼度變化情況以及是否舒適
每日舒適率

以下是個人的定義，不一定嚴謹，僅供參考：

舒適區間：人體感覺適宜的溫度在22到26度之間，相對溼度在40%到70%，在這樣的溫度和溼度的環境下人體感覺相對比較舒服。
舒適率：（舒適小時數 / 當天已統計小時數） * 100%，例如上午10:00，當天共統計10個小時，其中舒適小時數為5個小時，因此當天舒適率為（5/10)*100% = 50%

隨後我們進行資料處理階段，資料處理階段是非常靈活的，為了儘可能讓資料資產規範可持續消費，應當遵循一定規範進行建設，目前業界普遍按照維度建模和數倉建模的思路來組織整個開發過程，具體如下：

第一步：構建ODS層，目標是1比1完整接入，不考慮易用性，僅僅要求全。這一步將SLS日誌同步到ods_sensor表裡
第二步：構建DWD層，目標是加入規範，資料清洗，拼接相關欄位，讓資料好用。這一步將ods_sensor裡的日期時間戳轉化為標準的date格式，並且完成是否為舒適資料的判斷，最終生產為dwd_sensor表
第三步：構建DWS層，目標是對資料適度彙總，讓資料易用。這一步根據dwd_sensor表，生產出最近1小時和每小時的輕度彙總表，分別為dws_sensor_latest_1h和dws_sensor_1day
第四步：構建ASD層，與業務直接關聯的需求在此完成，上述舒適率便是一個個性化需求，因此放在這裡構建，產出ads_comfort_rate_day

最終構建後的數倉結構如下（在dataworks裡以視覺化方式呈現表依賴關係）：