彭俊,资深工程师,微软云计算架构师

当下的 IoT场景、数据挖掘,很多时候都需要使用消息系统+流数据分析+离线数据分析。基于此,很多客户包括集成商都开发了基于通用场景的架构来实现类似需求。来自horonwork的这张图就代表了一些场景:

实时的数据如IoT设备,爬虫信息,社交事件,都可以通过分布式消息系统传递消息。然后由流处理模块,离线处理模块,包括缓存层和索引层来给APP或者显示层提交可供消费的分析数据。

既然开源方案已经很成熟,在Azure上是否也有办法实现?

答案是肯定的。这一套从数据采集到事件中心到流处理/离线处理的方案是否与上图大同小异?

我们今天就来拿2套方案做个简单对比。

做个简单梳理:

今天笔者就搭建一下带*2套环境做个简单的DEMO

针对第二套方案,我们先在portal建立event hub,并在同一个resource group里建立hdinsight 组件,stormhbase 通过模拟温度收集器发送设备和温度数据给event hub,并通过storm topology来流处理温度信息。通过storm hbase的交互,我们保存所有数据进hbase并存在azure 存储里。最终将分析结果传递给webapp作为展现层。大致的arch如图:

组件如图:

网络:

这样storm就可以和hbase交互了。我们给eventhub建立好收发的规则并记录下用户名和密码。

我把这个实例里所有的程序代码都上传到我的github repo里了:

https://github.com/pjshi23/stormhbase-demo

我们通过nodejs 程序 sendevent 来模拟格式化的数据传输给eventhub:

编写storm topology java代码,下载hbase配置进你的本地文件夹,并本地测试编译。源代码在这里:https://github.com/pjshi23/stormhbase-demo/tree/master/TemperatureMonitor  记得改写一下config.property,填入evnethub连接字符串。

mvn clean compile package 编译成jar包。

这样本地就有了一个stormtopo包:

SSHstorm cluster并上传jar:

这时来到HBASE clusterhbase shell进入并创建hbase schema:

create 'SensorData', 'cf'

scan 'SensorData'

现在在storm里启动topo

storm jar TemperatureMonitor-1.0-SNAPSHOT.jar  com.microsoft.examples.Temperature Temp

进入stormuitopology已经开始运作了。

这时候,我们部署一下dashboard来接受分析完的数据:

检查HBASE数据:

部署完成:

之后可以使用eventhub的导出功能进azure存储和outputsql来进行更多可视化操作和离线分析。

我们之后来部署一下第三套方案并做出比较。 

 上面说到eventhub(kafka) + storm+hbase(开源方案)。其实客户也可以考虑在其中添加redis层,message queue层,甚至最后使用powerbi做为展现层等。从业务出发,完善整套基于开源方案但实际都存在Azure上的服务。

现在我们来说说完全建立于Azure本身提供的服务组件。

通过上图可以知道,在Azure体系里,event hub是数据入口的核心,而高速处理则是ASA(Azure stream analytics)所负责。在ASA处理过后,可以交给service bus做基于事务的进一步消费,也可以放在数据库里供展现层或者别的软件调用。而慢速处理部分,则可以选择交给hdinsight/HBASE/HADOOP/SPARK等做后续分析。亦或者丢给Azure blob/tabledata lake做储藏和分析。

今天的演示会比较接近这个架构,当然,data warehouseMl的部分我就不演示了。这也是我们cortana suite的简单演示,如果有兴趣可以参考:https://gallery.cortanaintelligence.com/Solution/Vehicle-Telemetry-Analytics-9

步骤和代码在此:

https://docs.microsoft.com/zh-cn/azure/stream-analytics/stream-analytics-build-an-iot-solution-using-stream-analytics

这里提供一键部署的脚本(国际版),有兴趣的同学也可以参考这个部署试玩:

https://github.com/Azure/azure-stream-analytics/tree/master/Samples/ASAOneClick

首先,我们创建event hub stream analytics 以及sql server

event hub添加逻辑入口。并使用模拟器发送业务逻辑数据,简单给一个partition做了listenerlatency几乎没有。throughput给单个partition大概在400左右稳定,接近100KB/S 一个RU的情况下)。

关联event hub+stream analytics,设置query做快速业务逻辑查询,并将数据导出到sql db

ASA跑起来后,就能得到实时分析出来的数据并存放在azure sql db里了。后续我们也可以把裸数据(raw data) 存放在table或者直接sinkazure sql/dataware里,做offline分析。

最后结合power bi等展现层应用,我们就可以很方便的查看实时和后期分析的数据了:

聊完这个组件,我们聊聊2方面的对比。从我个人理解的架构原则,“尽量采用成熟可靠的云服务和开源软件体系,自身专注于业务逻辑”但前提必须是:

  • 熟悉技术应用场景
  • 熟悉技术基本原理

由此引发的选型优先级,则应该是:

  • 成熟的适合的云服务
  • 成熟的生产化的开源体系
  • 闭环生态或者自主研发

依靠这个逻辑,在适合自己业务复杂度和性能需求的情况下:

Eventhub+ASA+Azure storage > Event hub+ storm+hbase(hdinsight) > kafka + storm+hbase(VMS)

这样,客户就基本摆脱了实际的运维考虑和成本,专注在了业务逻辑实现和产品附加值的体现上。

不过,我个人觉得纯IaaS实现在多云管理下,也是有一定的价值的。特别是在devops能力有一定强度的基础上。所以综合来说,我建议客户考评自身it 开发运维管理策略,结合成本和选型优先度,选择适合业务的方案。