标签：设置 工程师 复杂 中文名 分发 托管 ext 条件 枚举
作为一家高度数字化和技术驱动的公司，美团非常重视数据价值的挖掘。在公司日常运行中，通过各种数据分析挖掘手段，为公司发展决策和业务开展提供数据支持。经过多年的发展，美团酒旅内部形成了一套完整的解决方案，核心由数据仓库+各种数据平台的方式实现。其中数据仓库整合各业务线的数据，消灭数据孤岛；各种数据平台拥有不同的特色和定位，例如：自助报表平台、专业数据分析平台、CRM数据平台、各业务方向绩效考核平台等，满足各类数据分析挖掘需求。早期数据仓库与各种数据平台的体系架构如图1所示：
图1所示的体系架构，在业务需求的满足上非常高效，但在长时间的使用过程中，也产生了如下一些问题：
上述这些问题总结归纳起来，就是指标数据不一致的问题，最终带来的后果是指标数据可信度底，严重影响分析决策。通过后续追踪分析，上述问题的由来，主要是不同业务线的数据分析人员、数据开发人员，以及不同的产品之间，缺乏有效的沟通，也没有一个统一的入口，来记录业务的发生和加工过程。在加上人员的流动，长时间积累之后就产生了这些问题。针对这些问题，酒旅内部启动了数据治理项目，通过建设一个专业数据治理平台，实现指标维度及数据的统一管理，也探索一套高效的数据治理流程。
在建设起源数据治理平台的过程中，主要面临的挑战如下：
为了达成数据治理的目标，起源数据治理平台就必须记录下业务发展过程，并映射到数据加工和数据提取，规范约束这些过程。因此起源数据治理平台归纳到数据治理层，该层就位于数据仓库层（或数据集市层）之上，数据应用层之下起到桥梁的作用，而且提供一系列规则，改变原来无序交互方式，将数据仓库层和数据应用层的交互变为有序的、可查询、可监控。新的体系架构如图2所示：
如上图所示，在新的体系架构下：对于数据仓库层，起源数据治理平台综合业务组织形式、指标数据来源、上层产品的使用及查询的效率，指导数据仓库模型的建设；对于应用层的产品，业务元数据信息及数据信息都是由起源数据治理平台提供，保证了各数据产品获取到的信息一致，而且还简化了应用层产品数据获取成本，也降低了对原有系统的侵入。
起源数据治理平台核心是保证数据一致，在数据安全的前提下，尽可能提升数据分发能力。因此平台内部有着极其复杂的关系，需要在建设过程中进行抽象，形成具有相对单一功能的模块；合理地组织模块的层级和连接关系，降低平台的开发难度，并提升平台的可维护性。平台架构如图3所示，展示了平台的内部模块组织方式。
如上图所示起源数据治理平台在功能模块上由数据存储、数据查询、数据缓存、元数据管理、业务管理、安全管理、应用管理、对外API接口构成，各模块的功能介绍如下。
起源数据治理平台管理的数据存储范围包括：数据仓库中的Topic层和数据应用层，存储方式包括：Hive、MySQL、Kylin、Palo、ES、Druid。如下图4所示：
上图所示的这些数据存储中的数据的加工过程，由数据开发工程师负责，具体采用哪种存储介质，由数据开发工程师综合所需数据存储空间、查询效率、模型的组织形式等因素决定。但后续的使用维护都由起源数据治理平台管理，管理方式是通过管理这些数据表的元数据信息和查询实现，具体实现细节会在下面章节中详解。
数据存储托管之后，数据表元数据信息变更监控、表数据生产（存储空间、生产状态及完成时间）监控、表数据波动（同环比等）监控以及表的使用（模型的构建及查询效率等）监控及评估，都由起源数据治理平台自动完成，所有信息的变动都会自动周知对应的负责人，保证数据应用的安全和稳定。
元数据信息宏观上包括两大部分：业务元数据信息和数据元数据信息。其中业务元数据信息包括：指标业务定义、维度的业务定义等；数据元数据信息包括：数据表元数据信息、模型元数据信息、维表与维度的绑定关系、数据模型字段与指标的绑定关系。
起源平台为了实现元数据信息的管理，设计了四个模块实现，分别是：数据表管理模块、模型管理模块、指标管理模块、维度管理模块。元数据管理是起源数据治理平台的核心，起源平台就是通过控制好元数据，来驱动数据的生产和消费。
数据表管理模块管理了数据库信息和数据表信息。其中数据库信息包括数据库链接信息，数据库信息维护后，起源数据治理平台自动获取对应库中表的元数据信息。数据表信息包括：表的元数据信息（引擎、字段等）、表类型（维表或事实表）、表的使用情况（是否被模型使用）、表对应的ETL、表的负责人、表的推荐度、描述信息、表的监控配置及报警历史、以及样例数据等。上述这些信息为业务用户提供指导，为模型管理提供数据支持，为数据表和数据的稳定提供监控和预警。
模型管理模块能够还原业务落地后数据表的组织关系，包括：数据表的关联方式（join、left join、semi join等）、数据表的关联限制、模型ER图、模型包含字段、模型字段与维度的绑定关系、模型与指标的绑定关系。不过在实际使用过程中，面向业务和面向分析的模型有所不同，起源数据治理平台是面向分析的，所以主要的模型包括维度建模中的星型模型或雪花模型，再就是OLAP多维分析的MOLAP或ROLAP。模型管理如下图5、图6所示：
维度管理模块包括基础信息和技术信息，对应着不同人员维护。其中基础信息对应维度的业务信息，由业务管理人员维护，包括维度名称、业务定义、业务分类。技术信息对应维度的数据信息，由数据开发工程师维护，包括是否有维表（是枚举维度还是有独立的维表）、是否是日期维、对应code英文名称和中文名称、对应name英文名称和中文名称。如果维度有维表，则需要和对应的维度表绑定，设置code和name对应的字段；如果维度是枚举维，则需要填写对应的code和name。维度的统一管理，有利于以后数据表的标准化，也方便用户的查看。
指标管理模块核心包括基础信息和技术信息管理，衍生信息包括关联指标、关联应用管理。基础信息对应的就是指标的业务信息，由业务人员填写，主要包括指标名称、业务分类、统计频率、精度、单位、指标类型、指标定义、计算逻辑、分析方法、影响因素、分析维度等信息；基础信息中还有一个比较重要的部分是监控配置，主要是配置指标的有效波动范围区间、同环比波动区间等，监控指标数据的正常运行。
技术信息构成比较复杂，包括数据类型、指标代码，但是核心部分是指标与模型的绑定关系，通过使用演进形成了当前系统两类绑定关系：绑定物理模型和构建虚拟模型。绑定物理模型是指标与模型管理中的物理模型字段绑定，并配置对应的计算公式，或还包含一些额外的高级配置，如二次计算、模型过滤条件等；创建虚拟模型是通过已有指标和其对应的物理模型，具体步骤首先配置已有指标的计算方式或指标维度的过滤，然后选择指标已绑定的物理模型，形成一个虚拟模型，虚拟模型的分析维度就是所选指标基础模型的公共维度。
衍生信息中的关联指标、关联应用管理，是为了方便观察指标被那些其他指标和数据应用使用，这是因为指标技术信息采用了严格权限控制，一旦被使用为了保证线上的运行安全是禁止变更的，只有解绑并审核通过后才可以编辑，所以这些衍生信息就是方便管理人员使用。指标技术信息如图7所示：
业务管理按照功能划分为业务线管理、主题管理和工单管理三部分，在系统的实际建设中是拆分为业务主题管理、数据主题管理和工单管理三大模块实现的。相关模块的建设主要保证业务人员和数据人员业务主题建设，相关模块的权限控制，业务流程审核，对应资源的隔离以及业务资源加工申请和加工过程的记录追踪。具体实现和功能如下：
实现业务业务线管理和业务主题管理，实现不同业务线的管理以及业务线下的业务主题管理。业务线的拆分还隐藏着其他模块的权限管控和资源隔离的功能，不同业务线的用户只能看到有权业务线的指标和维度；而且业务线的用户划分为普通用户和管理员，分别查看或编辑维度和指标的业务信息。而且业务线和业务主题中分别维护的商分负责人对指标进行二级审核，因为新创建的指标仅仅是普通指标，如果想要全网都能查看，则需要发起认证，由这些人员审核。
数据主题管理实现数据业务线和数据主题管理，实现不同数据线的管理以及数据线下的数据主题管理。数据线的拆分也隐藏着对数据表、模型、指标、维度的资源隔离和权限管控的功能，不同数据线的用户只能查看有权数据线的资源；而且数据线的用户分为普通用户和管理员，对有权资源进行查看或编辑。数据线的接口人在工单模块中具有审核工单的权限功能。数据主题的负责人拥有审核模型和指标技术信息的权限功能。
工单模块管理实现了指标维度和对应模型加工线上申请、审核、加工、审批的流程。整个模块也是围绕着这四个流程实现的，具体是业务人员发起指标和维度集合的加工申请，然后由数据线接口人审核工单的合理性并分配对应的数据开发工程师，数据开发工程师加工模型并与对应的维度指标绑定，然后在工单中提交由数据接口人审核是否合理，最终由工单发起人验收。
这个流程是一个标准的工单流程，每个节点的业务流程可能会反复，但是每次操作都进行记录，方便业务人员后期追踪。工单管理如下图8所示：
安全管理是起源数据治理平台核心功能之一，分为平台操作权限管理和接口调用权限管理两大部分。其中平台操作权限管理是通过与公司将军令权限管理系统打通，并配合平台其他模块中权限控制代码，实现了权限管理、审批、审计三大功能模块；接口权限管理是通过平台内的数据应用管理和外部应用管理模块的映射关系，并在接口调用时鉴权实现，这部分会在下面的应用管理章节中介绍。
权限管理模块是将平台的资源分划分为页面权限、业务线&数据线用户权限、数据应用权限来实现的。页面权限实现平台内页面访问控制。业务线&数据线用户权限是将用户分类为普通用户和管理员，普通用户只能查看业务线和数据线内资源，管理员可以操作业务线和数据线内的资源；并且通过业务线和数据线的独立管理实现资源隔离，业务线实现了所属维度和指标的隔离；数据线实现了所属数据表和模型的隔离，并且通过建立业务线和数据线的关联关系，也保证了指标和维度的技术信息操作隔离。数据应用中每个应用都是独立管理的，每个应用权限都拆分普通用户和管理员，普通用户可以访问查询应用，管理员可以操作应用。
审批模块包含审批工作流、我的申请、我的审批构成。审批工作流是根据不同的应用场景实现不同层级的审批，例如：在指标管理中服务于个人的普通指标变更为服务于整个业务线的认证指标，就需要发起两级审批，由业务主题负责人和业务商分审核通过才可以；模型管理中新增或修改模型上线，都需要数据主题负责人审批；数据应用的变更，都需要下游所有依赖外部应用负责人审批才生效。我的申请和我的审批是平台页面方便用户查看流程进度和操作审核。审批模块目标是保证发布信息的正确性、系统服务的稳定性。
审计模块包括用户操作记录和记录查看追踪。用户操作记录是平台各模块调用接口记录用户每次操作前后的数据变更；记录查看追踪是检索查询页面，查看对应的变更。审计模块保证了用户操作追踪追责，也保证误操作的信息恢复。
应用管理由数据应用、外部应用、数据地图三大模块组成，它们构成了对外服务的主体，记录了外部应用与平台内管理的指标、维度、模型和表的关联关系，也提供数据查询展示、应用层ETL生产的能力。而且数据开发人员从底层向上观察，可以追踪数据最终的所有流向；业务分析人员从顶层向下观察，可以看到构成服务的所有数据来源。
数据应用模块是记录生成每个服务所需的指标、维度和数据模型的关系。每次服务中可以包含多个指标，这些指标可以来源于多个数据模型，不过不同的数据模型中需要包含公共维度，因为是通过这些公共维度将不同模型关联起来。
数据应用中构建的服务可以发布成查询服务、应用层ETL生产服务、对外API数据接口服务、通用报表配置服务，来满足业务的不同需求。数据应用管理如下图9所示：
外部应用模块管理外部应用和应用内的模块，以及这些模块订阅的对应数据应用，目标是实现API接口调用的权限管理和数据最终流向的记录。具体的实现上模块首先创建对应的外部应用，记录外部应用的名称、URL、APPKEY等信息，然后由对应应用的负责人创建模块，记录模块名称、URL、moduleKey等信息。这些信息完善后，由对应的数据应用赋权给对应的模块，建立起数据应用与外部应用的联系。最后在外部应用调用平台对外API接口时，进行权限管理。
数据地图功能是追查数据的流向，可以从数据表、模型、指标、数据应用、外部应用任意节点查看上游数据来源和下游数据去向。起源数据治理平台核心功能也是组织这些节点间的关系，形成完整的服务，数据地图就是通过上面介绍模块记录的关系，追踪数据流向，方便数据开发人员和业务分析人员了解数据消费和数据来源。数据地图如下图10所示：
对外API接口是一套完整的对外信息提供接口，提供的功能分为元数据信息类的接口、数据类接口、监控统计类接口，分别满足外部平台和分析人员的对应需求。外部系统通过起源数据治理平台获取到的元数据和数据是经过认证并由平台自动校验后的，可以保证信息的一致性、正确性。
元数据信息接口提供的包括指标、维度业务元数据信息和数据表、模型、指标计算、维度维表相关的数据元数据信息，实现与上游系统信息共享，达到信息一致性的目标。
数据类接口提供指标维度数据查询服务，不单单满足常见的单条SQL查询，而且可以实现多次查询聚合运算（例如：同环比等）以及跨引擎查询，并通过并发处理，可以有效提升查询效率，满足更多的业务场景。接口具有监控功能，能够评估每次查询效率，提供查询指导或预警的能力。
监控统计类接口提供指标数据监控信息、指标维度使用统计、数据接口的调用效率统计等服务，帮助下游服务平台了解服务质量。
起源数据治理平台内部工作原理就是实现指标、维度业务信息与数据模型计算关系的映射管理，并根据外部应用所需的指标、维度以及查询条件选择最优的模型动态的实现查询SQL或查询Query的拼接，然后通过分布式查询引擎实现数据的高效查询，具体过程如下图11所示：
上图所示的分布式查询引擎，整合了大数据分析常见的各种存储，通过封装的接口提供服务。而且分布式是通过Akka Cluster自主实现，通过Cluster Singleton解决单点故障的问题，通过Redis实现了任务队列的持久化，通过平衡子节点任务量实现任务的合理调度，通过查询状态监控自动实现查询降级和任务队列的拆解，并且也完善了整个调度的监控，可以实时查看任务和节点的运行情况。
起源数据治理平台生产所需参与的角色包括：业务人员和数据开发人员（RD）。为了保证信息的正确性，平台内有着严格的管理流程，需要不同的角色在对应的节点进行维护管理，平台的管理流程如下图12所示：
所上图所示，指标的业务信息需要业务人员首先进行维护，然后数据RD同学进行相应的数据表的建设，维护对应的数据表和模型的元数据信息，并完成指标与模型的绑定，最后由数据RD同学构建数据应用为用户、业务系统及数据产品等提供服务。
经过长时间的探索开发，完成了起源数据治理平台的建设，成功的解决了上面提到的问题，并且已经完成了酒旅内部10+个数据平台（包括定制化产品和通用报表服务平台）的数据治理支持。起源数据治理平台还带来了一些额外的收获，总结归纳起来实现了3个目标，提供了4种能力，如下：
如果换位到指标的角色，以辩证的角度分析，起源数据治理平台解决了一个终极哲学问题：我是谁，我从哪里来，我到哪里去。
起源数据治理平台是天工体系（从数据管理、查询到展示的一个完整生态）的一部分，整个天工体系还包括如意通用报表系统、筋斗云数据查询系统。通过对天工体系的建设，直接目标是为业务提供一整套高效、高质量的数据服务平台；但是在天工体系的建设中，进行微服务治理，抽象形出一套统一标准，吸纳更多的业务参与建设，为业务提供开发降级，避免服务的重复建设，提升服务建设速度。如下图13所示：
如上图所示，天工体系开放三套交互标准，实现模块的可插拔和自由扩展，分别是：
夷山，美团点评技术专家，现任TechClub-Java俱乐部主席，2006年毕业于武汉大学，先后就职于IBM、用友、风行以及阿里巴巴。2014年加入美团，长期致力于BI工具、数据安全与数据质量工作等方向。
李鹏，美团点评技术专家，曾就职于搜狐畅游、网易，2018年加入美团点评，长期致力于数据治理、数据仓库建设、数据平台研发等工作方向。
最后插播一个招聘广告，有对数据产品工具开发感兴趣的可以发邮件给 fuyishan#meituan.com。我们是一群擅长大数据领域数据工具，数据治理，智能数据应用架构设计及产品研发的工程师。
发现文章有错误、对内容有疑问，都可以关注美团技术团队微信公众号（meituantech），在后台给我们留言。我们每周会挑选出一位热心小伙伴，送上一份精美的小礼品。快来扫码关注我们吧！
标签：设置 工程师 复杂 中文名 分发 托管 ext 条件 枚举
原文地址：https://www.cnblogs.com/meituantech/p/10189808.html
