导读：随着大数据产业的快速发展和应用落地，大数据产业正在成为中国数字经济发展的重要驱动力。本文将分享 58 同城自研的星河-大数据开发应用平台。

今天的介绍会围绕下面四点展开：

• 大数据应用平台介绍
• 平台资源管控介绍
• 核心能力技术解析
• 总结及未来规划

---

分享嘉宾｜于涛 58大数据部 资深开发工程师

编辑整理｜王雨萌 中文在线

出品社区｜DataFun

---

01

大数据应用平台介绍

 

1. 58 平台介绍

首先，介绍一下星河平台。星河平台是 58 大数据应用平台，是一个自研的一站式大数据应用解决方案，集数据集成、开发、运维、治理、资产管理能力于一身。致力于解决多业务场景、多业务系统下的数据开发、数据治理、资产管理等难题。帮助业务团队提升研发效率，降低运维管理成本，挖掘数据价值，为业务决策提供支撑。最关键的，为业务赋能，是数据应用平台价值体现的重要部分。

 

58 大数据平台，一共经历了三个时代。

第一个时代，也就是 1.0 时代，是一个基本探查的时代。在基本探查时代，我们仅支持探查类的一些查询，异构数据源仅支持 Hive 和 MySQL 的一些离线方面的查询。更多的应用开发面向产品的需求。

到了 2.0 时代，升级为核心调度时代。调度体系，也就是我们核心的一个工作内容。在这个阶段，主要任务是打造自研的核心调用平台，支持更多的生产场景，数据源支持多元化，自研全新的调度服务、元数据服务等。同时，在这个阶段，我们升级了元数据服务，使得元数据服务体系更加独立。为什么要这样做呢？后面会和大家详细解说。

到了 3.0 时代，就变成了一个全链路闭环的时代。这个时代，我们的重点是投入更多的经历到体系化的产品建设方面，形成一站式的数据应用平台。增加了数据全链路的服务管控能力。在这个阶段，我们也做了一些元数据服务体系衍生出来的一些核心能力的升级：比如数据地图、以及全链路的血缘关系，同时也专项的推进了一些数据治理的工作。在这个时期，我们基本上已经承载了全公司的业务。

2. 58 大数据应用平台核心

 

接下来介绍 58 应用平台的核心宗旨。

• 统一数据规范

首先，统一数据规范以及资产标准，通过对数据规范的一些建设，提升效率。

• 保证数据安全

保证数据安全，不仅对表库级别的数据安全有一些核心的控制，在针对字段力度，有一些更加细粒度的行列权限的控制，包括敏感和加密字段的管理，构造数据屏障。

• 丰富的数据交换任务

丰富的数据交换任务，刚才我们已经说了支持20多中数据任务的开发。这种形式的页面交互，对小伙伴们进行数据开发、作业调度等，门槛会大大降低。

• 综合数据治理

结合数据治理，对数据探查任务以及开发任务，我们都做了一些深度的治理的落地。

• 整合全域数据

最后整合全域数据，支持大部分的数据源。有了比较完整和完备的数据采集能力。而且全链路的血缘图谱，相较于之前的血缘图谱有了更大程度的优化。

3. 星河平台体系架构

 

底层是引擎层，上面数据开发大部分就是星河平台的内容。

贯穿整个数据开发生命周期的就是我们的数据监控。

--

02

平台资源管控介绍

 

接下来介绍平台的资源管控。

首先，整体架构分为三层。

顶层，是事业群，下面分别是我们的一级组织和二级组织。左侧开发用户和二级组织，是在 3.0 时代升级为现有的 1:N 的关系。为什么要这么做呢？是为了解决一些历史性的难题。比如便于管理、方便在部门之间或者个人之间的交接。既有利于小伙伴们一些基本任务的执行稳定不受影响，又能让部门或者是同项目内的成员更加方便或者高效的管理数据开发任务。

另外一个就是升级了组织之间的对应关系，由原来的 1:1 升级为 1: n。这样，在整个应用平台里，你在不同的组织下，看到的任务和资产都是不一样的。然后呢，这边还做到了一个资源的灵活分配。就是一级组织和二级组织的数据负责人有权限针对他不同的队列资源进行分配。

--

03

核心能力技术解析

1. 核心能力痛点

 

核心能力主要从两个方面来讲，一个是整体的元数据体系，另一个就是针对数据治理的专项工作。

首先我们想一下，在生产当中我们会使用技术重构、优化也好，或者升级也好。其实，我们的根本目标是要解决一些业务上的问题。我们这些数据服务体系，包括数据治理，我们之前碰到的业务痛点是什么？接下来我们围绕几个核心的能力痛点展开介绍：

• 规范落实

不管是数据治理还是元数据，都跟数据规范有着千丝万缕的联系。规范其实很难定制、落地。这个问题对于大家来说可能都是一个比较困难的事情。

• 跨组织账号权限

跨部门的交接合作中，也是会有一些不方便的地方。

• 数据搜索屏障

是否能很轻松的找到自己想要的数据资产和数据表，这个其实也是大数据应用平台的一个核心能力。

• 元数据信息不一致

另外还有一些历史问题，元数据信息不一致。例如元数据入口较多，且业务逻辑不一致；复杂调用链条，且私有客户端执行频繁。

• 治理无从下手

数据治理无从下手，治理只能线下单一纬度的统计和执行。生态工具较弱，业务方很难直观操作。其实整个应用平台的目标，就是业务方能够更加高效或者说更加简便的来操作自己的资产。

• 血缘准确、时效

最后就是血缘的准确性和时效性。血缘更新不及时，下线表和任务的重要参考依据不能直观反应当前的依赖状态。

 

接下来，聊一聊我们在元数据、数据地图、血缘图谱和数据治理这几个方面是怎么做的。

2. 元数据

 

元数据的痛点主要有两方面，首先就是异构数据源接入不统一。在整体的数据开发周期当中，如果数据不是一个可靠且稳定的服务，那开发过程中会遇到很多问题，也会直接造成 Oncall 问题剧增。

 

元数据是大数据应用平台的基石。如果缺少规范，会遇到很多问题。例如快速发展导致形成数据孤岛，数据口径不一致，作业的稳定性较差等等。

降本增效和数据安全是数据治理的两大重要目标。

 

58 在规范落地时，做了以下这些规范：

• 命名规范：从数仓建表开始，表和字段命名的约束，包括分区的命名以及字段的命名，都做了一些核心的控制。
• 分层规范：分层的规范，从 RAW 到ODS，再到 DWD，DWS，APP。最终到数据集市层。对于这些，企业都会有自己的规范。在这里面，也会有底线的规定。比如逆向层的一些调用，底层调用比较高层的数据，都是不允许的。但是规范较细，会对开发效率造成一些影响，于是我们定义了 TMP 层，也就是一些临时层，方便开发的小伙伴在开发阶段可以快速联调。
• 存储规范：我们对存储也有明确的规定，还有对生命周期的约束。
• 建表规范：包括建表审核、分层依赖约束和分层权限约束等。

 

元数据服务的优势有以下几大方面：

首先，规范调用方的统一调用协议，可以保证单一业务单元的逻辑一致。

另外，聚合元数据的统一封装，保证对内对外出口一致。

最后，屏蔽了复杂业务逻辑和底层数据源的耦合。

 

目前我们支持的数据源包括：MySQL、Hive、Hbase、SQLServer、Oracle、Doris、ClickHouse、Redis，以及我们自研一些产品，例如：Wtable Wlist。

 

上图展示了元数据服务的整体技术架构。

上层是子系统服务，包括一些业务的触发，可能是建表，也可能是数据的一些开发任务。流入到消息中间件后，经过数据血缘，可能回到血缘数仓。有一部分会流入到元数据服务的接入层。这个服务的接入层是统一的，接受处理屏蔽一些真实数据和上层业务逻辑的关系。有一些会流入到业务库中。同步到 ES 当中。同步到 ES 是为了便于ES后面的数据地图的搜索。

 

再来看一下服务的实现。

首先，底层有一个专门的连接器工厂。其实就是适配和策略的一个应用。然后，抛出连接实例，进行业务逻辑的探查。

接着，针对不同的业务绑定，流出到统一的元数据库。

3. 数据地图

前文中提到，元数据扩展服务里面核心的一点就是数据地图。数据地图最关键的两个问题：一个是找数据难，另一个是理解数据难。

 

确实，我们在生产环境中，非专业的数据开发，很难找到合适的数据。而且找到数据以后，是不是看到数据的库表结构，就能很好的理解数据了呢？显然不是，这其中可能需要一个全维度的检索和升级。

 

首先，从检索方面，升级后的数据地图支持了一些，包括表、表说明、字段、表字段中文名、表字段备注方面的查询。包括数据域、主题域以及一些基本信息的元数据信息的查询。还支持查询次数、收藏次数、下游任务数、表的权限等级、数据的重要层级等查询。

 

数据写入的时候，有同步和异步两种方式。最终更新到 ES 索引文档中。所以，在检索的时候，其实是在 ES 中进行查询。通过统一的排序方式检索回来的唯一的幂等表示，再从业务库里找这个信息，最终提供给大家。

 

4. 血缘图谱

 

血缘方面的问题包括，血缘解析的准确性欠缺，以及血缘链路的全覆盖比较难，时效性也很难保证。真实的业务场景中，当我们需要执行删除或者下线操作的时候，血缘的追踪是很重要的参考依据。

 

上图是简单的技术架构。首先，无论是探查类的业务，还是开发类的业务，都会经过缓存，流入到元数据的服务中，缓存会判断有效血缘期限。经过这个判断，会流入到元数据库，进行词法解析。完成词法解析后，进入到血缘关系层。

5. 数据治理

数据治理，贯穿了大数据的所有环节。整个开发周期，针对数据治理的问题，不是某一个服务可以完全承载的，甚至可能不是一个部门去完全承载，而是需要所有人的配合。

 

首先，数据治理的目的，一个是降本增效，另一个是为了底层的数据安全。

有效的治理工具最重要的两个方面：一是制定规范和标准，另外就是在元数据的驱动下，治理工具的协作。

 

治理体系包括如下内容：

首先，也是比较重要的一个部分，就是建立元数据的数仓。搭建全维度指标的元数据仓库，融合底层以及平台层的相关数据。

然后，就是治理方案的规划，支持业务方自定义拼装一些治理规范，筛选目标治理的实体。

接下来，是数据作业的一个流程，通过一些数据作业过滤规则，找到最真实的治理痛点，这些痛点也就是需要治理的数据资产。

最后，到数据治理工作池，通过平台提供的核心能力，利用治理工具批量操作数据资产，再有效的进行实时反馈。

 

这张图，是我们真实的数据治理的数据流图。首先从业务数据出发，还有实时数据，流入到元数据仓库，同步到星河业务库。

业务方，数据治理负责人，会通过创建和修改治理方案，动态地修改和更新治理任务。治理的实体会存入到数据治理的元数据库中。治理工具会通过业务库的数据以及治理的一些数据，将治理落地，最终的效果反馈给业务方，或者是数据的负责人。

目前，数据治理的实体就是表，包括表级别还有目录级别的治理。

--

04

总结及未来规划

 

最后，总结一下本文内容，并介绍一下未来规划。

前文对平台进行了介绍，以及在资源方面的管控，包括我们遇到的历史性的难题和我们的应对方案。在核心能力、技术落地方面，重点介绍了元数据的服务体系，以及数据治理的一些落地。