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 分工与关注点不同，大家对各类日志器重水平不一，导致数据日志品质有时存在品质隐患，如何解决日志品质问题大抵有如下计划：

1. 数据 RD 负责设计打印：数据开发负责统计日志打印，造成数据开发整体的闭环，从而在基本上解决日志品质问题。对于不同的统计需要以及后续的扩展性上能够失去充沛的思考与模型设计。在技术实现上临时思考通过注解等模式拦挡后端属性，通过配置化解析来打印对应日志，可行性上有待商讨；另一种就是在业务开发的代码中嵌入对应的日志打印，这种和失常的日志打印没有区别，次要是负责的人不一样，分工不同。（数据闭环、工作量大）
2. 业务 RD 负责日志打印：约定大于配置，进步业务 RD 数据日志标准理解与器重水平。另外如果有条件还请把统计日志打印退出到测试流程！变成测试上线必要流程，这样能力在很大水平上保障日志的品质。（疾速、标准上稍微升高。目前采纳这种形式，不过没有强制测试流程，日志品质会造成后续统计问题）

业务源表

• 增量抽取
• 应用拉链表等相干表设计
• 一张业务表只抽取一次，避免资源节约
• 应用从库，避免影响线上失常业务

采集技术

日志采集：采集一般服务器就是应用 flume 进行采集；对应云服务日志采集能够应用 Log-Pilot 进行采集。

业务源表同步：能够通过 sqoop 抽取、或者 canal 解析 binlog 来同步数据，也能够采纳其余开源同步框架。

零碎设计

• 配置化治理
• 自动化
• 异样采集复原
• 监控体系建设
• 元信息记录残缺全面
• 日志形象

日志采集零碎架构设计如上图，大抵分为 5 个局部

1. 内部零碎对接：次要感知内部对根底数据有影响的局部，做到及时处理，能够提供零碎对接的接口。简略状况主动解决并发送变动信息到相干人员。

• 运维管理系统，感知服务器集群信息变动；
• 服务管理系统，感知各类部署服务变动状况；
• DBA 工单零碎，感知数据表构造变动新增批改等。

1. 日志管理系统

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

1. 日志采集服务

• LogMaster：日志采集服务主节点，管理控制日志采集服务 server，同时为了保障高可用采纳主从模式 standby LogMaster-Secondary，在主节点不可用时通过 zookeeper 实现主从切换；
• Log-server：日志采集根底服务，在服务器部署时就须要当成根底服务来部署，服务启动之后与 zookeeper 放弃心跳；该 server 依据 logMaster 调配的工作治理采集本人服务器上对应的日志信息，并监控 flume 与 log-pilot 采集状况，出现异常上报 logMaster；
• LogMaster-Secondary：从节点，在主节点不可用的状况下提供治理监控 server 执行状况与分配任务。

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

• 集群信息：同步与收集集群根本信息以及变动信息；
• 服务信息：同步与收集各类服务变动信息；
• 采集配置信息：系统配置的采集信息进行整顿收集；
• 日志源表形象信息：日志与源表采集的日志须要进行形象，不光实现日志采集，还须要明确采集日志的内容信息，以供后续对立指标口径、业务逻辑配置化。

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

• 采集服务监控
• 集群服务变动监控
• 日志数据落地监控，包含与数据源头数据量比照、日志自身同期比照监控等等
• 数据表变动监控，监控数据表变动，尽量实现自动化解决抽取，无奈兼容的状况下须要人工染指

日志与源表形象

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

• 结构化日志

  • 前端日志：通过 SDK 或者 WEB 接口收集到的日志，在设计之初就是一个结构化的格局，所以能够间接映射成前端日志对象，而后通过配置对象中的 action 和 page，标记日志类型，如曝光日志、点击日志、下单日志等；
  • 源表：源表个别都是 mysql 的数据，曾经是一种结构化的数据，同前端日志间接映射成源表对象与源表对象分类。

• 非结构化日志

  • 后端日志：因为后端日志各个服务打印各类参数泛滥，所以打印的时候采纳了可扩大的模式，为了映射成后端日志对象须要通过 ELT 把后端日志结构化，而后通过结构化的日志标记 action，来辨别和标记各类后端日志。

常见问题与解决方案

1. 没有明确日志标准，业务 RD 打印日志天马行空，后续各种兼容

• 解 1：约定大于配置
• 解 2：配置化治理
• 解 3：统计日志数据 rd 打印深刻业务

2. 日志抽象化没有遍及

• 解 1：在日志申请采集时，须要记录 采集：日志服务、服务器信息、目录信息、业务线、负责人、kafkatopic、日志形象信息配置；除了采集部署，须要通知零碎所采集的内容格局等

3、业务源表反复抽取至 hive，浪费资源

• 解 1：业务表抽取，检测只容许抽取一次；能不全量抽取就不全量抽取，采纳增量拉链表等形式
• 解 2：应用 canal 抽取数据处理

4、源表构造变动

• 解 1：提供接口，接入到 DBA 数据库线上治理平台，有变动时 主动解决变动

5、日志采集异样修复

• 解 1：采集异样预案与工具化建设