最近在做数据中台、数据湖仓相关的调研，以下是收集的材料整理出来的资料，今天把它发出来供老铁们参考。

1.概述

1.1什么是数据中台

数据是从业务系统产生的，而业务系统也需要数据分析的结果，那么是否可以把业务系统的数据存储和计算能力抽离，由单独的数据处理平台提供存储和计算能力？这样不仅可以简化业务系统的复杂性，还可以让各个系统采用更合适的技术，专注做本身擅长的事。这个专用的数据处理平台即数据中台。

数据中台是一个用技术连接大数据计算存储能力，用业务连接数据应用场景能力的平台。

“连接能力”是数据中台的精髓。作为一个处在中间层的能力平台，“连接”是其根本任务。在业务层面需要尽可能连接各种数据源作为其生产资料；同时，由于生产数据的场景越来越多，覆盖了线上线下等多渠道，各数据生产资料之间也需要进行连接，才能形成全域的数据；数据在数据中台这个平台上按照 标准的模型进行规范加工处理后需要服务于多种场景，同样需要我们提供标准的数据服务接口将数据与应用场景连接起来。因此，连接是数据中台的根本能力，也是数据中台的价值所在。

数据中台通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。

数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。这些服务跟企业的业务有较强关联性，是这个企业独有且能复用的。

1.2数据中台解决什么问题

1、效率问题：为什么应用开发增加一个报表，就要十几天时间？为什么不能实时获得用户推荐清单？当业务人员对数据产生一点疑问的时候，需要花费很长的时间，结果发现是数据源的数据变了，最终影响上线时间。
2、协作问题：当业务应用开发的时候，虽然和别的项目需求大致差不多，但因为是别的项目组维护的， 所以数据还是要自己再开发一遍。
3、能力问题：数据的处理和维护是一个相对独立的技术，需要相当专业的人来完成，但是很多时候，我们有一大把的应用开发人员，而数据开发人员很少。

1.3数据中台和数据仓库、数据平台的区别

1、数据中台是企业级的逻辑概念，体现企业 D2V（Data to Value）的能力，为业务提供服务的主要方式是数据 API；
2、数据仓库是一个相对具体的功能概念，是存储和管理一个或多个主题数据的集合，为业务提供服务的 方式主要是分析报表；
3、数据平台是在大数据基础上出现的融合了结构化和非结构化数据的数据基础平台，为业务提供服务的 方式主要是直接提供数据集；
4、数据中台距离业务更近，为业务提供速度更快的服务；
5、数据仓库是为了支持管理决策分析，而数据中台则是将数据服务化之后提供给业务系统，不仅限于分析型场景，也适用于交易型场景；
6、数据中台可以建立在数据仓库和数据平台之上，是加速企业从数据到业务价值的过程的中间层。

1.4名词解释

1.数据主题域

指面向业务分析，将业务过程或者维度进行抽象的集合。其中，业务过程可以概括为一个个不拆分的行为事件，在业务过程之下，可以定义指标；维度，是度量的环境，如门店采购订单事件，门店采购是维度。为了保障整个体系的生命力，数据域是需要抽象提炼，并且长期维护更新的，变动需 执行变更流程。

2.业务过程

指公司的业务活动事件，如采购、销售、支付、配送等都是业务过程。其中，业务过程不可拆分。

3.时间周期

用来明确统计的时间范围或者时间点，如最近30天、自然周、截止当日等。

4.修饰类型

是对修饰词的一种抽象划分。修饰类型从属于某个业务域，如日志域的访问终端类型涵盖APP端、PC端等修饰词。

5.修饰词

指的是统计维度以外指标的业务场景限定抽象，修饰词属于一种修饰类型，如在日志域的访问终端类型下，有修饰词APP、PC端等。

6.度量/原子指标

原子指标和度量含义相同，基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名称，如支付金额。

7.维度

维度是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，也可以称为实体对象。维度属于一个数据域，如地理维度（其中包括国家、地区、省市等）、时间维度（其中包括 年、季、月、周、日等级别内容）。

8.维度属性

维度属性隶属于一个维度，如地理维度里面的国家名称、国家ID、省份名称等都属于维度属性。

9.指标分类

主要分为原子指标、衍生指标、复合指标
原子指标
基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名称，如呼单量、交易金额衍生指标
是一个个原子指标+多个修饰词（可选）+ 时间周期，是原子指标业务统计范围的圈定。
派生指标又分以下二种类型：
1）事务型指标
是指对业务过程进行衡量的指标。例如，订单量、订单支付金额，这类指标需要维护原子指标以及修饰词，在此基础上创建派生指标。
2）存量型指标
是指对实体对象某些状态的统计，例如注册司机总数、注册配送车辆总数，这类指标需要维护原子指标以及修饰词，在此基础上创建派生指标，对应的时间周期一般为“历史截止当前某个时间”。
复合指标
是在事务性指标和存量型指标的基础上复合成的。主要有比率型、比例型、统计型均值。

2.平台建设目的

大数据时代的到来，让越来越多的企业看到了数据资产的价值。将数据视为企业的重要资产，已经 成为业界的一种共识，企业也在快速探索应用场景和商业模式，并开始建设技术平台。
为了解决企业业务在实际中存在的以下问题：

1.各个业务数据重复开发浪费存储与计算资源

2.数据标准不统一，存在数据质量问题，数据使用成本高

3.业务数据孤岛问题严重业务协同能力弱，数据利用效率低

4.缺乏精准模型支撑，数据分析能力不足，数据应用价值不高

基于四个统一，统一数据采集，统一数据处理，统一数据存储，统一数据服务，基于计算及存储基 座，提供标准统一、可连接萃取的数据中台，包含数据采集与研发、数据连接与萃取、数据资产管理及 统一数据服务，服务于上层业务，如经营分析、消费者营销洞察等场景
在实际数据开发应用中存在，不知数据在什么地方，数据是什么意思，拿到一个报表怎么开发，数 据怎么获取，最后数据怎么能快速的可视化呈现出来这五个难题，我们建设这个数据中台就是要解决： 找数据，理解数据、问题评估、取数及可视化展现这五个问题，整个平台的故事也是围绕这个五个点， 从根本上解决：

找数：数据从什么地方来到什么地方去，将数据和业务过程结合起来，实现数据的快速查询
理解数据：通过数据的血缘关系，数据关联关系及数据的说明信息，让数据开发人员，业务人员快速理 解数据。
问题评估：数据分析人员拿到需求，可以通过该平台实现问题的自动评估，大大提高数据分析效率。
取数：用户可以不再关心数据的来源，不再担心数据的一致性，不再依赖RD的排期开发。通过所选即所 得的方式，满足了用户对业务核心指标的二次加工、报表和取数诉求。
数据可视化：依托于我们的BI可视化系统和数据中台的打通，数据分析人员可以快速的将数据中台创建 的数据模型快速的转换成可视化报表。

3.数据中台建设内容

1.数据规范统一：采用维度事实建模理论进行严格的，规范化、标准化的定义，保障数据质量，避免 数据指标的二义性。

# 2.一站式研发体验：从数据接入、建模、研发、运维、数据查找及探查等过程提供高效一站式统一的 研发立案率。

3.系统化构建数据体系：以标准的技术框架，系统地构建规范可读的业务化数据体系，形成数据资 产，方便业务查找及应用。

4.可视化数据资产：系统化构建业务数据资产大图，还原业务系统，提取业务知识，快速提取业务关 键环节及业务。

5.数据使用简单可依赖：定义及服务，研发构建的业务主题式数据逻辑表可被直接，快速查询及访 问，简化查询代码。

3.1数据中台架构

3.1.1数据中台系统架构

3.1.2数据中台技术架构

架构说明：

1.数仓整体以Doris为核心构建公司企业级数据仓库，（后期会根据实际需要还可能会引进Hive、ClickHouse等其他组件）

2.通过统一的数据采集系统，多种数据采集手段，包括Mysql binlog解析（CDC，StreamSet， Cannal等），日志采集Flume、埋点接口等实现多种异构数据的采集

3.将采集的数据统一通过消息队列（Kafka）完成高并发的数据吞吐，同时实现数仓及计算引擎的解耦

4.Spark/Flink计算引擎完成数据的ETL处理及实时数据的统计，并将数据推送到Kafka，

5.有Doris的入库程序完成Kafka数据的入库

6.对外通过doris和消息队列对外提供数据服务

7.数据质量管理是实现对从数据采集到数据ETL处理，数据存储及数据服务全生命周期的数据管理， 包括元数据，数据质量，数据规范、数据安全。

3.1.3系统架构数据管理及数据流向

3.1.4数据中台功能整体规划

3.2数据资产管理

3.2.1资源管理

实现集中对各种数据资源的管理，包括数据库，消息队列等
实现数据库数据源管理：属性包括：所属业务名称，业务技术负责人，数据源IP，端口、数据库名称， 用户名、密码，数据库类型（Mysql、oracle、SQLServer、Doris等），创建时间，创建人
实现Kafka数据源管理：属性包括：Kafka集群名称，Kafka Broker Server地址（示例： 172.22.197.134:9028），对应zookeeper地址（示例： 172.22.197.134:9029）,创建时间，创建人，集群负责人

3.2.2元数据管理

3.2.2.1技术元数据

3.2.2.1.1元数据管理系统架构

3.2.2.1.2元数据管理功能

1.业务数据元数据同步采集
实现对业务数据库数据表的元数据自动采集同步，包括建表语句中的中文备注信息，并将中文备注信 息填写到对应的中文字段名称中，界面提供元数据修改功能，主要修改是添加业务技术负责人、修改表 的中文名称、备注说明等信息，表的字段名称，类型、长度等信息不允许修改
2.数据仓表元数据采集
实现对数仓数据库数据表的元数据自动采集同步，包括建表语句中的中文备注信息，并将中文备注信 息填写到对应的中文字段名称中，界面提供元数据修改功能，主要修改是添加数仓表对应技术负责人、 修改表的中文名称、备注说明等信息，表的字段名称，类型、长度等信息不允许修改
3.元数据版本管理
因为数据库表存在结构变更，这里需要提供元数据多的历史版本管理，可以查询元数据历史版本信息
4.业务元数据变更管理及预警
对业务元数据的变更（主要是Mysql数据库），通过flink监控binlog的schema变更时间，一旦发现及时发送消息通知，后端监控变更消息队列，取到变更信息，发出元数据变更预警，并自动修改相应的元数据，生成版本信息。
5.元模型构建
分为以物理表为核心的基础元模型构建，以及以血缘为中心的血缘元模型。
基础元模型构建以物理表为中心，打通其与技术元数据（主题、业务过程、Schema）的关系，实现了物理表的清晰归属，打通其与生产元数据的关系，要加上物理表查询热度、资源消耗、查询密级等生产使用信息，打通其与指标、维度和应用的对应关系，为上层的取数应用建立了完备的元数据。
血缘元模型以血缘为中心，通过监控Doris审计日志，通过sql解析完成自动的血缘关系构建，不仅要构建从上游业务表到仓库表的物理血缘，而且要打通仓库表到下游对应报表的血缘，为后续的影响评估构建了完备的元数据基础
6.虚拟库及表的管理
对于通过API接口方式对接的数据，要通过页面手动添加库，添加表及表字段类型，字段名称，字段中文名称，字段长度等等，这样的目的是为了统一元数据管理方式

3.2.2.2业务元数据

3.2.2.2.1数据域主题管理

1.数据仓库是面向主题（数据综合、归类并进行分析利用的抽象）的应用。数据仓库模型设计除横向的分层外，通常也需要根据业务情况进行纵向划分数据域。数据域是联系较为紧密的数据主题的集合，是业务对象高度概括的概念层次归类，目的是便于数据的管理和应用。
2.数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。为保障整个体系的生命力，数据域需要抽象提炼，并长期维护更新。在划分数据域时，既能涵盖当前所有的业务需求，又能让新业务在进入时可以被包含进已有的数据域或扩展新的数据域。数据域的划分工作可以在业务调研之后 进行，需要分析各个业务模块中有哪些业务活动。
3.数据域可以按照用户企业的部门划分，也可以按照业务过程或者业务板块中的功能模块进行划分
数据域的管理本质是一个分类管理，暂定二级分类
数据域主题作用于数仓内部数据表的管理及数据指标的分类管理

3.2.2.2.2数据维度管理

建立统一的维度管理系统，实现对维度信息的统一管控，并为公司的数据产品提供统一的维度数据服务，包含维度开发管理，维度信息管理及维度数据服务三个方面。
维度管理：基于数据维度管理规范，对维度新增、修改、发布等生命周期进行统一管理。
**维度服务：**基于数据仓库ODS层模型源数据，建立服务化的维度表模型，在模型基础上建立维度，包括系统维度和手工维度定义，支持离线和实时大数据量的维度查询服务，维度创建完成后为各数据产品提供高可用，高性能的数据服务
1，选择业务过程
根据业务场景以及可用数据源
2，声明粒度
根据事实表及应用场景，确定汇总粒度，一般尽可能的用最细粒度
3，确定维度
根据确定的粒度，定义对应的维度，最细粒度，也是最低层次的维度
4，确定事实
确认将哪些事实放到事实表中，维度表只是做关联，不做维度数据的查询服务。
维度定义：
维度按集团产业进行指标一级业务域划分，包括：智能工厂、供应商、采购、销售、门店、仓储、运 输、POS等；在各业务域下，对维度进行主题分类，主要有：时间类（DT）、组织类（OG）、产品
（PD）、销售平台（SP）、经营方式（BM）、终端™、业务渠道(BC)、营销(MK)、会员(MB)、采购 模式(PM)、地点(AD)等。
维度管理：
维度：维度平台要支持快速定义维度,通过设置维度的基本信息，选择维度映射的维度表，做好维度与维度表的映射，设定维度的一些特性（布尔维度，时间维度，杂项维度等），检测维度的定义结果。达到了让业务人员能够只是通过页面操作就可以制定需要的维度。
维度表：数据开发人员可以通过维度库平台定义维度表，定义好之后可以集成数据仓库的同步任务一键将仓库的数据同步到维度表中，将维度表与维度做映射关系。
维度层级：维度库平台支持定义维度层级，只要是维度库平台上有的维度表并且做好维度与维度的映射关系之后，就可以定义需要的维度层级，根据维度层级提供维度值的上卷下钻查询服务。
维度血缘：提供了维度，指标，报表的血缘关系，以及还准备做的维度数据的血缘，维度，指标，报表 调用次数的血缘等等。

3.2.3数据地图

数据地图提供数据检索能力，致力于提供XX公司生态内丰富数据源的检索服务。完成找数据的过程，通过该平台，用户可以以较小成本找到所需数据，无论是业务数据、数仓数据库表或字段、数据指标，数据服务都可以通过该功能完成检索，对业务及数据开发使用人员能很快的找到需要的资源，并根据搜索的结果展示了解数据。

1.找表
通过统一的查询页面，通过输入关键字完成数据表的检索
在检索的结果页面找到符合自己的数据，进去查看表的详情页信息，详情页展示内容包括：

2.找维度
通过统一的维度检索页面，通过输入关键字检索字段信息，点击字段列表数据，可以查看该字段的信息

3.找指标
通过统一的指标检索页面，通过输入关键字检索指标信息，点击指标列表数据，可以查看该指标的信息
显示指标的基本信息
指标的生产链路
指标技术逻辑
指标字段信息(按维度和指标分开)
指标数据预览
指标使用说明
指标评论

4.找服务
通过统一的服务检索页面，通过输入关键字检索服务信息，点击服务列表数据，可以查看该服务的信息
数据服务接口基本信息数据接口参数及响应说明数据接口使用说明
接口权限

5.找报表

3.2.4数据生命周期管理

主要是为了完成数据从产生、采集、处理、存储、加工、使用及归档销毁的全生命周期的各个阶段的管理
主要是通过数据接入，数据ETL、数据地图、元数据、数据指标各个系统在使用过程中的使用日志数据，对数据进行一个全面的采集及分析，生成数据在各个阶段的数据指标。
生命周期管理关注以下内容：
1.数据归档管理：对符合归档的数据进行归档到冷存储上，减少存储及计算成本
2.统计在数据每个阶段的数据变化趋势
3.业务库DDL变更趋势
4.数据热度排名：数据库，数据表的使用热度统计
5.数据库数据量排名，
6.库内数据表数据排名
根据数据的使用情况或者根据 用户设定的数据生命周期，及时帮用户销毁数据

1. 在大数据研发中大部分用户关注的是数据怎么进入数据仓库，但是很少有用户会关注数据的销毁。随着时间持续性发展之后数据会无限量增加，数据仓库慢慢的成为一个很大的成本负担。数据生命周期管理，关注于数据整个链路的生命周期管理，及时推荐无效数据下线。 在数据下线的过程中， 很多用户会担心数据误删，完备的数据下线机制，在有效期限内可以对数据进行恢复，确保数据误删的情况。

3.2.5数据资产

数仓界的360，可以定量评估数据资产的成本，价值，质量。帮助企业优化存储成本，节约计算资源。精细化的数据生命周期管理，帮助企业更好的管理数据的生产到销毁的整个生命周期。
资源视图
数据库统计
表统计
表引用统计
数据在各个生命周期阶段的资源使用情况
文件数量: 总文件数，累计存储量，当月优化存储量
job统计
优化建议等
足迹

3.2.6数据问答

我们为数据地图中的找表，找维度，找指标，找服务，找报表都提供了数据问答功能，通过评论问 答功能，帮助用户可以快速得到问题反馈：如果用户看了信息后还是感到有问题，提供评论问答的功能，用户通过这个功能可以进行提问，会有相应的负责人进行回复。对于重复问反复问的问题，用户通 过查看其它人的提问和回复就能找到答案。并且负责人还会定期的将问答信息沉淀到对应的元数据里， 不断地对元数据进行补充和完善。

3.3数据接入管理

在开发数据模型时，我们必须有一个统一的平台，能够像流水线一样，把数据一步步加工成数据模型。这其中涉及到数据萃取、数据聚合、作业调度等。
主要是为了实现业务数据的快速接入，零代码实现，数据分析人员只需要通过UI进行简单的配置、 提交任务即可完成数据的接入，并能实现对数据接入任务的管理及监控。

3.3.1 Mysql数据源数据接入

主要是为了完成针对Mysql数据的业务系统数据接入零代码实现，不需要开发人员接入，提供给数据分析人员使用，目的是为了业务数据快速接入，无需编码
1.通过UI界面添加数据接入任务的方式
2.Mysql数据的采集是通过Canal 采集binlog完成
3.在界面上第一步是配置canal实例（canal实例的管理是通过cannal admin），除了kafka topic名称需要手工输入，其他信息尽可能不要让使用人员手工数据
4.第二步配置Flink Job任务信息，需要的kafka topic名称来源于上一步，业务表和数仓表的对应关系通过元数据选择方式完成，避免手工输入
5.第三步：提交任务，这时候完成canal实例创建，运行，Flink job任务提交运行
6.并在列表上监控canal实例及Flink job运行状态的监控

3.3.2 DataX 数据接入

要实现的内容基本和Mysql binlog的同步一样只不过是Datax是为了实现非mysql数据的数据接入零代码完成

3.3.3数据API方式数据接入

传统数据API方式的数据接入都需要进行代码开发对接才能完成，初步设想这块通过通用的代码生成器的方式实现针对常用API方式（WebService,RestFul API）零代码接入

3.3.4数据开发控制台

1.提供一个数据类似于HUE的SQL数据开发控制台，数据开发人员可以通过这个控制台进行sql的开发调试
2.生产环境这里delete，drop等操作要进行审批确认，才能进行，避免误操作，删除数据
3.可以将调试好的sql，添加到定时任务调度系统中

3.4数据质量管理

围绕完整性、准确性、一致性、及时性监控分析数据质量问题、提升企业数据质量。 从数据接入、数据加工、数据导出、指标、数据应用实现全链路血缘跟踪、提前预判数据是否能够准时产出、了解任务失败后影响分析以及快速地修复。做到事前控制，事中处理，事后追踪。
事前（规则丰富多样）：
1.定义数据监控规则
2.模板规则（字段规则，单表规则，多表规则）
3.自定规则（SQL），暂不实现
事中（数据流程监控）：
1.监控和控制数据生成过程
2.稽核规则和ETL无缝对接
3.定时检查
4.数据清洗
事后（数据质量溯源）：
1.邮件钉钉等及时预警
2.问题追踪处理、故障review
3.稽核报告查询
4.表打分及历史趋势查询

3.4.1数据质量规则管理

数据质量关键流程步骤：
1.质量需求：发现数据问题；信息提报、收集需求；检核规则的需求等。
2.提炼规则：梳理规则指标、确定有效指标、检核指标准确度和衡量标准。
3.规则库构建：检核对象配置、调度配置、规则配置、检核范围确认、检核标准确定等。
4.执行检核：调度配置、调度执行、检核代码。
5.问题检核：检核问题展示、分类、质量分析、质量严重等级分类等。
6.分析报告：数据质量报告、质量问题趋势分析，影响度分析，解决方案达成共识。
7.落实处理：方案落实执行、跟踪管理、解决方案Review及标准化提炼。
8.知识库体系形成：知识经验总结、标准方案沉淀、知识库体系建设。
9.可以对指定好的规则进行单次执行试运行，以调试规则的正确性
数据质量检验标准：
**完整性：**主要包括实体缺失、属性缺失、记录缺失和字段值缺失四个方面；
**准确性：**一个数据值与设定为准确的值之间的一致程度，或与可接受程度之间的差异； 合理性：主要包括格式、类型、值域和业务规则的合理有效；
**一致性：**系统之间的数据差异和相互矛盾的一致性，业务指标统一定义，数据逻辑加工结果一致性；
**及时性：**数据仓库ETL、应用展现的及时和快速性，Jobs运行耗时、运行质量、依赖运行及时性。
第一阶段要完成的工作：
首先完成业务数据库的数据接入数据质量，从源头上保障接入数据的质量问题。
1.根据业务实际情况，抽象定义各个业务的质量规则库，可以按照业务主题管理
2.定义通用的数据处理规则模板，比如：日期格式，是否是数字，字符串长度是否超长等
3.通过接入的业务元数据，对表和字段进行数据规则定义，通用规则可以从规则库进行选择
4.通过统一的规则处理引擎SDK，嵌入到Flink 实时流处理引擎中对数据进行规则判断
5.符合规则的数据入数仓，不符合规则的数据，推送到异常数据队列（异常数据，来知道来源，异常 类型，时间，严重等级等）
6.在异常数据UI界面展示异常数据，并可以对异常数据进行手动处理，重新推送到数仓（kafka-flink job处理）
7.数据质量看板
8.每日数据质量报告生成

3.4.2 数据质量管理流程

3.4.3数据质量看板

提供统一的数据质量看板，快速了解每天数据质量问题及趋势。并能及时进行追踪处理。

3.5数据指标管理

指标管理模块核心包括基础信息和技术信息管理，衍生信息包括关联指标、关联应用管理。基础信 息对应的就是指标的业务信息，由业务人员填写，主要包括指标名称、业务分类、统计频率、精度、单 位、指标类型、指标定义、计算逻辑、分析方法、影响因素、分析维度等信息；基础信息中还有一个比 较重要的部分是监控配置，主要是配置指标的有效波动范围区间、同环比波动区间等，监控指标数据的 正常运行。
技术信息构成比较复杂，包括数据类型、指标代码，但是核心部分是指标与模型的绑定关系，通过 使用演进形成了当前系统两类绑定关系：绑定物理模型和构建虚拟模型。绑定物理模型是指标与模型管 理中的物理模型字段绑定，并配置对应的计算公式，或还包含一些额外的高级配置，如二次计算、模型 过滤条件等；创建虚拟模型是通过已有指标和其对应的物理模型，具体步骤首先配置已有指标的计算方式或指标维度的过滤，然后选择指标已绑定的物理模型，形成一个虚拟模型，虚拟模型的分析维度就是 所选指标基础模型的公共维度。
衍生信息中的关联指标、关联应用管理，是为了方便观察指标被那些其他指标和数据应用使用，这是因为指标技术信息采用了严格权限控制，一旦被使用为了保证线上的运行安全是禁止变更的，只有解 绑并审核通过后才可以编辑，所以这些衍生信息就是方便管理人员使用

3.5.1指标管理常见问题

1.相同指标名称，口径不一致
2.相同口径，指标名称不一致
3.不同限定词，描述相同事实过程的指标，相同事实部分口径不一致
4.指标口径描述不一致
5.指标命名难以理解
6.指标数据来源及计算逻辑描述不清楚

指标系统数据开发，是指标的统一入口，通过定义原子、派生和复合指标，明确指标业务口径和技术口径，解决指标定义不一致、口径不一致和数据来源不一致的问题，实现规范定义，助力数据模型规范设计。
1.指标按业务过程划分主题管理（最多支持两级）
2.指标定义（原子指标、派生指标，符合指标）
3.指标修饰词管理
4.指标查看：查看指标定义，指标数据生产链路、指标关联数据表，指标使用（后续支持单个指标接口无代码访问）

3.5.2 指标主题域管理

指标主题域的构建是根据业务过程来创建，和数仓主题域管理感念一致，统一采用一套叫数据主题 域，没有指标主题域这个概念，指标是挂在某个数据主题域下。

3.5.3 指标修饰词管理

修饰词是统计维度以外指标的业务场景限定抽象，修饰词属于一种修饰类型，如在日志域的访问终 端类型下，有修饰词APP、PC端等
提供统一的指标修饰词管理维护。

3.5.4 指标管理

包括基础信息、技术信息和衍生信息，由不同角色进行维护管理。

基础信息对应指标的业务信息，由业务管理人员、数据产品或BI分析师维护，主要包括归属信息(业务板块、数据域、业务过程)，基本信息(指标名称、指标英文名称、指标定义、统计算法说明、指标类型(去重、非去重))，业务场景信息(分析维度，场景描述)；

技术信息对应指标的物理模型信息，由数据研发进行维护，主要包括对应物理表及字段信息；

衍生信息对应关联派生或衍生指标信息、关联数据应用和业务场景信息，便于用户查询指标被哪些 其它指标和数据应用使用，提供指标血缘分析追查数据来源的能力。

原子指标定义归属信息 + 基本信息 + 业务场景信息派生指标定义时间周期 + 修饰词集合 + 原子指标
修饰类型主要包含类型说明、统计算法说明、数据源(可选)

3.5.5 指标体系图谱模型

实例：

3.5.6 数据指标建模流程

在数据指标体系搭建项目启动前，需要与各业务方详细了解具体业务、梳理清楚关键业务流程。需求采集可分为定量、定性采集两种类型。
根据对业务需求、各个模块的业务流程进行分析，进行数据域的划分。数据域划分按照业务过程或 者业务板块的功能模块划分。依据实际业务过程进行归纳、抽象得出数据域。
梳理了业务域、数据域、业务过程的整体框架之后，开始针对指标规范进行设计，完成总线矩阵设计。把行为不同的业务处理过程，即事实，在交叉点上打上标记表示该业务处理过程与该维度相关这个矩阵，称为总线矩阵总线架构和一致性维度、一致性事实共同组成了Kimball的多维体系结构的基础。

3.5.7 数据指标开发评审流程

3.5.8 指标生产及加工

提供可视化的数据指标生产加工管理工具，并可以监控指标生产的过程，将指标的生产无缝的和任务调 度系统进行融合，为数据指标的数据质量提供质量保证。

3.6 数据服务管理

数据服务标准：数据结构标准化、在线查询实时化、数据开发可视化。数据结构标准化针对数据交互，我们需要提供统一的接口视图，可进行数据的查询、权限管控。在线查询实时化针对各业务的调用，我们需要提供指标级数据口径统一的实时数据结果。数据开发可视化提供数据接口的可视化统一管理页面，开发人员通过通过可视化管理API，降低接口理解的难度，易于维护。

3.6.1 数据服务化

数据服务提供快速将数据表生成数据 API 的能力，通过应用授权，供外部应用系统调用 API 获取数据，且对 API 进行统一管理和发布，支持一键创建数据抽取任务。
1.提供向导模式和 SQL 模式，可以通过简单的配置即实现取数 API 的自动构建，屏蔽底层数据源细节，提高数据中台的整体效率
2.提供应用、表和 API 的关系链路，降低运维成本，解耦应用与底层表，提供统一的认证、权限和监控，确保数据应用质量。
3.提供接口开发，调式、参数定义，返回结果说明等开发IDE

3.6.2 数据服务看板

具备 API 使用的监控统计能力，可查看调用次数、调用延时等信息，提供 API 库表和应用的关系查询可以按照业务主题进行分组，可以给数据服务设置数据安全等级，对于安全等级较高的服务进行数据访问限流，及审计数据应用开发通过API配置功能统一创建和发布的API，可以在服务概览页面查看API的调用详情，包括查看不同时间维度下的调用API数量、次数和成功的次数，且能够清晰的查看调用API的Top5和服务调用比例，同时，概览页面提供调用和未调用API列表，若API长时间未被调用或一直未被调用，可考虑下线或者删除。

3.6.3 数据服务权限管理

提供统一的认证、权限和监控，确保数据应用质量及数据安全

3.7数据安全

数据安全有对立的两方面的含义：一是数据本身的安全，主要是指采用现代密码算法对数据进行主动保护，如数据保密、数据完整性、双向强身份认证等，二是数据防护的安全，主要是采用现代信息存储手段对数据进行主动防护，如通过磁盘阵列、数据备份、异地容灾等手段保证数据的安全，数据安全是一种主动的包含措施，数据本身的安全必须基于可靠的加密算法与安全体系，主要是有对称算法与公开密钥密码体系两种，数据处理的安全是指如何有效的防止数据在录入、处理、统计或打印中由于硬件故障、断电、死机、人为的误操作、程序缺陷、病毒或黑客等造成的数据库损坏或数据丢失现象，某些敏感或保密的数据可能不具备资格的人员或操作员阅读，而造成数据泄密等后果。而数据存储的安全是指数据库在系统运行之外的可读性。一旦数据库被盗，即使没有原来的系统程序，照样可以另外编写程序对盗取的数据库进行查看或修改。从这个角度说，不加密的数据库是不安全的，容易造成商业泄密，所以便衍生出数据防泄密这一概念，这就涉及了计算机网络通信的保密、安全及软件保护等问题。

我们在设计数据中台同时在数据安全上主要集中在以下几个方面：
1.数据不会丢失（数据备份、数据恢复）

2.数据脱敏：对敏感数据对外提供服务的时候要进行脱敏处理

3.数据加解密：对高度敏感数据为了防止被直接从库表访问或者拖库问题，要对敏感数据在存储的时 候就要进行加密处理，使用的时候进行解密，比如：客户名称，手机号、身份证号码、营业执照等

4.敏感数据使用账号及授权情况分析

5.用户对使用数据的日常审计

6.数据水印技术：数据水印技术是为了保持对分发后的数据的追踪，在数据泄露行为发生后，对造成数据泄露的源头可进行回溯。在分发数据中掺杂不影响运算结果的水印数据，水印中记录分发信息，当拿到泄密数据的样本，可追溯数据泄露源

7.数据日常稽核：日常数据巡检（表名规范，数据规范、数据量、数据表数量、接口数量、使用情况）

8.数据隔离
在所有数据中要添加数据所属（企业ID，部门编号等）信息
根据数据访问人员所属组织，判定改人员是否有访问改数据的权限
具体这个数据服务接口，或者嵌入到业务系统的报表访问权限，交给GAIA平台的资源授权统一管控，这块我们不做管控，我们只做到数据隔离就行，保证A企业的人不能访问B企业的数据
可以管控到列级别，可以给不同角色授权可以看到的表中哪些列，主要是为了保护敏感数据的 访问，比如手机号，身份证，企业营业执照，企业经营的相关数据等

9.异常行为分析：
一段时间内重复查询数十次至几百次
一个号码一天内被查询10次以上或者一个月被查询数百次单次超大量查询，每次查询数据量超十万以上
长时间不使用的账号，登录一下查询敏感信息
同一账号被不同人员使用，同时登录或者在不同地方IP登录执行数据删除或修改操作

3.8 数据填报

3.8.1 数据导出

提供针对需要导出数据的场景，通过模板方式快速从数仓中快速完成数据导出工作，并记录数据导出的 详细信息
3.8.2自助取数
提供可视化的UI界面，让用户能根据自己需要（可以选择数据聚合方式），数据获取方式（API、消息队列、数据库等），完成数据获取

3.8.3 数据自助填报

用户可以在界面上自己设计表单，后台自动完成数据库表的创建，用户可以通过设计的表单自助完成数据填报，避免各种手动导入数据的场景都需要开发相应的程序，节省时间周期提高工作效率

3.8 数据仓管理

3.8.1 数仓分层模型

数仓分层模型的好处：
1、数据结构化更清晰：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解。
2、数据血缘追踪：提供给外界使用的是一张业务表，但是这张业务表可能来源很多张表。如果有一张来源表出问题了，我们可以快速准确的定位到问题，并清楚每张表的作用范围。
3、增强数据复用能力：减少重复开发，通过数据分层规范化，开发一些通用的中间层数据，能够减少重复计算，提高单张业务表的使用率，提升系统的执行效率。
4、简化复杂的问题：把一个复杂的业务分成多个步骤实现，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
5、减少业务的影响：业务可能会经常变化，这样做就不必改一次业务就需要重新接入数据。
6、统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径

3.8.2 数仓主题域管理

数仓主题域管理实现数据业务线和数仓主题域管理，实现不同数据域的管理以及数据域下的数据主题管理。

3.8.2 数仓看板

主要是为了提供一个全面的数仓数据总览视图，从存储、数据库、数据表、业务域等角度全方位了解数仓数据情况，同时提供技术视角的数仓表健康总览视图
1.从存储角度：每个业务数据库所占存储空间、表数量
2.从技术角度全面了解数仓中的数据量，副本数，tablet数量等对于数据仓库的成本，价值，质量，标准缺乏一套标准的评估体系，很难回答目前的成本分布，以及价值体现。资产360评估功能，对存储资源，计算资源，数据质量，数仓标准等进行定量的全方位评估。帮助管理者回答资产分布情况以及资产的价值体现。

3.8.3 数仓任务管理及资源监控

管理和监控数据部分Routine load任务的，包括可视化创建routine load任务，启动，暂停，恢复、停止等操作实现对doris数仓statistic资源的监控，包括数据库名称、数据库表数量，副本数量，分区数量，tablet数量，不健康tablet数量，克隆中的表数量，teblet不一致的数量，

3.8.4 数仓用户及权限管理

主要是管理数仓用户，角色，权限
实现对数仓用户的添加、删除、修改密码，授权，撤销权限对角色的添加、删除，修改，授权、撤销权限等
实现对数据用户，角色权限的精细化管理

3.8.5 数仓资源管理

1.管理Spark资源（主要是用于数据ETL，数据迁移）
2.ODBC资源：查询和导入外部表的数据

3.8.6 数仓备份及恢复

改功能主要是提供集群数据的备份及恢复功能
1.数据备份是增量备份，定时执行
2.可以对选定表，或者选定表的指定分区数据进行备份到HDFS，
3.选定备份进行还原操作，

3.8.7 数仓表管理

1.表的分区管理
2.表配额管理
3.表副本管理
4.表数据量展示
5.表tablet管理

3.8.8 数仓数据库管理

1.数据库数据统计展示
2.数据库副本管理
3.数据库配额管理

3.9 运维监控

3.9.1 Doris 集群监控

主要是监控Doris数仓组件运行状态
1.管理节点FE运行状态
2.数据节点BE运行状态
3.Doris FE 状态一致性检查，出现不一致的情况及时预警

3.9.2 Kafka 集群监控

监控内容：
1.kafka集群监控：各节点运行状态，集群Topic、Broker等多维度历史与实时关键指标查看
2.Kafka topic列表
3.kafka topic数据查看
4.Topic 运维：包括创建、查询、扩容、修改属性、下线等
5.指标监控：基于Topic生产消费各环节耗时统计，监控不同分位数性能指标
6.消费组运维：支持将消费偏移重置至指定时间或指定位置

3.9.3 Canal监控

1.Canal集群管理
2.Canal服务管理及状态监控
3.Canal 示例管理及监控
3.9.4DataX 监控
主要监控DataX任务调度执行情况，执行状态及查看任务执行日志信息。

3.9.5 Flink 作业监控

主要是监控所有Flink Job任务运行情况，提供一个统一监控管理入口

3.10数据应用-标签工厂

数据标签化，标签业务化，消除数据与业务之间的鸿沟，真正实现零门槛应用，帮助企业实现增长 标签工厂是一个多对象标签管理与应用平台，通过规范化标签体系建设，帮助客户构建标签知识管理和共享机制；同时通过标签圈选、群组创建和投放策略等配置，帮助客户更好的进行精准营销，助力企业实现增长。

1.异构数据汇聚：通过标签体系实现跨存储类型的数据源整合，降低数据同步运维成本

2.标签知识管理：零脚本积累多对象的标签资产，将标签开发与应用解耦，提升使用效率

3.便捷策略制定：通过多维标签圈选和交并集自助配置，快速构建群组并可查看其画像特征

4.多渠道数据触达：无缝衔接业务系统，通过投放策略配置快速实现标签和群组数据交换

5.标签全生命周期管理：支持标签创建、数据源配置、枚举值配置、标签发布与下架等全生命周期的管理

6.对象和标签体系管理：支持不同实体对象的创建和各自标签体系的建设，统一管理和积累企业标签资产

7.异构数据源接入及同步：提供多种数据源和数据集的接入，实现对异构数据源数据的自动同步

8.灵活标签圈选：通过标签圈选和交并集可视化规则设置，快速构建群组

9.自助式业务标签生产和维护：业务人员可根据运营需要灵活配置个性化业务标签，即用即配

10.群组洞察及投放：提供群组画像分析能力，并可对群组进行编辑、下载、更新和投放等操作

有帮助到老铁的可以点击关注哦，好内容持续更新中！！！