PA数据平台-第一章-现有系统的剖析-CSDN博客

2019独角兽企业重金招聘Python工程师标准>>>

1. 现有系统

下图是现有收集各个移动端数据以及同步专业公司RDBMS数据库的系统结构图。现有系统结构

1.1) 系统结构说明

从上图可以看到，整个数据流的流转会经历下面几个环节：

接入前解析
集团下各个子公司的td数据，以文件形式的上传到source file等前置机上，前置机在启用单独的解析程序，对这些文件进行解析，解析完后产生俩个主要的数据，正常的解析数据，异常LOG。正常的解析数据放在专有的目录下面，等待同步任务进行同步。异常的日志，如果正常数据推送到各个专业公司，各个专业公司没有反馈异常，则会被清洗掉。
传输
开发人员开发各自种传输的shell脚本，上传到任务调度系统（oozie/scheduler），shell功能负责调用filesync工具，将远端数据拷贝到filesync本地缓存，最后调用hive接口，将本地数据上传到hive中日明细表按小时分区。整个流程结束后写生成一个成功标记文件，一天24小时会生成24个标记文件，放到hdfs中。如果失败，hdfs中不会存放成功标记文件。有多少个不同数据传输任务，就会有多少个shell，和与之对应的scheduler任务。
合并日明细数据
编写shell脚本，上传到任务调度系统，shell功能，负责检查是否产生24个成功标记文件，如果存在，则认为前一天数据已经传输到位，可以开始进行合并，将textfile格式的日明细数据合并到orcfile总表，至此数据上传到位
推送
推送童鞋，编写推送shell脚本，上传到任务调度系统，根据调度系统中设置任务启动时间直接对，启动推送，将总库中的数据，分发给集团下各个子公司
监控
目前的监控，加入了汇总后，以及推送后的数据监控，能够对每日的数据做到事后及时告警

1.2) 现有系统存在的问题以及原因剖析

从系统结构说明中，可以归结三个问题

数据质量受到挑战
在接入环节，缺少对异常日志的数据量，异常日志类型等异常分析，所以自然而然的就略过了解析程序bug引发的模式层的数据质量问题，略过了缺少主要关键字段，关键字段值域不一致引起的实例层面的数据完整性和一致性的数据质量问题。所有的问题都需要等待最终接收数据的业务方提出疑问后，才开始进行排查。由于整个系统现阶段是弱架构性的，所以这样的排查也是费时费力的，在后面2.4会说道如何破解目前的窘境
数据吞吐量受到挑战
在数据接入环节有俩个目标，一个就是保证数据的完整性和一致性，另外就是要保证吞吐量。现在filesync工具采用磁盘数据对拷，td的数据都需要拷贝到filesync所在的服务器本地磁盘。物理服务器带宽可以开到万兆，所以数据吞吐量瓶颈就是单任务磁盘的写入速度。服务器的CPU，内存，网络带宽都维持在一个较低的水平，登陆filesync服务器确可以看到磁盘的读写负载维持在较高的水平。从网络监控图中，我们可以做一个推算，单台服务器每天现有接收的数据20M/s2460*60s=1.7TB，目前已知td数据每日新增量在2TB左右，其他数据接入情况没做计算,这可以解释为什么前段时间上线某汽车主题的app数据后导致其他同步服务出现较大的延迟，如果承载的传输任务越多，这个传输效率还会进一步下降。以上是基于现有数据情况下所做的计算。
随着业务发展接入的数据增多会遇到几个问题。
1. 维护和扩展难，每个人员都必须记住自己配置的目录，文档没有维护好很容易漏。随着数据量的递增就需要考虑分盘，甚者分服务器。配置会更加眼花缭乱。容易出错。也容易影响到其他服务器的。同时需要改动所有同步的脚本业务和控制逻辑，容易引发新的异常。
2. 对接新需求容易干扰现有业务。应对突发问题，内化问题能力不足。现在缓存目录都是各个业务自己配置上去，没有全局的视角去做资源的权衡，很难知道自己上线的同步任务会对现有传输造成什么影响。磁盘传输速度有限，发生异常，历史接连几个任务需要同时在同一磁盘上传输容易造成，互相干扰，导致传输速度急剧下降。
3. 容错能力弱。filesync在同步的时候，会先去ping目标服务器，如果可以ping通，那么任务就会发往默认的第一台服务器，不论服务器的磁盘负载是否高。最坏的情况就是所有经过相同传输服务器的job都延迟。备用机的资源没法利用上。最坏情况是经过相同节点的传输的任务都延迟。
弱架构性
架构关注俩点，聚焦一个目标。关注组成系统的各个组件容错，恢复，扩展，以及易用性，关注各个组件之间的联系。最终达到降低成本目标。之所以说系统是弱架构的，是组成各个系统的模块的运维基本靠人工且缺乏明确的沟通和反馈的联系机制。各个组件联系方式各异，且需要开发特定的代码，而不是靠既定申明的协议实现程序的内在沟通。在前面俩点我们也谈论到系统的问题，现在在回头来看整个流程，分俩个流程：数据接入到推送过程，问题反馈与排查解决流程
1. 数据接入到推送过程：数据在推入GBD大数据平台，需要放在若干台的前置机进行解析，在解析后，解析程序会往写入的目录，新增一个文件，表示解析完成，数据在同步前，判断是否存在标记文件，如果存在解析程序写完，数据在同步完成后，程序会往hdfs目录写入另外一种标记文件，表示同步完成并且已经上传到hdfs，数据在合并的时候，需要遍历相应的目录是否存在一定数量的标记文件，如果是则完成合并。推送任务依赖合并的完成。在推送完成后在调用特定代码进行统计入库数。
2. 问题反馈与排查解决流程：当进行数据问题的排查时候，通常看scheduler日志，hadoop日志也难看出具体出现什么问题，有些代码关键逻辑日志缺失，或是只打部分，只告知一系列处理流程后的最终结论失败，失败的节点在哪里？需要查看代码！需要下载源码，查看看各种巧思写成的推送，合并，接入逻辑代码，这点很考验排查问题童鞋代码能力和开发经验，以及细心程度，代码杂糅在各种shell脚本，用java拼凑的shell业务中，很容易看漏一个逻辑。这里面可能也需要引入整个流程涉及组件与之管理的同学。排查流程长，周期长，代价大。
3. 反思：整个流程亲历下来，整个系统更像是临时拼凑而成，缺少从上至下的顶层设计，都是问题驱动，在遇到问题后开发补丁代码，进行修修补补。eg，将解析代码放在前置机就地解析；传输和合并标记文件采用不一样的标记方式；数据的统计是先写入到hdfs在通过sqoop同步到mysql。可以描绘下未来可能出现的场景，横向，流程环节需要增加；纵向，业务以及接入任务专业公司增加。开发人员需要直接对现有的上下游依赖严重的（eg：登陆标记文件所在服务器，查看标记文件是否存在），特殊状态硬编码（eg：判定同步的文件个数是否达到特定的个数），以及大量重复的代码进行修改，对开发，测试，系统稳定上线都是一个极大的挑战，随着时间流逝，接手人员的不断变更，这个成本只会越来越高。此外，做为一个数据平台，关注工程稳定运行是一方面，关注数据质量也是一个不可忽视的问题。eg：解析数据的数据质量，传输流程的数据质量，同步推送的数据质量。现基本为空白。