Edeva公司于2009年成立于瑞典林雪平,專門為智慧城市開發功能強大的解決方案。它提供托管服務和完整系統,包括軟硬件平臺。
作為動態減速帶Actibump和智慧城市平臺EdevaLive的開發者,Edeva團隊主要服務于市政、區域和全國道路管理部門、收費站、環保機構及執法機構。
該團隊還解決其他許多問題:從獲取大量環境數據用于決策,到開發篩查量表以幫助執法機構評估車輛超載情況,不一而足。比如說,后者可以縮短控制每輛車所需的時間,加快交通檢查速度,并讓執法機構可以控制更多的車輛。
團隊介紹
Edeva的團隊是11人組成的頗有影響力的小團隊,負責研制硬件物聯網設備、分析時間序列數據以及讓客戶(有時甚至公眾)可以訪問這些數據等任務。
作為一名軟件架構師,我負責構建最佳解決方案,以接收、存儲、分析、顯示和共享客戶的事件數據。然后我們的團隊齊心協力,創建切實有效、客戶真正想要的解決方案。
項目介紹
Edeva開發了一個名為Actibump的動態減速帶和智慧城市平臺EdevaLive。Actibump自2010年以來一直在瑞典使用。超速行駛的車輛激活道路上的升降口,升降口會降低幾厘米,因而形成凹下的減速帶。Actibump為公共汽車和緊急車輛等公共交通工具提供了良好的可達性,同時保證行人及其他易受傷害的道路使用者的安全速度。它也是一種環保解決方案,有助于減少噪音和二氧化碳排放。
Actibump可以與EdevaLive系統相結合,為Edeva的客戶提供有價值的遠程監控服務和統計數據。
我們收集的大部分數據都基于物聯網設備:
交通流量數據:Actibump測量來車的速度,以決定是否需要激活減速帶。我們捕獲雷達數據等信息,并將事件發送到智慧城市平臺EdevaLive。數據將來車視為流量而不是單輛車,以創建盡可能順暢的交通流量。
車輛分類數據(動態稱重):Actibump經配置后可具有動態稱重功能。這意味著減速帶的蓋子配備了非常靈敏的高速采樣量表。車輛通過減速帶時,量表記下幾個重量測量值。這樣一來,它可以檢測車輛有多少個車軸,并對車輛類型進行分類。同時,它使用量表指紋為每個軸觸發一個事件,以便我們分析重量測量是否正確。
車輛分類數據(雷達):如果我們想在還沒有安裝Actibump 的地方對車輛進行分類,可以引入對車輛類型進行分類的雷達。路邊服務器控制雷達,收集其數據,并將數據推送到 EdevaLive。
單車和行人數據:我們使用安裝在行人和自行車道上方的攝像頭。攝像頭可以檢測和統計雙向通過的行人和單車。我們將這些數據推送到EdevaLive進行分析。
車牌數據:我們可以使用攝像頭來檢測車輛車牌。這樣,我們可以控制柵門等設備自動打開。它還可用于查看通過攝像頭的電動車輛與汽油車輛或柴油車輛的數量,或確定某輛車的貨重是否超限。
陀螺儀數據:我們提供的陀螺儀傳感器可以收集所有不同平面的加速度數據。該設備生成大量數據,這些數據可以批量或作為數據流上傳到EdevaLive(如果車輛連接互聯網)。比如說,該數據帶有GPS標記,可用于計算加速度,向公交汽車司機表明工作條件狀況。該數據還可用于計算車輛的損耗及許多其他指標。
環境數據:智慧城市平臺中監控環境數據非常重要。這就是為什么我們使用小型便攜式設備來測量空氣中出現的不同大小的顆粒。它還可以測量二氧化碳及其他氣體。此外,它可測量溫度和風速等平常數據。所有這些數據都被推送到EdevaLive。
報警數據:如果傳感器或其他部件出現故障,我們的物聯網設備和路邊服務器可以發送報警信息。所有這些數據都像常規的物聯網事件那樣進入EdevaLive,但這些事件僅在內部使用,以便我們在出現問題時能盡快做出反應。
狀態數據:如果報警數據檢測到異常,狀態數據只報告服務器或物聯網設備的狀態。這些設備將運行自檢,并報告統計數據,比如磁盤利用率、溫度和負載。這也僅供內部使用,以發現趨勢,或出現任何問題時排除故障。比如說,將CPU負載與固件版本號或其他軟件版本關聯起來就非常有用。
管理數據:SQL和時間序列數據在這方面真正發揮作用。假設我們添加了一個新設備,它有一個配置對象,該對象在Timescale的常規表中持久存在。該對象保留一些元數據,比如添加到系統的日期或設備的顯示名稱。這樣,我們可以輕松地使用連接(joint)來獲取有關設備的元數據,同時獲取即將發生的事件的時間序列數據。實現過程只需要處理一個數據庫連接,只需要運行一個查詢。
選擇并使用TimescaleDB
幾年前,我們開始將數據存儲在MySQL中時,就意識到需要時間序列數據庫。當時我們改用了MongoDB,它對我們來說運行良好,但需要大量的管理工作,且導入其他開發人員較困難。我研究了InfluxDB,但最終未考慮用它,因為它是另一個要學習的系統,我們已從MongoDB中吸取了這個教訓。
我尋找一種解決方案來填補以前系統無法填補的空白。這時候我找到了Timescale,發現了這款托管解決方案。我們是個小團伙,但創建有重大影響的軟件,這意味著我們其實沒有時間投入大量精力來調整和管理所使用的每一個工具,但我們仍希望擁有控制權。
此外,由于TimescaleDB基本上是具有增強版時間序列功能的PostgreSQL,因此如果需要,導入新的開發人員要容易得多。有了Timescale,我們的開發人員立即知道如何使用該產品,因為他們中大多數人已經熟悉SQL。Edeva使用TimescaleDB作為我們智慧城市系統中的主數據庫。我們的客戶可以控制其物聯網設備(比如EdevaLive的Actibump),并且作為該系統的一部分,可以查看已捕獲的數據,快速了解趨勢和歷史數據。我們提供許多圖以顯示不同時間跨度(比如日、周、月和年)的數據。為了快速呈現這些數據,我們使用了持續聚合(Continuous Aggregation)。
當前部署和未來計劃
對我們的工作影響最大的TimescaleDB功能之一是持續聚合。它使我們的儀表板從蝸牛般緩慢變成快如閃電。如果我們構建功能以便數據可供客戶使用,總是先聚合以加快查詢速度,并減輕數據庫的負載。過去,運行一些長期數據查詢需要幾分鐘,現在長期數據的幾乎所有查詢都不到1秒鐘即可完成。
比如說,隨著時間的推移,我們總是難以顯示85%的速度。想獲得準確的百分位數據,你必須基于原始數據進行計算,而不是聚合數據。如果你在超表中有2億個事件,想要某個傳感器幾年以來的數據,可能需要很長時間才能得出結果,可是用戶不想等那么久。
鑒于Timescale引入了percentile_agg和approx_percentile,我們實際上可以查詢持續聚合,并獲得相當準確的百分位值,無需查詢原始數據。
請注意,“vehicles”是一個超表,其中actibump_id是含有數億條記錄的動態減速帶的ID。以下是我們構建持續聚合的方式:
CREATE MATERIALIZED VIEW view1
WITH (timescaledb.continuous) AS
SELECT actibump_id,
timescaledb_experimental.time_bucket_ng(INTERVAL '1 month', time, 'UTC') AS bucket,
percentile_agg(vehicle_speed_initial) AS percentile_agg
FROM vehicles
GROUP BY actibump_id, bucket
這是為該圖獲取數據的查詢:
SELECT TIMESCALEDB_EXPERIMENTAL.TIME_BUCKET_NG(INTERVAL '1 month', bucket) AS date,
actibump_id,
APPROX_PERCENTILE(0.85, ROLLUP(PERCENTILE_AGG)) AS p85,
MAX(signpost_speed_max)
FROM vehicles_summary_1_month
WHERE actibump_id in ('16060022')
AND bucket >= '2021-01-30 23:00:00'
AND bucket <= '2022-04-08 21:59:59'
GROUP BY date, actibump_id
ORDER BY date ASC
這是該圖的示例:
目前,我們使用PHP和Yii2來部署TimescaleDB。 我們使用Qlik Sense連接到TimescaleDB以進行業務分析。在Qlik Sense中,你可以使用PostgreSQL集成,輕松連接到TimescaleDB。特別方便的一點是能夠連接到長期數據的持續聚合,而不會因過多的原始數據而使系統過載。我們經常使用Qlik Sense為稍后添加到EdevaLive的圖創建原型。
忠告和資源
我們的下一步是想出一個好方法,以減少存儲在TimescaleDB中的原始數據量。我們正在研究如何將其與數據湖集成。此外,我們很高興開始構建更多的圖和地圖應用程序。
如果你打算存儲時間序列數據,建議考慮使用Timescale。用戶很容易上手,因為它“就是”SQL;同時可以獲得處理時間序列數據所需的重要功能。建議你關注下它,尤其是沖著持續聚合方面。
入手時,要考慮整個生命周期。使用場景是否允許你使用壓縮等功能,還是說需要考慮如何在TimescaleDB的外面存儲長期數據,以便一開始就確保成本合理?你總是可以一路上解決問題,但最好在上線之前為此制定好計劃。
原文標題:How Edeva Uses Continuous Aggregations and IoT to Build Smarter Cities,作者:Ana Tavares和John Eskilsson