一、流量域概览
1.1 概念
众所周知，在数仓建设过程中，首先都需要划分数据域，以确定数据的方向。如交易域、营销域、客满域等，流量域也属于其中一部分，主要是针对埋点数据做一些数据处理和数据分析的动作，包含但不局限于活跃用户分析、漏斗分析、归因分析等，从而给运营团队，用户增长团队，商业化团队以及高层决策，提供强有力的数据支撑以做出正确的决策。
1.2 流量域建立初衷
建立"全面、准确、高效、低成本、高价值"的流量数据体系 ，整合全域流量基础数据，开启上帝视角，让业务做到知行合一 ，贯穿事前、事中、事后建设一套完备的数据质量体系，打造流量数据公信力。这是全体流量域建设者的愿望。要想做到这样，必须做到数据模型就绪时间早，执行时间短，查询响应快。
1.3 指导思想
1.3.1 建模理念
思考原则：
顶层设计思考原则（思考主题建设最终态）
建模原则：
1 高内聚低耦合
这是架构设计最主要的目标，实现系统的高内聚、低耦合遵从以下原则：利用分层架构实现系统在纵向上的低藕合；利用开源框架进一步确保纵向分层的具体实现；按照功能划分子系统来实现横向上的低偶合；利用包结构确保横向上低耦合的具体实现 。
主要从数据业务特性和访问特性两个角度来考虑：将业务相近或相关、粒度相同的数据设计为一个逻辑或物理模型；将高概率同时访问的数据放在一起，降低概率同时访问的数据分开存储。
2 核心模型与扩展模型分离
核心模型包括的字段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要和扩展。要避免破坏核心模型的架构简洁性和可维护性。
3 公共处理逻辑下沉及单一
越是底层共用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用实现，不要让公用逻辑多处同时存在。
4 成本与性能平衡
适当的数据冗余可换取查询和刷新性能，不宜过度冗余和数据重复。
5 数据可回滚
处理逻辑不变，在不同时间多次运行数据结果确定不变。
6 一致性
具有相同含义的字段在不同表的命名必须相同，必须使用规范定义中的名称。
二、流量域基础数据架构
2.1 数仓架构
2.3 技术架构
三、流量域数据全链路治理
目前的痛点：
- 大家可能会经常听到业务方抱怨，两张报表的同一个指标对不上？
- 开发和分析师共同抱怨，同样的指标，不同需求方提供的口径不一样？
- 数据使用方也会问，怎么我们的数据产出这么晚，能不能提前呢？
- 听到分析师抱怨，版本升级后，埋点改了也没人通知?
- 听到数据开发同学抱怨，每次都要从日志明细数据去取数据?
3.1 流量数据特性
- 数据量极其大(日增百亿，千亿甚至万亿，几乎可以达到百 T 甚至 PB 级别)
- 横跨多个数据域，业务场景比较复杂，需要数据开发对其他数据域比较了解，如用户域，会员域等
3.2 问题暴露
主要有以下几点导致问题发生：
- 埋点不规范
- 数据开发不规范
- 指标口径不统一，口径调整没用及时通知
- 指标重复开发，有可能造成数据一致性问题
- 烟囱式开发，大家都从 ODS 或者 DWD 层取数据，难以做到数据一致性及造成成本的浪费
- 指标波动情况没用的到有效的监控
- 数据的 SLA 无法保证
- 维表的维护问题
3.3 解决方案
3.3.1 完善开发规范，优化数据模型
基于现有的词根，词典，数据域/主题域划分，模型评审流程，数据开发规范，数据 ETL 清洗规范等做了进一步的完善优化
基于元数据着手于公共层数据模型的优化，并取得一定的成效，明显提高模型完善度，模型复用度及模型的规范度，提高数据研发效率和质量
3.3.2 埋点规范
什么是埋点？
埋点就是通过植入一段代码到某个页面或者按钮，从而收集上报用户行为数据。能通过埋点看用户在 APP 里做了些什么，访问了哪些页面（页面统计+行为统计）。
基于埋点管理平台，可以有效杜绝埋点混乱的问题。
3.3.3 指标管理平台上线
指标管理平台可以从根本上解决大部分指标一致性问题
3.3.4 数据质量保证
-
完整性
数据完整性问题包含数据条目不完整，数据属性不完整等 -
一致性
多源数据的数据模型不一致，如命名不一致，数据编码不一致，含义不一致，生命周期不一致等 -
准确性
准确性也叫可靠性，不可靠的数据可能会导致严重的问题，会造成有缺陷的方法和糟糕的决策 -
唯一性
用于识别和度量重复数据，冗余数据，重复数据是导致业务无法协同， 流程无法追溯的重要因素，也是数据治理需要解 决的最基本的数据问题 -
关联性
数据关联性问题是指存在数据关联的数据关系缺失或错误，例如：函数关系、相关系数、主外键关系、索引关系等。存在数据关联性问题，会直接影响数据分析的结果，进而影响管理决策。 -
真实性
数据必须真实准确的反映客观的实体存在或真实的业务，真 实可靠的 原始统 计数据是企业统计工作的灵魂，是一切管理工作的基础，是经 营 者进行正确 经营决策必不可少的第一手 资料。 -
及时性
数据的及时性是指能否在需要的时候获到数据，数据的及时性与企业的数据处理速度及效率有直接的关系，是影响业务处理和管理效率的关键指标。 -
逻辑检查
不同表字段之间可能会有逻辑关联，需要稽核 -
离群值检查
部分数据可能会偏离其他数据，比如同一个商品金额大家都是 100 元，而有一条数据是 1W ，对此也需要作出告警 -
波动稽核
与上周环比稽核波动情况 -
强弱规则
每个规则的权重应该是不一样的，需要配置优先级，这对后续的告警方式是有帮助的
我们最终的目的是希望做到页面可配置
3.3.5 SLA的保障
四、模型层面
4.1 模型设计层面
这个就没啥好说的了，严格按照模型架构，模型设计原则，分层原则去做模型设计，这个就没啥好说的了，如果这个没设计好，是会影响任务产出的，比如链路过长。
4.2 模型迭代
模型在迭代后，一定要先试运行再提交，保证此次模型迭代是没问题的，然后一定要看一下下游任务会不会受影响，尤其是在新增字段的时候。如果这些都没去校验的话，晚上极有可能是会有报错情况的，因为这么多年的经验发现，只要白天没有新任务上线或者老任务迭代，晚上不出意外情况的话，一般是不会有报错的，特殊情况除外。
但是只要白天上了新任务或者核心的模型进行了迭代，晚上值班人员就会慌得一批，一般都会报错。
4.3 模型优化层面
模型优化其实是多方面的，但是跟任务及时产出有关系的主要有一个任务调优及事实表或者维表的横向或者水平拆分。
之前任务有一条链路产出时间非常晚，几乎都是 10 点之后，后来发现主要有2方面的原因：
- 一个任务执行时长达到 2 小时
- 一个是一张核心维表有 2 个属性依赖于爬虫，爬虫每天早上 6 点才能爬到数据
所以当时我们做了 2 个方面的优化，一个是对运行时长过长的任务进行了 sql 层面的调优，最后这个任务 15 分钟就能产出，另一方面我们对该维表进行了垂直拆分，解决了 2 个爬虫获取的属性直接影响核心报表产出的延迟问题
当然具体的优化还是得看具体的场景，优化方式也是比较多的。
4.4 模型优先级设置
每个任务都应该设置任务优先级，这样我们就能知道哪些任务产出就基本能代表数仓核心任务全部跑完，并且在告警机制里面，优先级也是非常重要的一项参考。
五、调度层面
5.1 调度系统
目前发现的调度系统会存在以下 2 个问题
- 上游所有任务都跑完了，但是下游不会调起来或者很久之后才调起来，导致任务延迟
- 任务其实已经跑完了，但是状态一直是 running ，没有变成 success ，导致下游任务一直调不起来，导致任务延迟
这一块就需要负责调度系统的同学及时的去发现并且去解决这些问题，我们数据部门的同学也要及时的去跟他们反馈。
5.2 任务调度配置
- 任务没有配置上游依赖，可能会导致跑出来的数据全部是有问题的，这个时候就需要重跑，比其他问题引起的任务延迟更严重，因为这种的可能导致整个数仓任务重跑，换句话说就是晚上跑的任务都白跑了。
- 任务配置了相互依赖，循环依赖，大家都别想跑了，这个需要特别注意一下的。
六、大数据运维层面
6.1 资源
及时评估存储及计算资源，之前发生过存储不足导致晚上大批量任务报错的情况。
6.2 组件故障
这种遇到比较多的就是 hive on spark 出现问题了，连接不上，导致大批量任务报错。或者是别的大数据组件 server down，导致任务不能运行。
七、监控层面
7.1 数据质量监控
此项监控比较核心，对今日抽取的数据量，核心模型数据唯一性，核心指标阈值等进行实时监控，避免数据有问题也没发现，导致白天所有下游任务需要重跑。可以配置重要表的监控和字段监控，确保核心模型按时产出。
7.2 任务延迟未产出监控
这个就比较好理解了，一般我们运行的任务都会有一个差不多的时间范围，比如某个核心任务一般 2 点 - 2 点半就会产出，但是今天凌晨在 4 点钟开没开始跑或者还没跑完，这个时候就应该有监控报警，提示值班人员该任务产出时间异常。
八、值班层面
什么是值班？就是晚上不但要睡觉，还有负责整个数仓的任务正常运行，若不正常则需要处理。
上面说了那么多的方案，优化，报错，数据质量监控，任务延迟产出告警之类，但是如果没有人去处理这些问题，那将毫无意义。
这个时候我们将需要进行值班人员安排，周期安排，还有对应的告警机制，是邮件告警，短信告警还是电话轰炸呢，还有发现问题处理不了的话应该找哪一方，任务延迟故障定级等。目前我们也正致力于完善这一块内容。
作者：政采云技术团队
链接：https://juejin.cn/post/7111472481382170660
来源：稀土掘金
网友评论