数据系统架构-1.基础数据篇

本文主要是介绍数据系统架构-1.基础数据篇，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1.基础数据篇

序

在这里插入图片描述

(图-本篇文章涉及红框内容，整体架构详见第一篇数据之旅-开篇)

本篇文章主要介绍一下基础数据部分，数据来源主要分成2方面，第一部分介绍一下日志相关内容，第二部分介绍一下业务源表相关，以及在此基础上构建的采集系统与抽象系统，之后再介绍一些常见的问题与对应的解决方案。

总则：基础数据是大数据的基础，规范化、合理、准确的基础数据可以使后续的各类数据应用开发事半功倍。（基础数据十分重要！基础数据十分重要！基础数据十分重要！）

巧妇难为无米之炊，基础数据就是大数据开发中的原材料，材料的好坏直接影响着后续功能的复杂度、稳定性、准确性。尽管基础数据这么重要，但是大多数情况下公司对基础数据的重视程度都不够，导致基础数据十分混乱，比如：日志格式就算在同一个格式规范下都能够五花八门、百花齐放，导致后续统计各种兼容，徒增复杂度影响后续数据的准确性；业务表数据反复抽取浪费资源与抽取表设计不合理等等。

基础数据就是大数据的伊始，一个规范化、合理、准确的基础数据，可以为后续各种系统打好基础。我们需要有耐心和细心逐步梳理整理各类信息，使基础数据调理清晰，数据井井有条。

日志种类与设计

日志是对未产生业务数据变化的行为进行的记录，是对业务库数据的一种行为上的补充，基本要素为 who when what，谁在什么时间发生了什么，从而对用户的行为进行记录与收集。以下日志格式是目前所采用的格式，当然可以有其他的更优形式，只要设计合理即可，如json等等。

1. 前端日志

日志定义：前端日志是用户在使用App或者Web页面应用，在App或者页面上收集到的用户行为信息,比如用户A在什么时间点击了某个按钮、用户B在什么时间浏览了某个商品的详情页等等。
日志协议
- 分隔符：可以采用八进制不可见字符 ‘\001’
- 字符集：UTF-8
- 时间格式: 13位UNIX时间戳
日志格式设计：
- token：用户标识 [必须]
- uid:用户注册之后的ID信息[必须]
- action：用户行为[必须]
- page：页面[必须]
- timestamp：行为发生时间[必须]
- datapool：标准字段之外扩展补充字段[必须]
- version：app客户端版本[可选]
- log_version:日志版本[可选]
- channelid：渠道[可选]
- os：操作系统[可选]
- osv：操作系统版本[可选]
- 其他扩展字段…
日志上报：
- SDK：App中提供的日志上报工具，把收集到的日志上报到对应的前端日志采集集群，日志采集集群把日志落地，以供后续flume配置采集，上传至kafka与HDFS。
- WEB接口：主要是提供给非App日志上报其他需要上报日志的场景，接口服务可以部署到采集集群里。

2. 后端日志

日志定义：后端日志是后端服务所打印的用户行为日志、系统性能日志、异常排查日志等组合而成，各类日志应该按照不同的日志类型打印到不同的目录，以供后续采集使用。采集分2种情况，一种是正常微服务日志采集，另一种是服务云日志采集，不同的情况需要不同的采集方案。
用户行为日志协议：
- 分隔符：采用空格分隔（如果日志参数中存在空格会造成解析异常）
- 协议：使用k=v的方式打印各类后端日志参数信息
- 字符集：UTF-8
- 时间格式：13位UNIX时间戳
用户日志格式设计（不同模块可以打印各种kv参数信息）：
- server：服务模块
- token：用户token标识
- uid：用户uid
- action：行为如 paySuccess、visit
- timestamp：日志时间戳
- 其他相关信息：如orderId，infoId
- …

系统性能日志 、异常排查日志 ，可以在系统接入层拦截统一打印与采集，日志格式上可以根据业务RD需要酌情设计，这2份日志主要是给业务RD做服务性能与问题排查。

3. 日志打印与质量

由于RD分工与关注点不同，大家对各类日志重视程度不一，导致数据日志质量有时存在质量隐患，如何解决日志质量问题大致有如下方案：

数据RD负责设计打印：数据开发负责统计日志打印，形成数据开发整体的闭环，从而在根本上解决日志质量问题。对于不同的统计需求以及后续的扩展性上可以得到充分的考虑与模型设计。在技术实现上暂时考虑通过注解等形式拦截后端属性，通过配置化解析来打印对应日志，可行性上有待商榷；另一种就是在业务开发的代码中嵌入对应的日志打印，这种和正常的日志打印没有区别，主要是负责的人不一样，分工不同。（数据闭环、工作量大）
业务RD负责日志打印：约定大于配置，提高业务RD数据日志规范了解与重视程度。另外如果有条件还请把统计日志打印加入到测试流程！变成测试上线必要流程，这样才能在很大程度上保证日志的质量。（快速、规范上略微降低。目前采用这种方式，不过没有强制测试流程，日志质量会造成后续统计问题）

业务源表

增量抽取
使用拉链表等相关表设计
一张业务表只抽取一次，防止资源浪费
使用从库，防止影响线上正常业务

采集技术

日志采集：采集普通服务器就是使用flume进行采集；对应云服务日志采集可以使用Log-Pilot进行采集。

业务源表同步：可以通过sqoop抽取、或者canal解析binlog来同步数据，也可以采用其他开源同步框架。

系统设计

配置化管理
自动化
异常采集恢复
监控体系建设
元信息记录完整全面
日志抽象

在这里插入图片描述

日志采集系统架构设计如上图，大致分为5个部分

1.外部系统对接：主要感知外部对基础数据有影响的部分，做到及时处理，可以提供系统对接的接口。简单情况自动处理并发送变化信息到相关人员。

运维管理系统，感知服务器集群信息变化；
服务管理系统，感知各类部署服务变化情况；
DBA工单系统，感知数据表结构变化新增修改等。

2.日志管理系统

配置管理：可以同步其他的系统的元信息，配置管理日志采集信息，管理日志采集的源头与采集落地目标信息，如从某个服务集群的某个目录采集到某个HDFS地址、某个kakfa的topic下等等；
源表数抽取：对应源表数据抽取配置，每天更加配置抽取对应的数据至HDFS，并映射成对应的hive表；
智能自动化处理：对于简单的变化场景，尽量实现自动化处理；
MySQL：各种配置信息存储。

3.日志采集服务

LogMaster：日志采集服务主节点，管理控制日志采集服务server，同时为了保证高可用采用主从模式standby LogMaster-Secondary，在主节点不可用时通过zookeeper完成主从切换；
Log-server：日志采集基础服务，在服务器部署时就需要当成基础服务来部署，服务启动之后与zookeeper保持心跳；该server根据logMaster分配的任务管理采集自己服务器上对应的日志信息，并监控flume与log-pilot采集情况，出现异常上报logMaster；
LogMaster-Secondary：从节点，在主节点不可用的情况下提供管理监控server执行情况与分配任务。

4.元信息管理，把信息关联起来【集群->服务->日志源->日志目的地（HDFS/Kafka）->日志抽象内容->业务口径、指标描述】

集群信息：同步与收集集群基本信息以及变化信息；
服务信息：同步与收集各类服务变化信息；
采集配置信息：系统配置的采集信息进行整理收集；
日志源表抽象信息：日志与源表采集的日志需要进行抽象，不光完成日志采集，还需要明确采集日志的内容信息，以供后续统一指标口径、业务逻辑配置化。

5.采集监控，对系统设计的各个部分进行全方位监控

采集服务监控
集群服务变化监控
日志数据落地监控，包括与数据源头数据量对比、日志本身同期对比监控等等
数据表变化监控，监控数据表变化，尽量实现自动化处理抽取，无法兼容的情况下需要人工介入

日志与源表抽象

在这里插入图片描述

日志与源表抽象，就是为了把一份份日志映射成一个个的日志对象，为了后续描述统计逻辑、指标口径、业务逻辑打下数据基础。

结构化日志
- 前端日志：通过SDK或者WEB接口收集到的日志，在设计之初就是一个结构化的格式，所以可以直接映射成前端日志对象，然后通过配置对象中的action和page，标记日志类型，如曝光日志、点击日志、下单日志等；
- 源表：源表一般都是mysql的数据，已经是一种结构化的数据，同前端日志直接映射成源表对象与源表对象分类。
非结构化日志
- 后端日志：由于后端日志各个服务打印各类参数众多，所以打印的时候采用了可扩展的形式，为了映射成后端日志对象需要通过ELT把后端日志结构化，然后通过结构化的日志标记action，来区分和标记各类后端日志。