大数据平台在分布式服务中的应用

对大数据平台的一些理解

大数据是目前比较火的领域，它涉及的领域比较广泛，例如数据挖掘、机器学习等等；所有这些基于数据的操作能够正常工作的前提是：搭建相应的大数据收集平台，在该平台中能够通过主动和被动的方式收集到足够的数据；一般情况下，大数据平台里的数据来源主要有：

（1）日志数据，相对于大数据平台，这是一种主动收集数据的方式；这种方式可能是大数据平台中最主要的数据来源，并且随着用户请求量、服务数量的增长，日志数据的数据将会成倍增长；此种方式收集的数据可能会有大量的无效数据（可能当前我们用不到这些数据），但是对于后续的数据挖掘会有较大的用处；

（2）上报数据，相对于大数据平台，这是一种被动收集数据的方式，这种方式收集的数据针对性强，基本都是有效数据，而且格式比较统一，便于数据分析和处理；

我们为什么要做大数据平台？

这与我们采用的技术方案有关，我们在组建后台研发团队后做的第一个项目是：推送系统，要求支持千万级在线用户，显然它的潜在要求是支持高并发，高可靠性；另外，由于目前用量还不够多，因此整个系统要能够动态扩缩容；为了设计支持如此的需求，我们采用了分布式服务的架构（其实我们一直很避讳谈微服务，我认为的微服务就是分布式服务的更规范化、通用化、自动化的一种实现形式），这样我们的推送就被设计成了多个独立的子服务程序，服务之间采用rpc通信（rpc框架使用了我们最为熟悉的Thrift），这一切都很顺利，我们整个系统最小化的集群部署（每个服务都是一个实例运行）可以轻松超越1500qps，整个系统的容量、并发性也都能随着水平扩展而增加，基本上满足了需求;后续我们逐步新增加了类似设计思想的IM、VOIP等业务以及分布式ID生成器、通用评论系统等等一系列平台性服务。等到这些服务陆续上线的之后，我们面临的问题逐渐出现了（只列出一部分）：

（1）当使用过程中遇到问题时，我们就得找运维同事把全部相关子服务日志都弄下来，对于运维，需要挨个机子把这些服务的日志文件取下来，对于研发来说，我们需要从第一个服务程序开始，挨个查找每个服务的日志文件，不仅非常麻烦，而且不利于定位问题！

（2）每个服务上的日志文件都有一定的保存期限，例如保留最近7天的日志文件，这样当我们想要分析7天之前的日志时可能就找不到了；

（3）有时候，一些问题可能要跨越好几天的日志文件，我们也不知道到底该要哪一天的日志，这时就得对每个服务的每天的日志都进行分析，这个工作量太大了；

不过，好的一点是我们提前对后台业务的日志格式做了规定：

（1）我们要求所有的日志输出都必须带日志索引；

（2）日志索引必须在每条日志的特定位置以特殊形式加进来；

（3）所有的接口函数必须在第一个参数提供日志索引，让调用方传递日志索引进来；

（4）在服务的入口处，需要从我们自研的分布式ID生成器中获取一个唯一的日志ID；

这样一个请求进入到系统，它的所有日志输出都是使用同一个日志ID，只要我们找到了对应请求的日志ID，就可以寻找到这个请求在所有服务中的日志信息；只是，我们目前得拿着这个日志ID到每个服务的日志文件里面去寻找！

为了解决这个问题，我们决定搭建自己的大数据平台，其实对于这个问题，有很多公司采用了常用的ELK三件套来解决，我们则考虑了如下几点：

（1）支撑各种日志的高效解析、处理和分析，我们未来的业务量可能会非常大，涉及到的新服务也会越来越多，我们就需要这个系统能够接受并解析各种日志；

（2）随着后续业务的发展，这些日志数据不仅能被用来解决“查找日志难”的问题，还可以做更多的数据分析，因此我们不仅需要ES的数据检索功能，还需对全部原日志数据的存储功能，以便后续spark做更复杂的分析和处理；

（3） ES中的数据存在也有冷热之分，越是近期的数据越有可能被访问，越是时间久的数据其热度月底，可能一个月之前的数据就不会被我们通过es来检索了。因此ES中的数据在一定时期内要定期清除，这时，我们就需要一个地方来存储全部的源日志数据，以便后续spark进行更为复杂的离线数据分析；

（4）这套系统不仅应该能主动收集各服务的日志数据，还可以接受阁各种数据传入，即它是一个数据平台，而非一个日志分析工具；

我们如何构建自己的大数据平台？

针对我们当时的分析，并结合前几年曾经使用过的方案，最终决定采用如下方式：flume+Kafka+strom+ElasticSearch+Kibana+HDFS+Spark

这套新方案的大概思路为：

这里：

（1） Flume agent部署在每个服务上，它读取每个服务的日志文件，并将读取的结果发送到kafka中；

（2）数据上报服务是自研的服务中心，它主要用于接收所有的上报数据，包括客户端上报的数据以及部分业务服务上报的数据，主要用于后续的统计分析；

（3） Kafka主要对来自各种数据源的数据进行汇总，当storm处理的速度大于这些数据上报的数据时，Kafka还可以对数据进行缓冲；

（4） ES作为搜索引擎，它存储了最近一个月的数据，并对数据提供检索以及部分统计功能；

（5） HDFS负责存储所有的数据，我们在storm处理中，几乎任何源数据都会存储在HDFS中一份；

（6） Strom 集群中，是每个类型的业务数据一个topology，例如：尽管我们统一了后台各服务的日志格式，但是由于后台采用的语言不同，并且还有很多采用开源软件，对于这部分与我们规定不一样的日志格式，就需要特殊处理；另外，ES为了加快检索速度，需要对关键字段进行提取，并组装成json格式，这部分的处理工作也是有ES来完成；以日志处理为例：我们需要从日志中提取出来时间、服务名称、线程名、文件名、行号、类名、方法名、日志索引等检索关键词，然后将这些关键词以及源数据组装成json格式存储到ES里，并且还要将日志按照各服务名称存储到HDFS中；

（7） Kibana是ES的展示界面，我们主要通过Kibana来对es中的数据进行检索；

（8） Spark主要用于离线数据处理。

如何实施大数据平台？

大数据平台已经上线一年多了，期间遇到的各种问题也逐渐解决，系统已经进入稳定运营和使用阶段，回顾过去实施的经历，还是有不小感慨：小步慢跑，千万别急；大数据平台听着比较热，如果没有实际业务趋势，很难在公司里引起重视，并且实施下去，大家都是呼声高做起来难！这就要求我们在架构设计时要能够迭代，无论是搭建这样大数据平台，还是前期设计各种分布式服务的应用都是如此；我们在搭建这套服务的时候基本分为了这样几个过程：

（1）预研并且搭建起来flume+kafka+storm，能够将数据收集过来并且传入到storm；

（2） Storm对接es、Kibana，让整个流程跑通；

（3）根据我们的业务，对storm的topology进行设计和分析，然后再进行topology的开发；

（4）对上述业务上线运营；

（5）新增全数据存储功能，引入HDFS；

（6）扩展数据源，引入数据上报服务中各种的数据，当然这一步也要对应的storm的topology来进行处理；

在我们实践过程中遇到的问题以及解决办法:

（1） flume多行日志合并收集；原生的flume是逐条从日志文件中收集日志数据，不支持多行日志的归并收集，这种场景主要针对java服务程序；例如：我们的java服务程序，在抛出异常时，要打印异常堆栈，这些堆栈信息都是每个调用占用一行，如此以来一条java异常日志内容将会被打印多行，flume现在无法处理这个问题：flume按行进行处理，它每收集一行日志就将之丢到kafka，Kafka会把每个丢过了的数据作为一个独立的整体，我们从storm中再也无法将这些多行的日志合并到了同一行中；

我们解决的办法是修改flume的源码：由于我们自研java程序都有日志规范，我们可以据此来识别出哪一行是日志的开始，哪一行不是！这样在flume进行日志手机的时候，进行延迟一条上报，即如果新读取的一行数据是一条新日志的开始，则将缓存的数据上交给kafaka，如果不是，则这条日志数据与本地缓存中的拼接起来；

（2） flume 的断点续传；例如，当flume挂掉再重启的时候，要能够从上次读取到的位置继续读取，不能文件的开头读，这样会在日志系统中出现大量的重复日志数据；断点续传是flume本身就具备的功能，使用时进行相关配置即可；

（3） storm连接es时，必须在topology中配置全部（或者尽可能多的）的es地址，不然，一旦所连接的es挂掉，es就会出现进程假死的问题。

大数据平台在分布式服务中的应用相关推荐

2021年中国大数据平台公有云服务市场规模达33.7亿元
IDC于近日发布了<中国大数据平台公有云服务市场份额,2021>,报告针对2021年中国大数据平台公有云服务的市场规模.增长速度.主要玩家.市场与技术的发展趋势等内容进行了详细研究. 报告 ...
离线部署 CDH 6.2 及使用 CDH 部署 Hadoop3 大数据平台集群服务
Cloudera Manager Cloudera Manager 分为两个部分:CDH和CM. CDH是Cloudera Distribution Hadoop的简称,顾名思义,就是cloudera ...
离线部署 CDH 5.12.1 及使用 CDH 部署 Hadoop 大数据平台集群服务
Cloudera Manager Cloudera Manager 分为两个部分:CDH和CM. CDH是Cloudera Distribution Hadoop的简称,顾名思义,就是cloudera ...
华为大数据平台FusionInsight HD部署中遇到的问题汇总
1.下载华为的FusionInsight 版本配置规划工具,有关浮动IP的填写(不需要自己手动去机器上进行配置): 与集群节点的IP处于同一网段,且唯一.即该IP地址在该网段没有节点使用.在服务器上P ...
进入hbase shell速度很慢_HBase——大数据平台之分布式NoSQL数据库教程
1.1 HBase下载:CDH(网站不显示,可以直接下载) http://archive.cloudera.com/cdh5/cdh/5/hbase-1.2.0-cdh5.9.0.tar.gz 1.2 ...
大数据平台的服务内容以及猛犸大数据平台近期的思考【摘录】
猛犸大数据平台经过去年一年的快速发展,已成为公司内多个产品的大数据开发工具的首选,作为一个当初定位为开发门户的这样一个平台网站,以调度管理为核心,将公司内已有的大数据工具进行了整合,提供了可视化的操作 ...
中通大数据平台在大促中的进化
一年一度的双十一又双叒叕来了,给技术人最好的礼物就是大促技术指南! 而经过这些年的发展,大促早已不仅仅局限于电商行业,现在各行各业其实都会采用类似方式做运营活动,汽车界有 818,电商有 618 .1 ...
硅谷企业的大数据平台架构什么样？看看Twitter、Airbnb、Uber的实践
导读:本文分析一下典型硅谷互联网企业的大数据平台架构. 作者:彭锋宋文欣孙浩峰来源:大数据DT(ID:hzdashuju) 01 Twitter的大数据平台架构 Twitter是最早一批推进数字 ...
内蒙农信携手星环科技建设农信大数据平台，激活金融业务创新
背景内蒙古自治区农村信用社联合社(简称"内蒙农信")经过多年的信息化建设,目前投产使用的信息化系统近100套,产生了大量的数据.该社于2019年采用MPP架构的分布式数据库,实现 ...

大数据平台在分布式服务中的应用

大数据平台在分布式服务中的应用相关推荐

最新文章

热门文章