1. 数据分析网首页
  2. 大数据

从0到1构建数据生态系列之三:拆解架构图

这篇我们来好好拆解一下我们的蓝图

接上一篇《从0到1构建数据生态系列之二:拓荒》,这篇我们来好好拆解一下我们的蓝图。

1 写在之前

之前有朋友在后台留言说,从第二章中,可以看出文章略显匆忙,并没有把拓荒的一些过程细节给描绘出来。

这里检讨一下,我坦白、我认罪。

当时那个话题一写开来的时候,突然就发现这是一个巨大的话题,随便发散下去又一大篇了,所以我还是在这一张穿插着把上一张的部分内容补充完整。

当然,至今为止,我已经把未来三章的内容规划出来了,这样更容易把控这个系列的质量。

所以,请期待,请不要放弃治疗。

回归话题,这一部分我将结合架构图中的东西,讲述我们是如何拆解完整的数据规划到执行的过程,并且期间一些思考方式也会一起分享出来(感觉这更是重点)

2 结合业务需求拆解架构图

这里,我们把之前一章已经上过的架构图再贴一次:

从0到1构建数据生态系列之三:拆解架构图

先简单的从整体上说一下这个架构图。

从架构图中,我们可以看出来,我们整个数据架构中,需要做的事情很多。

随着数据的流向,从下到上,主要分三层:

  • 第一层是数据收集层,负责基础数据的收集工作;
  • 第二层是数据存储以及处理层,负责数据存储,以及对数据进行深度处理,数据的转换,价值的挖掘等;
  • 最上层是应用层,基于下面的数据处理,进行价值转换;当然还有贯穿整个过程的监控以及任务调度相关的工作。

第一层中,主要有四个数据来源:用户行为埋点上报数据、服务日志的数据、后端的业务数据、互联网的公开数据。

第二层中,我们主要的核心框架是hadoop的核心生态,基于HDFS的存储(本质上hive的存储也是基于HDFS),以及基于spark的部分实时处理的需求场景,主要是平台级的架构。

当然,至于说具体的处理以及数据的加工、挖掘详细数据业务,后续其他章节再详述。

第三层中,我们直接面向的是业务方。

一方面是数据生态中最基础最常见的的数据智能商业化分析,我们以EXCEL封装成邮件日报周报的形式提供另一方面是平台化的BI系统,以及高度自助性的数据自助查询系统。

在深度挖掘方面,推荐是一个大方向,基于数据的当代搜索也是数据生态的重要组成部分,以及业务画像、用户画像(绝对核心价值所在)等。

当然,除了以上这些,还有一些基于数据的推送服务啊、榜单数据啊、精准营销系统啊,都是数据进一步有效应用,以及数据化价值的直接体现。

收回话题,在时间有限,人力有限,并且基础是0的前提下,事情解决的顺序就显得尤为重要了。

当前的业务需求。

想要使用数据,前提是有数据。所以,我们第一个需要解决的问题是数据源,但是核心的驱动价值因素是我们的业务需求。

我们第一个业务需求就是从数据上洞察产品的运营效果,电商的各种数据运营需求,指导内容数据化运营、电商数据化运营以及通过数据改进产品。

跟业务强相关的基础数据是产品的业务数据库,这个是现成的,只要打通数据流通即可。

与用户行为强相关的则是最直接的用户行为埋点上报数据,以及用户使用服务,在应用服务中留下的访问LOG。

基于服务日志LOG解析数据,一方面如果需要从服务LOG中清洗出有用数据,前提是服务中已经有意识的进行相关信息的LOG落地,这一点,很遗憾,当时并没有这个前瞻性。

其次,从服务LOG中清洗数据的代价略高,且信息量有限。

所以,在这个阶段中,我们并没有打算直接从服务LOG中清洗数据,因为在服务LOG中埋入数据收集点位,也是一个巨大的改造工程,但效果并不一定好。

我们将最快限度的打通业务数据库与数据中心的通道,然后以最快速度的对业务方提供可参考性的数据化日报。

打通行为数据到数据应用的链路,结合用户行为数据,进一步优化数据化运营体系,以及为产品优化迭代提供数据支撑。

构造最基础的数据中心平台,打通数据收集到数据分析应用的链路,为业务方、决策层提供数据化运营决策方案,为产品迭代提供最真实的数据反馈支撑。

这就是我们数据部门第一个战略目标,什么深度挖掘,什么推荐系统,这些在这个时候统统都不要想太多啦,饭需要一口一口的吃!

我们之所以需要拆分阶段目标,依然是投入与产出比的问题!

当我们有一个大目标时,我们需要把目标进行拆分,进一步拆分为阶段可实施、成果可见的阶段性目标,在这里同样适用。

并且,记住,你的老板是不懂技术的,他才不会管你的平台又建设到什么什么程度,集群又搭建了多少台,他只会问,这都一两个月了,你们数据怎么还没有给公司带来价值啊?!(哈哈,有点黑BOSS的感觉了)

不过这肯定是现实,不同位置上的人关注的核心重点不一样。可能你需要关注整体的进度,而业务层只关心你的产出给他带来什么帮助。

是的,拆解大目标有利于我们快速入手启动项目;成果阶段化,更具有鼓励性,成就感;最后就是阶段性目标的实现情况更容易量化你的效率。

从人力的需求评估角度上说,也是有道理的,只有随着你的体系一步一步完善,你才知道哪个环节真正的缺人,缺什么人,这点很关键。

不过最本质的问题,还是投入与产出比。

我们在做人一件事情的时候,都需要注意投入与产出的比例,在一定的时间段内、投入一定的精力、产出一定比例的成果。

有这种价值观,处理事务才更有效率!

3 如何做机器需求的评估

要打通数据收集到数据分析业务的输出链路,那么,你需要一个数据平台进行支撑。甚至,后续你将持续开挖的数据核心价值,也是基于平台上做的。

所以,我们需要一个数据平台,而说到平台,则机器资源是绕不过去的一个问题。

那么,如何去评估你的集群需要多少台机器呢?每个机器又是以一个什么样的角色而存在呢?

在评估之前,你首先清楚的了解到,你平台上需要承载的业务,包括内部的处理业务以及对外暴露的数据业务。

其次,你需要考虑后续一个可扩展性,即后续数据量上涨的情况下,机器的横向扩展当然是没有问题的,但是部分角色机器的资源需求是在纵向。

举个简单例子,Hadoop的datanode可以在横向上进行扩展,但是namenode的资源需求则无法做到。

至于说如何进行机器资源评估,在了解自身业务需求的前提下,这里所说的业务需求,不单纯是业务范围,也意味着业务范围承载的数据量是什么情况。

在了解自身数据量的情况下,多查找其他公司的案例,与其他同行多交流沟通,借鉴其他公司的数据量与集群规模,来评估自身所需要的机器资源。

不过需要注意一点的是,对于电商行业,经常会出现节日性、活动性质的流量暴涨。

所以,你的机器资源一定是需要考虑这些实际场景负载的,或者对于这种场景,你有其他的方案进行处理也OK。

4 使用Nginx做数据上报伪服务

上面说到第二个重点,那就是用户行为数据的上报。

了解数据上报以及埋点相关逻辑的朋友应该清楚,其实所谓的SDK,其本质也是一个接受数据上报的服务。

直接往上报服务中丢数据,跟封装成工具SDK,本质的意义是一样的,我们需要提供一个对外的数据上报服务。

上报什么数据,数据以什么格式上报,这个在下一章的“数据上报体系”部分详细阐述,这里只是对上报服务这块进行讲解。

那这意味着,我们需要为客户端或者H5的童鞋提供一个统一的上报服务接口,让他们在用户特定行为操作的时候。

比如浏览了某个页面,操作了某个按钮等之类的操作,进行这种信息的收集统一上报。

说白了,封装用户的行为数据,在适当时候调我们的接口,把用户的行为数据给我传过来。

那这看似就是一个后台服务,用于处理上报过来的数据。

但是请注意,不管你是一个服务也好,伪服务也好,一般情况下绝不会直接把获取到的数据直接落地的,这是传统的思维路子。

要知道上报的业务流量是很大的,特别是你的点位足够丰满的情况下,在流量高峰期,你要是敢直接进行数据落地,它就敢直接把你的服务给搞死。

一般情况下,我们都会把数据丢给缓存,以解耦上报与落地两端的压力。

既然如此,在有限的人力资源下,在项目时间有限的前提下,为何要花这么大的精力去维护一个服务呢?于是,有了伪服务设想。

我们直接使用Nginx对外伪装成一个Web服务,提供Restful API,但我们不对上报的内容做任何处理,直接落地成Nginx的日志,再通过Flume对日志进行监控,丢到Kafka中。

这样我们就迅速的搭建起一个上报“服务”,提供给客户端童鞋以及H5的童鞋,制定好数据上报的规范,然后就可以坐等数据过来了。

关于数据的合理性校验、规范性校验、有效性校验、以及进一步的解析,我们都放到Spark Streaming这一层去做。

其实当时也是调研过lua的,在Nginx这一层也是可以做到数据完整性以及有效性校验的,但是为了不至于给Nginx端带来过大的负荷,我们把复杂的逻辑处理放到后端。

基于这种伪服务的设计,还有一个好处就是,即使后端链路出现故障,但我的原始数据是落到LOG中的,了不起我进行数据的回溯,再通过LOG清洗出异常的部分就行了。

这也是我们后续实时数据容错的核心依据所在,所以,重点推荐。

5 使用Spark Streaming做实时数据清洗

接上面的上报,我们在后端一层是使用Spark Streaming做数据校验、进一步清洗的。

如果业务对于实时性要求不高,我们完全是不必要做数据的实时链路的,只需要周期性的把Nginx中的上报日志进行批量清洗入库即可。

但是,一方面基于部分对实时性稍高(其实也不高,分钟级别),例如电商活动期间对数据的实时监控;另一方面来说,实时性的数据上报链路是最终的目标,为了业务的时效性,迟早是需要做的。

由于我们需要在后端的处理环节中,对数据的有效性、规范性做校验,并且做进一步的属性解析,例如通过IP解析地理位置之类的,所以承载的业务逻辑还是蛮复杂的。

所以,我们打算引入一个实时处理框架来做这件事。

关于实时框架这块,我想,熟悉的朋友都会想到两个:Storm与Spark Streaming。

简单的说一下两者的对比。

很久以前翻译过一篇文章《翻译:Storm与Spark Streaming的对比》,这里只是简单的说一说。

Storm与Spark Streaming最本质的区分在于,Storm是真正实时处理,而Spark Streaming的处理本质则是微批处理。

所以Storm能够将实时业务达到毫秒级,而Spark Streaming虽然也能达到亚秒级,但对于效率的影响会比较大,所以一般会用于秒级的数据处理。

目前就我们自身的业务需求来说,对于实时性并没有高到毫秒级的要求。

并且,为了维护系统平台的统一性(统一的平台架构,统一的YARN资源管理,同一个垂直生态),我们选择使用Spark Streaming作为我们数据清洗的入口。

使用Spark Streaming需要解决的一个问题就是,输出结果的高度碎片化。

正如上面所说,Spark Streaming其核心依然是Spark的路子,在微小的时间窗内,对微小批量的数据进行处理,达到类似实时的效果。

而其每一个批量处理之后都是以批量结果得以输出,于是,就会产生大量的碎片文件。

其实,解决这个问题也简单,那就是合并!进行周期性的文件合并,这点就不多说了。

既然说到了Spark Streaming,也就顺带着说一说Spark这个生态。

在很早以前,Hadoop、MapReduce经常会被人提到,但是随着Spark的兴起,已经越来越少人愿意使用MapReduce去批量处理数据了。

是的,Spark目前在Hadoop大生态中,已经形成一个比较完整的子生态:

  • 包括与数据查询分析关联的Spark SQL;
  • 实时处理领域的Spark Streaming;
  • 正常内存处理可以替代MapReduce的离线批量;
  • 还有集成大量机器学习包的MLlib;
  • 以及还有什么图形处理的什么鬼(好吧,那个不是我擅长的)。

在效率至上的数据时代,MapReduce说抛弃就被抛弃了(哈哈,其实也没有这么严重,只是越来越多人弃用MapReduce,这肯定是事实)。

在体系支撑上,Spark依然成气候,数据的常规SQL分析,数据的内存处理、实时处理,以及数据的深度挖掘等,全部一起打包,好用的不得了,所以越来越得人心,也是木有办法的事。

关于IP地理位置解析,这里也可以分享一下。

IPIP.NET提供的IP库实在是值得推荐的,没钱的可以使用它提供的免费版,有钱的主可以考虑使用使用付费版。

其实免费版也没有想象中那么不堪,只是他提供的服务没有这么多,更新的频次少点而已,大部分能解析到市一级,至于省份这一级,那是妥妥的没问题的。

6 结语

这一章主要阐述如何从局部入手,拆解架构图,进行阶段性的任务执行,从这个角度讲,上一章节的标题反倒是更适合这个了。

其中,详细讲解了部分核心重点,包括架构图的拆解、机器资源的评估、Nginx的上报伪服务、以及基于Spark Streaming的数据清洗等。

但是,个人认为,更重要的是期中阐述一些问题的思考方式、价值观等。诸如拆解整体规划的思考、扩展预留的思考、方案选择的对比衡量等。

方法论远比现成的方案有用!我一向的观点是:授人以鱼不如授人以渔。

OK,到这里,本章节打完收工。

下一章节将很有意思,内容就不过多暴露了,看标题《从0到1构建数据生态之二:与研发团队的爱恨情仇》。

7 致谢

PS:在数据生态构建的初期,也咨询过很多业内的同行朋友,他们也给了很多真心的建议,所以,这里给这些大神们致谢!

哈哈,所谓的排名不分先后,都一律谢过:

  • @乐视云的祝威廉大神
  • @乐视云的一斐大神
  • @极客学院的马健大神
  • @百度的二铁兄
  • @前百度现GrowingIO的何健大神
  • @其他Storm-Hadoop-大数据群里,给过意见或建议的盆友

来源:数据虫巢,作者:blogchong

本文采用「CC BY-SA 4.0 CN」协议转载自互联网、仅供学习交流,内容版权归原作者所有,如涉作品、版权和其他问题请给「我们」留言处理。

发表评论

登录后才能评论

联系我们

如有建议:>>给我留言

QR code