本文首发于 Nebula Graph Community 公众号

本文整顿自 BIGO 在 nMeetp 上的主题分享，次要介绍 BIGO 过来一年在数据管理建设方面的了解和摸索。而 BIGO 数据管理的外围重点在于元数据平台的建设，用以撑持下层数据管理和建设利用，包含数据地图、数据建模、数据治理和权限治理等等。本文次要围绕以下五个方向开展：

  1. OneMeta 根底建设；
  2. 图引擎：Nebula 替换 JanusGraph
  3. 数据资产平台利用；
  4. Adhoc 即席查问；
  5. 将来布局
BIGO 是欢聚时代（YY 直播母公司）原挪动新产品部根底上成立的独立公司，致力于打造寰球当先的社区化视频直播利用与品牌。旗下主打产品 BIGO LIVE，上线仅一个月就荣登泰国收费 APP 榜首。

数据管理平台

上图为 BIGO 数据资产治理平台的形象图，如上图所示，在元数据平台外面存储着技术元数据、业务元数据、数据血统、数据计量、标准模型、权限内容等数据，基于元数据平台下层对接应用层，包含：地图、老本、取数、权限、治理、模型。

OneMeta 根底建设

业务背景

目前 BIGO 数据管理面临以下问题：

  1. 元数据芜杂无规范，没有对立的搜寻和治理平台；
  2. 数据没有血缘关系，各个开发平台如同数据孤岛；
  3. 没有业务类元数据，业务方难以查问及统一口径；
  4. 数据权限管控粗放，权限申请及审批流程原始化；

简略来说：短少规范、数据短少分割、短少业务元数据、短少细颗粒度的权限管控，为此，BIGO 外部搭建了元数据管理平台 OneMeta 来解决上述问题。

而 OneMeta 的平台能力如下：

  1. 全域元数据实时入库及治理性能，对立构建公司集体及团队数据资产目录。
  2. 数据地图、取数查问、数据治理、血统姻联、权限治理、标准模型等利用存储管理能力。
  3. 反对 HIVE / HDFS / OOZIE / CLICKHOUSE / BAINA / SPARKSQL / KYUUBI / KAFKA 等元数据及血缘关系的存储。
  4. 精准计量业务元数据：各式各样的元数据的操作次数、冷热水平、业务归属等信息更新。

元数据平台架构

BIGO 元数据平台次要依赖 Apache Atlas、Vesoft Nebula、Yandex ClickHouse 和 BIGO 外部开发的 DataCollector 进行构建，整体上能够划分为四层。

最上层（蓝色局部）是数据采集的源头和 DataCollector 服务，各个平台的技术元数据次要以 Hook 的模式实时收集，而业务元数据则通过 DataCollector 服务以小时或天级定时调度、更新；第二层（橙色局部）是音讯队列和 API 层，提供通道接入数据到 Atlas；第三层则是 Atlas（绿色局部），这是最外围的元数据管理层，所有元数据、属性信息和血缘关系等都在 Atlas 进行治理，此外 Atlas 层还提供了接口供给用调用；最底层（紫色局部）是存储层，次要应用 Nebula Graph、Elasticsearch 和 ClickHouse，其中次要的元数据都存储在 Nebula 中，其中须要全文索引的数据通过 Nebula Graph 转存到 ES，而须要查问历史趋势或聚合的数据时，则去 CK（ClickHouse）中读取数据。

Apache Atlas 优化

这部分解说下 BIGO 基于开源的 Atlas 做了何种优化，次要有以下方面的优化：

  1. 通过 SpringBoot 切面实现审计能力建设。
  2. 引入 MicroMeter 和 Prometheus 实现监控告警能力建设。
  3. 抽离图引擎依赖，反对分布式 Nebula Graph 图引擎的读写，新增 3w+ 行代码。
  4. 新增访问速度管制及黑白名单性能，管制突发流量和歹意拜访，保证系统稳固。
  5. 定期工作，以便清理生效 Process 过程数据，防止数据收缩。
  6. 增加 Atlas 平滑退出机制，避免因重启导致生产音讯失落。
  7. 重构血缘关系 DAG 图展现，优化用户视觉体验同时防止大图渲染过慢问题。
  8. 反对血缘关系关联调度引擎工作流，解决数据血统中最重要的「查找产出」一环。
  9. Hook 拓展：全新反对 Oozie、Kyuubi、Baina、ClickHouse、Kafka 等元数据采集。
  10. 若干原生版本代码中的 BUG 修复。

Data Collector 性能

在 BIGO 元数据平台中有个比拟重要的性能——DataCollector，它是一个数据采集服务，次要性能用于定时收集并更新业务元数据（服务于下层的数据计量等利用），比方 HIVE 表每天的拜访次数和拜访人员、HDFS 门路的存储量、元数据的业务线归属、元数据的冷热判断、元数据的实在负责人等业务元数据。同时，DataCollector 还具备数据清理（生命周期 TTL）和同步数据接入层（Baina）元数据的性能。

图引擎代替

Atlas 原生图引擎是 JanusGraph，在应用过程中发现 Atlas Janus 有以下缺点：第一，Atlas 依赖的内嵌 JanusGraph 图引擎存在单点问题，并发量上来后存在计算瓶颈。第二，JanusGraph 依赖 Solr 构建索引，尽管 JanusGraph 宣称可用 Elasticsearch 替换 Solr，但实际操作起来却存在不少问题。此外，BIGO 外部对 Solr 不存在相干的技术累计，这须要投入肯定的人力老本。第三，海量数据场景下 JanusGraph 搜寻性能差，并存在偶发搜寻不到数据的 BUG 难以解决。第四，JanusGraph 没有开源社区与公司外部团队反对，保护老本高。

再来说下 Nebula Graph 替换 JanusGraph 的几大劣势。首先，业务同学和运维同学多方测试证实 Nebula Graph 在图摸索性能上是 JanusGraph 的 N 倍以上。再者，Nebula Graph 是个分布式图数据库，反对分布式部署，计算和存储均可横向扩大，并且反对高并发。此外，Nebula Graph 开源社区沉闷，产品一直迭代优化，反对千亿顶点和万亿边的数据量。最初，在 BIGO 外部有单干团队反对与保护 Nebula Graph 平台性能保护和开发。

图引擎替换的挑战&解决方案

尽管在选型上确定了用 Nebula Graph 来替换 JanusGraph，然而在理论的替换过程中还是存在肯定的挑战。

首先是在数据模型上，Nebula Graph 是个强 Schema 类型数据库，如果要替换弱类型的 JanusGraph 的话，须要弱化 Tag 和 Edge 的概念。而后，在数据类型反对方面二者也有出入，原生 Nebula Graph 对 MAP、LIST 之类的简单类型反对水平不高。再者是索引的设计问题，在 Nebula Graph 中索引性能并非起到减速作用，而是 LOOKUP 此类搜寻的必备条件。此外，Nebula Graph 自身是不反对事务的，这块给咱们减少了不少的工作量。最初一点，是应用习惯的转变，在查问形式上 Nebula Graph 自研查询语言 nGQL，而 JanusGraph 反对通过 Java API 和 Gremlin 进行查问。

问题呈现了如何解决呢？在强弱类型转换上，BIGO 外部批改了 Atlas 的外围代码，减少参数动静判断 DDL 数据类型。简略来说，在写入数据或者执行查问时，通过特定参数来判断该条 nGQL 操作何种数据类型。在数据类型反对方面，Atlas 业务层自定义数据序列化形式来反对简单类型。在原生索引搜寻上，在零碎初始化时主动创立独立索引和复合索引解决 Atlas 的搜寻问题。在事务方面，在 Atlas 业务层新增半事务接口，缩小 Nebula Graph 存储层数据出错的概率。

Atlas 和 Nebula Graph 的革新

这里，集中讲述在图引擎替换过程中 BIGO 对 Atlas 和 Nebula Graph 的革新。

在 Atlas 革新过程中，BIOG 新增 3w+ 行代码解藕 Atlas 和原生图引擎 JanusGraph 并反对分布式图引擎 Nebula Graph 读写。通过革新全文索引实现在 Atlas 层以 INTERSECT 形式多条件并发过滤查问，从而晋升搜寻速度。还将 Atlas 的多属性更新改造为并发更新，减速元数据入库的更新速度。对生产音讯失落的预处理上，BIGO 在 Atlas 层增加平滑退出机制，避免因重启导致生产音讯失落。此外，Atlas 通过反对自定义多种（反）序列化形式实现对简单类型数据的反对。刚有提到过事务反对，在 Atlas 层新增 Vertex#openTranscation/Vertex#commit 接口反对半事务，缩小因为 Nebula Graph 无事务回滚出错。最初，在 Atlas 层合并大量独立索引为复合索引，通过创立默认索引和属性优化零碎初始化速度。

而 Nebula Graph 方面，BIGO 也对其进行了革新。首先是对 LOOKUP 子句的革新，让其反对并发执行，经测试扫描 100 万数据的 Latency 从 8s 升高到了 1s。此外，反对了 LOOKUP 从 Elasticsearch 查问分页性能。再者，其余局部革新工作集中在 Elasticsearch，BIGO 反对了后端 ElasticSearch 中的数据更新和删除；对 Listener 也做了 Commitsnapshot 的反对，以及全量数据的更新。对全文索引反对了 REBUILD 性能，并将 REBUILD INDEX 权限下发到 admin 用户。BIGO 还减少了独自创立和删除全文索引性能，防止所有的列写入 ElasticSearch 减少其存储使用量。最初，对 Nebula Graph 的定期 Compaction 操作也进行了优化，缩小下层性能稳定。

替换之后搜寻性能

上图展现了 BIGO 用 Nebula Graph 替换 JanusGraph 之后的搜寻性能。上图 P99 须要耗时 2s 多的起因是搜寻总存在大搜寻，会拖慢搜寻速度。替换之后，搜寻速度晋升 5 倍以上，从原先的 5s 返回后果升高到了 1s 以内；而且再也不会呈现偶然搜寻不到数据的问题，系统维护也无需额定保护索引，还反对了高并发和超大数据量存储。

数据资产平台利用

之前有分享过上层的对立元数据平台架构，这里再来具体解说下。如上图所示，上层次要为对立元数据平台，下层则为产品应用层。左下局部为实时元数据入库模块，包含 Hive、Kyuubi、Oozie、Baina、CK（ClickHouse）、HDFS 等等数据源，通过 Hook 通过 Kafka 音讯队列写入到对立元数据库平台。对立元数据库平台外围组件是 Atlas，其依赖 ClickHouse 和 Nebula Graph。此外，对立元数据平台还依赖 BIGO 外部的 OneSQL 平台，次要是对立 SQL 查问引擎，以及 Ranger 次要负责权限管控。

而数据资产平台下层则对接了应用层，包含：REST 接口、数据地图、实时血统、即席查问、数仓建模、可视化建表、到职交接、权限治理等利用。

上面着重来介绍下相干利用。

数据地图

上图为数据地图-搜寻（局部），反对全域元数据（HIVE、HDFS、CK、BAINA）搜寻与发现（数据源还在减少中）、后果排序和下载、反对筛选、反对高级搜寻等性能。在搜寻界面，左侧为筛选条件，顶部为搜寻框入口，下方为搜寻后果展现数据。

上图为数据地图-详情（局部），通过搜寻找到特定的元数据之后，可点击查看技术明细、数据计量、业务归属、生命周期、历史趋势等元数据根底信息。在详情界面，以上图 HIVE 元数据的详情为例，次要分为上方的根本信息和下方的明细信息、血缘关系、数据预览展现。

根本信息列举了昨日查问次数 107 次，数据大小 1.27 TiB，占用空间为 3.8 TiB…此外，通过【编辑】操作可对数据生命周期、业务线进行治理。

明细信息（下方左侧）列举字段信息：HIVE 表的字段、字段类型、字段相干形容，供产品、经营应用。下方右侧为分区字段信息，如果某个数据是分区表的话，该模块会展现分区字段的信息；如果是个全量表的话，则不会展现分区字段信息。此外，数据血缘关系、数据预览性能这里不作具体介绍。

实时血统

在实时血统模块，BIGO 重构了有向无环图 DAG 图，新增数据表格展现，实现了数据懒加载、关联和搜寻工作流，在业务层的血缘关系图里实时地展现工作流的执行状态。

血统模块反对图表和可视化两类视图，上图抉择了可视化视图模式。可视化视图局部可在上、上游节点中抉择对应节点，配有【显示过程】按钮用来显示或者暗藏过程工作流。举个例子，a 表和 b 表，b 表是由 a 表通过一个工作流生成，关上【显示过程】按钮则会展现该生成过程，敞开【显示过程】则会屏蔽这个过程数据。

上图为数据血统外围模块，展现了某个元数据的上下游。左侧浮动深度和过滤选项，可抉择以某个元数据为核心的上下游层数（深度），比方，上图就抉择了 tiki_core_india... 数据的 2 层上游和上游节点。

数据治理

数据治理这块，次要展现 TTL 治理，用于治理通用打点表各个事件的生命周期。

上图为数据治理 TTL 治理局部截图，从上文提到的数据地图详情局部点击【编辑】按钮即可对数据进行 TTL 生命周期治理。当然，BIGO 数据治理除了生命周期治理之外，还有别的性能这里不做具体介绍。

数据建模

在数据建模方面，元数据对立平台提供 SQL 脚本形式用来创立表模型，供数仓开发者和数据分析师交互应用。

图注：一条 SQL 模型数据

图注：数据建模入口

监控大盘

BIGO 外部的监控大盘实时展现公司数据，包含资源总量、各业务线资源占比、变化趋势和热门资源等，从而推动团队、业务线进行老本优化。

图注：脱敏的大盘截图

除了上述的利用之外，数据资产治理平台还有模板取数、权限治理、到职交接、群组治理、数据预览，以及珍藏下载等利用。

Adhoc 即席查问

业务背景

BIGO 原来应用 Cloudera HUE 作为即席查问平台，但因为多种起因，HUE 早已无奈适配外部查问需要，常常被用户投诉难用且不稳固。次要起因有：

  1. 代码古老，根本处于被开源放弃状态；
  2. BIGO 历史起因经验至多六位员工接手 HUE，沉积大量外部代码；
  3. HUE 运维十分繁琐；
  4. 编辑窗口不合乎用户理论需要；
  5. BIGO 已外部建设对立 SQL 路由器，无需让用户抉择执行引擎。

基于上述起因，决定自研一套全新 SQL 查问平台，解决上述问题，对立元数据管理和数据查问到资产治理平台，并退出以下个性：第一点，建设对立 SQL 路由器（onesql），依据语法规定主动路由 SQL 到后端 sparksql/hive/presto/flinksql 引擎执行；第二点，提供全新查问入口给用户执行 SQL，并规范化 DDL 语句，为数据治理、权限治理及老本管制提供便当；第三点，依据产品调研设计全新多 TAG 交互操作的编辑窗口；第四点，提供通过 SQL 建表 / LOAD 数据或通过可视化建表 / LOAD 数据的性能；第五点，主动兼容 pad / phone 等挪动设施端查问，不便国内外共事应用；第六点，减少日常用户拜访审计 / 全面监控告警；最初一点，反对在对立入口查问 ClickHouse 数据（布局中）。

将来瞻望

数据平台将来布局的话，次要围绕：元数据建设、产品减少、业务赋能三方面。

在元数据建设方面，将会笼罩接入层、计算层、调度层、存储层所有平台的元数据。此外，咱们还在布局计算资源治理以及一站式工作开发（Python / Jar / Shell / SQL）等。

在产品加强方面次要分为治理、老本、效率、利用四块内容，在治理方面，增强数据治理能力，主动治理不衰弱的数据；在老本方面，帮忙公司各团队实现老本剖析闭环，为老本优化提供工具；在效率方面，通过标准建表、精准计量、查问优化、血统建设等晋升用户工作效率；在利用方面，进一步欠缺集成即席查问和散布式调度零碎性能，加强用户应用体验。

在业务赋能方面，将会进行智能归因诊断，赋能业务团队主动剖析问题能力。此外，还会迭代优化模板取数，赋能业务团队简略开掘更多数据价值。

以上，为本次 BIGO 数据平台实际分享。

Nebula 社区首届征文活动进行中！ 奖品丰富，全场景笼罩：撸码机械键盘⌨️、手机无线充、衰弱小助手智能手环⌚️，更有数据库设计、常识图谱实际书籍 等你来领，还有 Nebula 粗劣周边送不停～

欢送对 Nebula 有趣味、喜钻研的小伙伴来书写本人和 Nebula 乏味的故事呀～

交换图数据库技术？退出 Nebula 交换群请先填写下你的 Nebula 名片，Nebula 小助手会拉你进群~~

关注公众号