精华内容
下载资源
问答
  • 2021-08-23 10:17:49

    01前言

    为什么想开这个话题,一是因为目前业内数据产品也基本完成了从0-1的建设工作,但主要集中在数据生产加工和数据应用分析两侧,对于数据管治方向的建设多分散在了包括安全、指标元数据、SLA等在内的各个环节,缺乏统一的规划统筹,笔者认为,数据产品可以分为工具类数据产品、业务分析类数据产品和管控治理类数据产品三类,而工具类数据产品和业务分析数据产品市面上也开始趋近饱和,但管控治理类数据产品其实是更高能力要求的一个细分工种,既需要懂工具建设也需要懂数据分析,还需要具备跨多团队横向协调的项目推动能力和策略运营能力;二呢,笔者曾经就做过一次失败的大治理工作,也做过一次相对成功的安全治理工作,也参与过指标监控、安全工具等的建设,所以也想把这其中那的成功和失败的经验分享出来供大家参考。

    02概念定义

    根据笔者的研究,目前业内数据治理总结起来一共分为两类,一类是狭义的数据治理,是指数据指标口径一致性的治理,此类数据治理主要是解决指标口径的一致性,解决数据“不准”的问题,也由此引申出一些智能数仓、指标元数据工具,比如美团的起源、快手的盖亚、阿里的dataphin等等;另一类是指广义的数据治理,是指包括数据指标口径治理、数据安全治理、数据资源成本治理、数据资产元数据治理、数据产出治理等在内的大治理,此类数据治理是需要综合解决数据从采集加工到应用分析再到销毁全生命周期内的口径、成本、安全、合规和产出问题,在工具建设上,目前笔者看到的多是分散在数据安全、资产中心、SLA中心等不同的产品领域。

    03结论先行

    这次笔者就不卖关子了,直接抛观点,笔者认为,数据治理战略层面的设计总结就两点:

    第一,数据治理是一个系统性工程。数据治理主要面对三个问题,一是用户心智培养问题,二是组织保障问题,三是系统提效问题,所以,单纯从组织保障层面发力会面临效率和质量不高成本却奇高的问题,单纯从运营机制建设层面发力会面临缺乏组织和工具来落地策略的问题,单纯从建设工具发力会面临缺乏组织抓手且找不到核心使用用户,需求无法进入正向循环的问题。以上问题一句话总结就是靠组织无法长期有效,靠运营无法落地实施,靠工具又缺乏用户和需求持续跟进,因此,数据治理是一个需要组织保障、运营实施和工具建设三位一体跟进的工作。

    第二,数据治理又是一个抓大放小的工程。世界本质是一个熵增的过程,即任何事物本质是一个自发的由有序向无序发展的过程,这个既是人性也是客观规律,而数据治理本质是减熵的过程,是建立秩序,因此任何的治理本身是逆人性和逆客观规律的,需要源源不断投入能量(资源)才能维持熵值平衡。但问题就在于,人性天然有建设性和破坏性两面,想要秩序的存在并维持下去,本身就是需要投入非常大的建设精力和成本的,而且这个成本还不是一成不变的,它是随着公司资产的累加而增加的,也是会随着公司战略、制度和文化的革新变化而变化的,因此,数据治理工程中追求完美主义是不可取的,我们要学会分类分级,学会判断优先级,学会抓大放小,允许有序和无序的并存。

    04问题分析

    数据治理到底解决什么问题?或者说什么问题的存在才需要数据治理?首先,我们来场景化模拟下数据从诞生到销毁的一生中遇到的主要问题。

    场景1:小明是A视频公司的策略产品经理,工作职责之一就是分析用户的特点和行为习惯,从而帮助算法工程师优化视频推荐策略,从而提高用户对视频APP的使用黏性。这天,小明抽样了部分用户浏览行为数据,发现部分用户单位时间内视频切换速率较高,停留时长较短,且点赞和关注数都较少,小明猜测是算法推荐的质量有问题,小明找了算法RD,算法RD却回复最近视频推荐的准召率(准确率和召回率)没有问题,并没有出现下降,肯定不是算法的问题,是视频内容质量的问题,或者是抽样数据的问题。小明很苦恼,为什么数据分析下来,小明觉得用户对视频的喜好度是不够高的,但研发说准召率却没问题,那问题出在哪?

    场景2:小红是B咨询公司的新来的数据分析师,最近她接到一个任务,需要为客户的一个市场咨询报告提供数据分析支持,因此小红从业务经理那里了解完需求后,开始从公司数据库和第三方数据库获取数据,但事情却一波三折,就单单在业务数据分析的定义上就来回沟通了好几次,业务经理告诉小红她想知道a指标的数据,小红翻阅了前人关于a指标的统计口径记录发现,a指标居然有不下10个统计口径,诸如a1字段在x1维度下的聚合、a2字段在x2维度下的聚合等等,到底应该遵循哪个规范?结果咨询一堆同学,发现每一个口径都有特定的需求背景和定制化规则,这一通忙活。。。

    场景3:小东是C公司的数据RD,最近他经常半夜被各种数据跑批任务延迟和失败告警给吵醒,原来是公司最近要迎接618,活动量的爆炸式增长导致业务数据量的爆炸式增长,而业务报表的数据统计逻辑和背后的数据源却没有及时优化,导致集群计算资源不足以支撑暴涨的需求而出现任务延迟或者失败的情况,这个情况又影响了业务报表的数据及时展示,影响了公司各业务KP邮件报表的及时性。

    场景4:小阳是D公司的安全运营,最近公司上线了一个新业务,和已经上线的几家公司形成了假正经关系,然后他最近经常收到市场情报反馈,竞品公司能迅速感知到公司的投放数据和增长数据,到底是哪个环节出了问题,为什么竞品公司能这么快知道公司核心数据机密,这让他最近压力倍增?

    分析以上问题,场景1其实是数据指标准确性的问题,场景2的问题主要是数据指标规范性和唯一性的问题,场景3主要是数据产出及时性的问题,而场景4是数据安全性的问题,以上,笔者认为都属于数据治理需要解决的问题。

    05治理目标

    综上,数据治理的目标主要是解决以下四方面的问题:

    1. 规范治理:解决数据完整性、规范性和唯一性问题

    2. SLA治理:解决数据产出及时性问题

    3. 口径治理:解决数据指标准确性和口径一致性问题

    4. 安全治理:解决数据采集生产应用各环节中账号注册认证、权限管理、安全审计和隐私保护等安全治理问题

    06策略概述

    1. 成立数据治理委员会,提供立法和组织保障:

    • 成立治理制度执委会,负责研究和出台相关治理制度和规范标准,目标是促成公司内各个业务团队达成共识,形成统一规范,避免信息孤岛

    • 成立治理产品执委会,负责梳理数据各环节的需求处理流程和业务流转流程,负责各环节的治理工具建设,形成可执行方案,然后报制度执委会推行

    • 成立治理技术执委会,负责数据各环节的技术定义、模型设计和口径维护,对数据资产的落库规范性和唯一性等负责

    • 成立第三方治理审计监察组,负责治理效果的评估、badcase的运营跟进和事后追溯审计

    2. 建设数据治理套件,提供工具保障:

    • 建设资产治理中心,目标是为解决数据元信息的完整性、规范性、唯一性提供技术支持

    • 建设SAL治理中心,目标是为解决数据生产加工任务产出的及时性和任务调度的运维提供技术支持

    • 建设指标治理中心,目标是统一指标定义、指标生产和服务,解决指标口径一致性和服务的效率问题

    • 建设安全治理之心,目标是为数据安全5A领域)(账号、认证、授权、审计、隐私保护)的问题提供技术支持

    07策略详述

    1流程保障策略

    图片

    图1:数据治理流程保障规划示意图

    思路:如上图所示,数据治理流程保障规划整体思路参考PDCA循环,即制定详细规范方案,然后去验证并解决问题,接着检查问题是否真实被根本解决,最后根据反馈再继续爹迭代方案,进入下一个循环。

    机制:如上图所示,数据治理流程保障规划整体解决机制上分为三个部分,分别是事前预防,事中监控和事后处理。第一部分的目标是尽量将潜在问题在未爆发前就消灭掉;第二部分的目标是尽量将问题都找出来,减少影响范围;第三部分的目标是对暴露出的问题进行快速响应和解决,并总结经验。

    整体流程:如上图所示,数据治理流程保障规划整体流程上将以解决数据质量六性问题(唯一性、规范性、完整性、准确性、及时性、安全性)为目标,按照“规范建设-质检审查-发现问题-评估问题-解决问题-验收问题”的闭环流程,贯穿整个事前、事中和事后的环节。

    具体实施:如上图所示,数据治理流程保障规划的具体实施细则上,会重点依托易龙的“数据治理五大项目模块”,然后每个模块都按照“规范建设-质检审查-发现问题-评估问题-解决问题-验收问题”的闭环流程进行梳理和规划。

    1.1 定义理想态

    ① 发现问题

    • 召回率(覆盖率)100%

    • 准确率100%

    指标释义:

    召回率(覆盖率):召回率又叫覆盖率,是指所有真实存在的问题中,系统或者人工检测出的问题占比。例如一共100条数据,其中20条存在异常,系统报警显示有30条存在问题,事后被验证30条报警中真实存在问题的有10条,则召回率(覆盖率)=10/20*100%=50%

    准确率:是指所有被系统或者人工检测出的问题中,真实存在问题的占比。例如一共100条数据,其中20条存在异常,系统报警显示有30条存在问题,事后被验证30条报警中真实存在问题的有10条,则准确率=10/30*100%=33.3%

    注意: 理论上最理想的状态就是一次监控任务中,所有问题都被发现,且所有报警的数据中没有掺杂虚报情况,也就是召回率达到100%,准确率为100%。但是实际场景中,这样的理想情况几乎是不存在的! 过度追求高召回率,监控规则一定会设置的异常简单,那往往会有很多正常的波动会被系统判定为“异常”;同理,过度追求高准确率,监控规则一定会设置的异常苛刻,那自然被报警的数据都是存在异常的,准确率100%,但是这样往往很多异常数据会被监控系统给漏掉,漏报率就会异常的高!

    因此,优秀的监控系统都是根据实际场景一直在找寻召回率和准确率间的平衡点。

    ② 解决问题

    • 响应时长:24小时内响应问题

    • 定位问题:3天内完成问题的定位

    • 解决问题:2周内彻底解决问题

    ③ 数据通道质量

    • 丢失率<0.1%

    • 重复率<0.1%

    • 延迟率<0.5%

    1.2 规范建设

    ① 唯一性

    • 指标、纬度、模型、库表、数据、报表的唯一

    • ID唯一

    • 名称唯一

    • 定义唯一

    • 加工逻辑唯一

    • 产出渠道唯一

    • 相似的指标、纬度、模型、库表、报表做减法,减少冗余

    ② 规范性

    • 流程规范

    • 需求→评估→处理→测试→上线→验收环节严格执行

    • 数据和流程double check

    • 测试、试验验证数据质量和流程执行情况

    • 日志、库表、模型、报表、代码有统一的设计和输出规范,信息齐全、分层合理、资源使用合理

    ③ 完整性

    • 日志、库表的元信息完善,灰度测试阶段只有空值率、异常值占比、分区缺失等指标合格后方可上线发布

    1.3 发现问题:监控体系建设

    如图2和图3所示,对于重要级别的日志、指标、库表数据,除了粗粒度的质检外,还需要每天进行更加严格和科学的监控,以提前发现问题并推动解决:

    图片

    图2:数据埋点质量监控报表

    图片

    图3:数据指标准确性监控报表

    ① 完整性(是否缺失或不可用)

    • 日志

    • 丢失率

    • 库表

    • 丢失率

    • 分区缺失

    • 信息缺失(0、空值、NULL)

    ② 准确性

    • 业务侧

    • 相同指标不同报表间建立交叉验证

    • 相同报表不同指标间建立逻辑验证

    • 相同报表相同指标建立波动验证

    • 技术侧

    • 埋点间的交叉验证

    • 多层库表间相同指标交叉验证

    • 明细层和统计层建立数据量、行数、计算结果的比对验证

    ③ 及时性

    • 日志上报

    • 有效上传率

    • 延迟率

    • 资源使用

    • 当前占用占比

    • 剩余资源占比

    • 任务调度

    • 完成率

    • 失败率

    • 延迟率

    1.4 问题分级

    ① 监控分级

    • 对业务的影响度

    • 模型、库表、报表使用热度

    • 作业耗时热度

    • 故障分级

    ② 预警分级

    • 蓝色预警

    • 黄色预警

    • 红色预警

    ③ 报警方式

    • 电话

    • 邮件

    • 短信

    • 企业微信

    1.5 事后处理

    ① 问题跟踪处理

    • 问题分发(按业务、主题、部门等划分问题归属)

    • 问题跟踪

    • 问题原因追溯

    • 问题解决排期

    • 问题解决反馈

    ② 问题验收

    • 业务验收

    • 监控系统验收

    ③ 定责存档

    • 事故等级划分

    • 事故存档

    2组织保障策略

    图片

    图4:数据治理组织保障规划示意图

    责任划分:以“规范建设-质检审查-发现问题-评估问题-解决问题-验收问题”的闭环流程为切入点,将“需求规划组、模型工程组、质检监控组、审计评估组、数仓工程组、应急响应组”分别配属到对应的环节中去,以提供流程执行的组织人力保障。

    平台支持:重点建设埋点管理平台、元数据管理平台、质检监控平台、工单管理平台,为各流程环节中的组织人效提供帮助和支持。

    具体实施:如上图所示,数据应用PM、数据平台PM和模型工程师将对整个数据治理组织和平台的健康高效运转负责,并对其向数据治理委员会汇报。

    2.1 成立数据治理委员会,提供立法和组织保障

    • 成立治理制度执委会,负责研究和出台相关治理制度和规范标准,目标是促成公司内各个业务团队达成共识,形成统一规范,避免信息孤岛

    • 成立治理产品执委会,负责梳理数据各环节的需求处理流程和业务流转流程,负责各环节的治理工具建设,形成可执行方案,然后报制度执委会推行

    • 成立治理技术执委会,负责数据各环节的技术定义、模型设计和口径维护,对数据资产的落库规范性和唯一性等负责

    • 成立第三方治理审计监察组,负责治理效果的评估、badcase的运营跟进和事后追溯审计

    2.2 项目落地实施划分一系列项目小组

    • 成立需求规划小组,对所有业务需求的接待和规范负责

    • 成立模型工程小组,对接数据应用PM,对数据从业务关联到技术侧的文档和规范负责

    • 成立质检监控小组,对数据业务测试和技术测试的实施负责,对数据上报的质量筛查负责,对数据质量的监控负责

    • 成立审计评估小组,对上报的问题评估定级负责,对问题的合理分发和处理进展负责

    • 成立数仓工程小组,对数仓的规范建设负责,对问题的修复负责

    • 成立应急响应小组,对紧急高优先级的需求快速高质量负责

    3运营思路

    数据治理项目规划地图横向一共分为机制、流程保障、细则、责任划分、工具平台和各个子项目模块(包括日志埋点模块、通道传输模块、内容规范模块、加工过程模块、语义定义模块)

    数据治理项目机制划分为:事前预防——事中监控——事后处理

    数据治理项目流程保障划分为:规范建设→质检审查→发现问题→评估问题→解决问题→验收问题

    图片

    图5:数据治理项目规划地图

    05结语

    本期主要从数据治理的问题分析、治理目标和治理策略进行了阐述,下期起将重点介绍数据治理涉及的相关工具和平台建设,包括资产治理中心、SLA治理中心、安全治理中心和指标治理中心等,

    更多相关内容
  • 2021年浅谈图书馆联盟的多层治理模式与可持续发展策略.docx
  • 为解决大同矿区立井井筒穿越多层采空区的技术难题,提出在井筒开凿前,对其穿越的采空区及其危害进行综合探查和评估,采用地面预注浆技术对采空区进行治理,注浆结束后进行效果评价。通过工程实践表明,井筒采空区采用...
  • 根据已发生的多次冲击显现分析了坚硬顶板多层煤开采条件下冲击地压发生原因。根据微地震监测数据确定了对工作面冲击危险产生主要影响的坚硬岩层。提出从降低静载荷、削弱动载荷、增强抗冲能力、完善冲击危险性监测...
  • 为了保证地面瓦斯抽采系统建(构)筑物基础的长期稳定性,通过验证孔钻探和钻孔电视技术对场地下伏采空区物探成果进行检验,综合确定了采空区治理范围。采用地面充填注浆技术对下伏3层采空区进行治理,共布置注浆钻孔34个...
  • 2021年 各行业安全生产教育培训
  • 一些主要理论是:传统治理,多层治理,数字治理,问责制,领导力,人类发展治理,治理和争议解决以及网络治理。 治理研究的内在美在于它可以应用于任何领域或学科。 1.本文将专门研究网络治理及其在斐济公共部门内...
  • 社会治理平台建设项目是面向J2EE企业级分布式多层体系架构,数据库采用MYSQL数据库,但应支持主流数据库类型,方便今后迁移或变化,系统划分为基础设施层、数据资源层、应用支撑层和应用系统层。并且采用面向服务的...
  • 针对唐山矿12号井-793m水平井底车场出车线巷道受构造应力影响变形严重,每3~5个月就需要套修1次的现状,以钢丝绳为骨架的柔性喷层封闭围岩,以多层锚杆和注浆提高煤岩自身强度及承载能力,构建高强度支护圈体,加强跟踪...
  • 碎软厚煤层大采高工作面瓦斯治理时,采用多层钻孔才能覆盖整个采高,同时还须保证足够的钻孔深度,才能满足瓦斯抽采的需要。针对碎软煤层多层深孔施工对钻进装备的要求,研制了ZDY10000L大功率多层孔钻机,配套了宽翼片...
  • 向家坡滑坡是一个具有多层滑面的组合式滑坡,滑面由浅层滑面、中层滑面和深层滑面组成.针对该滑坡受到不良地质情况和大气降雨等因素的影响,经过3次治理后并未取得良好效果的情况,拟对该滑坡进行第4次治理.在密切...
  • 研究表明:地质与水文地质资料分析是资源整合矿井水害隐蔽致灾因素普查与治理的重要基础手段,地面物探结合井下物探是解决多层采空区积水探查的较好方法,钻探结合物探技术是疏放多层采空区积水较好的途径。
  • 庙沟铁矿地质条件复杂,主井井筒穿过的地层含多层富水含水层。井筒施工至-150m水平时,爆破施工后,出现突水,涌水量约120m3/h。由于排水能力不足,井筒水位迅速升至-15m标高,井内水深135m。为此,增大了井筒排水能力,降盘...
  • 微服务:架构体系的深度治理

    千次阅读 2019-09-05 16:03:47
    微服务模式下,庞大的服务节点数量、日趋复杂的服务分层、离散的组织协同、扁平化的管理模式让服务治理的广度、深度、难度都达到前所未有的程度。 单纯依靠微服务框架层面的治理是远远不够的,需要构建贯穿研发、...

    微服务模式下,庞大的服务节点数量、日趋复杂的服务分层、离散的组织协同、扁平化的管理模式让服务治理的广度、深度、难度都达到前所未有的程度。

    单纯依靠微服务框架层面的治理是远远不够的,需要构建贯穿研发、测试、运维、管理各领域的立体式的深度治理体系。

    本文整理自天弘基金(余额宝)移动平台技术总监兼首席架构师李鑫在 QCon 全球软件开发大会(北京站)2019 上的演讲,他基于自身多年微服务治理的实践经验及感悟,全面地介绍了如何构建完备的微服务治理的指标体系及治理模型,并通过自动化的线上线下一体的“度量”及“管控”这两大能力的构建来综合解决微服务全生命周期的现实治理需求。点此下载完整版 PPT。

    在 QCon10 周年的大会上,我做了题为《微服务架构体系的深度治理》的分享,现将 PPT 和演讲文稿整理出来,希望能够给仍在(微)服务治理迷局中夺路狂奔的同学们一点启发和指引。

    微服务架构体系的深度治理

    这次分享

    • 首先介绍了服务治理的发展历史,它的 4 个阶段
    • 接着重点介绍微服务度量及分析体系的构建
    • 最后,分别针对微服务线上及线下体系的治理进行深入探讨

    微服务架构体系的深度治理

    “治理”这个词,在汉语词典中是“整治、修整”的意思。任何一个事物,当它的复杂度达到一定程度时,就可能出现问题,我们需要对问题进行梳理、改进和优化。因此,对事物的治理,本质上是对事物复杂度的管理。同样的,服务治理就是对服务复杂度膨胀问题的管控及管理。

    微服务架构体系的深度治理

    【单体应用及其治理需求】

    在业务发展的早期,我们也许用一台机器就能扛住线上所有用户的访问,所有的功能和模块都被整合在一个单体应用中,独立部署,这在企业应用中非常普遍。这个时期没有什么“服务化”的概念,也自然谈不上服务治理。

    系统的复杂度更多来自于系统内部组件间相互调用及依赖关系,很多企业都会维护一个庞大的组件库,力图通过“搭积木”的方式来构建应用系统。由于组件之间存在版本和依赖性方面的问题,所以需要进行组件治理,这是单体应用治理方面的主要需求。

    我在从事企业级应用开发的时候,做过一段时间组件治理,组件库的构建和维护比较复杂,有一套自己的方法论体系。

    微服务架构体系的深度治理

    【企业级 SOA 及其治理】

    随着企业 IT 建设的不断深入,系统越建越多,系统之间有了互联互通及整合的需求。

    为了实现系统整合,早期业界尝试过很多技术,

    一种是最简单的点对点直连模式,

    另一种是基于 RMI、COBAR、DCOM 这类中间件技术搞的星形连接模式,但效果都不太好,都没办法彻底解决标准化的问题。

    后来,IBM 联合一些大厂推出了面向服务的架构(SOA),并制定了一系列的标准。SOA 最核心的诉求就是构建一条企业服务总线(ESB)。通过 SCA 规范开发服务适配器,将不同的异构系统接入服务总线,通过 SDO 标准进行请求数据封装,服务之间通过 WebService 协议进行互相调用,通过 BPEL 流程标准对服务进行流程化的编排,创建出来的服务可以通过 UDDI 协议对外暴露,以供第三方应用或服务调用。由于涉及的软、硬件资源越来越多,“治理”的需求也就应运而生。事实上,服务治理这个概念是随着 SOA 技术的兴起被同步提出来的。

    这个时期的服务治理规范基本上被 IBM 这些传统 IT 大厂一手把持,比如 IBM 的 SOA Governance & Management Method(SGMM) 标准。我们知道 IBM 做事有一个特点,喜欢把简单的事情复杂化,它的这套 SGMM 标准全面覆盖企业 IT 的管理流程、工具及基础设施建设、甚至企业的组织架构,定义了一堆的人员角色、规范、做事流程,非常复杂。你得掏钱来让他给你做咨询才能把这套体系玩起来,整个技术栈及流程太重了,对人的要求也非常高。这严重制约了它的推广和普及,但它的一些思想还是很好的,比如重视各个环节的指标采集和度量,重视全生命周期的治理,这些都可以给我们有益的启发和参考。

    微服务架构体系的深度治理

    【互联网服务化及其治理】

    2010 年之后,伴随着互联网应用的大规模爆发,又兴起了一股由互联网企业主导的所谓“轻量化 SOA”的技术浪潮,也就是我们常说的“分布式服务化”技术。

    这一阶段,服务化的目标不仅要解决系统间的整合问题,还要解决系统的可伸缩性问题。大量互联网公司开始对自己的系统进行“服务化”改造,以期获得横向扩充的能力,应对快速增长的业务和访问量。这一时期使用的技术五花八门,有使用代理网关模式,也有采用 RPC 直连方式,技术上没有统一的标准,也涌现出了像 dubbo 这样的明星产品。

    这个时期的服务治理更多是聚焦在对服务的线上生命周期的管控及治理上,包括服务的限流、降级、容错,以及服务的弹性伸缩、灰度发布等等,线下的治理基本上不涉及。

    我们知道,2C 业务服务多、节点多,由于涉及到大量的服务节点,靠人肉的方式是肯定管不过来的,因此这一时期的服务治理很强调自动化,尤其是和自动化运维技术结合在一起。

    微服务架构体系的深度治理

    【微服务及其治理】

    互联网发展到今天已经成了一种基础资源,越来越多的业务被搬到线上,线上的竞争也越来越激烈。互联网企业为了生存,就要去竞争、去打仗。为了适应业务的快速发展,在技术迭代上一定要“”,所谓“天下武功、唯快不破”。

    “服务化”是实现“快”的一个非常重要的手段。把大量通用功能下沉为服务,并对服务不断进行拆分,再根据不同的业务形态,快速组装出前端应用,通过服务组装和聚合的方式实现更快的开发速度,前端也能变得更轻。

    把服务拆得越细,服务的粒度越小,可组装性就越好。只有这样,我们才能在业务有需求的时候,利用大量的“小服务”快速构建出一个前端业务应用,支持业务的快速试错。

    随着近几年容器技术的快速发展,服务封装及部署的成本越来越低。一方面,服务被拆的越来越小,成了“微服务”,另外一方面,随着业务的发展,平台规模越来越大。“大平台、微服务”已经成了我们这个时代的一个典型技术特征。量变导致质变,我们的开发模式、测试模式、运维模式都会受到冲击。

    这就很有意思了,业务的发展决定了我们一定会走上微服务之路,根据康威定律,我们的组织架构、管理策略、研发模式都要做出相应的调整,才能保证微服务架构的平稳落地。

    这一阶段的服务治理不再局限于线上的治理,也要同步延伸到线下领域,实现线上线下一体化及立体化的治理。面对越来越复杂的环境,我们不仅要实现治理自动化,更要实现治理智能化,大量的算法被利用于服务质量及服务关系的洞察及服务管控上,只有这样,才能应对层出不穷的新的问题。

    微服务架构体系的深度治理

    【微服务治理整体架构:三位一体的体系】

    这里直接给出微服务治理的整体架构图,微服务的治理既要进行线上的治理,也要进行线下的治理,通过线上线下两大维度进行治理指标的采集,并把它汇总到数据仓库中,进行统一的度量和分析。

    这些度量指标中,有相当一部分线上的性能及异常指标会被转化为运维事件,一旦触发我们预先设置的阈值,就会被进一步转化成“管控指令”,并通过调度中心下发,进行服务的弹性伸缩、扩容缩容操作,或者进行服务的限流、降级、容错、路由调整等管控操作。

    另外一部分度量指标,包括架构、开发、测试、运维、过程协作效率等指标会通过治理委员会(泛指,治理成员的集合)进行人为的深入分析,并制定出治理决策,这些治理决策会通过相关的管理措施进行落地。

    这样,我们就通过服务的度量、管控、管理这三大举措,构建起一个三位一体、围绕服务治理的闭环体系。

    微服务架构体系的深度治理

    从前面的介绍可以看到,微服务治理体系中,针对微服务的度量是进行微服务管理和管控的前提和基础,“只有看得到,才能管得到”,接下来,我们就来重点介绍如何构建微服务的度量及分析体系。

    微服务架构体系的深度治理

    管理学大师彼得. 德鲁克说过“如果你不能度量它,你就无法改进它”,强调的就是度量的重要性。

    微服务架构体系的深度治理

    【微服务全生命周期度量指标采集】

    度量的第一步,就是度量指标的采集。

    前面介绍了,微服务的治理囊括了线上及线下体系,同样的,服务治理度量指标的采集也要线上线下同步进行。

    在线上,

    可以通过服务注册中心获取到服务的注册信息及服务的管控指令信息,

    通过各个微服务主机节点上的主机日志、应用及服务日志、APM 监控的调用链日志,可以获取到相关的性能及异常指标信息。

    线下的指标就更多了,

    通过需求管理系统,可以采集到 UserStory 及各类需求的基本信息;

    通过项目管理系统可以采集到开发人员、开发团队、开发任务的基础信息;

    通过测试相关的管理系统可以采集到测试用例及测试 bug 的相关定义信息及过程指标信息;

    通过源码仓库及软件版本仓库可以采集到最终研发产出物的基本信息。

    软件研发是一个强调协同的群体行为,产品、开发、测试、运维需要紧密合作。为了达到更高效的配合,我们经常会采用一些协作模式,比如针对开发和测试之间的配合,会采用持续集成(CI);针对产品、开发、测试的协作,会采用敏捷协作模式;另外,我们可能还会使用一些 DevOps 的 Pipeline。不管我们采用何种协作模式,都可以从其相关的过程管理系统中抽取出相关的过程指标事件,比如一个任务什么时候完成设计、什么时候开始进入开发、什么时候完成开发…等等,这也是一大类很重要的治理度量指标。

    有了以上这些线上线下指标,就可以将它们统一汇总到数据仓库,进行进一步的深度度量和分析。

    微服务架构体系的深度治理

    我们介绍的指标已经很多了,也很全了,但是不是有了这些就足够了呢?总感觉还少了些什么…

    微服务架构体系的深度治理

    【通过代码来“理解”代码】

    不知道大家是如何使用你们的源代码及源代码仓库的?做做 codereview?或者用静态代码扫描工具扫扫代码质量?其实,我们完全可以做的更多。

    通过管理只能做到对过程的优化及规范化,但你很难通过管理去提升软件内在的架构设计质量及代码质量,因为它是和研发人员的能力及自我要求息息相关的,并且需要进行长期的训练。

    我之前在负责构建微服务治理体系的时候,发现如果要对架构的质量及研发的质量进行深度的度量及治理的话,是无论如何都绕不过源代码的,为什么这么说呢?软件研发它是一项协作性的智力行为,在研发过程中,需求人员、设计人员、研发人员需要进行紧密的协同和配合,这些人所有的思考、意图、策略最终都会体现在代码上。可以说,一个系统的代码就是一本“书”,你只要读懂了这本“书”,你就知道这个系统的前世今生。

    但问题是,你如何读懂这本“书”,相信大家都对自己负责的系统的源代码非常熟悉,但是,你们能否做到对你们整个服务集群中所有服务的源代码都非常熟悉呢?这显然不可能,要读懂这一堆的“书”,靠人力是显然不行的,我们需要借助一些自动化的手段。

    正是基于以上的思考,我们开发了一套针对源码仓库中所有工程源码进行统一扫描的工具。它的核心是 eclipse 中负责源码解析的 AST 组件(Abstract Syntax Tree,中文为抽象语法树),通过 AST,可以获取到源码工程中任何一个 Java 源码文件中所调用的外部类、继承或者实现的接口(父类)、类变量集合、类方法集合、方法逻辑块(多层嵌套)、注释等等基本信息,有了这些基本信息之后,通过对代码的逐行扫描,并基于一系列的正则及其它匹配,就可以获取到一个方法对其它方法的调用关系,最终汇总之后,就可以构建出一个跨工程、方法一级的非常庞大的调用关系矩阵,微服务之间的调用关系则是这个调用矩阵的一个子集。这个调用关系矩阵和基于动态调用链路跟踪所获取到的调用链路非常类似,我给它起了一个名字叫静态调用链路。有了这个静态调用链,实际上,我们就有了代码内的逻辑关系,在它基础上,就可以进行深度的架构关系及代码质量的梳理,这在后面的介绍中会有详细的讨论。

    微服务架构体系的深度治理

    【微服务度量及分析体系】

    有了以上所有这些度量指标,包括前面重点介绍的代码一级的静态调用链路(矩阵),就可以来看看最终针对微服务治理的度量及分析体系是个什么样子。

    从下往上看,首先通过各个指标来源渠道获取到各类度量指标,并把它们以 ODS(操作型数据)的格式汇总到数据仓库;通过数据模型抽取出主数据(MDM),这些主数据包括了服务、需求、任务、人员、团队等,在此基础上,通过不同的数据主题(Topic)构建起一个多层的“数据集市”,这些数据主题包括了异常、性能、资源、调用关系、容量、系统、测试、开发、运维协同效率等;有了这个数据集市,就可以在其基础之上进行各类数据分析,包括性能分析、容量分析、健康度分析、团队及个人的质量报告、质量趋势、动态调用链及静态调用链的深度梳理、以及各维度的汇总报表。

    根据这些分析报告,由治理委员会进行深度的分析并制定出各类的治理决策,或者通过人为或自动化的机制发出各类管控指令。

    治理决策管控指令就是微服务度量及分析体系的最终产出物。

    微服务架构体系的深度治理

    有了治理决策和管控指令,就可以对微服务的线上及线下体系进行治理,首先来看一下对线上体系如何进行治理。

    微服务架构体系的深度治理

    【服务限流】

    服务限流是微服务集群自我保护的一种常用机制,我们对线上调用比较频繁及资源占用较大的服务都加上了相应的限流举措,并构建了单机限流及集群限流两套限流措施。

    首先来看一下单机限流,它有多种限流算法可供选择,最主要的是两种,漏桶算法及令牌桶算法。

    它们之间有什么区别呢?打个比方,比如有家酒吧已经客满了,保安开始限制客流,一种举措是酒吧中出来一个客人,才放进去一个客人,这样就可以保证酒吧中的客人总数是固定的,人人都有座位,这就是漏桶算法—必须有出去的,才能有进来的;

    另外一种举措是不管有没有客人出去,保安固定每隔 5 分钟就放一个客人进去,这和春运火车站的波段式限流非常类似,可以保证客流是比较均匀的,但是这种策略也有一定的风险,如果离开的客人不够及时,酒吧中的客人总数可能会升高,导致一部分客人没有座位,这就是令牌桶算法。因此,如果要对线上并发总数进行严格限定的话,漏桶算法可能会更合适一些,这是单机限流机制。

    接下来再看看集群限流,

    集群限流的情况要更复杂一些,首先在各个微服务节点上要有一个计数器,对单位时间片内的调用进行计数,计数值会被定期的汇总到日志中心,由统计分析器进行统一汇总,算出这个时间片的总调用量,集群限流分析器会拿到这个总调用量,并和预先定义的限流阈值进行比对,计算出一个限流比例,这个限流比例会通过服务注册中心下发到各个服务节点上,服务节点基于限流比例会各自算出当前节点对应的最终限流阈值,最后利用单机限流进行流控。

    我们可以看到,这是一套环环相扣的、各环节紧密协作配合的技术体系。单纯拎出一个点来看,实现技术都不麻烦,但要构建起这么一套贯穿整个技术栈的技术体系,则需要有一套统一的技术标准,各个环节都需要遵循这套标准,对不符合标准的应用还要推动其进行改造,才能保证标准落地,有了标准之后才能推动各环节一点一点的改造构建起这套限流技术体系,所以构建服务限流能力的难点,一在于标准化,二在于体系化

    另外,限流一大原则是限流动作尽量前置,毕竟被限制的流量注定要被“抛弃”,越早处理越好,免得无谓的消耗资源。

    微服务架构体系的深度治理

    【集群容错】

    接下来再来看看集群容错,集群容错是微服务集群高可用的保障,它有很多策略可供选择,包括:

    • 快速失败(Failfast)
    • 失败转移(Failover)
    • 失败重试(Failback)
    • 聚合调用(Forking)
    • 广播调用(Broadcast)

    不管用哪种集群容错策略,一定要注意重试的次数,尤其是线上负载已经很高的时候,这时候如果重试次数太多,一方面,会推高服务被调用方的负载及并发,另外一方面,会导致服务调用方的调用延时增长,双重因素叠加之下,最终极可能导致“服务雪崩”,导致集群被“击穿”。

    所以,在使用集群容错的时候,一定要设置最大重试次数

    微服务架构体系的深度治理

    【服务降级】

    服务降级和服务限流类似,也是微服务集群自我保护的机制,一般在线上动用服务降级手段的时候,都是线上比较危急的时候,生死存亡了,这时候留给你思考和反应的时间已经不多,所以在使用服务降级之前一定要做好预案,你要提前梳理出核心业务链路和非核心业务链路,然后通过降级开关一键把部分或所有非核心链路降级,这样才能救命。

    服务降级也有很多手段可以使用,包括:

    • 容错降级
    • 静态返回值降级
    • Mock 降级
    • 备用服务降级

    我们常说的熔断,本质上也是容错降级策略的一种,只不过它比一般容错降级提供了更为丰富的容错托底策略,支持半开降级及全开降级模式。构建服务降级能力也和限流机制类似,同样需要坚持标准化和体系化。

    微服务架构体系的深度治理

    【故障定界定位】

    线上的故障定界定位应该是我们每天做的最多的事情。分布式环境下的故障定界定位,最有效的工具就是动态调用链路跟踪,这应该是没有疑义的,不管你是使用开源的 Zipkin,SkyWalking、PinPoint、CAT,还是使用商用的听云、AppDynamic 或 NewRelic 等等。

    调用链本质上也是基于日志,只不过它比常规的日志更重视日志之间的关系。在一个请求刚发起的时候,调用链会赋予它一个跟踪号(traceID),这个跟踪号会随着请求穿越不同的网络节点,并随着日志落盘,日志被收集后,可以根据 traceID 来对日志做聚合,找到所有的关联日志,并按顺序排序,就能构建出这个请求跨网络的调用链,它能详细描述请求的整个生命周期的状况。

    动态调用链要用的好一定是需要和监控大盘相结合。介绍一下我们的使用经验,我们在很早之前就构建了动态调用链跟踪体系,在我们的监控大盘上有很多的点可以进入调用链:

    1、我们有一个单位时间段内异常最多服务的 TopN 排序列表,点击列表上的任何一个服务,会打开这个服务这个时间段内所有异常的列表,再点击列表上的每一个异常,就会打开这个异常所属调用链,进行故障分析。

    2、可以利用监控大盘,监控大盘上有很多“毛刺”,这些都是系统的一些异常点,点击任何一个“毛刺”,会将“毛刺”所在时间段内的请求以“散点”的形式列出(可能会基于请求数量做抽样),“散点”的颜色代表了不同的状态,有的成功,有的失败。点击任何一个“散点”,就可以进入这个请求对应的调用链。

    3、针对核心服务的异常有专门的一个监控表格,会列出最近发生的核心链路服务上的异常,点击这上面的任何一个异常,也可以进入对应的调用链。

    以上就是基于动态调用链进行线上故障定界定位的常用模式。

    微服务架构体系的深度治理

    【容量规划】

    线上的流量今天涨一点,明天涨一点,如果麻痹大意的话,说不定哪天服务就被冲垮了,所以要对线上的流量时时进行规划,以做到心里有数。

    容量规划有两种形式,一种是容量预估,另一种是性能压测

    系统或者服务上线之前,首先要进行容量的预估,一般做法是基于经验,同时结合对业务的前景预期,先估算出一个总的调用量,比如 1 亿的 PV,可能会有 10% 的流量落在购物车服务上,购物车服务就是 1000 万的 PV,一次购物车访问会产生 2 次数据库调用,那么它的关联数据库就会有 2000 万的一个调用量,这样,基于图上从左至右,层层分解之后,就可以获取到每个服务节点上摊到的访问量,再结合运维部门的单机容量指标,就可以估算出整个集群需要多少的软硬件资源。

    系统或者服务一旦上线之后,它的性能就开始处于不断“劣化”的状态,上线前预估的指标会越来越不准,这时候就需要通过线上性能压测来对实时容量进行监控。做线上性能压测也要遵循一定的规律,不是说一上来就做全链路压测。同样是基于上图中的调用关系,线上性能压测首先需要在调用链的末梢,也就是对数据库或者缓存先进行压测,以保证它们不是瓶颈,再对调用数据库或者缓存的上一级节点进行压测,再一级一级往上压测,最终覆盖整个链路,实现全链路压测。

    可见,全链路压测的前提是单点压测,需要先把单点压测能力做好,才能做全链路压测。

    在压测的时候,由于流量是模拟的,数据也是“伪造”的,所以一定要做好隔离,各种各样的隔离,尤其是数据的隔离,我个人不建议将“染色”的压测数据和真实的线上业务数据共表存储,最好将“染色”数据单独表进行存储,并通过分表策略进行区隔。

    以上就是性能规划,包含了容量预估与性能压测两大能力。

    微服务架构体系的深度治理

    【微服务关联资源的治理】

    对于线上任何资源,如果只有服务对它进行调用,那么完全可以基于服务对资源的调用日志来分析资源的使用状况、性能状况。

    比如,对于数据库,可以汇总对某个数据库访问的所有服务的调用日志,多维统计之后,就能知道数据库整体被调用状况,及数据库中表的调用的分布状况,每个表的被调用状况,包括被写入了多少数据、被删除了多少数据、被修改了多少数据,每次查询的调用延时统一汇总之后,推算出每个表的查询操作的整体表现及相关的慢查询等等。

    对分布式缓存,也可以汇总所有的读、写操作,并计算出读写比例,也可以基于每次的调用结果(是否为 null、是否异常)汇总出命中率,正常的缓存表现应该是读多写少,如果推算出的读写比例是读少写多,或者命中率偏低,说明缓存的使用策略有问题,需要进行改进。

    对消息队列也类似,可以通过调用日志,计算出单位时间内写入的消息量,以及被消费的消息量,据此推算出消息队列当前的堆积情况。

    通过调用日志获取的资源的使用及性能状况,比通过资源自身的监控所获取到的相关指标会更客观一些,毕竟它代表了应用 / 服务的真实感受。比如对于数据库的访问,请求需要先通过服务的数据库连接池,再穿越网络,最后才到达数据库,这中间任何一个环节出现问题,都会影响到最终的调用效果。

    除此之外,还可以通过服务的调用日志对资源的使用状况进行优化。对线上运维而言,比较头疼的问题是资源分出去之后就收不回来了,因为你也不知道资源是否还在使用,如果结合服务侧的调用日志监控来做资源使用判定的话,则能有效的解决这个问题,比如说,如果通过调用日志发现对某个 namespace 下的缓存已经没有调用了,那完全可以考虑将这个 namespace 的缓存资源释放掉。

    微服务架构体系的深度治理

    【微服务线上生命周期管理】

    我们目前针对微服务的线上生命周期管控的能力是基于蚂蚁金融云的能力来构建的,蚂蚁金融业在它的云上弹性计算资源的基础上,通过整合资源编排及资源调度的能力,构建了微服务的综合管控平台,通过这个平台,可以比较方便的进行服务的上线、下线、扩容、缩容等操作。

    微服务架构体系的深度治理

    以上就是针对微服务线上体系的治理,实际上,这些能力都是微服务的通用能力,很多微服务框架都具备,我这里只是重点介绍了我们的使用经验及心得。接下来我们来讨论一些更加硬核一点的内容,来看看微服务的线下体系的治理。

    微服务架构体系的深度治理

    【微服务整体架构治理】

    首先看一下针对微服务的整体架构的治理。

    先看第一个图,这个图是线上微服务集群服务间的调用关系总图,这个图可以通过动态调用链的汇总来获取,目前大部分公司都是这么干的;除此之外,还可以基于我前面介绍的静态调用链(调用矩阵)来获得,这个图只是静态调用矩阵的一个子集,通过静态调用链获取到的这个图中的调用关系会比动态调用链更多,有了这个微服务间的整体调用关系之后,我们就可以对微服务的调用质量进行深入的分析。

    服务是分层的,好的服务调用关系一定也是分层的,层层往下推进,最终形成一个有向无环图(DAG)。因此,可以对调用关系图进行闭环检测,如果检测到如图上 G 点到 B 点这样的回环调用的话,说明调用关系是有问题的,需要进行优化,这种回环调用也许现在无感,但难保未来哪天就会由于一条旁路逻辑导致死循环。

    还可以对整个调用网络进行遍历计算,找出所有调用深度最深的调用链,如图上红色标注出来的调用链,我们知道,对跨网络的调用访问,涉及到的网络节点越多,它的稳定性越差,可以将所有调用链路最深的这些链路找出来,并按调用深度进行 topN 排序,重点对排在头部的这些调用链分析它的必要性及合理性,看是否可以对调用深度进行缩减和优化。

    还可以找出整个网络中被调用最多的这些服务节点,比如图上的 F 节点,从调用关系上来说,它是被依赖最多的节点,自然是最重要的节点,作为枢纽节点,在运维等级上需要重点保障。当然,实际应用中,我们还会加上调用量这个权重来综合判定服务节点的重要性。

    随着架构的不断演讲,可能有些服务节点再不会有调用关系了,比如图上绿色的 L 节点,这些节点再不会去调用别的服务节点,别的服务节点也不会来调用它。这类被找出来的“孤零零”的节点,可以考虑对它进行下线处理,以释放资源。

    以上所有的度量和治理都是在这个调用关系图的基础上进行的,所用的算法也是图计算(图论)中的常用算法,包括 BFS、DFS、PageRank 等等,大家如果嫌麻烦,可以找个图数据库,比如 neo4j,这些算法已经集成在它的基本查询能力中。

    微服务架构体系的深度治理

    【单个微服务架构治理】

    微服务之所以被称为“微”,一方面是它承载的业务比较单一,另外一方面,它在架构上也要尽量的做到自洽和内敛,也就是说,它的设计要尽量的遵循“迪米特法则”,要尽量少的和外部的系统或者服务发生交互

    可以通过调用链对微服务的对外调用关系进行梳理和分析,如果对外调用关系过多,比如说,如 (页面中) 上图所示,它如果调用了 3 个外部的系统或者服务,可能是正常的,但如果它对外调用了 30 个服务,那就要好好分析一下它承载的业务是否太多,是否不够纯粹,是否需要对它进行拆分,拆成多个服务。

    另外,既然同时具有动态调用链和静态调用链,完全可以将这两种调用链进行叠加,如 (页面中) 下图所示,红色部分是被动态调用链覆盖到的逻辑,非红色部分则是没有被触发的代码调用逻辑,这部分未触发逻辑中,有一部分是异常处理逻辑和旁路逻辑,可能是正常的,另外一部分则可能是版本兼容代码。比如说,线上 APP 有很多的版本,某个版本一旦下线,后台服务中针对此版本的兼容代码就成了冗余代码,需要进行清理。通过动态调用链和静态调用链的叠加,就可以相对方便的定期找出冗余代码进行清理,这样可以保证微服务的体量不会膨胀。

    微服务架构体系的深度治理

    【微服务开发质量度量及治理】

    针对代码质量的管理,常规的做法除了代码的 codereview 外,一般还会使用 Checkstyle,FindBugs,Jtest 这类静态代码扫描工具来做代码的缺陷扫描。其实我们还可以做的更深入和更广一些,基于前面介绍的自定义代码扫描的技术,结合代码的调用关系,我们完全可以做到对跨类和跨方法的调用缺陷进行扫描,比如跨方法的多层循环嵌套,这类缺陷通过常规的代码扫描工具是扫不出来的,

    除了代码质量之外,还可以结合线上 bug 的种类和数量,来综合评估开发人员的开发质量,因为,代码是人写的,bug 也是人制造出来的,通过结合开发人员开发的代码的质量,及他的产出物产生的异常等级(类型及数量),就可以对开发人员的开发质量进行综合的度量。当然,实际中还会结合其它的指标,但这两个是最主要的指标之一。通过这两个核心指标,可以生成研发人员开发质量综合评估报告。

    进一步汇总个人的质量综合评估报告,可以获得针对团队的开发质量综合评估报告,这两个报告本质上就是个人及团队的研发质量“画像”,完全可以作为个人及团队 KPI 考核的重要参考。在此基础之上,还可以通过这两个报告的变化趋势(时间纵比),来不断促使开发人员和开发团队不断进行开发质量的改进和开发技能的提升。

    微服务架构体系的深度治理

    【微服务架构下的测试治理】

    微服务架构下的测试治理的两大核心诉求,一个是提高测试的覆盖度,具体说就是提高需求覆盖度、代码覆盖度、页面覆盖度;另外一个则是降低测试用例的维护成本

    先讨论测试覆盖度。

    首先看一下需求覆盖度,可以通过服务这个维度来对需求及测试用例进行关联,找出每个需求下所对应的单元测试用例、自动化测试用例、手工测试用例,在此基础上,可以把多个开发迭代周期的这些指标进行时间维度的纵比,以得出需求覆盖度的变化趋势。

    代码覆盖度有很多的工具帮我们来做,比如 contest 或者 JaCoCo 这类的工具,这里不再赘述。

    页面覆盖度,可以将每次集成测试中调用的页面以日志的形式记录下来,再通过日志的聚合分析,结合工程源码的扫描,两厢一比较,就可以统计出哪些页面是没有被覆盖到的。

    测试用例的维护成本分两块,一块是新增用例的维护成本,这个比较好度量;比较麻烦的是存量测试用例的变更度度量,我们采用相似度匹配算法,先算出存量测试用例前后两个版本代码的相似度,再换算成变更度。

    通过对测试的这两大类指标的不断度量和治理,可以实现测试工作的整体“降本增效”。

    微服务架构体系的深度治理

    【调测能力构建】

    在服务化的过程中,研发最大的痛点,一定是调试。原来单体应用中的服务被拆分到不同团队,并部署在不同的服务器上,而本地只有一个服务接口。这时候要做调试,要么做 P2P 直连,这需要搭建不同开发版本的集群,成本较高。要么做 MOCK,采用传统的 MOCk 手段,要写一堆的 MOCK 语句,比如你用 mockito,你要写一堆的 when……thenReturn…. 的语句,耦合度非常的高。

    我们利用分布式服务框架提供的过滤器机制,开发了一个 Mock 过滤器,通过 Mock 数据文件来详细定义要被 mock 的服务的名称、入参及出参。这样,当请求过来的时候,将服务名及入参和 mock 数据中的定义进行比对,结果吻合,就直接将 mock 数据文件中的出参反序列化后作为服务的调用结果直接返回,同时远程调用的所有后续操作被终止。这样,通过 mock 数据模拟了一个真实的远程服务。通过这种方式来构建服务的 mock 能力,我们就不需要写一堆的 mock 代码了,而且整个过程对业务逻辑来说毫无感知,完全把 mock 能力下沉到底层的服务框架。

    另外,为了有效降低制作 mock 文件的成本,我们还基于服务框架的过滤器机制开发了“在线数据抓取过滤器”,它可以将指定的服务请求的入参和返回结果都抓取下来,直接写成 mock 数据文件。通过抓取方式获得的 mock 数据文件,往往有更好的数据质量,毕竟反映的是更加真实的业务场景。不过,这里还有一个合规性的问题,对线上数据的抓取是种敏感行为,大部分公司这么干都会很谨慎,一般都要做好数据脱敏的处理工作。对于我们,目前只在测试环境中进行数据抓取操作。

    通过以上的策略,可以有效改善服务化架构下团队的开发效率,而且团队规模越大,效果越明显。

    微服务架构体系的深度治理

    【微服务架构下团队协同】

    微服务架构下,服务被分散到不同的团队,经常一个业务会涉及多个团队之间的协同配合,如何让团队内部、团队之间的协作更高效?

    我在前面说了,根据康威定律,组织协作的模式必须是和架构相匹配的,这方面我们也做了不同的尝试,从综合效果来说,敏捷模式会更适合微服务架构下团队之间的协同。我们目前采用两周一迭代、固定发版的模式,同时每个迭代之内,采用“火车发布模式”,实行班车制,准点发车,这样的话,其它协作部门在很早之前就能大概知道我们的一个发布计划,产品方面也大概知道要把需求放入哪个迭代之中。这样,能够有效减轻部门间的沟通成本。在每期工作量评估的时候,我们一般会预留一些工作量 buffer,以应对一些临时性需求,这类需求不受版本约束,按需发布。如果这个迭代周期内没有这类紧急需求的话,我们会从 backlog 中捞一些架构优化的需求来填补这些 buffer。

    由于迭代周期很短,所以需要严控每个迭代的风险和不可控的因素,对每个迭代而言,最不可控的就是 UI 设计。UI 的设计过程中,感性的因素会更多一些,可能会反复修改多次,不像程序代码那么明确。所以,我们一般不将 UI 设计纳入迭代之中,而是将其作为需求的一部分,在每个迭代开始之前的工作量评估中,要求必须提供完整的 UI 物料,否则不予评估工作量,此需求也不会被纳入迭代之中。

    微服务架构体系的深度治理

    【微服务架构下团队协同质量度量及治理】

    团队的协同效率同样需要进行度量和治理。以我们所使用的敏捷迭代协作为例,我们采用数据驱动的精益看板方法,持续采集每个迭代中各个阶段的过程指标事件,比如任务什么时候完成设计、什么时候进入开发、什么时候开发结束、什么时候进入测试…等等,这些过程指标被汇总后,会在其基础上制作出精益看板中的几大典型报表:

    • 韦伯分布图
    • 累积流图
    • 价值流图
    • 控制图

    通过这几个报表,就可以对需求流动的效率进行持续的评估,看研发管道是否有堆积?是否有阻塞?并进行实时的干预和治理,注意,这里评估的是协同的效率,而不是研发资源的利用率,对研发资源的利用率,我们有另外的度量指标和报表。

    通过每个迭代持续的进行精益看板的数据分析和度量,并通过治理策略进行不断的改进优化,就可以让我们的研发协同越来越顺畅。

    这里再次强调,以上所有指标采集和多维分析和度量,直至最终分析报表的生成要最大可能做成自动化的方式,一键生成,否则,靠“人肉”的方式是无法完成如此繁琐的采集及制作任务、也无法保证时效性。这也是我在前面所强调的自动化智能化的治理。

     

    以上就是本次分享的主要内容,介绍了服务治理发展的 4 个阶段的治理需求及特点,给出了微服务治理的整体架构;重点介绍了微服务度量及分析体系的构建,这是微服务管控及管理的前提和基础;最后,分别针对微服务的线上及线下体系的治理做了深入的讨论。

    展开全文
  • 煤层气井多煤层合采效果研究为煤炭安全、井下瓦斯治理、确定开发技术指标、单井配产、合理划分开发层系、煤层气高效开发以及制定中长期煤层气开发规划具有很好的参考价值。以晋城成庄矿区为例,将开发中后期排采效果...
  • 文章以某煤矿采矿的地质条件作为研究背景,对采空区的地基稳定性进行分析,并且基于有限元理论建立起基本的数据学模型,选取合理的数学参数,然后利用ANSYS分析软件对采空区的地基稳定性进行深入的分析研究。...
  • 为检验公司治理对外部审计结果的预测能力,使用神经网络中的多层感知器方法,以2000~2007年所有A股上市公司为样本进行研究.结果发现,公司治理指标对外部审计结果有预测能力,而且在公司治理对外部审计的预测能力...
  • 通过介绍某危房治理的工程实例, 对复杂地质条件下住宅楼进行顶升纠偏作了一定的探索, 并就在施工过程中碰到的难点问题提出了解决办法.
  • 目录 架构原则 【什么是架构】 【架构的思考维度】 【架构的原则】 ...【稳态IT架构范式:企业服务化架构(SOA)】 ...【敏态IT架构范式:互联网(微...本文共三大部分,包括架构原则、架构范式、架构治理,分别介绍架构

    目录

    架构原则

    【什么是架构】

    【架构的思考维度】

    【架构的原则】

    架构范式

    【企业业务概览】

    【稳态IT架构范式:企业服务化架构(SOA)】

    【敏态IT架构范式:互联网(微)服务化架构】

    【数据架构】

    架构治理

    【企业服务化架构(SOA)治理】

    【微服务化架构治理】

    【数据治理架构】

    结语


    本文根据InfoQ极客大学架构开放日专场的分享整理而成,原标题《架构师的道、法、术》,但笔者更喜欢现在的标题,更直接明了。

    本文共三大部分,包括架构原则、架构范式、架构治理,分别介绍架构的概念和方法论、典型业务场景下的架构范式、不同架构的治理特点这3个方面的内容。如图1所示:

                                                           图1


    架构原则


    【什么是架构】

    架构这个词最早来源于建筑,所谓的建筑架构描述的是一幢建筑的结构,包括各个部件,以及这些部件如何有机地组成一幢完美的建筑。建筑架构设计是针对建筑结构的设计过程。

                                                           图2

    如图2所示,左上角是一栋只包含一间房子的房屋,这栋房屋的结构很简单,除了一个框架、四面墙,一个屋顶之外,就是一些简单的门、窗构件。构建这么一栋简单房屋不需要什么复杂的设计,甚至可能连图纸都不需要,一个熟练的建筑师傅凭经验就能很快完成。

    但如果要构建一套如图1右边所示的包含多个房间、多个楼层、功能完备的复杂楼房的话,单靠建筑师傅的经验就远远不够了。这时候,我们只能老老实实的把每层的结构落实到平面设计图纸上,涉及的每个建筑构件的尺寸、规格、各个构件之间的组装关系等都要标注清楚。这样,建筑师傅才能根据设计图纸的指导顺利进行构建工作。

    所以,设计工作对于简单建筑结构并非必须,而对于复杂建筑结构则是不可或缺的。可见,建筑架构最主要的目的是解决建筑结构复杂度所带来的挑战。建筑结构越复杂,架构设计的工作越重要。

    将架构的概念引用到软件设计领域,可以得到软件系统架构的如下定义:

    软件架构是在特定的业务和技术体系中,用特定语言来描述一个软件系统的结构,包括各个部件以及这些部件的关系的设计行为。软件架构活动的核心目的是解决软件系统复杂度所带来的挑战。

    【架构的思考维度】

    软件架构如何做?架构的切入点和思考维度是什么?

    既然架构最主要目的是对抗复杂度,那么讨论这个问题也要从软件系统的复杂度入手。软件系统的复杂度主要来源于两个维度,空间复杂度时间复杂度,如图3所示。

                                                           图3

    • 空间结构复杂度

    软件的空间复杂度主要来源于软件系统的结构复杂度。随着全社会信息化程度的不断提高,软件系统规模越来越大,涉及到的人、事、物越来越多,业务逻辑也越来越复杂。所以,在架构设计之前,首先要全面了解软件系统所服务的业务及它所处的背景环境。

    洞察

    就像我们要买一辆电动车,除了了解电动车自身的功能和性能外,还要了解住家附近是否有合适的停车场和充电桩这些环境信息,综合各方面的信息才能作出最优的决策。对软件系统的洞察也类似,不仅要了解业务所涉及的人员、角色、组织、逻辑和目的,还要了解该业务在整个企业业务体系中的位置,以及该业务和其它企业业务的关系。除此之外,还要了解软件系统的技术背景,例如当前企业已经构建的技术体系,包括运维技术体系、中间件技术体系等等,毕竟软件系统最终是要在这个技术体系中构建和运维的。通过“内”和“外”这两个维度对软件系统有了充分了解,做到深刻洞察后,才能进行后续的架构设计工作。

    架构拆分

    解决一个复杂结构的事物最有效的手段就是拆分,软件架构也是如此。以构建一个电商交易的卖场系统为例,可以把这个卖场系统拆分成几个一级子系统,包括百货卖场子系统、母婴卖场子系统、图书卖场子系统等等。每个卖场子系统可以进一步拆分成首页、商品列表页、商品详情页等二级子系统。此外,可以将购物车、订单管理等功能拆分出来独立部署,为子系统提供统一的服务。子系统和服务还能进一步拆分成更细化的模块,比如商品详情页子系统可以拆分成商品信息模块、价格模块、促销模块等;每个模块可以根据所使用的软件框架,比如一些MVC框架等,进一步拆分成组件,比如控制组件、逻辑组件、数据访问(DAO)组件等。

    架构分层

    通过如上的层层架构拆分,就可将一个复杂结构的软件系统拆分成一堆模块或组件,这就是软件系统的原子构件。但是,如果拆分出来的这些原子构件相互耦合在一起,关系混淆不清,不仅不能降低复杂度,反而会升高复杂度,为后续的开发带来麻烦。因此,架构拆分也需要遵循一定的规范,通常是按照架构分层来进行。前面所讨论的一级子系统,二级子系统,服务等概念,本质上就是架构分层。只有在架构分层框架下,有序的进行架构拆分,才能够有效的降低系统的空间结构复杂度。

    • 时间演变复杂度

    软件架构在时间维度上也同样存在一系列的复杂度挑战。主要源于业务不断演变所带来的可扩展性和可维护性的要求。业务不断迭代和进化,导致软件系统需要不断的添加或修改功能,必然要求软件架构具有一定的可扩展性,能够灵活、可靠、低成本地支持系统开发。软件系统要长期在线上运行,需要稳定可靠的进行迭代发布、容量管控、限流降级等运维操作,在架构上也必须具有可维护性。另外,大家通常会忽视软件系统的可观察性。“只有看得到,才能管得到”,软件系统的可观察性是保证系统可靠运行的重要因素,因此必须将业务、性能、异常指标的监控度量等能力纳入架构设计中。

    不管是在应对空间结构复杂度的架构拆分和架构分层上,还是应对时间演变复杂度的可扩展性、可维护性、可观察性的设计上, 都要综合考虑功能、性能、安全及成本这四大因素。任何一个系统的设计都有一定的成本约束,人力资源是有限的,资金投入也是有限的,上线时间压力也是存在的,我们不能无限制的投入资源去设计一个十全十美的软件系统。因此在架构设计上要把握一个度,要在功能够用、性能达标、安全可靠成本可控之间达成妥协。

    综上所述,软件架构需要在空间结构复杂度和时间演变复杂度这两个维度上,综合考虑功能、性能、安全、成本这四个因素,平衡各方诉求进行体系化的设计

    以上,就是做软件架构的通用思考维度。

    【架构的原则】

    讨论架构的原则是一个仁者见仁、智者见智的话题。“一千个读者就有一千个哈姆雷特”,每个程序员眼中都有自己独特的架构原则,我在这里只谈谈个人的架构原则。

    我将自己多年的架构经验总结为三大原则:中庸、简单、变通,如图4所示。

                                                           图4

    • 中庸

    中庸是中国古代的一本道德哲学专著,书里面提到了一种针对事物的认识方法和学习过程:

    博学之,审问之,慎思之,明辨之,笃行之

    这5个词既是我个人做架构的指导原则和方法论,更是我时时警醒自己的一种架构态度。

    与讨论架构的思考维度时所提的“洞察”一样,这句话要求我们在对一个软件系统进行架构设计时,要用辩证的眼光看待它,从“内”、“外”两个角度全方位考察系统所服务的业务、背景和体系。在深刻洞察和全面了解的基础上,综合功能、性能、安全、成本这四个因素设计出合适的架构。要始终坚持从业务出发,基于业务实际和企业客观环境来进行架构设计;开源和自研、新技术和成熟技术、自运维和云服务等技术选型工作要拿捏得当,做到不偏、不倚、不过,这就是所谓的中庸之道。

    • 简单

    中国有句成语“化繁为简”, 意为“越是复杂的事情越是可以用简单的方法去化解,往往会得到意想不到的效果”。架构领域中,简单对抗的是空间结构复杂度,它也是架构拆分的终极目标。

    将一个复杂软件系统通过架构拆分层层分解为最小的原子构件,拆分结果应该是非常简单的。但怎么判断拆分的结果是否符合简单原则呢?一方面,原子构件的种类要尽可能少;另一方面,构件之间的关系也要尽可能少,即使有关系,也最好只是少数几种弱耦合关系。如果拆分出来的是一大堆强耦合在一起、关系混淆不清的构件,无法分层,无法组织,自然谈不上简单。拆分得当、结构简单,关系简单的构件有很多好处:

    1. 越简单的构件可扩展性越好。可以在其基础上扩展出不同的功能,更灵活也更通用。

    2. 越简单的构件越容易做到高性能。复杂构件受到制约因素太多,想实现高性能非常困难;越简单的构件调用路径越短,关系越单一,越可能实现高性能。

    3. 越简单的系统可维护性越好。复杂系统容易失控,架构治理的挑战大,生命周期短,这些都意味着长期运维成本的上升,所以保持简单可以在长期成本投入方面保持优势。

    • 变通

    变通这个词出自《易经》:易,穷则变,变则通,通则久

    只有变通,才能长久。软件领域流行一句话“这个世界没有银弹”,没有任何一种架构能包打天下,放之四海而皆准。 业务在空间和时间维度上都是在不断变化的,架构也要顺势而为、随需应变。 所谓“架构如流水,无常态”,只有这样,才能时刻匹配业务的需求,保持生命力。

    所以不能用固定眼光来看待架构,没有最好的架构,只有最适合的架构。这个“最适合”,也是放在特定的空间(特定的业务体系和技术体系)和时间语境来看待的。同一个系统,随着时间的推进,业务的演化,架构也要随之自我调整和升级。

    以上就是我个人的三大架构原则,分享给大家。


    架构范式


    前面讨论的都是架构的方法论层面的内容。虽说架构如流水,无常态,但毕竟软件行业发展几十年,还是积累下来一些非常经典、获得普遍认可的架构范式。在这部分,将结合业务场景针对这些经典架构范式进行讨论。只要善于利用这些架构范式,就能有效避免造轮子和走错路,极大提高架构设计的效率和可靠性。

    【企业业务概览】

    应用系统归根结底是为企业业务服务的,讨论软件系统架构,无论如何避不开企业的业务体系。

    • 企业业务体系

    企业的业务体系是什么样子? 笔者做了个总结,大概可以把企业的业务划分为企业运营、生产制造、市场运营、客户触达四大领域,如图5所示。

                                                           图5

    企业运营业务是维持企业正常运作的基础,支撑它的业务系统包括了企业的组织管理、流程管理、人事管理、日常办公等,一般由内部IT团队负责。企业的组织架构和运作流程相对稳定,调整周期通常以“年”为单位,很少看到一个企业三天两头调整组织和流程,因此相对应的系统也强调稳定,一般不追求快速迭代及变更。

    更上一层业务是生产制造,这是企业的核心业务,是企业利润的来源。生产制造的生产线大多都是采购的,相关生产管理及控制系统包含了企业的产品生命周期管理、物料管理、生产计划排班管理、上下游供应链管理等。这些系统主要也都是采购的商业系统,相互之间要花大力气进行集成和打通,一旦出现故障导致生产线停顿,就意味着损失,因此也以稳定为主。但随着市场变化越来越快,精益制造和柔性制造理念也在不断普及,在“稳”的同时,“快”的诉求也在增长。为了支持个性化、小批量订单的生产诉求,企业需要更频繁地对生产线及生产制造系统进行调整。

    生产出来的产品要到市场里售卖,就涉及市场运营业务,包括客户、竞品、市场、渠道等。市场瞬息万变、机会稍纵即逝,因此这层业务应具备较高的敏捷性,能随时感应市场变化,有效进行资源的调配和重组等特点。这就意味着支持这一层业务运作的系统也必须具有较高的灵活性,能根据市场需求随时进行新功能的开发和部署,才能满足一线销售的需要。

    商品最终要卖给终端消费者,企业要不断吸引和留住顾客,就需要直接触达顾客,这就是终端消费业务。我们处在一个“喜新厌旧、追求热点”的时代,客户群体的口味时刻在变,热点层出不穷,但绝大部分热点只能保持3天热度。笔者目前负责的业务就包含终端业务,热点营销活动从规划到上线基本以周为单位来计算,这就要求这一层的支撑系统具有极高的敏捷形态,能够快速开发和部署,以支持业务的快速试错,同时能够应对流量的大幅波动。

    • 双模IT

    纵观企业业务体系,最底层的企业运营业务的迭代周期以年为单位,稳定为主,支撑这类业务的IT技术更适合传统IT技术和架构,追求稳定,是一种“稳态IT”模式。越往顶层的业务,迭代周期越短,追求的是一种敏捷性,更适合微服务这一类“短、平、快”的IT技术和架构,可以称之为“敏态IT”模式。

    可见企业IT架构中存在两种IT形态:

    • 稳态IT架构模式

    • 敏态IT架构模式

    架构师在做架构的时候,需要根据业务所处的体系和特点,选择适合的IT架构模式。

    【稳态IT架构范式:企业服务化架构(SOA)】

    稳态IT架构模式主要应对企业内部业务,为企业运营和生产制造这两层业务服务。

    企业内部业务和2C的个人业务最大的区别在于企业业务中存在大量的业务协同规章制度,涉及的部门、人员比较多,条条框框的规矩也比较多。做过企业级系统开发的同学应该都知道,将业务协同和规章制度落实到系统层面最有效的手段就是工作流。在企业内部IT技术体系中,工作流是一个基础服务(组件)。很多系统架构设计,都要将流程能力纳入到考虑中。针对特定企业业务构建的应用系统,随着业务不断重组,不同的业务发生交集,系统之间需要随之整合。为了实现系统整合,业界推出过很多架构方案,包括点对点连接架构基于中间件的星型连接架构等,大浪淘沙之后,最终是面向服务化的架构(SOA)由于彻底解决了“标准化”这个整合的核心难题而得以胜出。

                                                           图6

    如图6所示,SOA 最核心的诉求就是构建一条企业服务总线(ESB),通过服务总线实现跨业务系统的工作流整合和业务数据整合。ESB包含了大量协议和规范,它通过 SCA 规范开发服务适配器,将不同的异构系统接入服务总线,通过 SDO 标准进行请求数据封装,服务之间通过 WebService 协议进行互相调用,通过 BPEL 流程标准对服务进行流程化的编排,创建出来的服务可通过 UDDI 协议对外暴露,供第三方应用或服务调用。

    为了解决数据和流程散落在各个业务中的问题,企业还会构建统一的企业门户,收集各个业务系统的信息及流程代办项,为企业员工提供统一的工作入口和个人工作台。各业务系统只要遵循诸如JSR168这类的Portal规范,开发相应的Portlet,就可以把相关业务功能入口以可视化的方式整合到企业门户中。

    【敏态IT架构范式:互联网(微)服务化架构】

    敏态IT架构范式主要是指互联网(微)服务化架构。微服务架构脱胎于企业服务化架构,但与企业服务化架构又有很大的不同,它相对更轻量,没有很重的协议和规范。

    微服务化架构主要面向互联网应用领域,主要应对市场营销和终端消费这两块面向个人的业务功能。个人业务具有需求迭代快、流量波动大、并发高、性能及可靠性要求高等特点,所以需要架构具有很高的可扩展性和可维护性。同时架构还需要足够敏捷,能够快速开发迭代,也能快速进行弹性伸缩。

                                                           图7

    如图7所示,微服务架构在各个环节基本都会采用集群的方式,这样不仅可以通过往集群中增加和减少机器来实现快速的弹性伸缩,以应对线上访问流量的波动,还能够实现高可用,不会因为一个节点的宕机导致整个集群不可用。

    为了实现快速迭代,微服务集群中的服务会被拆的很细,服务分层也比较多,只有这样,才能将服务的粒度控制在一个足够小的程度,才能称之为“微”。 服务的粒度越小,可组装性就越好,更方便在业务有需求的时候,通过服务组装或聚合的方式,利用大量的“小服务”快速构建出前端业务应用,支持业务的快速试错。

    随着近几年容器技术的快速发展,服务封装及部署的成本越来越低。一方面,服务被拆的越来越小,成了“微服务”,另外一方面,随着业务的发展,平台规模越来越大。“大平台、微服务”已经成了敏态IT架构的典型技术特征。量变导致质变,虽然都是服务化架构,但微服务架构的开发模式、测试模式、运维模式都与SOA架构存在较大差异,它对自动化的要求更高,这在后面的架构治理部分,会进一步探讨。

    此外,微服务架构一般都会采用统一的分布式服务框架,通过降低对异构技术及协议的支持力度,达到降低系统架构、开发、运维的难度的目的。

    【数据架构】

    以上讨论的都是应用服务的架构,这里重点讨论针对数据的架构。

    数据架构主要面向两大领域,分别是联机事务处理(OLTP)领域和联机分析处理(OLAP)领域,如图8所示。

                                                           图8

    • OLTP数据建模

    联机事务处理(OLTP)领域的数据架构主要针对单个业务系统的数据架构,架构师基于业务模型进行领域建模后,再基于抽象出来的业务实体进行有针对性的数据建模,相应的产物包括针对结构化数据的E-R关系建模、NoSQL表格建模、NoSQL KV建模以及针对非结构化数据的文档建模等。根据数据模型可以构建最终的物理模型,包括表、视图、KV、主外键关系等;为了提高数据访问性能,需要进行索引或读写分离策略的设计;如果数据量很大,还要进行分库分表等数据分片策略设计。此外,为了防止数据不断增长导致超出线上存储容量,还要考虑历史数据或者冷数据的备份策略设计。

    • OLAP数据建模

    和OLTP针对单个系统所做的设计不同,OLAP的数据架构设计视角一开始就要聚焦于企业的全业务体系。理想情况下,一个企业只能有一个OLAP系统(一套统一数仓),一个OLAP系统只能有一套数据模型。所以, OLAP系统数据架构要囊括各个业务系统的核心数据模型,这也决定了OLAP的数据架构难度要远高于OLTP的数据架构。

    在OLAP的元数据定义中,会针对不同的业务域定义不同的数据域。每个数据域根据实际业务诉求包含多个数据主题,比如商品主题、客户主题、销售主题等。每个主题下再包含多个业务指标、维度定义和事实定义,最终通过维度和事实的关联构建面向分析的多维数据立方体(Cube)。

    基于元数据管理中所定义的数据模型,就可以构建最终的数据仓库物理模型。数据仓库基于基础的ODS数据(数据贴源层,接近于OLTP系统中的原始数据)以及主数据(企业的基准数据,如客户信息、部门信息等)来构建不同汇总程度的业务事实表,包含明细事实和汇总事实;再结合不同维度表,最终构建出面向不同业务领域的多层数据集市。在数据集市的基础上,进行各种报表分析、特定指标计算、数据分析等深度数据应用。

    • ETL架构

    除了OLTP和OLAP的数据架构设计外,还有一类很重要的ETL架构,用于解决数据从OLTP领域到OLAP领域的有序流转需求。ETL是英文Extract-Transform-Load的缩写,描述的是将数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程。传统的ETL工具,包括Kettle和面向大数据领域的MapReduce、Spark等都采用定时批量机制。但随着业务发展越来越快,对数据的时效性要求越来越高,实时ETL架构也应运而生,包括像Storm、Spark Streaming这类数据工具都可以有效提高数据的同步时效性。现在的ETL架构大部分都采用定时批量机制抽取+近实时消息事件同步的混合架构。


    架构治理


    架构绝不是一锤子买卖,不是说一个系统的架构设计完了、开发完了,就可以把它扔在线上不管了。业务不断在发展,系统要不断进化,我们也要不断的对系统架构进行评估和调整,以保证系统的活力和可扩展性,这就是架构的治理。架构治理的目标是防止架构失控和架构腐化。

    这一部分的内容将针对前面所讨论的架构范式聊聊它们所对应的治理策略。

    【企业服务化架构(SOA)治理】

    架构治理主要包含如下动作:

    • 识别出当前架构有什么问题?

    • 需要做哪些改进?

    • 改进的策略和落地步骤是什么?

    因此需要建立架构衡量指标体系和监控评估体系,用以持续的对架构进行度量、优化和重构,这是一套很复杂的体系。大多数企业都会采用某种业界通用的治理方法论来对SOA架构进行治理,比如IBM推出的“SOA治理及管理方法(SGMM)”治理规范就把服务治理的生命周期定义为:

    计划、定义、启用、度量

    这4个步骤,如图9所示。

                                                           图9

    这四个步骤构成了一个完整的SOA治理生命周期,这个SOA治理生命周期会产生一个治理 模型来管理SOA生命周期。以下是治理模型中,各个治理步骤的作用:

    • 计划步骤:建立治理需求。包括收集和验证业务策略、评估当前企业IT能力、定义并优化SOA策略。

    • 定义步骤:定义治理方法。明确度量指标体系、明确责任人及治理资源投入、定义或修正治理流程、设计治理的IT架构。

    • 启用步骤:部署监管模型。部署治理机制、部署IT基础架构、对治理关系人进行培训、执行治理策略。

    • 度量步骤:对SOA实施状况进行评估、对治理效果进行评估。

    SOA治理生命周期和SOA生命周期这两个生命周期相互配合、同时运行,共同推进SOA架构的不断落地。

    SOA治理的标准和规范基本上被 IBM 这类传统 IT 大厂一手把持,比如上述的 IBM 的SGMM治理规范。这类传统IT大厂做事有一个特点:喜欢把简单的事情复杂化。SGMM这套规范全面覆盖企业 IT 的管理流程、工具、基础设施建设以及企业的组织架构,定义了一堆的人员角色、规范、做事流程,非常复杂。企业得掏钱请他来给你做咨询才能把这套体系玩起来,整个技术栈及流程太重了,对人的要求也非常高,因为规范中包含了大量手工度量、评估、治理动作,所以需要对相关治理干系人进行全面的培训。这些都严重制约了SOA治理的推广和普及。在笔者的职业生涯中,所见到的SOA治理成功落地的案例极少。现在很多企业都学乖了,一般不全套照搬这些治理规范,而是有选择的使用里面部分能力。

    虽然传统SOA治理存在种种不尽如人意之处,但它的一些思想还是很好的,比如重视各个环节的指标采集和度量、重视全生命周期的治理等等,这些都可以给我们有益的启发和参考。

    【微服务化架构治理】

    微服务架构脱胎于SOA架构,所以很多SOA架构的治理理念都可以应用于微服务架构治理。但互联网应用的集群规模要普遍大于企业内部应用,所以微服务架构的治理更关注自动化和智能化,大量的算法被用于服务质量及服务关系的洞察及自动化的服务管控上。

                                                           图10

    图10是一个典型的微服务治理架构图。微服务的治理既要进行线上的治理,也要进行线下的治理,通过线上线下两大维度进行治理指标的采集,把它们汇总到数据仓库中,进行统一的度量和分析。

    这些度量指标中,有相当一部分线上的性能及异常指标会被转化为运维事件,一旦触发预先设置的阈值,就会被进一步转化成“管控指令”,通过调度中心下发,进行服务自动化的弹性伸缩、扩容缩容操作,应对线上流量的波动;或者进行服务的限流、降级、容错、路由调整等管控操作,完成服务的自我保护,提高服务的稳定性。

    另外一部分度量指标,包括开发、测试、运维、过程协作效率等会通过治理委员会(泛指,治理成员的集合)进行人为的深入分析,并制定出治理决策。这些治理决策通过相关的管理措施进行落地。

    这样,我们通过服务的度量、管控、管理三大举措,构建起一个三位一体、围绕服务治理的闭环体系。

    【数据治理架构】

    数据治理的定义有很多版本,这里给出了接受度比较广的DAMA(国际数据管理协会)对数据治理的定义:

                              数据治理是对数据资产的管理活动行使权力和控制的活动集合

    从定义可见,数据治理更多的属于管理范畴,而不是技术范畴,技术只是将数据管理理念进行落地的工具。

                                                           图11

    图11是笔者曾经参与过的一个数据治理项目的整体架构图。数据治理活动关注的核心是数据的“可信”和“可控”,换句话说,就是数据的质量(一致性、准确性)和安全。在数据治理活动中,质量和安全贯穿于数据的整个生命周期的各个环节,因此数据治理是一个大而全的治理体系,如图11所示。它与元数据管理、主数据管理、模型管理、数据价值管理、数据共享管理等能力紧密结合。

    为了落实数据质量管控目标,可以通过数据治理构建比较完善的数据质量管理机制。笔者之前参与的数据治理项目就是通过批处理引擎定期运行一系列预定义的质量检查规则,进行“脏数据”的检测,并根据检测结果自动生成质量报告,指导数据质量的不断改进。这些检查规则都是根据实际数据使用过程中所遇到的质量问题不断积累定制的,最终会形成企业的数据质量知识库。

    数据安全的管控主要通过数据模型入手。由于用户主要接触的是模型,如果在数据架构上对数据模型进行严格管控可以带来一系列的好处。首先,比较容易进行安全控制,能够进行从数据域、数据主题、一直到数据表、字段一级的授权控制,把安全策略和模型结合,可以在模型解析执行时,生成受控的运行脚本或者SQL。

    数据模型不仅可应用于安全管控,基于良好的数据模型还可以很容易识别出数据血缘,清楚的知道数据的来源,存储在哪里,又被哪些第三方系统使用。完整的数据血缘有助于控制指标的联动影响。因为指标之间往往由于数据的关系产生关联,一个指标变动之后,可能会影响到其它指标。这时,可以通过数据血缘来识别指标影响的范围,从而实现更精细的ETL调度策略。

    数据治理需要通过一整套的数据开发规范及数据使用规范来保证。管理规范如果只是存在于纸面上,是很难落地的,必须通过技术手段来强制贯彻。前面讨论SOA架构时说过,落地管理规范最有效的手段是工作流。因此可以在数据门户中引入流程引擎,所有的数据使用申请,开发申请都需要在数据门户中发起工单,走相应的审批流程,实现“一切皆工单,一切皆流程”。同时,还需要构建一套知识库来维护和沉淀所有指标、模型的定义。避免数据干系人对同一个指标或者模型理解出现歧义和偏差,因为一旦出现理解偏差,必然会导致数据的不一致性。


    结语


    以上就是本次分享的全部内容,希望对有志于进入架构领域的同学们有所帮助。如果您对架构有独特的见解和思考,或者对以上内容有不同的看法,欢迎和我交流!

    我把多年在服务化领域的经验总结起来,出了本书,叫做《微服务治理:体系、架构及实践》,大家如果感兴趣可以关注一下。

     

     

     

    展开全文
  • 数据仓库建设及数据治理总结

    在谈数仓之前,先来看下面几个问题:

    数仓为什么要分层?

    1. 用空间换时间,通过大量的预处理来提升应用系统的用户体验(效率),因此数据仓库会存在大量冗余的数据;不分层的话,如果源业务系统的业务规则发生变化将会影响整个数据清洗过程,工作量巨大。

    2. 通过数据分层管理可以简化数据清洗的过程,因为把原来一步的工作分到了多个步骤去完成,相当于把一个复杂的工作拆成了多个简单的工作,把一个大的黑盒变成了一个白盒,每一层的处理逻辑都相对简单和容易理解,这样我们比较容易保证每一个步骤的正确性,当数据发生错误的时候,往往我们只需要局部调整某个步骤即可。

    数据仓库之父 Bill Inmon对数据仓库做了定义——面向主题的、集成的、相对稳定的、反映历史变化的数据集合,用于支持管理决策。从定义上来看,数据仓库的关键词为面向主题、集成、稳定、反映历史变化、支持管理决策,而这些关键词的实现就体现在分层架构内。

    一个好的分层架构,有以下好处:

    1. 清晰数据结构:每一个数据分层都有对应的作用域,在使用数据的时候能更方便的定位和理解。

    2. 数据血缘追踪:提供给业务人员或下游系统的数据服务时都是目标数据,目标数据的数据来源一般都来自于多张表数据。若出现目标数据异常时,清晰的血缘关系可以快速定位问题所在。而且,血缘管理也是元数据管理重要的一部分。

    3. 减少重复开发:数据的逐层加工原则,下层包含了上层数据加工所需要的全量数据,这样的加工方式避免了每个数据开发人员都重新从源系统抽取数据进行加工。

    4. 数据关系条理化:源系统间存在复杂的数据关系,比如客户信息同时存在于核心系统、信贷系统、理财系统、资金系统,取数时该如何决策呢?数据仓库会对相同主题的数据进行统一建模,把复杂的数据关系梳理成条理清晰的数据模型,使用时就可避免上述问题了。

    5. 屏蔽原始数据的影响:数据的逐层加工原则,上层的数据都由下一层的数据加工获取,不允许跳级取数。而原始数据位于数仓的最底层,离应用层数据还有多层的数据加工,所以加工应用层数据的过程中就会把原始数据的变更消除掉,保持应用层的稳定性。

    数仓分几层最好?

    目前市场上主流的分层方式眼花缭乱,不过看事情不能只看表面,还要看到内在的规律,不能为了分层而分层,没有最好的,只有适合的。

    分层是以解决当前业务快速的数据支撑为目的,为未来抽象出共性的框架并能够赋能给其他业务线,同时为业务发展提供稳定、准确的数据支撑,并能够按照已有的模型为新业务发展提供方向,也就是数据驱动和赋能。

    如何搭建一个好的数仓?

    1. 稳定:数据产出稳定且有保障。

    2. 可信:数据干净、数据质量高。

    3. 丰富:数据涵盖的业务足够广泛。

    4. 透明:数据构成体系足够透明。

    数仓设计

    数仓设计的3个维度:

    • 功能架构:结构层次清晰。

    • 数据架构:数据质量有保障。

    • 技术架构:易扩展、易用。

    数仓架构

    按照数据流入流出的过程,数据仓库架构可分为:源数据数据仓库数据应用

    数据仓库

    数据仓库的数据来源于不同的源数据,并提供多样的数据应用,数据自下而上流入数据仓库后向上层开放应用,而数据仓库只是中间集成化数据管理的一个平台。

    源数据:此层数据无任何更改,直接沿用外围系统数据结构和数据,不对外开放;为临时存储层,是接口数据的临时存储区域,为后一步的数据处理做准备。

    数据仓库:也称为细节层,DW层的数据应该是一致的、准确的、干净的数据,即对源系统数据进行了清洗(去除了杂质)后的数据。

    数据应用:前端应用直接读取的数据源;根据报表、专题分析需求而计算生成的数据。

    数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL(抽取Extra, 转化Transfer, 装载Load)的过程,ETL是数据仓库的流水线,也可以认为是数据仓库的血液,它维系着数据仓库中数据的新陈代谢,而数据仓库日常的管理和维护工作的大部分精力就是保持ETL的正常和稳定。

    建设数据仓库犹如创造一条新的生命,分层架构只是这条生命的逻辑骨架而已。想要在骨架上长出血肉,就必须进行合适的数据建模,数据仓库的强壮还是孱弱,健美还是丑陋,就取决于建模的结果。

    数仓建模方法

    数据仓库的建模方法有很多种,每一种建模方法代表了哲学上的一个观点,代表了一种归纳、概括世界的一种方法。常见的有 范式建模法、维度建模法、实体建模法等,每种方法从本质上将是从不同的角度看待业务中的问题。

    1. 范式建模法

    范式建模法其实是我们在构建数据模型常用的一个方法,该方法的主要由 Inmon 所提倡,主要解决关系型数据库的数据存储,利用的一种技术层面上的方法。目前,我们在关系型数据库中的建模方法,大部分采用的是三范式建模法。

    范式 是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则,而在关系型数据库中这种规则就是范式,这一过程也被称为规范化。目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、Boyce-Codd范式(BCNF)、第四范式(4NF)和第五范式(5NF)。

    在数据仓库的模型设计中,一般采用第三范式。一个符合第三范式的关系必须具有以下三个条件 :

    • 每个属性值唯一,不具有多义性 ;

    • 每个非主属性必须完全依赖于整个主键,而非主键的一部分 ;

    • 每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去。

    范式建模

    根据 Inmon 的观点,数据仓库模型的建设方法和业务系统的企业数据模型类似。在业务系统中,企业数据模型决定了数据的来源,而企业数据模型也分为两个层次,即主题域模型和逻辑模型。同样,主题域模型可以看成是业务模型的概念模型,而逻辑模型则是域模型在关系型数据库上的实例化。

    2. 实体建模法

    实体建模法并不是数据仓库建模中常见的一个方法,它来源于哲学的一个流派。从哲学的意义上说,客观世界应该是可以细分的,客观世界应该可以分成由一个个实体,以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法,将整个业务也可以划分成一个个的实体,而每个实体之间的关系,以及针对这些关系的说明就是我们数据建模需要做的工作。

    虽然实体法粗看起来好像有一些抽象,其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分,实体,事件,说明,如下图所示:

    实体建模

    上图表述的是一个抽象的含义,如果我们描述一个简单的事实:“小明开车去学校上学”。以这个业务事实为例,我们可以把“小明”,“学校”看成是一个实体,“上学”描述的是一个业务过程,我们在这里可以抽象为一个具体“事件”,而“开车去”则可以看成是事件“上学”的一个说明。

    3. 维度建模法

    维度模型是数据仓库领域另一位大师Ralph Kimall所倡导,他的《数据仓库工具箱》是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型,构建的数据模型为分析需求服务,因此它重点解决用户如何更快速完成分析需求,同时还有较好的大规模复杂查询的响应性能。

    星形模型

    典型的代表是我们比较熟知的星形模型(Star-schema),以及在一些特殊场景下适用的雪花模型(Snow-schema)。

    维度建模中比较重要的概念就是 事实表(Fact table)和维度表(Dimension table)。其最简单的描述就是,按照事实表、维度表来构建数据仓库、数据集市。

    目前在互联网公司最常用的建模方法就是维度建模。

    维度建模怎么建:

    在实际业务中,给了我们一堆数据,我们怎么拿这些数据进行数仓建设呢,数仓工具箱作者根据自身60多年的实际业务经验,给我们总结了如下四步。

    数仓工具箱中的维度建模四步走:

    维度建模四步走

    这四步是环环相扣,步步相连。下面详细拆解下每个步骤怎么做

    1、选择业务过程

    • 维度建模是紧贴业务的,所以必须以业务为根基进行建模,那么选择业务过程,顾名思义就是在整个业务流程中选取我们需要建模的业务,根据运营提供的需求及日后的易扩展性等进行选择业务。比如商城,整个商城流程分为商家端,用户端,平台端,运营需求是总订单量,订单人数,及用户的购买情况等,我们选择业务过程就选择用户端的数据,商家及平台端暂不考虑。业务选择非常重要,因为后面所有的步骤都是基于此业务数据展开的。

    2、声明粒度

    • 先举个例子:对于用户来说,一个用户有一个身份证号,一个户籍地址,多个手机号,多张银行卡,那么与用户粒度相同的粒度属性有身份证粒度,户籍地址粒度,比用户粒度更细的粒度有手机号粒度,银行卡粒度,存在一对一的关系就是相同粒度。为什么要提相同粒度呢,因为维度建模中要求我们,在同一事实表中,必须具有相同的粒度,同一事实表中不要混用多种不同的粒度,不同的粒度数据建立不同的事实表。并且从给定的业务过程获取数据时,强烈建议从关注原子粒度开始设计,也就是从最细粒度开始,因为原子粒度能够承受无法预期的用户查询。但是上卷汇总粒度对查询性能的提升很重要的,所以对于有明确需求的数据,我们建立针对需求的上卷汇总粒度,对需求不明朗的数据我们建立原子粒度。

    3、确认维度

    • 维度表是作为业务分析的入口和描述性标识,所以也被称为数据仓库的“灵魂”。在一堆的数据中怎么确认哪些是维度属性呢,如果该列是对具体值的描述,是一个文本或常量,某一约束和行标识的参与者,此时该属性往往是维度属性,数仓工具箱中告诉我们牢牢掌握事实表的粒度,就能将所有可能存在的维度区分开,并且要确保维度表中不能出现重复数据,应使维度主键唯一

    4、确认事实

    • 事实表是用来度量的,基本上都以数量值表示,事实表中的每行对应一个度量,每行中的数据是一个特定级别的细节数据,称为粒度。维度建模的核心原则之一是同一事实表中的所有度量必须具有相同的粒度。这样能确保不会出现重复计算度量的问题。有时候往往不能确定该列数据是事实属性还是维度属性。记住最实用的事实就是数值类型和可加类事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量,这种情况下该列往往是事实。

    其中粒度是非常重要的,粒度用于确定事实表的行表示什么,建议从关注原子级别的粒度数据开始设计,因为原子粒度能够承受无法预估的用户查询,而且原子数据可以以各种可能的方式进行上卷,而一旦选择了高粒度,则无法满足用户下钻细节的需求。

    事实是整个维度建模的核心,其中雪花模型或者星型模型都是基于一张事实表通过外健关联维表进行扩展,生成一份能够支撑可预知查询需求的模型宽表,而且最后的查询也是落在事实表中进行。

    实际业务中数仓分层

    数仓分层要结合公司业务进行,并且需要清晰明确各层职责,要保证数据层的稳定又要屏蔽对下游影响,一般采用如下分层结构:

    数据分层架构

    数据层具体实现

    使用四张图说明每层的具体实现

    • 数据源层ODS

    数据源层

    数据源层主要将各个业务数据导入到大数据平台,作为业务数据的快照存储。

    • 数据明细层DW

    数据明细层

    事实表中的每行对应一个度量,每行中的数据是一个特定级别的细节数据,称为粒度。维度建模的核心原则之一是同一事实表中的所有度量必须具有相同的粒度。这样能确保不会出现重复计算度量的问题。

    维度表一般都是单一主键,少数是联合主键,注意维度表不要出现重复数据,否则和事实表关联会出现数据发散问题。

    有时候往往不能确定该列数据是事实属性还是维度属性。记住最实用的事实就是数值类型和可加类事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量,这种情况下该列往往是事实;如果该列是对具体值的描述,是一个文本或常量,某一约束和行标识的参与者,此时该属性往往是维度属性。但是还是要结合业务进行最终判断是维度还是事实。

    • 数据轻度汇总层DM

    数据轻度汇总层

    此层命名为轻汇总层,就代表这一层已经开始对数据进行汇总,但是不是完全汇总,只是对相同粒度的数据进行关联汇总,不同粒度但是有关系的数据也可进行汇总,此时需要将粒度通过聚合等操作进行统一。

    • 数据应用层APP

    数据应用层

    数据应用层的表就是提供给用户使用的,数仓建设到此就接近尾声了,接下来就根据不同的需求进行不同的取数,如直接进行报表展示,或提供给数据分析的同事所需的数据,或其他的业务支撑。

    一张图总结下数据仓库的构建整体流程

    数仓整体流程

    数据治理

    数仓建设真正的难点不在于数仓设计,而在于后续业务发展起来,业务线变的庞大之后的数据治理,包括资产治理、数据质量监控、数据指标体系的建设等。

    其实数据治理的范围很⼴,包含数据本⾝的管理、数据安全、数据质量、数据成本等。在DAMA 数据管理知识体系指南中,数据治理位于数据管理“车轮图”的正中央,是数据架构、数据建模、数据存储、数据安全、数据质量、元数据管理、主数据管理等10大数据管理领域的总纲,为各项数据管理活动提供总体指导策略。

    数据治理之道是什么

    1. 数据治理需要体系建设

    为发挥数据价值需要满足三个要素:合理的平台架构、完善的治理服务、体系化的运营手段

    根据企业的规模、所属行业、数据量等情况选择合适的平台架构;治理服务需要贯穿数据全生命周期,保证数据在采集、加工、共享、存储、应用整个过程中的完整性、准确性、一致性和实效性;运营手段则应当包括规范的优化、组织的优化、平台的优化以及流程的优化等等方面。

    2. 数据治理需要夯实基础

    数据治理需要循序渐进,但在建设初期至少需要关注三个方面:数据规范、数据质量、数据安全。规范化的模型管理是保障数据可以被治理的前提条件,高质量的数据是数据可用的前提条件,数据的安全管控是数据可以共享交换的前提条件。

    3. 数据治理需要IT赋能

    数据治理不是一堆规范文档的堆砌,而是需要将治理过程中所产生的的规范、流程、标准落地到IT平台上,在数据生产过程中通过“以终为始”前向的方式进行数据治理,避免事后稽核带来各种被动和运维成本的增加。

    4. 数据治理需要聚焦数据

    数据治理的本质是管理数据,因此需要加强元数据管理和主数据管理,从源头治理数据,补齐数据的相关属性和信息,比如:元数据、质量、安全、业务逻辑、血缘等,通过元数据驱动的方式管理数据生产、加工和使用。

    5. 数据治理需要建管一体化

    数据模型血缘与任务调度的一致性是建管一体化的关键,有助于解决数据管理与数据生产口径不一致的问题,避免出现两张皮的低效管理模式。

    浅谈数据治理方式

    如上面所说,数据治理的范围非常广,其中最重要的是数据质量治理,而数据质量涉及的范围也很广,贯穿数仓的整个生命周期,从数据产生->数据接入->数据存储->数据处理->数据输出->数据展示,每个阶段都需要质量治理,评价维度包括完整性、规范性、一致性、准确性、唯一性、关联性等。

    在系统建设的各个阶段都应该根据标准进行数据质量检测和规范,及时进行治理,避免事后的清洗工作。

    质量检测可参考以下维度:

    维度衡量标准
    完整性业务指定必须的数据是否缺失,不允许为空字符或者空值等。例如,数据源是否完整、维度取值是否完整、数据取值是否完整等
    时效性当需要使用时,数据能否反映当前事实。即数据必须及时,能够满足系统对数据时间的要求。例如处理(获取、整理、清洗、加载等)的及时性
    唯一性在指定的数据集中数据值是否唯一
    参照完整性数据项是否在父表中有定义
    依赖一致性数据项取值是否满足与其他数据项之间的依赖关系
    正确性数据内容和定义是否一致
    精确性数据精度是否达到业务规则要求的位数
    技术有效性数据项是否按已定义的格式标准组织
    业务有效性数据项是否符合已定义的
    可信度根据客户调查或客户主动提供获得
    可用性数据可用的时间和数据需要被访问时间的比例
    可访问性数据是否便于自动化读取

    下面是根据美团的技术文章总结的几点具体治理方式:

    1. 规范治理

    规范是数仓建设的保障。为了避免出现指标重复建设和数据质量差的情况,统一按照最详细、可落地的方法进行规范建设。

    (1) 词根

    词根是维度和指标管理的基础,划分为普通词根与专有词根,提高词根的易用性和关联性。

    • 普通词根:描述事物的最小单元体,如:交易-trade。

    • 专有词根:具备约定成俗或行业专属的描述体,如:美元-USD。

    (2) 表命名规范

    通用规范

    • 表名、字段名采用一个下划线分隔词根(示例:clienttype->client_type)。

    • 每部分使用小写英文单词,属于通用字段的必须满足通用字段信息的定义。

    • 表名、字段名需以字母为开头。

    • 表名、字段名最长不超过64个英文字符。

    • 优先使用词根中已有关键字(数仓标准配置中的词根管理),定期Review新增命名的不合理性。

    • 在表名自定义部分禁止采用非标准的缩写。

    表命名规则

    • 表名称 = 类型 + 业务主题 + 子主题 + 表含义 + 存储格式 + 更新频率 +结尾,如下图所示:

    统一的表命名规范

    (3) 指标命名规范

    结合指标的特性以及词根管理规范,将指标进行结构化处理。

    1. 基础指标词根,即所有指标必须包含以下基础词根:

    1. 业务修饰词,用于描述业务场景的词汇,例如trade-交易。

    3.日期修饰词,用于修饰业务发生的时间区间。

    4.聚合修饰词,对结果进行聚集操作。

    5.基础指标,单一的业务修饰词+基础指标词根构建基础指标 ,例如:交易金额-trade_amt。

    6.派生指标,多修饰词+基础指标词根构建派生指标。派生指标继承基础指标的特性,例如:安装门店数量-install_poi_cnt。

    7.普通指标命名规范,与字段命名规范一致,由词汇转换即可以。

    2. 架构治理

    (1) 数据分层

    优秀可靠的数仓体系,往往需要清晰的数据分层结构,即要保证数据层的稳定又要屏蔽对下游的影响,并且要避免链路过长,一般的分层架构如下:

    (2) 数据流向

    稳定业务按照标准的数据流向进行开发,即ODS-->DWD-->DWA-->APP。非稳定业务或探索性需求,可以遵循ODS->DWD->APP或者ODS->DWD->DWT->APP两个模型数据流。在保障了数据链路的合理性之后,又在此基础上确认了模型分层引用原则:

    • 正常流向:ODS>DWD->DWT->DWA->APP,当出现ODS >DWD->DWA->APP这种关系时,说明主题域未覆盖全。应将DWD数据落到DWT中,对于使用频度非常低的表允许DWD->DWA。

    • 尽量避免出现DWA宽表中使用DWD又使用(该DWD所归属主题域)DWT的表。

    • 同一主题域内对于DWT生成DWT的表,原则上要尽量避免,否则会影响ETL的效率。

    • DWT、DWA和APP中禁止直接使用ODS的表, ODS的表只能被DWD引用。

    • 禁止出现反向依赖,例如DWT的表依赖DWA的表。

    3. 元数据治理

    元数据可分为技术元数据和业务元数据:

    技术元数据为开发和管理数据仓库的IT 人员使用,它描述了与数据仓库开发、管理和维护相关的数据,包括数据源信息、数据转换描述、数据仓库模型、数据清洗与更新规则、数据映射和访问权限等。

    常见的技术元数据有:

    • 存储元数据:如表、字段、分区等信息。

    • 运行元数据:如大数据平台上所有作业运行等信息:类似于 Hive Job 日志,包括作业类型、实例名称、输入输出、 SQL 、运行参数、执行时间,执行引擎等。

    • 数据开发平台中数据同步、计算任务、任务调度等信息:包括数据同步的输入输出表和字段,以及同步任务本身的节点信息:计算任务主要有输入输出、任务本身的节点信息 任务调度主要有任务的依赖类型、依赖关系等,以及不同类型调度任务的运行日志等。

    • 数据质量和运维相关元数据:如任务监控、运维报警、数据质量、故障等信息,包括任务监控运行日志、告警配置及运行日志、故障信息等。

    业务元数据为管理层和业务分析人员服务,从业务角度描述数据,包括商务术语、数据仓库中有什么数据、数据的位置和数据的可用性等,帮助业务人员更好地理解数据仓库中哪些数据是可用的以及如何使用。

    • 常见的业务元数据有维度及属性(包括维度编码,字段类型,创建人,创建时间,状态等)、业务过程、指标(包含指标名称,指标编码,业务口径,指标类型,责任人,创建时间,状态,sql等),安全等级,计算逻辑等的规范化定义,用于更好地管理和使用数据。数据应用元数据,如数据报表、数据产品等的配置和运行元数据。

    元数据不仅定义了数据仓库中数据的模式、来源、抽取和转换规则等,而且是整个数据仓库系统运行的基础,元数据把数据仓库系统中各个松散的组件联系起来,组成了一个有机的整体。

    元数据治理主要解决三个问题

    1. 通过建立相应的组织、流程和工具,推动业务标准的落地实施,实现指标的规范定义,消除指标认知的歧义;

    2. 基于业务现状和未来的演进方式,对业务模型进行抽象,制定清晰的主题、业务过程和分析方向,构建完备的技术元数据,对物理模型进行准确完善的描述,并打通技术元数据与业务元数据的关系,对物理模型进行完备的刻画;

    3. 通过元数据建设,为使用数据提效,解决“找数、理解数、评估”难题以及“取数、数据可视化”等难题。

    4. 安全治理

    围绕数据安全标准,首先要有数据的分级、分类标准,确保数据在上线前有着准确的密级。第二,针对数据使用方,要有明确的角色授权标准,通过分级分类和角色授权,来保障重要数据拿不走。第三,针对敏感数据,要有隐私管理标准,保障敏感数据的安全存储,即使未授权用户绕过权限管理拿到敏感数据,也要确保其看不懂。第四,通过制定审计标准,为后续的审计提供审计依据,确保数据走不脱。

    5. 数据生命周期治理

    任何事物都具有一定的生命周期,数据也不例外。从数据的产生、加工、使用乃至消亡都应该有一个科学的管理办法,将极少或者不再使用的数据从系统中剥离出来,并通过核实的存储设备进行保留,不仅能够提高系统的运行效率,更好的服务客户,还能大幅度减少因为数据长期保存带来的储存成本。数据生命周期一般包含在线阶段、归档阶段(有时还会进一步划分为在线归档阶段和离线归档阶段)、销毁阶段三大阶段,管理内容包括建立合理的数据类别,针对不同类别的数据制定各个阶段的保留时间、存储介质、清理规则和方式、注意事项等。

    从上图数据生命周期中各参数间的关系中我们可以了解到,数据生命周期管理可以使得高价值数据的查询效率大幅提升,而且高价格的存储介质的采购量也可以减少很多;但是随着数据的使用程度的下降,数据被逐渐归档,查询时间也慢慢的变长;最后随着数据的使用频率和价值基本没有了之后,就可以逐渐销毁了。

    展开全文
  • 埋点间的交叉验证 多层库表间相同指标交叉验证 明细层和统计层建立数据量、行数、计算结果的比对验证 ③ 及时性 日志上报 有效上传率 延迟率 资源使用 当前占用占比 剩余资源占比 任务调度 完成率 失败率 延迟率 1.4...
  • 在凿井施工揭露煤层采空区前,采用地面注浆充填加固技术,使用水泥粉煤灰浆液,对采空区进行了治理。每个井筒在地面布置4圈注浆孔,圈径分别为24,30,60,72m,每圈布置4~6个孔,注浆压力2.0~3.0MPa。副立井共注入水泥粉煤灰...
  • 本项目从节能服务外包关系的多层性和关系治理的多维性入手,分析外包关系多元治理方式的构成(包括合同、关系契约和心理契约等3 种治理方式),探索各治理方式的维度;并运用能力理论和社会网络理论,揭示外包管理能力、...
  • 平台可以被认为是一个新的虚拟利益相关者,它与网络理论一致,将传统的合作伙伴(股东,经理,雇员,贷方,客户,供应商等)连接起来,代表了多层网络中的桥接节点和边缘。 利益相关者是在桥接(集线器)节点之间...
  • 保护层开采是突出矿井区域防突最有效、最经济的措施,更是实现突出矿井安全生产的根本保证,尤其是下保护层开采后大量被保护层(1层或多层)瓦斯充分解吸通过裂隙涌入开采保护层采空区,保安煤业多措并举彻底解决了回采...
  • 点击上方 "大数据肌肉猿"关注,星标一起成长点击下方链接,进入高质量学习交流群今日更新| 950个转型案例分享-大数据交流群本文分为两大节介绍,第一节是数仓建设,第二节是数据治理,内容较...
  • 基于数据中台的数据治理解决方案

    千次阅读 2021-08-03 00:07:57
    数据不可溯源,跟踪数据处理过程困难 数据中台为了能实现数据整合与高效应用,以及指标计算的复杂性,往往会进行多层的数据处理。而且数据处理的逻辑往往只是在程序或者文档描述中,存在结构化差异,描述不全、不...
  • 本文根据InfoQ极客大学架构开放日专场的分享整理而成,原标题《架构师的道、法、术》,但笔者更喜欢现在的标题,更直接明了。本文共三大部分,包括架构原则、架构范式、架构治理,分别介绍架构的概...
  • 关于数仓建设及数据治理的超全概括

    千次阅读 多人点赞 2021-07-22 15:29:48
    本文分为两大节介绍,第一节是数仓建设,第二节是数据治理,内容较长,还请耐心阅读! 本文首发于公众号【五分钟学大数据】 在谈数仓之前,先来看下面几个问题: 数仓为什么要分层? 用空间换时间,通过大量...
  • 微服务架构体系的深度治理 天弘基金(余额宝) 李鑫 微服务模式下,庞大的服务节点数量、日趋复杂的服务分层、离散的组织协同、扁平化的管理模式让服务治理的广度、深度、难度都达到前所未有的程度。单纯依靠微服务...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,665
精华内容 1,066
关键字:

多层治理