沃卡惠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
