您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
大数据应用案例-如何搭建大数据平台技术架构?
 
  2168  次浏览      50
 2019-4-26 
 
编辑推荐:
来源于作者艾佳,本文以掌慧纵盈为案例,阐述了物联网企业的业务架构和数据架构,以及技术选型的思考过程。

如何搭建大数据平台技术架构?有没有好的大数据平台架构案例? 请看下文

借助“互联网+大数据+机场”三轮驱动,掌慧纵盈每年为6.4亿人次出行提供无线网络连接服务。 随着业务的拓展,随之后来的挑战是数据量的暴增。 2016年,掌慧纵盈通过阿里云产品,率先构建了业界领先的大数据平台。

以下来自掌慧纵盈的大数据平台架构师的分享:

业务架构

掌慧纵盈的业务架构如图所示。我们的业务模式主要就是通过自有设备对数据进行收集,对数据的价值进行挖掘,最后对这些数据应用。

数据收集层,我们创立了国内机场官方Wi-Fi第一品牌“Airport-Free-WiFi”,网络遍布全国25个枢纽机场和39个枢纽高铁站,每年为6.4亿人次出行提供无线网络连接服务;我们拥有全国最大的驾校Wi-Fi网络,到17年底将覆盖1500+所驾校;我们也是中国四大车展(北京、上海、广州、成都)Wi-Fi服务商,为超过120万人次提供了网络服务;此外,我们还运营了全国2000+个加油站和600+个汽车4S经销店的Wi-Fi网络。

数据应用层,我们打通了线上和线下行为数据,用于用户画像,为包括SSP,DSP,DMP,RTB在内的广告业务提供更高效的精准触达;并和公安部合作,排查公共网络安全威胁。

掌慧纵盈的大数据平台和广告投放平台还为企业输出技术能力,帮助企业建立自己的大数据平台,用丰富的量化数据提升企业的运营管理效率。

数据架构

基于我们的业务架构,我们抽象除了我们的数据架构,其中包含了许多主题,其主题视图如图所示。图中本体可以简单的理解为人,客体可以简单的理解为物;本体与客体以各种形式进行连接,这种连接是一种时间维度和空间维度上的交汇,这种连接通过计算机网络和电信网络完成。本体在连接网络中有自己的像,可以简单的理解为虚拟身份(Avatars);客体在连接网络中也有自己的像,例如维基百科对某一事物的描述,再比如某一事物商业化后形成产品或服务,再经过广告包装成其广告形象,这些都是其客像。本体与客体的交互实际上就是本像和客像的交互,这种交互在时间和空间的维度上都会留下轨迹。

本体的个体特征和群体特征,客体的个体特征和群体特征,本客交互的所有轨迹,所有这些主题形成的大数据,经过深度挖掘和学习,可以得出强大的洞察力,这种洞察力具有不可估量的商业价值。

掌慧纵盈目前在本体域和交互域的数据体量:

技术选型

接下来说一下我们技术选型的思路。我认为,没有最好的技术架构,只有最合适的架构。成功的IT规划就是从业务架构出发,针对其每一个业务场景,给出最合适的技术架构。

功能需求

首先来看我们的功能需求。以我们的广告业务为例,目标是日消息处理量达到100亿条。其对大数据能力的要求如下:

假设记录大小是2KB,容纳这些数据我们需要70PB的物理容量。对查询范围的要求,推导出,离线计算的处理时长24小时,在线计算10分钟。

非功能需求

希望通过云平台将基础设施安装运维外包。

大数据技术日新月异,希组件版本能够及时更新。

外部商业环境迅速变化,希望计算资源可以动态增减,以节约成本。

希望以较低的成本获取相对专业的安全服务。

尽量使用开源组件,方便整体输出。

产品选择

综合考察国内的云服务提供商,我们选择了阿里云,尤其是其E-MapReduce产品,购买之后,集群马上就创建好了,Hive, Spark, HBase等开源大数据组件即刻可用。

首先我们选择数据存储引擎。

我们以存储25TB的数据为基准,考察各个选项的性能和价格。从图中可以看出,针对离线分析来说,如果想用开源组件,可以考虑Hive on OSS的模式,来存储近一年的数据。针对在线分析的场景,使用HBase存储近三个月的数据,可以获得很高的性价比,这个方案可以多表联查,但是SQL的响应对场景敏感,不同复杂度的SQL响应时间是不一样的。如果希望响应时间恒定,可以考虑基于索引的方案,即日志服务,缺点就是不能多表联查;如果想使用开源组件,可以自行在ECS上搭建ELK。

接下来我们选择查询引擎。我们使用一个基准SQL,方便对其响应时间进行横向对比,基准SQL如下图所示:

结论是,使用Phoenix基于HBase进行交互式查询,可以获得很满意的响应周期。

选型部分告一段,接下来给出大数据平台的技术架构。

技术架构

大数据平台的技术架构概览如图所示,图中几乎所有的服务和功能都是通过阿里云产品来实现的,其中开发测试环境也是基于阿里云的ECS搭建的。从图中可以看出,我们并不需要关心机房的电源、网络、虚拟化、硬盘更换等一系列基础设施问题,直接基于云平台,专注于我们自己的业务。

产品使用中有一些心得,总结如下:

E-MapReduce

阿里云的E-MapReduce是我们大数据平台的核心产品,其涵盖了Hive, Spark, HBase, Storm等大数据领域核心的开源组件,还有Phoenix, Presto等业界前沿的查询引擎,其Zeppelin, Hue等交互组件也是开箱即用。

E-MapReduce不断有新的版本发布,其中的组件版本也是不断更新,但是已经购买的E-MapReduce是无法方便的升级的,为了及时升级组件版本,我们采取包月而不是包年模式。包月到期,想要升级,直接买新的,旧的不续费,自行销毁。阿里的E-MapReduce只能增加节点不能减少节点,通过上述的滚动模式,还可以随时调整集群规模和各种配置。

上述的这种滚动模式,对于计算集群来说没问题,数据存储怎么办呢?E-MapReduce所用的机器配置都很高,用来存储数据就可惜了,数据可以存储在OSS上,使用Hive加载即可。不过要使用HBase还是要把数据存到E-MapReduce上,一但放到E-MapReduce上,这个集群就不能随意销毁了。所以,我们实践当中将数据集群和计算集群分开,计算集群可以随时销毁和升级,数据集群需要长期稳定提供服务。这两种的集群配置也是不一样的,计算集群用SSD,主攻“快”,数据集群(HBase)用高效云盘,主攻“大”。

那按量付费呢,什么场景下使用?我们计算过,如果计算时长超过7天,那么还是直接购买包月的集群比较划算。按量付费的集群可以用于临时突发的计算任务。

工单管理

使用阿里的云服务,最吸引人的就是工单服务。由于我们的运维团队会经常遇到复杂且需要紧迫解决的问题,团队成员可以直接通过工单请求阿里的工程师协助解决。沟通问题的过程也是我们学习的过程,我们向阿里云服务的工程师们学到了不少的东西。

软件视图

基于技术概览,我们技术架构中的软件视图如下所示:

一些使用心得总结如下:

负载均衡SLB

原来,为了管理方便,我们好多云服务器ECS都开通了外网,但是实际使用率不高,外网带宽的成本占用云服务器成本很大的一部分,现在我们所有云服务器都去掉了外网带宽,统一走负载均衡SLB,共享负载均衡SLB的外网带宽,包括SSH等所有应用的端口都是用负载均衡SLB转发。负载均衡SLB带宽不受限制,速度上来了,成本下来了,算是我们对负载均衡SLB的一个活用。

云服务器ECS

由于我们的业务环境变化很快,有些机器可能今天还有用,明天就没用了,所以我们采用包月加自动续费的模式,随时增减机器,随时增配减配。

ONS

也即阿里的日志服务,阿里内部叫MQ,其响应时间很快,吞吐量很大,可以应用于实时性非常高的场景,例如实时竞价。

日志服务Log Service

其包含Logtail,LogStore, LogHub,LogShipper和LogSearch服务,其中日志投递(LogShipper)功能很有用,可以自动将采集的日志投递到对象存储OSS,这样就可以直接使用Hive加载了,不过目前只支持json格式。在我们的建议下,日志服务团队将会支持CSV,SequenceFile和Parquet格式,预计于2017年1月上线。

Spark

其官方给出的例子和阿里帮助文档里的例子都是基于Scala的,不过我们还是选择了用Java进行Spark应用的开发,这样我们开发团队的组建会更加便利。如果能使用Java 8,那么从函数式编程方式尤其是lambda表达式的角度就十分接近Scala的表现能力了。在我们的建议下,目前阿里云新版本的E-MapReduce已经支持了Java 8。

需要提一句,数据在大数据计算服务ODPS(现名称MaxCompute),那也没关系。E-MapReduce 提供 SparkSQL服务,可以无缝访问大数据计算服务ODPS数据。使用大数据计算服务ODPS的用户也可以加入到Spark生态体系中。

Storm

目前E-MapReduce已经提供了Storm组件,想要使用此组件,有两个选择:从日志服务消费;或者通过引导操作在E-MapReduce上安装Kafka,支持增加节点。

对象存储OSS

对象存储OSS主要用于存储,与E-MapReduce结合,实现了计算与存储的分离。

Zeppelin

这真的是一个好东西,业务人员通过它,可以通过Web的形式使用HiveQL, SparkSQL, Phoenix, Presto等对数据进行探索式和交互式的查询,而无需编程和登录SSH,并且可以保存过往的查询,还可以形成简单的柱状图饼图。我们的DMP工程师再也不用为了某一个统计数字通宵写代码了,业务人员自己就可以搞定。

Phoenix

HBase本身是NoSQL数据库,结构化查询是其弱项,我们就是有很多OLAP的需求,希望交互式出结果,原来的做法是自己创建HBase的二级索引,对非主键字段进行跳转查询。后来发现,E-MapReduce上,Phoenix已经为我们搭建好了啊,其索引机制生成的HBase索引表,不就是我们原来手工创建的索引表吗。于是全部转向使用Phoenix进行交互式查询。E-MapReduce老版本的Phoenix的默认查询超时是1分钟,对我们来说太短了,改参数又要重启。在我们的建议下,目前E-MapReduce新版本的Phoenix的默认超时时长已经设置为半个小时了。

场景举例

批量计算,LogTail + LogHub + LogShipper + OSS + Hive + SparkSQL

批量计算重在采集,使用LogTail配置好采集规则,通过LogShipper自动投递到OSS,使用Hive直接加载形成数据仓库,在Zeppelin界面上通过SparkSQL直接查询Hive中的数据,整个ETL的过程十分流畅,几乎不用写任何代码。

交互式计算,LogTail + LogHub + Storm + HBase + Phoenix

对于响应时间要求更严格的OLAP业务,可以以HBase为中心构建OLAP数据库,为了缩短数据可用的周期,可以单独一条通道。使用LogTail采集,并将LogHub中的数据对接到Storm上,使用Storm进行转换并写入HBase,然后在Zeppelin的界面上使用Phoenix进行查询。

实时计算,Servlet + ONS + Spark Streaming + Redis

对于实时竞价等实时计算业务,可以充分利用ONS的超快响应(1ms以内),超大并发的特性,通过Spark Streaming进行计算,最后存储到Redis中。

展望未来

Spark 2.0 发布了Release,Hadoop 3.0发布了Alpha,HBase 2.0 发布了SNAPSHOT,这些组件中的好多新特性都是我们十分期待的,我们会密切关注阿里云E-MapReduce新产品的发布,希望早日用上新版本的开源组件。

 

   
2168 次浏览       50
相关文章

基于EA的数据库建模
数据流建模(EA指南)
“数据湖”:概念、特征、架构与案例
在线商城数据库系统设计 思路+效果
 
相关文档

Greenplum数据库基础培训
MySQL5.1性能优化方案
某电商数据中台架构实践
MySQL高扩展架构设计
相关课程

数据治理、数据架构及数据标准
MongoDB实战课程
并发、大容量、高性能数据库设计与优化
PostgreSQL数据库实战培训