万字讲述如何通过Doris构建数据中台

目录

• 基于Apache doris怎么构建数据中台(一)-什么是数据中台

• 基于Apache doris怎么构建数据中台(二)-数据中台建设内容

• 基于Apache doris怎么构建数据中台(三)-数据资产管理

基于Apache doris怎么构建数据中台(一)-什么是数据中台

这是数据中台系列的第一篇文章，主要阐述数据中台概念，从技术和业务视觉看数据中台及数据中台要解决的问题

1.什么是数据中台

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

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

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

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

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

2.数据中台解决什么问题

1、效率问题：为什么应用开发增加一个报表，就要十几天时间？为什么不能实时获得用户推荐清单？当业务人员对数据产生一点疑问的时候，需要花费很长的时间，结果发现是数据源的数据变了，最终影响上线时间。

2、协作问题：当业务应用开发的时候，虽然和别的项目需求大致差不多，但因为是别的项目组维护的，所以数据还是要自己再开发一遍。

3、能力问题：数据的处理和维护是一个相对独立的技术，需要相当专业的人来完成，但是很多时候，我们有一大把的应用开发人员，而数据开发人员很少。

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

1、数据中台是企业级的逻辑概念，体现企业 D2V（Data to Value）的能力，为业务提供服务的主要方式是数据 API；

2、数据仓库是一个相对具体的功能概念，是存储和管理一个或多个主题数据的集合，为业务提供服务的方式主要是分析报表；

3、数据平台是在大数据基础上出现的融合了结构化和非结构化数据的数据基础平台，为业务提供服务的方式主要是直接提供数据集；

4、数据中台距离业务更近，为业务提供速度更快的服务；

5、数据仓库是为了支持管理决策分析，而数据中台则是将数据服务化之后提供给业务系统，不仅限于分析型场景，也适用于交易型场景；

6、数据中台可以建立在数据仓库和数据平台之上，是加速企业从数据到业务价值的过程的中间层。

4.技术视觉的数据中台

数据从生产到应用的整体流程是任何一个数据从业者都绕不开的主题，即便是非数据领域的产品和运营同学，同样也应该对业务中数据的流向有个初步的认识。要展开描述，我们必须从数据的技术视角思考两个问题：

• 需要解决的问题是什么？

• 如何保证数据流中不同阶段的最优解？

4.1. 需要解决的问题是什么？

• 1、数据供给：提供便捷的数据生产方案，以数据产生为起点，规范数据整个主体的供给，为夯实数据平台的基础提供保障；

• 2、数据产出：保证数据在产出层面的普遍适用性。该阶段包括分析报表，自动化分析工具，查询入口等的建设；

• 3、过程管理：保证数据的完整性、准确性、时效性，实现数据从产生到应用全流程的高效管理。

4.2. 数据流的不同阶段如何解决

不同企业所处的业务发展阶段不同，所面对的问题会不一样。同样，业务本身特性及企业对数据建设的资源倾斜程度不同，也会直接影响数据全流程处理的差异。最重要的还是立足于现状，站在更高的战略视角去思考整体的解决方案。下面从技术视角来看我们数据中台做什么：

4.2.1 数据产生

数据产生，这个阶段是最适合向业务方宣灌数据生产应用流程的阶段，因为该阶段的优劣将会直接影响之后的各环节。该阶段的关键字是数据规范录入，需要给数据上游的业务方提供可行的数据埋点规范。

4.2.2 数据采集

数据采集：这是最被动的一个环节，也是最出力不讨好的环节，最容易被甩锅和背锅的环节，

数据部门会提供给业务方不同场景下的模块日志采集方案清单，业务方只需按照现有清单选择模块上报，数据部门会自动收集；

数据部门会提供模块日志注册系统，形成良性注册机制，让数据部门提前感知，自动化收集模块数据。

4.2.3 数据处理

数据处理、清洗是数据输入到仓库的前置阶段，该阶段最主要的是规则，目的是建立符合业务需要的数据清洗方案。比如什么格式的数据该被过滤；哪些用户是要被过滤掉等。

4.2.4 数据仓库

数据仓库面向应用而生，为了保证数据的普遍适用性及拓展性，会对仓库进行分层，通常分为：ODS、DW、DWS、ADS。常见数据仓库模型为“星型模型”，我们在进行维度建模的时候会建一张事实表，这个事实表就是星型模型的中心，然后会有一堆维度表，这些维度表就是向外发散的星星。

4.2.5 数据计算

数据计算是数据变活的过程，主要分为离线和实时计算。会按照不同业务单元的需要，设计数据指标，并按照不同场景中的业务逻辑确定统计规则，最终由系统实现例行计算。

4.2.6 数据应用

数据的应用是数据最终产生价值的部分，基于数据流前面的流程处理，该环节最终会提供给应用方业务报表、数据访问、自动化工具、统计模型等应用；

在数据应用方面我们应当关注的问题：

1. 1、是否能提供完善的业务分析指标体系

2. 2、是否能提供完善的精细化运营工具；

3. 3、现有数据是否足够支撑业务分析，是否能依据现有数据发现更多的业务问题

4. 4、是否能洞察潜在的商业机会

4.2.7元数据管理

元数据管理贯穿整个数据流程始终，是一个较为宽泛的概念，元数据治理的好坏将直接决定了整个数据平台的品质。元数据管理主要分为两部分：技术元数据、业务元数据

5业务视觉的数据中台

基于立场的不同，导致了从业务视角与从技术视角看到的表现层内容会不一样，但究其本质是相通的。无论数据在应用层面以何种方案最终呈现，最终都是为了解决问题而存在,

1. 1、为什么需要数据团队解决？

2. 2、需要解决的问题是什么？

3. 3、该通过什么方式解决？

5.1 为什么需要数据团队解决？

业务技术团队的定位是服务于业务一线，数据团队的定位是提供专业性的数据解决方案，二者分工上的差异性决定了解决问题的最佳路径。如下列举了需要数据团队解决几类问题：

1. 数据类型：数据产生场景复杂、数据类型多（订单、客户、商品，仓储，物流等），数据结构复杂（结构化/非结构化/半结构化数据）；

2. 数据量级：存储量级大，传统关系型数据库不能解决；

3. 数据处理：清洗规则多，计算任务流程长，计算血缘关系复杂等；

4. 数据应用：行为分析，多维交叉分析，实时多维分析，丰富的可视化等。

5.2需要解决的问题是什么？

（1）业务是什么

不同业务单元依据自身业务属性，需要数据团队解决的数据问题也不一样。如市场团队关注应用市场投放相关的数据，客户端团队关注设备/应用版本/用户转化相关的属性数据，运营团队关注活动相关数据，风控团队关注风控相关数据等。

（2）如何衡量它们

团队属性的不同，也决定了量化到数据指标的衡量标注不同。各业务团队拥有自己的关键唯一指标和对应拆解/下钻的指标体系。

（3）如何让数据驱动业务

市场团队通过衡量不同渠道来源用户的质量，评估渠道ROI，优化投放策略；客户端团队通过观察不同产品方案的转化效果，改进注册及其他核心行为发生的主流程设计；运营团队通过用户细分，评估不同用户群在活动对的转化效果，进行精细化运营等。

5.3 通过什么方式解决？

以下从业务视角来看数据中台产品解决方案：

实时监控

专注于关键核心指标的实时表现，如客户、商品、订单，仓储，运输等。视具体情况会将关键指标维度下钻后进行实时监控

离线分析

核心看板：核心看板着重关注公司战略层核心指标在核心维度上的趋势及构成表现

业务看板：业务看板服务于不同业务团队，亦可视作各业务单元的核心看板

客户分析及画像：客户构成、客户留存、客户转化、行为、生命周期等场景的分析、

商品分析：商品构成、库存、售出、质量、商品生命周期等场景的分析

精细化运营工具

留存分析：按照留存模型，起始行为精分客户群体，依据精分客户群交易行为、频次、额度等的表现，观测各层客户的留存

画像分群：按照不同主体拆分属性，通过属性组合，筛选目标分群，进行精细化运营

交易分析：分析客户的订单行为

SQL查询控制台：可视化SQL查询

预警及分析

实时异常分析：实时异常分析基于历史数据，获取当前时间点的可能数值范围，当实际值在该范围以外时，即认为数据异常。关键要求是及时和准确

智能分析：具体策略是对关键核心指标进行维度拆解，寻找出影响核心指标波动中不同维值的“贡献度”，最终定位问题

6. 平台建设目的

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

为了解决企业业务在实际中存在的以下问题：

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

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

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

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

基于四个统一，统一数据采集，统一数据处理，统一数据存储，统一数据服务，基于计算及存储基座，提供标准统一、可连接萃取的数据中台，包含数据采集与研发、数据连接与萃取、数据资产管理及统一数据服务，服务于上层业务，如经营分析、消费者营销洞察等场景

在实际数据开发应用中存在，不知数据在什么地方，数据是什么意思，拿到一个报表怎么开发，数据怎么获取，最后数据怎么能快速的可视化呈现出来这五个难题，我们建设这个数据中台就是要解决：找数据，理解数据、问题评估、取数及可视化展现这五个问题，整个平台的故事也是围绕这个五个点。从根本上解决：

找数：数据从什么地方来到什么地方去，将数据和业务过程结合起来，实现数据的快速查询

理解数据：通过数据的血缘关系，数据关联关系及数据的说明信息，让数据开发人员，业务人员快速理解数据

问题评估：数据分析人员拿到需求，可以通过该平台实现问题的自动评估，大大提高数据分析效率

取数：用户可以不再关心数据的来源，不再担心数据的一致性，不再依赖RD的排期开发。通过所选即所得的方式，满足了用户对业务核心指标的二次加工、报表和取数诉求

数据可视化：依托于我们的BI可视化系统和数据中台的打通，数据分析人员可以快速的将数据中台创建的数据模型快速的转换成可视化报表。

基于Apache doris怎么构建数据中台(二)-数据中台建设内容

这次主要是将基于Doris的数据中台建设内容及系统架构设计

围绕着上次将的我们要解决的五个问题：找数，理解数据，问题评估，取数及数据可视化，给出一个概要的设计及框架

数据中台建设内容

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

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

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

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

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

数据中台架构

数据中台系统架构

数据中台技术架构

对用户来说，Doris 的优点是功能强大，易用性好。功能强大指可以满足我们用户的需求，易用性好主要指 兼容 Mysql 协议和语法，以及 Online Schema Change。兼容 Mysql 协议和语法让用户的学习成本和开发成本很低， Online Schema Change 也是一个很吸引人的 feature，因为在业务快速发展和频繁迭代的情况下，Schema 变更会是一个高频的操作。

对平台侧来说，Doris 的优点是易运维，易扩展和高可用：

• 易运维指 Doris 无外部系统依赖，部署和配置都很简单。

• 易扩展指 Doris 可以一键加减节点，并自动均衡数据。

• 高可用值 Dors 的 FE 和 BE 都可以容忍少数节点挂掉。

所以这里数仓是使用Doris作为核心组件来构建

架构说明：

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

2. 通过统一的数据采集系统，多种数据采集手段，包括Mysql binlog解析（Cannal），日志采集Flume（Doris审计日志）、埋点接口等实现多种异构数据的采集，针对Mysql，Kafka数据源我们封装了零代码入仓，可视化完成

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

4. Flink计算引擎完成数据的ETL处理及实时数据的统计，并将数据推送到Kafka及Doris（Stream Load）

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

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

7. 血缘关系的构建是基于Doris的审计日志，这块我会在后面数据资产的元数据管理里讲解

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

3.1.4 数据中台功能整体规划

数据中台功能整体规划

这是我们数据中台的整体功能规划，我会在后续展开每个功能

基于Apache doris怎么构建数据中台(三)-数据资产管理

前面我们讲了什么是数据中台，及数据中台的架构及功能规划，这次我们开始从数据资产开始拆解每个功能模块做的内容

数据资产管理平台可以定量评估数据资产的成本，价值，质量。帮助企业优化存储成本，节约计算资源。精细化的数据生命周期管理，帮助企业更好的管理数据的生产到销毁的整个生命周期。

在管理方面：管理者在规划数据文化建设时，对企业数据资产的全局构成、使用形式、 使用效果都需要详细的指标输入，往往这些指标都没有被统筹起来；在组织保障上， 需要多少资源、运作机制应该如何制定才能保障数据文化的落地，也需要运营指标来 辅助决策，所以管理者通常需从以下几个方面的问题进行思考：

1. 数据如何被用起来？

2. 数据保值后如何增值？

3. 组织已不再满足变化所需？

4. 管理体系如何建立？

在治理方面：企业拥有大量的数据资产之后，由于分工不同，一般的数据生产者、数据 消费者之间会随着时间推移、人员变动等因素，造成数据资产的信息成为无人维护的 静态状态，数据的存储成本、检索的理解成本会越来越高。这些数据资产分布在一片 数据沼泽中，难以分辨数据资产的成本、价值，更难以进行生命周期管理，甚至给数据 消费者带来难以跨越的信息鸿沟；数据治理通常关注以下几个方面的问题：

1. 数据的成本如何降低？

2. 数据生命周期如何管理？

3. 数据质量低，如何保证可用？

4. 数据价值如何评估？

在运营方面：数据资产从被建立，到数据内容的生产、到被使用，各环节用户各自所关注的、所进行的工作重点不一致；从数据管理视角、数据生产视角、数据应用视角来 看，各个视角之间的目标实现、工作重点、协作方式，不再以点对点的形式存在，而是 贯穿于整个数据链路中，数据运营正是为了从以上角度来发现问题、解决问题，作用是：数据运营会从“战略、执行、目标拆解、跟踪实现”各个阶段进行统筹，对运营目标 负责。数据运营通常关注以下几个方面的问题：

1. 有限的资源如何科学分配？

2. 数据的关系如何互相影响？

3. 如何发现最迫切的问题？

4. 数据运营缺乏工具、渠道；

在使用方面：数据只有被用起来，才能发挥其应有的价值。然而当前部分的企业使用 数据的情况并不乐观。根据调研统计，只有约 14%的企业数据相关的从业人员认为使用 数据是方便的。数据使用是否方便，可从两个维度来判断，一是工具：是否能够具备 “顺畅的、快捷的、容易完成的”数据使用场景的工具集；二是时间：是否可以快速地查找、信任、理解数据。根据调研统计，有不低于 80%的时间消耗在“查找-理解-信任”数据的过程中；这两个现状成为阻碍数据使用的最大的瓶颈。我们归纳了数据使用的几 大问题点，如下所示：

1. 数据孤岛亟需打破；

2. 发现、理解、使用数据耗时费力；

3. 知识经验无法共享、迭代；

4. 沟通不畅、权责不明；

5. 个人信息无法归档；

6. 数据安全如何保障；

本次只介绍数据资产管理的核心元数据管理及数据资产数据地图，及数据生命周期管理，其他相关模块：数据接入，数据处理，数据服务等后面介绍

资源管理

实现集中对各种数据资源的管理，包括数据库，消息队列等的管理

实现数据库数据源管理：属性包括：所属业务名称，业务技术负责人，数据源IP，端口、数据库名称，用户名、密码，数据库类型（Mysql、oracle、SQLServer、Doris等），创建时间，创建人

实现Kafka数据源管理：属性包括：Kafka集群名称，Kafka Broker Server地址（示例：172.22.197.123:9020），对应zookeeper地址（示例：172.22.197.123:2181）,创建时间，创建人，集群负责人

元数据管理

元数据管理是整个系统的核心，所有的功能及业务流程都是围绕这个进行的，也是整个系统数据治理的核心

元数据主要解决三个问题：首先，通过建立相应的组织、流程和工具，推动业务标准的落地实施，实现指标的规范定义，消除指标认知的歧义；其次，基于业务现状和未来的演进方式，对业务模型进行抽象，制定清晰的主题、业务过程和分析方向，构建完备的技术元数据，对物理模型进行准确完善的描述，并打通技术元数据与业务元数据的关系，对物理模型进行完备的刻画；第三，通过元数据建设，为使用数据提效，解决找数据，理解数据，问题评估难题以及取数和数据可视化难题

元数据管理系统架构

这里元数据分为物理元模型和血缘元模型

元数据采集

元数据采集分为人工录入和自动抽取，通过人工录入的方式实现物理表的准确归属（包括该表属于仓库哪一层、对应的主题、业务过程、星型模型关系等）以及指标的采集，从而完成技术元数据和业务元数据的采集，通过自动抽取的方式完成生产元数据的采集和使用元数据的采集，主要包括：物理模型的依赖关系、存储占用、热度等信息

血缘关系：这块因为我们数仓是用的Apache doris，实现起来相对月Hadoop架构的简单了很多，通过Flume采集每个Doris Fe节点的审计日志（fe.audit.log）中的sql，通过阿里开源的数据库连接池Druid进行解析自动生成，这里同时还可以对SQL操作进行一些安全审计，比如Delete，truncate，drop及sql执行成功失败，执行时间等进行审计预警

元数据管理功能

1.业务数据元数据同步采集

实现对业务数据库数据表的元数据自动采集同步，包括建表语句中的中文备注信息，并将中文备注信息填写到对应的中文字段名称中，界面提供元数据修改功能，主要修改是添加业务技术负责人、修改表的中文名称、备注说明等信息，表的字段名称，类型、长度等信息不允许修改

2.数据仓表元数据采集

实现对数仓数据库数据表的元数据自动采集同步，包括建表语句中的中文备注信息，并将中文备注信息填写到对应的中文字段名称中，界面提供元数据修改功能，主要修改是添加数仓表对应技术负责人、修改表的中文名称、备注说明等信息，表的字段名称，类型、长度等信息不允许修改

3.元数据版本管理

因为数据库表存在结构变更，这里需要提供元数据多的历史版本管理，可以查询元数据历史版本信息

4.业务元数据变更管理及预警

对业务元数据的变更（主要是Mysql数据库），通过flink监控binlog的schema变更时间，一旦发现及时发送消息通知，后端监控变更消息队列，取到变更信息，发出元数据变更预警，并自动修改相应的元数据，生成版本信息。

5.元模型构建

分为以物理表为核心的基础元模型构建，以及以血缘为中心的血缘元模型。

基础元模型构建以物理表为中心，打通其与技术元数据（主题、业务过程、Schema）的关系，实现了物理表的清晰归属，打通其与生产元数据的关系，要加上物理表查询热度、资源消耗、查询密级等生产使用信息，打通其与指标、维度和应用的对应关系，为上层的取数应用建立了完备的元数据。

血缘元模型以血缘为中心，通过监控Doris审计日志，通过sql解析完成自动的血缘关系构建，不仅要构建从上游业务表到仓库表的物理血缘，而且要打通仓库表到下游对应报表的血缘，为后续的影响评估构建了完备的元数据基础

6.虚拟库及表的管理

对于通过API接口方式对接的数据，要通过页面手动添加库，添加表及表字段类型，字段名称，字段中文名称，字段长度等等，这样的目的是为了统一元数据管理方式

业务元数据

数据域主题管理

1. 数据仓库是面向主题（数据综合、归类并进行分析利用的抽象）的应用。数据仓库模型设计除横向的分层外，通常也需要根据业务情况进行纵向划分数据域。数据域是联系较为紧密的数据主题的集合，是业务对象高度概括的概念层次归类，目的是便于数据的管理和应用。

2. 数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。为保障整个体系的生命力，数据域需要抽象提炼，并长期维护更新。在划分数据域时，既能涵盖当前所有的业务需求，又能让新业务在进入时可以被包含进已有的数据域或扩展新的数据域。数据域的划分工作可以在业务调研之后进行，需要分析各个业务模块中有哪些业务活动。

3. 数据域可以按照用户企业的部门划分，也可以按照业务过程或者业务板块中的功能模块进行划分

数据域的管理本质是一个分类管理，暂定二级分类

数据域主题作用于数仓内部数据表的管理及数据指标的分类管理

数据维度管理

建立统一的维度管理系统，实现对维度信息的统一管控，并为公司的数据产品提供统一的维度数据服务，包含维度开发管理，维度信息管理及维度数据服务三个方面。

维度管理：基于数据维度管理规范，对维度新增、修改、发布等生命周期进行统一管理。

维度服务：基于数据仓库ODS层模型源数据，建立服务化的维度表模型，在模型基础上建立维度，包括系统维度和手工维度定义，支持离线和实时大数据量的维度查询服务，维度创建完成后为各数据产品提供高可用，高性能的数据服务

1， 选择业务过程 根据业务场景以及可用数据源 2， 声明粒度 根据事实表及应用场景，确定汇总粒度，一般尽可能的用最细粒度 3， 确定维度 根据确定的粒度，定义对应的维度，最细粒度，也是最低层次的维度 4， 确定事实 确认将哪些事实放到事实表中，维度表只是做关联，不做维度数据的查询服务。

维度定义： 维度按集团产业进行指标一级业务域划分，包括：智能工厂、供应商、采购、销售、门店、仓储、运输、POS等；在各业务域下，对维度进行主题分类，主要有：时间类（DT）、组织类（OG）、产品（PD）、销售平台（SP）、经营方式（BM）、终端(TM)、业务渠道(BC)、营销(MK)、会员(MB)、采购模式(PM)、地点(AD)等。

维度管理：

维度：维度平台要支持快速定义维度,通过设置维度的基本信息，选择维度映射的维度表，做好维度与维度表的映射，设定维度的一些特性（布尔维度，时间维度，杂项维度等），检测维度的定义结果。达到了让业务人员能够只是通过页面操作就可以制定需要的维度。

维度表：数据开发人员可以通过维度库平台定义维度表，定义好之后可以集成数据仓库的同步任务一键将仓库的数据同步到维度表中，将维度表与维度做映射关系。

维度层级：维度库平台支持定义维度层级，只要是维度库平台上有的维度表并且做好维度与维度的映射关系之后，就可以定义需要的维度层级，根据维度层级提供维度值的上卷下钻查询服务。

维度血缘：提供了维度，指标，报表的血缘关系，以及还准备做的维度数据的血缘，维度，指标，报表调用次数的血缘等等。

数据地图

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

1.找表

通过统一的查询页面，通过输入关键字完成数据表的检索

在检索的结果页面找到符合自己的数据，进去查看表的详情页信息，详情页展示内容包括

• 表的详情信息

• 表的字段信息

• 表的数据预览（最多10条）

• 表的血缘关系（包括表的上下游依赖，表的关联关系）

• 表的使用情况统计

• 表的建表语句

• 表评论信息，对于表有不理解的地方可以在这块进行提问

• 表的分区信息

• 表的使用说明

• 收藏及使用足迹记录

表明细

2.找维度

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

• 维度所在表的信息

• 维度关联表的信息

• 维度说明信息

• 该维度关联的指标数据信息

• 维度评论

3.找指标

通过统一的指标检索页面，通过输入关键字检索指标信息，点击指标列表数据，可以查看该指标的信息

• 显示指标的基本信息

• 指标的生产链路

• 指标技术逻辑

• 指标字段信息（按维度和指标分开）

• 指标数据预览

• 指标使用说明

• 指标评论

指标明细：

4.找服务

通过统一的服务检索页面，通过输入关键字检索服务信息，点击服务列表数据，可以查看该服务的信息

• 数据服务接口基本信息

• 数据接口参数及响应说明

• 数据接口使用说明

• 接口权限

5.找报表

数据生命周期管理

主要是为了完成数据从产生、采集、处理、存储、加工、使用及归档销毁的全生命周期的各个阶段的管理

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

主要是通过数据接入，数据ETL、数据地图、元数据、数据指标各个系统在使用过程中的使用日志数据，对数据进行一个全面的采集及分析，生成数据在各个阶段的数据指标。

生命周期管理关注以下内容：

1. 数据归档管理：对符合归档的数据进行归档到冷存储上，减少存储及计算成本

2. 统计在数据每个阶段的数据变化趋势

3. 业务库DDL变更趋势

4. 数据热度排名：数据库，数据表的使用热度统计

5. 数据库数据量排名，

6. 库内数据表数据排名

根据数据的使用情况或者根据 用户设定的数据生命周期，及时帮用户销毁数据

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

数据资产全景视图

数仓界的360，可以定量评估数据资产的成本，价值，质量。帮助企业优化存储成本，节约计算资源。精细化的数据生命周期管理，帮助企业更好的管理数据的生产到销毁的整个生命周期。

• 资源视图

• 数据库统计

• 表统计

• 表引用统计

• 数据在各个生命周期阶段的资源使用情况

• 文件数量：总文件数，累计存储量，当月优化存储量

• Job统计

• 优化建议等

• 足迹

数据问答

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

下一讲会讲解怎么基于Apache doris实现快速数据接入，零代码数据接入系统

文章来源：https://zhuanlan.zhihu.com/p/397252278