亚马逊AWS官方博客
基于Amazon Serverless和SageMaker实现空气质量预测
解决方案概述
随着人们生活水平的逐步提高,对于生活环境的标准也日益提高。近年来,利用传感器、物联网技术,实现空气污染指数采集,并进行空气污染指数预报的技术已经日趋成熟。
本文以伦敦空气质量数据集为例,为各位读者介绍一种基于亚马逊云科技服务快速实现空气质量数据采集,数据清洗,并进行预测的解决方案。总体方案拓扑示意图如下所示,可划分为三部分:
1.通过Step Function编排并调度Lambda,对公开数据集API实现数据采集
2.通过Glue爬取采集到数据的元数据到数据目录,以便通过Athena进行数据分析
3.通过SageMaker对数据进行进行处理,并通过时间序列算法LSTM进行预测
数据源说明
本方案示例使用的数据源为伦敦市空气质量监测数据。API接口和调用请参见以下链接:
https://api.erg.ic.ac.uk/AirQuality/help
通过调用API,可以获得伦敦空气质量相关小时级历史数据信息,用于后面的数据分析和预测。
利用无服务器架构实现低成本数据采集
考虑到API服务的可靠性与承载能力,通常在获取数据时,需要对数据请求进行限流操作,包括限制请求时间范围和限制请求发起频率,从而提高数据请求的成功率。
考虑到数据抽取为一次性功能,因此需要尽可能减少研发投入,压缩开发周期。考虑到开发工作量与数据抽取成本之间的平衡,本方案选择使用亚马逊云科技无服务器架构完成数据采集,从而尽可能压缩开发成本。
数据采集涉及服务与主要功能:
- Lambda – 具体API接口调用与数据采集。
- SQS – 解耦站点和采集时间段。由于限流需要,每次采集时间段不能超过1个月的数据,因此使用SQS实现站点清单,启用、弃用时间段与数据采集时间段解耦。
- Kinesis Firehose – 将采集到的结果传输到S3存储 ,为下一步数据分析奠定基础。
- S3 – 数据存储
业务流程如下图所示:
- 生成站点列表:
通过访问主站点,获取所有监测站点信息列表。该列表包含站点名称,代码,启用时间,弃用时间等关键信息。
生成站点列表代码如下:
获取的站点信息以Json格式,被发送给目标SQS队列进行处理。
- 生成采集时间:
通过从站点列表队列(SQS)中获取站点清单,可以获得所有站点,以及每个站点的启用和弃用时间(”DateOpened”和”DateClosed”)。若当前站点不再使用,则弃用时间包含具体日期。若当前站点仍然在使用,则该字段为空,在设置获取数据时间点时,使用调用Lambda函数的时间戳作为数据采集结束时间。
考虑到API站点承载能力和访问压力,在采集过程中,以月为单位进行数据采集,从而避免海量数据查询导致API压力过大,响应时间过长。同时,使用单一进程进行采集,避免多个查询相互影响,从而造成响应时间过长。
生成采集时间时,根据站点启用时间,将该站点生命周期内数据拆分成以月为单位的数十至数百采集任务,之后将任务发送给采集时间队列。从而将任务分解与任务执行解耦。
生成采集时间的代码如下:
由于站点列表来自于SQS队列,因此在生成具体采集时间任务后,需要从SQS中删除对应站点信息。如此设计的优势是通过SQS作为队列,当Lambda异常退出后,数据仍然保留在SQS中,从而可以实现自动重试的效果。在实际采集数据时,此项功能也格外有用。
- 完成指定时间段数据采集:
在完成了采集时间生成之后,就需要实际运行数据采集任务了。考虑到网络访问过程中,请求可能因为API可用性和压力等问题,而导致失败。需要引入重试机制,确保在偶然发生请求失败时,可以自动重试请求。同时,对于连续重试若干次的请求,可以将数据送至死信队列,用于未来进行问题排查和分析。
SQS任务队列可以完美的解决失败任务重试,并可以在配置的重试次数后,将数据送至死信队列用于未来进一步分析。
创建SQS时,可以选择可见性超时属性。当队列中数据被Lambda获取后,该计时器开始计时,确保数据不会重复分发给其他Lambda函数。通常超时时间配置为略长于Lambda最长运行时长。从而在Lambda运行失败后,确保该数据在队列中重新可见,并能够被其他Lambda函数获得,进而实现重试功能。
死信队列可以用于处理一些问题数据。部分数据由于各种原因,有可能无法被目标API正常处理,而如果放任这些数据存在于正常数据队列中,会导致这部分数据反复被尝试,从而占用计算资源,甚至阻塞正常数据的执行。因此通过配置死信队列,可以将该部分问题数据转移到专门的队列中,方便后续排查使用。示例中配置的重试次数为10次。
具体采集数据代码如下:
通过按照指定格式调用API接口,获得指定时间范围内的数据信息,并交由Kinesis Data Firehose缓存后转存到S3中。
使用Step Function组织采集流程
由于Lambda函数最长仅能运行15分中,因此需要使用编排框架将上述Lambda函数按照依赖关系和执行顺序进行组织。从而确保Lambda函数被有序调度。
亚马逊云科技提供Step Function用于实现Lambda函数调度功能。
本解决方案使用2组Step Function完成数据采集任务。第一组Step Function用于编排和调度获取站点与生成数据采集时间范围。其配置如下:
Step Function内部通过调用Lambda,并根据返回输出,不断调整内部状态机和执行路径,从而将解耦后的Lambda有序的调度为一个整体。第一个Step Function中实现了站点获取和采集时间段生成的功能。当Lambda完成上述功能后,会启动第二个Step Function,实现具体采集工作。
第二个Step Function内容如下:
第二个Step Function的本质是循环执行Lambda函数,直至所有SQS中存储的待采集信息全部处理完成。但由于Step Function的限制(每个Step Function最多处理25000状态变化),因此需要对Step Function执行过程进行拆分。当单次执行接近系统允许的上限时,通过启动全新的Step Function并终止当前Step Function的方式,实现长时间循环直至SQS中所有数据处理完成。
关于Kinesis Data Firehose将数据存储到S3的部分,本文不再赘述,有兴趣的读者可以参考Kinesis Data Firehose文档介绍:
https://docs.aws.amazon.com/zh_cn/firehose/latest/dev
数据采集成本效益分析
在使用托管服务后,数据采集的开发时间被显著压缩。笔者仅用了1天时间即完成了整个数据采集架构的搭建工作,并且在3天内完成测试和生产部署。而包含测试、迭代,生产使用的总成本不到30美元。其中Kinesis Data Firehose约22美元,Step Function约4.5美元,Lambda约0.5美元,SQS约0.3美元。
考虑到开发一整套编排框架,并完成Debug等所需的时间带来的人力成本,使用无服务器架构和托管服务在数据采集任务中极大的提速了上线进程,并有效降低了总体成本。
使用Glue爬网程序生成数据表
亚马逊云科技Glue服务作为托管的ETL工具,使得用户可以轻松高效的完成数据分类,清理和扩充。而其爬网程序可以自动清点数据存储中的数据,并将元数据添加到数据目录之中。用户可以通过包括Athena编写SQL快速查询存储于S3中的数据。
爬网程序的配置也非常简单。
在Glue页面中选择爬网程序->添加爬网程序。
输入程序名称,单击下一步继续。
保留默认配置,单击下一步。
配置S3链接,并指定需要爬网程序执行清点的S3路径,单击下一步。
保留默认配置,单击下一步。
为准备创建的IAM角色输入角色名称。单击下一步。
选择按需运行,单击下一步。
单击“添加数据库”,并根据向导填写数据库名称和信息,完成数据库创建。选择刚刚创建的数据库,并单击下一步。
单击完成,创建爬网程序。
选择刚刚创建的爬网程序,并单击运行爬网程序,等待运行结果。
爬网程序成功运行后,会看到以下内容:
该内容跟说明爬网程序已经成功根据输入信息,在数据目录中创建了对应条目。用户可以使用Athena对存储在S3中的数据进行检索了。
登录Athena界面后,在左侧数据源、数据库中选择之前配置的数据库,即可看到已经创建完成的数据表。用户可以通过SQL对数据库内容进行查询和检索。
使用Sagemaker从Athena获得分析数据源
数据工程师和数据科学家可以通过亚马逊云科技Sagemaker服务,对采集到的数据进行数据探索,模型训练等工作。
使用Sagemaker托管的Jupyter Notebook实例,数据工程师和数据科学家可以通过编写Python脚本,利用Athena提供的查询能力,对采集的数据进行探索。以下代码示例提供了使用Athena,在采集的数据中检索站点“HF4”,指标“NO2”的数据信息。
代码首先创建Athena客户端,并启动查询任务。然后循环等待,直至查询任务结束。Athena会将查询结果存储到指定的输出位置。因此可以直接使用Pandas读取S3输出位置的CSV文件,即可获得详细数据。
在上面截图中不难看出,该站点在2013年下半年至2014年年底前曾经关闭。因此该部分数据无法正常使用。而其他时间段也存在部分数据缺失的情况。为了能够准确的进行预测,需要在一定范围内对缺失的数据进行补充。
数据清洗与补值
物联网数据收网络链接质量,边缘设备工作状态,缓存等影响,时常发生数据丢失等情况。因此在使用数据进行分析预测前,需要检查数据是否存在缺失,并对缺失数据进行填补。
在本方案中,考虑到过长时间的数据缺失会导致难以准确填补。因此本方案选择填补缺失4小时内的数据。
根据之前从Athena中获得的数据,通过过滤value值为“NaN”,即空值的数据,实现精准查找缺失值,并根据缺失值前后范围是否超过4小时,进行判断。若缺失值在4小时内,则按照前后值差做4等分的方式,补充缺失的数据。如果超过4小时,则将输出数据切分成不同的数据分段,用于在后续选择数据量充足,可以进行预测的分段,生成预测数据。
通过对生成数据进行预览,带有“True”字段的部分即为填充数据内容。如下图所示:
选择训练数据,并分割训练集与测试集
考虑到训练需要有一定的数量基础,因此需要在数据集中寻找相对数据量较为充足的数据集。在兼顾数据时效性的角度下,本案例选择了“2017-06-01 13_00_00.csv”作为训练集和测试集使用。
首先完成训练数据加载工作。然后选取前2000条数据用于训练和测试。将数据标准化到0-1之间,再通过数据移位的方式为时间序列数据增加一些新的特征字段,从而转换为Tensorflow监督学习任务。最后将数据分割为训练集和测试集,并将训练集保存成文本文件并上传到S3供训练使用。
具体代码如下:
利用Sagemaker BYOS功能使用自定义脚本训练LSTM模型
LSTM并非Sagemaker内置模型。因此再训练时需要通过Notebook手写代码,或者使用BYOS的方法完成训练工作。
考虑到模型训练代码通常在不同使用环境下具有一定复用性,因此选择使用BYOS模式训练LSTM。
BYOS需要提前准备用于执行训练过程的脚本,并通过Sagemaker框架将该脚本发送到训练使用的虚拟机上。
本案例中直接使用基于Keras的LSTM模型训练脚本lstm.py文件作为训练脚本。
启动训练任务
仅需要几行代码,就可以启动训练任务。
首先,从当前Sagemaker记事本中获得角色信息,然后配置训练参数,包括用户提供的训练脚本(Bring Your Own Script,即BYOS),运行使用的IAM角色,用于训练的示例数量和大小,运行使用的TensorFlow框架版本,Python版本,以及是否启用分布式训练等。
在完成以上配置后,即可启动训练过程。
在训练时,Sagemaker会在后台启动一个训练任务。该任务可以通过控制台查看详细信息。任务执行日志和信息也会打印到Jupyter Notebook中。
当看到“Reporting training SUCCESS”字样时,即训练完成。Sagemaker还会提供训练实例使用时间和计费时间等信息。
部署模型
当完成模型训练后,仅需要一行代码,即可以使用Sagemaker直接部署模型到生产。
predictor = lstm_estimator.deploy(initial_instance_count=1, instance_type=’ml.m5.xlarge’)
调用模型
通过调用已经部署的模型终端,可以对测试数据进行预测,利用预测获得的结果与实际测试数据进行对比,模型预测效果参见下图:
小结:
在云计算时代,业务成本核算往往不再能够通过将系统拆分为开发、购买、运维等若干费用模块分别计算并汇总。而是对业务需求进行分解后,在此消彼长的成本之间寻求最优化的平衡。
在本方案中,通过应用无服务器系统架构,极大的缩短了软件开发所需的时间,加快了系统上线的过程。而服务产生的额外成本相比节省下来的开发成本、部署成本、运维成本可谓是微乎其微。
因而在系统原型搭建,业务压力较小,或对系统容量需求不明确,且上线时间周期紧张的情况下,使用无服务器架构可以有效应对相关挑战。
同时,在大数据时代,物联网方案最终均需要落地到一个具体的业务场景之中。本案例中利用物联网传感器技术,结合机器学习算法,有效实现了控制质量高精度预测场景。相似的系统架构对于给予传感器的时间序列预测也具有参考意义。
参考文献:
Scaling up a serverless web crawler and search engine:
https://aws.amazon.com/blogs/architecture/scaling-up-a-serverless-web-crawler-and-search-engine/
Deploy trained Keras or TensorFlow models using Amaozn Sagemaker