精华内容
下载资源
问答
  • 但是随着应用开发的深入,有时候也避免不了要调用第三方提供的接口服务,我们今天就带着大家使用一下低码平台外部数据源。 创建外部数据源 登录低码的控制台在数据源管理菜单中点击【新建数据源】,在下拉选项中...

    日常开发中我们经常使用低码平台自建数据源,我们可以定义自己需要的数据字段。但是随着应用开发的深入,有时候也避免不了要调用第三方提供的接口服务,我们今天就带着大家使用一下低码平台的外部数据源。

    创建外部数据源

    登录低码的控制台在数据源管理菜单中点击【新建数据源】,在下拉选项中我们选择外部数据源:

    我们输入数据源名称和数据源标识,点击【确定】按钮

    定义方法

    在打开的页面中点击【编辑】按钮进入数据源的编辑页面

    在编辑页面点击【新增自定义方法】增加一个方法

    然后我们设置方法的名称、标识、意图,方法的类型选择http请求,入参设置为city,url设置为https://restapi.amap.com/v3/weather/weatherInfo?key=5d2d3e6c0d5188bec134fc4fc1b139e0&city=%E5%91%BC%E5%92%8C%E6%B5%A9%E7%89%B9&extensions=base

    设置好后我们可以点击测试,点击运行测试,我们可以看到调用的结果

    成功后我们点击【出参映射】

    一切设置好后我们点击【确定】按钮让设置生效

    使用云函数改造结果

    通过http的形式会将接口的数据原样返回,但是返回的结果层次太深不利于我们的使用,我们利用第二种接口调用方式改造一下返回的接口。我们在数据源里点击【新增自定义方法】按钮

    方法类型选择云函数

    在编辑器中输入如下代码:

    /**
    
    * 使用 npm 包 request 发送http请求, 详细使用文档可以参考
    * https://github.com/request/request#readme
    
    */
    
    const request = require('request');
    
    /** 依据 http状态码 判断请求是否成功 */
    
    function isSuccessStatusCode(code) {
    
    return code >= 200 && code < 300;
    
    }
    
    module.exports = function (params, context) {
    
    // params 即为入参定义的结构, 可以在 request 的请求配置中使用 params
    
    return new Promise(function (resolve, reject) {
    
    request(
    
    {
    
    url: 'https://restapi.amap.com/v3/weather/weatherInfo?key=5d2d3e6c0d5188bec134fc4fc1b139e0&city=%E5%91%BC%E5%92%8C%E6%B5%A9%E7%89%B9&extensions=base',
    
    method: 'GET',
    
    // 将 json 为 true, 响应结果的 body 会被自动转换为对象,
    
    //   在POST请求中, 也会自动设置将 Content-Type 设置为 application/json
    
    json: true
    
    },
    
    function (err, response, body) {
    
    if (err) return reject(err);
    
    if (!isSuccessStatusCode(response.statusCode))
    
    return reject(new Error('request failed: ' + response.statusCode));
    
    return resolve(body.lives);
    
    }
    
    );
    
    });
    
    };
    

    设置入参参数

    入参定义好后点击方法测试按钮

    点击运行测试查看输出的结果

    可以看到我们过滤了一些不需要的结果,只保留我们需要的数据

    产品介绍

    腾讯云微搭低代码是高效、高性能的拖拽式低代码开发平台,向上连接前端的行业业务,向下连接云计算的海量能力,助力企业垂直上云。腾讯云微搭低代码将繁琐的底层架构和基础设施抽象化为图形界面,通过行业化模板、拖放式组件和可视化配置快速构建多端应用(小程序、H5应用、Web 应用等),免去了代码编写工作,让您能够完全专注于业务场景。腾讯云微搭低代码以云开发作为底层支撑,云原生能力将应用搭建的全链路打通,提供高度开放的开发环境,且时刻为您的应用保驾护航。

    开通低代码:https://cloud.tencent.com/product/lowcode
    产品文档:https://cloud.tencent.com/document/product/1301/48874
    技术交流加Q群:1003059706
    最新资讯关注微信公众号【腾讯云低代码】

    展开全文
  • 美团图数据库平台建设及业务实践

    千次阅读 2021-04-02 00:25:26
    总第442篇2021年 第012篇图数据结构,能够更好地表征现实世界。美团业务相对较复杂,存在比较多的图数据存储及多跳查询需求,亟需一种组件来对千亿量级图数据进行管理,海量图数据的高效存储...

     

    图数据结构,能够更好地表征现实世界。美团业务相对较复杂,存在比较多的图数据存储及多跳查询需求,亟需一种组件来对千亿量级图数据进行管理,海量图数据的高效存储和查询是图数据库研究的核心课题。本文介绍了美团在图数据库选型及平台建设方面的一些工作。

     

    • 1 前言

    • 2 图数据库选型

    • 3 NebulaGraph架构

    • 4 图数据库平台建设

      • 4.1 高可用模块设计

      • 4.2 每小时百亿量级数据导入模块设计

      • 4.3 实时写入多集群数据同步模块设计

      • 4.4 图可视化模块设计

    • 5 业务实践

      • 5.1 智能助理

      • 5.2 搜索召回

      • 5.3 图谱推荐理由

      • 5.4 代码依赖分析

    • 6 总结与展望

    • 7 作者信息

    • 8 参考资料

    • 9 招聘信息

    1 前言

    图数据结构,能够很自然地表征现实世界。比如用户、门店、骑手这些实体可以用图中的点来表示,用户到门店的消费行为、骑手给用户的送餐行为可以用图中的边来表示。使用图的方式对场景建模,便于描述复杂关系。在美团,存在比较多的图数据存储及多跳查询需求,概括起来主要包括以下 4 个方面:

    • 图谱挖掘: 美团有美食图谱、商品图谱、旅游图谱、用户全景图谱在内的近 10 个领域知识图谱,数据量级大概在千亿级别。在迭代、挖掘数据的过程中,需要一种组件对这些图谱数据进行统一的管理。

    • 安全风控: 业务部门有内容风控的需求,希望在商户、用户、评论中通过多跳查询来识别虚假评价;在支付时进行金融风控的验证,实时多跳查询风险点。

    • 链路分析: 包括代码分析、服务治理、数据血缘管理,比如公司数据平台上有很多 ETL Job,Job 和 Job 之间存在强弱依赖关系,这些强弱依赖关系形成了一张图,在进行 ETL Job 的优化或者故障处理时,需要对这个图进行实时查询分析。

    • 组织架构: 公司组织架构的管理,实线汇报链、虚线汇报链、虚拟组织的管理,以及商家连锁门店的管理。比如,维护一个商家在不同区域都有哪些门店,能够进行多层关系查找或者逆向关系搜索。

    总体来说,美团需要一种组件来管理千亿级别的图数据,解决图数据存储以及多跳查询问题。海量图数据的高效存储和查询是图数据库研究的核心课题,如何在大规模分布式场景中进行工程落地是我们面临的痛点问题。传统的关系型数据库、NoSQL 数据库可以用来存储图数据,但是不能很好处理图上多跳查询这一高频的操作。

    Neo4j 公司在社交场景(见图1)里做了传统关系型数据库 MySQL 跟图数据库 Neo4j 的查询性能对比 [1],在一个包含 100 万人、每人约有 50 个朋友的社交网络里找最大深度为 5 的朋友的朋友,实验结果表明多跳查询中图数据库优势明显(见图 2)。然而选取或者自主研发一款高吞吐、低查询延时、能存储海量数据且易用的图数据库非常困难。下面将介绍美团在图数据库选型及平台建设方面的一些工作。

    图 1

    图 2

    2 图数据库选型

    在图数据库的选型上我们主要考虑了以下 5 点:(A) 项目开源,暂不考虑需付费的图数据库;(B) 分布式架构设计,具备良好的可扩展性;(C) 毫秒级的多跳查询延迟;(D) 支持千亿量级点边存储;(E) 具备批量从数仓导入数据的能力。

    分析 DB-Engines[2] 上排名前 30 的图数据库,剔除不开源的项目,我们将剩余的图数据库分为三类:

    • 第一类:Neo4j[3]、ArangoDB[4]、Virtuoso[5]、TigerGraph[6]、RedisGraph[7] 此类图数据库只有单机版本开源可用,性能优秀,但不能应对分布式场景中数据的规模增长,即不满足选型要求(B)、(D)。

    • 第二类:JanusGraph[8]、HugeGraph[9] 此类图数据库在现有存储系统之上新增了通用的图语义解释层,图语义层提供了图遍历的能力,但是受到存储层或者架构限制,不支持完整的计算下推,多跳遍历的性能较差,很难满足 OLTP 场景下对低延时的要求,即不满足选型要求(C)。

    • 第三类:DGraph[10]、NebulaGraph[11] 此类图数据库根据图数据的特点对数据存储模型、点边分布、执行引擎进行了全新设计,对图的多跳遍历进行了深度优化,基本满足我们的选型要求。

    DGraph 是由前 Google 员工 Manish Rai Jain 离职创业后,在 2016 年推出的图数据库产品,底层数据模型是 RDF[12],基于 Go 语言编写,存储引擎基于 BadgerDB[13] 改造,使用 RAFT 保证数据读写的强一致性。

    NebulaGraph 是由前 Facebook 员工叶小萌离职创业后,在 2019年 推出的图数据库产品,底层数据模型是属性图,基于 C++ 语言编写,存储引擎基于 RocksDB[14] 改造,也使用 RAFT 保证数据读写的强一致性。

    这两个项目的创始人都在互联网公司图数据库领域深耕多年,对图数据库的落地痛点有深刻认识,整体的架构设计也有较多相似之处。在图数据库最终的选型上,我们基于 LDBC-SNB 数据集[15]对 NebulaGraph、DGraph、HugeGraph 进行了深度性能测评,测试详情见文章:主流开源分布式图数据库 Benchmark,从测试结果看 NebulaGraph 在数据导入、实时写入及多跳查询方面性能均优于竞品。此外,NebulaGraph 社区活跃,问题响应速度快,所以我们团队最终选择基于 NebulaGraph 来搭建图数据库平台。

    图 3

    一个完整的 NebulaGraph 集群包含三类服务,即 Query Service、Storage Service 和 Meta Service。每类服务都有各自的可执行二进制文件,既可以部署在同一节点上,也可以部署在不同的节点上。下面是NebulaGraph 架构设计(见图 3)的几个核心点[16][17]。

    • Meta Service: 架构图中右侧为 Meta Service 集群,它采用 Leader/Follower 架构。Leader 由集群中所有的 Meta Service 节点选出,然后对外提供服务;Followers 处于待命状态,并从 Leader 复制更新的数据。一旦 Leader 节点 Down 掉,会再选举其中一个 Follower 成为新的 Leader。Meta Service 不仅负责存储和提供图数据的 Meta 信息,如 Schema、数据分片信息等,同时还提供 Job Manager 机制管理长耗时任务,负责指挥数据迁移、Leader 变更、数据 compaction、索引重建等运维操作。

    • 存储计算分离: 在架构图中 Meta Service 的左侧,为 NebulaGraph 的主要服务,NebulaGraph 采用存储与计算分离的架构,虚线以上为计算,以下为存储。存储计算分离有诸多优势,最直接的优势就是,计算层和存储层可以根据各自的情况弹性扩容、缩容。存储计算分离还带来了另一个优势:使水平扩展成为可能。此外,存储计算分离使得 Storage Service 可以为多种类型的计算层或者计算引擎提供服务。当前 Query Service 是一个高优先级的 OLTP 计算层,而各种 OLAP 迭代计算框架会是另外一个计算层。

    • 无状态计算层: 每个计算节点都运行着一个无状态的查询计算引擎,而节点彼此间无任何通信关系。计算节点仅从 Meta Service 读取 Meta 信息以及和 Storage Service 进行交互。这样设计使得计算层集群更容易使用 K8s 管理或部署在云上。每个查询计算引擎都能接收客户端的请求,解析查询语句,生成抽象语法树(AST)并将 AST 传递给执行计划器和优化器,最后再交由执行器执行。

    • Shared-nothing 分布式存储层: Storage Service 采用 Shared-nothing 的分布式架构设计,共有三层,最底层是 Store Engine,它是一个单机版 Local Store Engine,提供了对本地数据的 get/put/scan/delete 操作,该层定义了数据操作接口,用户可以根据自己的需求定制开发相关 Local Store Plugin。目前,NebulaGraph 提供了基于 RocksDB 实现的 Store Engine。在 Local Store Engine 之上是 Consensus 层,实现了 Multi Group Raft,每一个 Partition 都对应了一组 Raft Group。在 Consensus 层上面是 Storage interfaces,这一层定义了一系列和图相关的 API。这些 API 请求会在这一层被翻译成一组针对相应 Partition 的 KV 操作。正是这一层的存在,使得存储服务变成了真正的图存储。否则,Storage Service 只是一个 KV 存储罢了。而 NebulaGraph 没把 KV 作为一个服务单独提出,最主要的原因便是图查询过程中会涉及到大量计算,这些计算往往需要使用图的 Schema,而 KV 层没有数据 Schema 概念,这样设计比较容易实现计算下推,是 NebulaGraph 查询性能优越的主要原因。

    NebulaGraph 基于 C++ 实现,架构设计支持存储千亿顶点、万亿边,并提供毫秒级别的查询延时。我们在 3 台 48U192G 物理机搭建的集群上灌入 10 亿美食图谱数据对 NebulaGraph 的功能进行了验证。

    • 一跳查询 TP99 延时在 5ms 内,两跳查询 TP99 延时在 20ms 内,一般的多跳查询 TP99 延时在百毫秒内。

    • 集群在线写入速率约为20万 Records/s。

    • 支持通过 Spark 任务离线生成 RocksDB 底层 SST File,直接将数据文件载入到集群中,即类似 HBase BulkLoad 能力。

    • 提供了类 SQL 查询语言,对于新增的业务需求,只需构造 NebulaGraph SQL 语句,易于理解且能满足各类复杂查询要求。

    • 提供联合索引、GEO 索引,可通过实体属性或者关系属性查询实体、关系,或者查询在某个经纬度附近 N 米内的实体。

    • 一个 NebulaGraph 集群中可以创建多个 Space (概念类似 MySQL 的DataBase),并且不同 Space 中的数据在物理上是隔离的。

    4 图数据库平台建设

    图 4

    为了统一管理图数据,减少工程同学在图数据库集群上的运维压力,我们基于开源分布式图数据库 NebulaGraph,搭建了一套一站式图数据库自助管理平台(见图 4),该平台包含以下 4 层:

    • 数据应用层。 业务方可以在业务服务中引入图谱 SDK,实时地对图数据进行增删改查。

    • 数据存储层。 支持两种图数据库集群的部署。

      • 第一种部署方式是 CP 方案,即 Consistency & Partition tolerance。单集群部署,集群中机器数量大于等于副本的数量,副本数量大于等于 3 。只要集群中有大于副本数一半的机器存活,整个集群就可以对外正常提供服务。CP 方案保证了数据读写的强一致性,但这种部署方式下集群可用性不高。

      • 第二种部署方式是 AP 方案,即  Availability & Partition tolerance。在一个应用中部署多个图数据库集群,每个集群数据副本数为 1 ,多集群之间进行互备。这种部署方式的好处在于整个应用对外的可用性高,但数据读写的一致性要差些。

    • 数据生产层。 图数据主要有两种来源,第一种是业务方把数仓中数据通过 ETL Job 转成点和边的 Hive 表,然后离线导入到图数据库中;第二种是业务线上实时产生的数据、或者通过 Spark/Flink 等流式处理产生的近线数据,调用在线批量写接口实时灌到图数据库中。

    • 支撑平台。 提供了 Schema 管理、权限管理、数据质检、数据增删改查、集群扩缩容、图谱画像、图数据导出、监控报警、图可视化、集群包管理等功能。

    与业界方案相比,团队主导设计的图数据库平台除了支持存储千亿顶点、万亿边,具备毫秒级别查询能力外,还提供了如下四项能力:应用可用性 SLA 达 99.99%;支持每小时百亿量级数据导入;实时写入数据时保证多集群数据最终一致性;易用的图谱可视化能力。下面将介绍具体的设计思路。

    4.1 高可用模块设计

    图 5

    首先介绍单应用多集群高可用模块的设计(AP 方案)。为什么有 AP 方案的设计呢?因为接入图数据库平台的业务方比较在意的指标是集群可用性。在线服务对集群的可用性要求非常高,最基础的要求是集群可用性能达到 4 个 9,即一年里集群的不可用时间要小于一个小时。对于在线服务来说,服务或者集群的可用性是整个业务的生命线,如果这点保证不了,即使集群提供的能力再多再丰富,那么业务方也不会考虑使用,可用性是业务选型的基础。

    另外,公司要求中间件要有跨区域容灾能力,即要具备在多个地域部署多集群的能力。我们分析了平台接入方的业务需求,大约 80% 的场景是 T+1 全量导入数据、线上只读。在这种场景下,对图数据的读写强一致性要求并不高,因此我们设计了单应用多集群这种部署方案。

    AP 方案部署方式可以参考图 5,一个业务方在图数据库平台上创建了 1 个应用并部署了 4 个集群,其中北京 2 个、上海 2 个,平时这 4 个集群同时对外提供服务。假如现在北京集群 1 挂了,那么北京集群 2 可以提供服务。如果说真那么不巧,北京集群都挂了,或者北京侧对外的网络不可用,那么上海的集群也可以提供服务。在这种部署方式下,平台会尽可能地通过一些方式来保证整个应用的可用性。然后每个集群内部尽量部署同机房的机器,因为图数据库集群内部 RPC 非常多,如果有跨机房或者跨区域的频繁调用,整个集群对外的性能会比较低。

    图 6

    高可用模块主要包含下面 4 个部分,如上图 6 所示:

    第一部分是右侧的图数据库 Agent,它是部署在图数据库集群的一个进程,用来收集机器和图数据库三个核心模块的信息,并上报到图数据库平台。Agent 能够接收图数据库平台的命令并对图数据库进行操作。

    第二部分是图数据库平台,它主要是对集群进行管理,并同步图数据库集群的状态到配置中心。

    第三部分是图数据库 SDK,主要负责管理连接到图数据库集群的连接。如果业务方发送了某个查询请求,SDK 会进行集群的路由和负载均衡,选择出一条高质量的连接来发送请求。此外,SDK 还会处理图数据库集群中问题机器的自动降级以及恢复,并且支持平滑切换集群的数据版本。

    第四部分是配置中心,类似 ZooKeeper,存储集群的当前状态。

    4.2 每小时百亿量级数据导入模块设计

    图 7

    第二个模块是每小时百亿量级数据导入模块,平台在 2019 年底- 2020 年初全量导入数据的方式是调用 NebulaGraph 对外提供的批量数据导入接口,这种方式的数据写入速率大概是每小时 10 亿级别,导入百亿数据大概要耗费 10 个小时,耗时较长。此外,在以几十万每秒的速度导数据的过程中,会长期占用机器的 CPU、IO 资源,一方面会对机器造成损耗,另一方面数据导入过程中集群对外提供的读性能会变弱。

    为了解决上面两个问题,平台进行了如下优化:在 Spark 集群中直接生成图数据库底层文件 SST File,再借助 RocksDB 的 Bulkload 功能直接 ingest 文件到图数据库。

    数据导入的核心流程可以参考图 7,当用户执行导数据操作后,图数据库平台会向公司的 Spark 集群提交一个 Spark 任务,在 Spark 任务中会生成图数据库里相关的点、边以及点索引、边索引相关的 SST 文件,并上传到美团的 S3 云存储上。文件生成后,图数据库平台会通知应用中多个集群去下载这些存储文件,之后完成 ingest 跟 compact 操作,最后完成数据版本的切换。

    为兼顾各个业务方的不同需求,平台统一了应用导入、集群导入、离线导入、在线导入,以及全量导入、增量导入这些场景,然后细分成下面九个阶段,从流程上保证在导数据过程中应用整体的可用性:SST File 生成 、SST File 下载 、ingest、compact、数据校验、增量回溯、数据版本切换、集群重启、数据预热。

    4.3 实时写入多集群数据同步模块设计

    图 8

    第三个模块是实时写入多集群数据同步模块,平台约有 15% 的需求场景是在实时读取数据时,还要把新产生的业务数据实时写入集群,并且对数据的读写强一致性要求不高。就是说,业务方写到图数据库里的数据,不需要立马能读到。针对上述场景,业务方在使用单应用多集群这种部署方案时,多集群里的数据需要保证最终一致性。针对这一需求,我们做了以下设计。

    第一部分是引入 Kafka 组件,业务方在服务中通过 SDK 对图数据库进行写操作时,SDK 并不直接写图数据库,而是把写操作写到 Kafka 队列里,之后由该应用下的多个集群异步消费这个 Kafka 队列。

    第二部分是集群在应用级别可配置消费并发度,来控制数据写入集群的速度。具体流程如下:

    • SDK 对用户写操作语句做语法解析,将其中点边的批量操作拆解成单个点边操作,即对写语句做一次改写。

    • Agent 消费 Kafka 时确保每个点及其出边相关操作在单个线程里顺序执行(见图 8),保证这点就能保证各个集群执行完写操作后最终的结果是一致的。

    • 并发扩展:通过改变 Kafka 分片数、Agent 中消费 Kafka 线程数来调整 Kafka 中操作的消费速度。如果未来图数据库支持事务的话,上面的配置需要调整成单分片单线程消费,有必要对设计方案再做优化调整。

    图 9

    第三部分是在实时写入数据过程中,平台可以同步生成一个全量数据版本,并做平滑切换(见图 9),确保数据的不重、不漏、不延迟。

    4.4 图可视化模块设计

    图 10

    第四个模块是图可视化模块(见图10),主要是用于解决子图探索问题。当用户在图数据库平台通过可视化组件查看图数据时,能尽量通过恰当的交互设计来避免因为节点过多而引发爆屏。主要包括以下几个功能:

    • 通过 ID 或者索引查找顶点。

    • 能查看顶点和边的卡片(卡片中展示点边属性和属性值),可以单选、多选、框选以及按类型选择顶点。

    • 图探索,当用户点击某个顶点时,系统会展示它的一跳邻居信息,包括该顶点有哪些出边?通过这个边它能关联到几个点?该顶点的入边又是什么情况?通过这种一跳信息的展示,用户在平台上探索子图的时候,可快速了解到周边的邻居信息,更快地进行子图探索。在探索过程中,平台也支持通过属性对边进行过滤。

    • 图编辑能力,让平台用户在不熟悉 NebulaGraph 语法的情况下也能增删改点边数据,对线上数据进行临时干预。

    5 业务实践

    5.1 智能助理

    该项目数据是基于美团商户数据、用户评论构建的餐饮娱乐知识图谱,覆盖美食、酒店、旅游等领域,包含 13 类实体和 22 类关系。目前,点边数量大概在百亿级别,数据 T+1 全量更新,主要用于解决搜索或者智能助理里 KBQA(全称:Knowledge Based Question Answer)类问题。核心处理流程是通过 NLP 算法识别关系和实体后构造出 NebulaGraph SQL 语句,再到图数据库获取数据。

    典型的应用场景包括商场找店,比如,某个用户想知道望京新荟城这个商场有没有海底捞,系统可以快速查出结果告诉用户;另一个场景是标签找店,用户想知道望京 SOHO 附近有没有适合情侣约会的餐厅,或者可以多加几个场景标签,系统都可以帮忙查找出来。

    5.2 搜索召回

    该项目数据是基于医美商家信息构建的医美知识图谱,包含 9 类实体和 13 类关系,点边数量在百万级别,同样也是 T+1 全量更新,主要用于大搜底层实时召回,返回与 Query 相关的商户、产品或医生信息,解决医美类搜索词少结果、无结果问题。比如,某个用户搜“啤酒肚”这种症状、或者“润百颜”这类品牌,系统可以召回相关的医美门店。

    5.3 图谱推荐理由

    该项目数据来自用户的画像信息、商户的特征信息、用户半年内收藏/购买行为,数据量级是 10 亿级别,T+1 全量更新。现在美团 App 和点评 App 上默认的商户推荐列表是由深度学习模型生成的,但模型并不会给出生成这个列表的理由,缺少可解释性。

    而在图谱里用户跟商户之间天然存在多条连通路径,项目考虑选出一条合适路径来生成推荐理由,在 App 界面上展示给用户推荐某家店的原因。该项目基于用户的协同过滤算法来生成推荐理由,在家乡、消费水平、偏好类目、偏好菜系等多个组合维度中找出多条路径,然后给这些路径打分,选出一条分值较高的路径,之后按照特定 Pattern 产出推荐理由。通过上述方式,就可以获得“在北京喜欢北京菜的山东老乡都说这家店很赞”,或者“广州老乡都中意他家的正宗北京炸酱面”这类理由。

    5.4 代码依赖分析

    该项目把代码库中代码依赖关系写入到图数据库。代码库中存在很多服务代码,这些服务会包括对外提供的接口,这些接口的实现依赖于该服务中某些类的成员函数,这些类的成员函数又依赖了本类的成员变量、成员函数或者其它类的成员函数,那么它们之间的依赖关系就形成了一张图,可以把这个图写到图数据库里做代码依赖分析。

    典型应用场景是精准测试:当开发同学完成需求并向公司的代码仓库提交了 PR 后,可以把更改实时地写到图数据库中。这样的话,开发同学就能查到他所写的代码影响了哪些外部接口,并且借助图可视化组件查看调用路径。如果开发同学本来是要改接口 A 的行为,改了很多代码,但是他可能并不知道他改的代码也会影响到对外接口 B、C、D,这时候就可以用代码依赖分析来做个 Check,增加测试的完备性。

    6 总结与展望

    目前,图数据库平台基本具备了对图数据的一站式自助管理功能。如果某个业务方要使用这种图数据库能力,那么业务方可以在平台上自助地创建图数据库集群、创建图的 Schema、导入图数据、配置导入数据的执行计划、引入平台提供的 SDK 对数据进行操作等等。平台侧主要负责各业务方图数据库集群的稳定性。目前,美团有三四十个业务已经在该平台上落地,基本满足了各个业务方的需求。

    未来规划主要有两个方向,第一,根据业务场景优化图数据库内核,提升平台稳定性,开发的通用 Feature 持续反哺 NebulaGraph 社区。第二,挖掘更多的图数据价值。现在平台仅支持图数据存储及多跳查询这种基本能力,后续将基于 NebulaGraph 去探索图学习、图计算的能力,为平台用户提供更多挖掘图数据价值的功能。

    7 作者信息

    登昌、梁帅、高辰、杨鑫、尊远、王超等,均为美团搜索与NLP部工程师。

    8 参考资料

    [1] Jim Webber, Emil Eifrem, Ian Robinson. Graph Databases(2nd Edition). O'Reilly Media, Inc. 2013: chapter 2.

    [2] Neo4j Database.

    [3] ArangoDB.

    [4] Virtuoso.

    [5] TigerGraph.

    [6] RedisGraph.

    [7] JanusGraph.

    [8] HugeGraph.

    [9] DGraph.

    [10] NebulaGraph.

    [11] RDF.

    [12] BadgerDB.

    [13] RocksDB.

    [14] LDBC-SNB数据集:关联数据基准委员会提供的评测数据集,包含26亿顶点、177亿关系.

    [15] NebulaGraph Architecture — A Bird’s View.

    [16] An Introduction to NebulaGraph's Storage Engine.

    阅读更多

    ---

    前端 |  算法 | 后端 | 数据

    安全 | Android | iOS  | 运维 | 测试

    ----------  END  ----------

    招聘信息

    如果你对“图存储”、“图学习”、“图计算”感兴趣,欢迎给我们投递简历,投递邮箱:zhaodengchang@meituan.com。

    也许你还想看

      | KDD Cup 2020 自动图学习比赛冠军技术方案及在美团广告的实践

      | 美团内部讲座|周烜:华东师范大学的数据库系统研究

      | 美团MySQL数据库巡检系统的设计与应用

    展开全文
  •   本文主要对GEE中的各类外部数据导入、下载与管理以及数据与代码分享...  首先,提到GEE的外部数据管理,不得不提及目前已经停止服务但曾经赫赫有名的Fusion Tables。Fusion Tables是谷歌提供用以存储、可视化与分

      本文主要对GEE中的各类外部数据导入、下载与管理以及数据与代码分享等操作加以介绍。本文是谷歌地球引擎(Google Earth Engine,GEE)系列教学文章的第七篇,更多GEE文章请参考专栏:GEE学习与应用(https://blog.csdn.net/zhebushibiaoshifu/category_11081040.html)。

      首先,提到GEE的外部数据管理,不得不提及目前已经停止服务但曾经赫赫有名的Fusion TablesFusion Tables是谷歌提供用以存储、可视化与分享数据的网络应用程序,在其退役前在GEE中尤为常见,常用来导入矢量数据(GEE中栅格数据的导入方式在当初和目前都是一致的,没有发生大的变化);但这一网络应用程序在2019年12月就被谷歌官方关闭。

    在这里插入图片描述

      尽管Fusion Tables已经被关闭,但本文开头还是对其当初的外部矢量数据导入方法加以回顾,从而找寻GEE中目前最新的外部矢量数据导入方法Fusion Tables外部矢量数据导入方法相比的优势。

      在当年,若需要通过Fusion Tables导入矢量数据,首先需要打开谷歌云端硬盘官网(https://drive.google.com/)。

    在这里插入图片描述

      接下来,选择左上角的“New”。

    在这里插入图片描述

      随后,依次选择“More”→“Connect more apps”。

    在这里插入图片描述

      在弹出的界面中,搜索fusion tables

    在这里插入图片描述

      在得到搜索结果后,点击进入弹出的界面,进行表格类型数据的导入即可。当然,由于目前Fusion Tables已经退役,上述搜索界面已经找不到对应的数据导入界面了。

      上述即为当年Fusion Tables导入矢量数据的方式,可以看到虽然并不算麻烦,但是也略显繁琐,尤其是需要导入大量数据时,就显得比较费时间。

      那么,最新的GEE外部数据导入方式(包括栅格与矢量数据)则显得非常简洁;由于目前GEE中栅格与矢量数据导入方法已经统一,我们本文就仅以一景外部栅格遥感影像的导入与数据管理为例进行介绍。

      首先,打开GEE,在左上角选择“Assets”;并选择“Image Upload”下属的这一项。

    在这里插入图片描述

      在弹出的界面中,选择遥感影像文件、在GEE Asset中的存放路径、元数据,同时对金字塔构建规则、掩膜模式等加以调整。在这里需要注意,GEE Asset中的存放路径(也就是下图中的Asset Name)所填内容如果不包含符号/,则自动存放在自己GEE帐号中“Asset”的总文件夹下。

    在这里插入图片描述

      相反,如果大家不想放到总文件夹下,而想放到某个单独的子文件夹下(例如假设想放到WuhanBC这个子文件夹下),就需要在存放路径中填写/WuhanBC/Test

    在这里插入图片描述

      在本文中,我们直接将导入的遥感影像放在总文件夹下,其他配置如下图所示:

    在这里插入图片描述

      随后,可以在GEE右侧“Tasks”中看到遥感影像的上传进度。

    在这里插入图片描述

      等待一定时间后,可以看到右侧显示已经上传完毕,同时在左侧“Asset”中可以看到Test这个遥感影像已经存在(并且是在总文件夹下)。

    在这里插入图片描述

      单击这一遥感影像的名称,可以看到其空间位置、数据大小、波段数量、修改时间等基本信息。

    在这里插入图片描述

      其中,“BANDS”一栏可以看到遥感影像的波段信息。

    在这里插入图片描述

      “PROPERTIES”一栏可以看到遥感影像的元数据信息。这里需要注意,元数据是当初我们在导入数据时选择添加的,如果当初没有添加则此处就不会有信息。

    在这里插入图片描述

      选择“IMPORT”,即可将数据导入GEE地图中。

    在这里插入图片描述

      可以看到,导入后的效果和第二篇GEE教学博客(https://blog.csdn.net/zhebushibiaoshifu/article/details/117296956)中导入的Landsat 8 Collection 1 Tier 1的大气表观反射率TOA Reflectance产品效果是一样的。

    在这里插入图片描述

      同样,按照第二篇GEE教学博客(https://blog.csdn.net/zhebushibiaoshifu/article/details/117296956)中内容,可以对其加以重命名并在地图中加以显示:

    Map.addLayer(Wuhan,{},"WUHAN");
    

    在这里插入图片描述

      此外,点击“SHARE”可以对这一景遥感影像加以分享。

    在这里插入图片描述

      在弹出的界面中,可以对遥感影像的分享权限加以配置。

    在这里插入图片描述

      此外,如果我们需要下载GEE中的栅格图像,可以基于.getDownloadURL({})函数实现:

    var URL=Wuhan.getDownloadURL({});
    print(URL);
    

      其中,.getDownloadURL({})获取对应栅格数据的下载链接,并通过print()函数加以打印。

      我们这里就直接以刚刚上传好的遥感影像为例进行下载;但是遇到一个问题:我们上传的遥感影像空间区域比较大,波段数量比较多,导致整幅图像下载时超出了GEE下载最大数据量的限制。

    在这里插入图片描述

      我们可以再来看一下遥感影像中波段的信息,从而尝试选择其中一个波段下载。

    在这里插入图片描述

      依据第六篇GEE教学博客(https://blog.csdn.net/zhebushibiaoshifu/article/details/119145230)中内容,依据波段名称对某一波段加以选择,并对选择后的单波段栅格图像加以下载:

    var band=Wuhan.select("b10");
    print(band);
    var URL=band.getDownloadURL({});
    print(URL);
    

      可是发现,单一波段图像虽然在数据量上显著下降,但是还是超出了GEE数据下载的限制。

    在这里插入图片描述

      因此,我们手动划定一个矢量矩形区域,并对单波段图像进行裁剪,从而减少下载数据的空间范围,看看能不能下载。

      在地图左上角,选择以下按钮:

    在这里插入图片描述

      并在原有遥感影像范围内划定一个小的区域:

    在这里插入图片描述

      可以看到,划定完毕后这一矢量区域已经加入了GEE中。

    在这里插入图片描述

      对其加以重命名后,我们依据第三篇GEE教学博客(https://blog.csdn.net/zhebushibiaoshifu/article/details/117390431)中内容,依据刚刚划定的矢量区域对单波段遥感影像加以裁剪,并重新执行.getDownloadURL({})函数。

    var band=Wuhan.select("b10").clip(smallarea);
    print(band);
    var URL=band.getDownloadURL({});
    print(URL);
    

      可以看到,此时右侧“Console”中已经出现了下载链接,说明数据量已经符合要求了。

    在这里插入图片描述

      点击下载路径即可实现对应数据的下载。

    在这里插入图片描述

      最后,再介绍“Repository”的新建方法;其实这里的“Repository”就是前面我们提及的存放外部遥感影像的子文件夹。

      选择“NEW”→“Repository”。

    在这里插入图片描述

      在弹出的界面中选择“Repository”的名称即可。

    在这里插入图片描述

      对于建立好的“Repository”,可以点击其右侧的齿轮图标进行分享设置。

    在这里插入图片描述

      分享有多种方式,包括用GEE内部的链接分享,以及通过Git方式分享。对“Repository”进行共享,即可实现将其内部的代码分享给他人。

    在这里插入图片描述

    欢迎关注公众号/CSDN/知乎/微博:疯狂学习GIS

    展开全文
  • Kyuubi是网易数帆旗下易数大数据团队开源的一个企业级数据管理平台,建立在Apache Spark之上。Kyuubi提供一个高性能的通用JDBC和SQL执行引擎,通过它,用户能够像处理普通数据一样处理大数据。本文将详细解读...

    Kyuubi是网易数帆旗下易数大数据团队开源的一个企业级数据湖管理平台,建立在Apache Spark之上。Kyuubi提供一个高性能的通用JDBC和SQL执行引擎,通过它,用户能够像处理普通数据一样处理大数据。本文将详细解读Kyuubi的架构设计。

    引言

    开源大数据项目的繁荣带来了强大的大数据平台,而对于负责数据价值挖掘的终端用户而言,平台的技术门槛是另一种挑战。如果能将平台的能力统合,并不断地优化和迭代,让用户能够通过JDBC和SQL这种最普遍最通用的技术来使用,数据生产力将可以得到进一步的提升。

    Kyuubi就是在此背景下诞生的一个企业级数据湖管理平台,它能够作为一个高性能的通用JDBC和SQL执行引擎,促进用户像处理普通数据一样处理大数据。

    在这里插入图片描述

    Kyuubi提供了一个标准化的JDBC接口,在大数据场景下可以方便地进行数据访问。终端用户可以专注于开发自己的业务系统和挖掘数据价值,而无需了解底层的大数据平台(计算引擎、存储服务、元数据管理等)。

    Kyuubi依赖Apache Spark提供高性能的数据查询能力,引擎能力的每一次提升,都能帮助Kyuubi的性能实现质的飞跃。此外,Kyuubi通过引擎缓存提升了ad-hoc响应能力,并通过横向扩展和负载均衡提升了并发能力。

    Kyuubi提供完整的认证和授权服务,确保数据和元数据的安全。

    Kyuubi提供强大的高可用性和负载均衡,以保证SLA的承诺。

    Kyuubi提供两级弹性资源管理架构,有效提高资源利用率,同时覆盖所有场景的性能和响应需求,包括交互式,或批处理和点查询,或全表扫描。

    Kyuubi拥抱Spark,并在Spark之上构建了一个生态系统,这它使得能够快速扩展现有的生态系统,并引入新的特性,例如云原生支持和Data Lake/Lake House支持。

    Kyuubi的愿景是建立在Apache Spark和Data Lake技术之上,统一门户,成为一个理想的数据湖管理平台。它可以以纯SQL的方式支持数据处理(如ETL)和分析(如BI)。所有的工作负载都可以在同一个平台上完成,使用一份数据,一个SQL接口。

    架构概述

    Kyuubi系统的基本技术架构如下图所示。

    在这里插入图片描述

    图的中间部分是Kyuubi服务端的主要部分,它处理来自图像左边所示的客户端的连接和执行请求。在Kyuubi中,这些连接请求被维护为Kyuubi Session,执行请求被维护为Kyuubi Operation,并与相应的session进行绑定。

    Kyuubi Session的创建可以分为两种情况:轻量级和重量级。大多数session的创建都是轻量级的,用户无感知。唯一重量级的情况是在用户的共享域中没有实例化或缓存SparkContext,这种情况通常发生在用户第一次连接或长时间没有连接的时候。这种一次性成本的session维护模式可以满足大部分的ad-hoc快速响应需求。

    Kyuubi以松耦合的方式维护与SparkConext的连接。这些SparkContexts可以是本服务实例在客户端部署模式下在本地创建的Spark程序,也可以是集群部署模式下在Yarn或Kubernetes集群中创建的。在高可用模式下,这些SparkConext也可以由其他机器上的Kyuubi实例创建,然后由这个实例共享。

    这些SparkConext实例本质上是由Kyuubi服务托管的远程查询执行引擎程序。这些程序在Spark SQL上实现,并对SQL语句进行端到端编译、优化和执行,以及与元数据(如Hive Metastore)和存储(如HDFS)服务进行必要的交互,最大限度地发挥Spark SQL的威力。它们可以自行管理自己的生命周期,自行缓存和回收,并且不受Kyuubi服务器上故障转移的影响。

    接下来,我们来分享一下Kyuubi的一些关键设计理念。

    统一接口

    Kyuubi实现了Hive Service RPC模块,它提供了与HiveServer2和Spark Thrift Server相同的数据访问方式。在客户端,您可以构建奇妙的业务报表、BI应用,甚至ETL工作,只通过Hive JDBC模块。

    您只需要熟悉结构化查询语言(SQL)和Java数据库连接(JDBC)就可以处理海量数据。它可以帮助您专注于业务系统的设计和实现。

    • SQL是访问关系型数据库的标准语言,在大数据生态中也非常流行。

    • JDBC为工具/数据库开发者提供了一个标准的API,使得使用纯Java API编写数据库应用成为可能。

    • 目前有很多免费或商业的JDBC工具。

    运行时资源弹性

    Kyuubi和Spark Thrift Server(STS)最大的区别在于,STS是一个单一的Spark应用。例如,如果一个应用运行在Apache Hadoop Yarn集群上,这个应用也是一个单一的Yarn应用,创建后只能存在于Yarn集群的特定固定队列中。Kyuubi支持提交多个Spark应用。

    对于资源管理,Yarn失去了资源管理器的角色,没有起到相应的资源隔离和共享的作用。当来自客户端的用户拥有不同的资源队列权限时,这种情况下STS将无法处理。

    对于数据访问,单个Spark应用在全球范围内只有一个用户,也就是sparkUser,我们必须赋予它一个类似超级用户的角色,才能让它对不同的客户端用户进行数据访问,这在生产环境中是一种极不安全的做法。

    Kyuubi会根据客户端的连接请求创建不同的Spark应用,这些应用可以放在不同的共享域中,供其他连接请求共享。

    Kyuubi在启动过程中不会占用集群管理器(如Yarn)的任何资源,如果没有任何活跃的session与SparkContext交互,Kyuubi会将所有资源返还。

    Spark还提供了动态资源分配,根据工作负载动态调整应用程序占用的资源。这意味着应用可以将不再使用的资源还给集群,当有需求时再次请求。如果多个应用程序在您的Spark集群中共享资源,这个特性特别有用。

    通过这些特性,Kyuubi提供了一个两级弹性资源管理架构,以有效提高资源利用率。

    比如说,

    ./beeline - u 'jdbc:hive2://kyuubi.org:10009/; \
      hive.server2.proxy.user=tom# \
      spark.yarn.queue=thequeue; \
      spark.dynamicAllocation.enabled=true \
      spark.dynamicAllocation.maxExecutors=500 \
      spark.shuffle.service.enabled=true \
      spark.executor.cores=3; \
      spark.executor.memory=10g'
    

    如果名为tom的用户打开了像上面这样的连接,Kyuubi将尝试在Yarn集群中名为thequeue的队列中创建一个拥有[3,500]个执行器(3核,每个10g mem)的Spark SQL引擎应用程序。

    一方面,由于tom启用了Spark的动态资源请求特性,Spark会根据SQL操作的规模和队列中的可用资源,高效地请求和回收程序内的执行器。另一方面,当Kyuubi发现程序闲置时间过长时,也会对程序本身进行回收。

    高可用性与负载均衡

    对于企业服务来说,服务水平协议(SLA)的承诺必须达到很高的水平。而并发量也需要足够强大,以支持整个企业的请求。Spark Thrift Server作为单一的Spark应用,在没有实现High Availability的情况下,很难满足SLA和并发的要求。当有大的查询请求时,在元数据服务访问、Spark Driver的调度和内存压力,或者是应用的整体计算资源限制等方面都有潜在的瓶颈。

    Kyuubi基于ZooKeeper同时提供了高可用和负载均衡解决方案,如下图所示。

    在这里插入图片描述

    我们从上到下进行分解。

    1. 图中最上面的是客户端层,客户端可以从服务发现层的命名空间中找到多个注册的Kyuubi实例(k.i.),然后选择一个连接。注册到同一命名空间的Kyuubi实例相互提供了负载均衡的能力。

    2. 被选中的Kyuubi实例将从服务发现层的eng-namespace中选择一个可用的引擎实例(e.i.)建立连接。如果没有找到可用的实例,它将创建一个新的实例,等待引擎完成注册,然后继续连接。

    3. 如果是同一个人请求新的连接,则会将连接设置为同一个或另一个Kyuubi实例,但引擎实例会被重复使用。

    4. 对于来自不同用户的连接,将重复步骤2和3。这是因为在服务发现层中,用于存储引擎实例地址的命名空间是基于用户隔离的(默认情况下),不同用户不能跨命名空间访问其他实例。

    认证与授权

    在一个安全的集群中,服务应该能够识别和认证呼叫者。由于用户声称的事实并不意味着这一定是真的。Kyuubi的认证过程用于验证客户端用来与Kyuubi服务器对话的用户身份。一旦完成,如果成功,客户端和服务器之间将建立一个可信的连接;否则拒绝。

    经过验证的客户端用户也将是创建关联引擎实例的用户,然后可以应用数据库对象或存储的授权。我们还创建了一个Submarine: Spark Security作为外部插件,实现基于SQL标准的细粒度授权。

    结论

    Kyuubi是一个统一的多租户JDBC接口,用于大规模数据处理和分析,建立在Apache Spark™之上。它扩展了Spark Thrift Server在企业应用中的场景,其中最重要的是多租户支持。

    除了网易集团业务,目前已有网约车、餐饮零售、物流等领域多家企业在其大数据技术栈中采用了Kyuubi。欢迎大家加入到Kyuubi项目,共促大数据价值最大化!

    作者简介: 燕青,网易数帆-易数事业部高级工程师,主要专注于开源大数据领域,是Apache Spark贡献者,主要贡献于SQL/Core模块。他也是Kyuubi项目和spark-authorizer项目的发起人,后者通过Apache Ranger解决Apache Spark的安全问题。他也是Apache Submarine Committer,致力于改进Submarine项目作为机器学习平台。

    展开全文
  • Flink流处理查询外部数据源的解决方法 在流处理中,常涉及到与外部数据源的交互。例如在实时数仓的设计中通常是流式采集用户的浏览、下单等行为,但是用户信息,SKU、SPU等信息因为是维度表不适合通过流的方式读取...
  • 我们谈论数据中台之前,我们也听到过数据平台数据仓库、数据湖的相关概念,它们都与数据有关系,但他们和数据中台有什么样的区别,下面我们将分别介绍数据平台数据仓库数据湖和数据中台。相关概念数...
  • Kubernetes连接外部数据

    千次阅读 2021-01-19 21:13:09
    Kubernetes架构下比较核心的问题是数据如何persistance,虽然提供了Persistent volumn的方式,但是对于像数据库之类的产品在kubernetes集群环境中运行和管理还是很有难度的,Kubernetes提供了endpoints这种模式让外部...
  • 大数据平台建设方案 (项目需求与技术方案) 一、项目背景 ...大数据平台整合省社会经济发展资源,打造集数据采集、数据处理、监测管理、预测预警、应急指挥、可视化平台于一体的大数据平台,以信息化提...
  • 在过去的一个月里,以精准情报为驱动的永安在线API安全管控平台价值全面释放,赋能众多企业实现从API资产自动化管理、API风险主动感知到攻击溯源的闭环安全管控,解除了因API安全侧风险造成的数据安全威胁。...
  • 数据治理系列(四):数据质量管理

    千次阅读 2021-01-13 14:09:53
    数据质量管理是对数据从计划、获取、存储、共享、维护、应用、消亡生命周期的每个阶段里可能引发的数据质量问题,进行识别、度量、监控、预警等一系列管理活动,并通过改善和提高组织的管理水平使得数据质量获得...
  • 1、医院数据集成平台建设的背景 国内大多数三级医院信息化起步于上世纪90年代初,至今发展有将近30年历史,主要分为四个阶段: 第一阶段,财务电子化模式:上世纪90年代中期,北上广的三甲医院已开始引入基于NOVEL...
  • 如果要删除干净外部表(正常删外部表是只删除表结构,元数据与hdfs文件不会删除)要先把外部表转换为内部表 hive -> ALTERTABLE app.app_th_report_share_cvr_di SET TBLPROPERTIES('EXTERNAL'='False'); hive ...
  • 因此,不断扩展企业内外部数据需求范围,及时了解梳理各类数据需求,提升数据需求响应速度,才可以最大程度发挥数据价值,使数据管理更充分的支撑业务发展。 数据管理成熟度评估模型(DCMM)中将“数据需求”作为...
  • 毋庸置疑的是,数据在机器学习中起着至关重要的作用。每个机器学习模型实例都是使用静态数据集的形式进行训练和评估,这些数据集的特性从根本上影响了模型的行为: 如果一个模型的部署环境与它的训练或...
  • 奇技 · 指南360系统部成立于2010年,负责整个集团的大数据底层基础平台建设(包括分布式存储、分布式计算、大数据搜索、图计算等各类大数据服务),目前服务于整个集团30+部门,1000...
  • V2X车路协同云控数据平台业务整理

    千次阅读 2021-05-08 13:13:45
    清楚【V2X车路协同云控数据平台】是做什么的?为什么需要?如何去做?(wwh的问题what\why\how)肯定是必选项; 其次我们还要清楚需要解决的核心问题有哪些: 车端和路侧与云端监控平台数据的上下行整体通路是怎样的...
  • HarmonyOS 媒体数据管理模块支持多媒体数据管理相关的功能开发,常见操作如:获取媒体元数据、截取帧数据等。 在进行应用的开发前,应了解以下基本概念: PixelMap:PixelMap 是图像解码后无压缩的位图格式,用于...
  • 点击上方蓝色字体,选择“设为星标”回复”资源“获取更多资源大数据技术与架构点击右侧关注,大数据开发领域最强公众号!大数据真好玩点击右侧关注,大数据真好玩!导读:随着近几年数据湖概念的兴起...
  • 【单选题】51单片机外部扩展存储器时,分时复用做数据线和低8位地址线的是( ) 【单选题】51单片机的定时器T1用做计数方式时计数脉冲是( ) 【单选题】当51单片机应用系统需要扩展外部存储器或其他接口芯片时,( )可作为...
  • 本文从数据治理角度,阐述数据标准、元数据、主数据数据模型的概念、关系。 这些都是数据治理中的重要概念,其中元数据、主数据也是数据治理的核心中的核心。只有理解了这些概念,才能更好的理解数据治理。
  • 详解数据治理九大核心领域

    千次阅读 2021-07-27 00:30:49
    01 前言股份制改革对银行业来说只是一个开始,企业在风险管理、创造价值等方面还有很长的路要走。风险管理要求提供精准的数据模型、创造价值要求充分银行数据资产,这是数据治理的外部推动因素。此外...
  • OpenStack云平台管理

    千次阅读 2021-11-26 20:50:23
    软硬件要求:最少16G内存,至少2CPU ...2.是一个开源的云计算管理平台 3.Apache许可证为授权 图解 openstack组件 1.Horizon组件: --为openstack服务的web控制面板,它可以管理实例,镜像,创建密钥令...
  • 数据治理项目前期调研

    千次阅读 2021-01-13 11:20:08
    随着企业的不断发展进步,业务部门的需求不断增加,企业逐渐上了很多应用系统以及硬件设备,如OA办公协同系统、ERP企业资源管理系统、HR人力资源管理系统、CRM客户关系管理系统等,也在业务发展中沉淀了大量数据,...
  • 对于很多服装企业来说,供应商管理很薄弱,甚至根本不存在,没法保证供应商的绩效。服装企业的战略供应商是个大问题,价格高、交期长、灵活度差。企业与供应商既没有合作协议,也没有定期沟通,与供应商唯一的关系...
  • Datawhale发布2020 中国数据竞赛年鉴报告随着信息时代的发展,数据智能正逐渐渗透到生产、生活等方方面面,如何培养数据人才,促进产学研用协同发展,数据竞赛给出了一条清晰的路径。...
  • 管理和运营是一个全流程的事情,首先我们需要知道有哪些数据(盘点),转化为能够发挥价值的数据资产(治理),再实现数据应用层面的价值(价值实现),也就是最终要能指导业务产出价值。
  • 这种方式一方面有利于应用系统的快速部署,另一方面也保证了数据的集中管理与运营,体现数据的资产、资源属性。 数据中台的出现弥补了数据开发和应用开发之间由于开发速度不匹配而出现的响应力不足等缺陷问题。 ...
  • 数据科学家和权威专家维克托·...数据变成数据资产的前提是有着完整的数据标准管理、数据质量管理、数据安全管理、易于使用的元数据管理和持续产生数据价值管理的从数据产生到销毁的数据全生命周期管理体系。今天小亿
  • 读透《华为数据之道》

    千次阅读 2020-12-28 07:30:00
    这是傅一平的第361篇原创【提醒:公众号推送规则变了,如果您想及时收到推送,麻烦右下角点个在看,或者把本号置顶】正文开始很多年前阿里出了《大数据之路》一书,在数据技术层面给出了有价值的指...
  • 04 外部数据管理(以确保合规遵从为核心) 外部数据是指华为公司引入的外部组织或者个人拥有处置权利的数据,如供应商资质证明、消费者洞察报告等。外部数据治理的出发点是合规遵从优先,与内部数据治理的目的不同...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 620,027
精华内容 248,010
关键字:

外部数据管理平台