数据中台实战课
郭忆
网易大数据专家
31971 人已学习
新⼈⾸单¥59
登录后,你可以任选2讲全文学习
课程目录
已完结/共 19 讲
数据中台实战课
15
15
1.0x
00:00/00:00
登录|注册

10 | 数据服务难道就是对外提供个API吗?

数据中台模型和数据应用的全链路打通
数据导出到中间存储
解决了不同接口对同一份数据的需求
资源隔离
弹性伸缩
服务的高可用
构建API 集市,实现接口复用
逻辑模型,实现数据的复用
利用中间存储,加速数据查询
推和拉的数据交付方式
全链路打通
数据网关
接口规范化定义
如何确保数据服务是数据中台的唯一出口
数据自动导出
逻辑模型
云原生
数据服务应该具备的八大功能
思考时间
数据服务系统架构设计
数据服务功能设计
数据服务功能设计和系统架构设计

该思维导图由 AI 生成,仅供参考

你好,我是郭忆。
在上一讲中,我为你介绍了为什么必须要有数据服务,你可以看到,数据服务在数据建设中发挥着重要的作用。那有的人可能会好奇了,数据服务到底长什么样子呢? 是不是只对外提供一个 API? 真的有这么简单吗?接下来,我们就带着这些问题,学习今天的内容。
而我希望你能在学完这部分内容之后,真正掌握数据服务的产品功能设计和系统架构设计。因为这会对你设计一个数据服务,或者选择一个商业化产品,有很大的帮助。

数据服务应该具备的八大功能

我认为,数据服务应该具备八个功能,只有具备这些功能,才能解决我们在上一讲提到的问题。比如,数据接入方式多样,接入效率低;数据和接口没办法共享;不知道数据被哪些应用访问……
那么为了让你更好地理解数据服务的功能,我来讲个小故事。
你肯定去过菜鸟驿站取快递吧?假设有一个很大的菜鸟驿站,里面有很多组货架,每个货架前都有一些工作人员帮助我们取快递,同时也有很多队伍排队。
取快递,要先约定好接口(比如统一使用收货码来取货)。然后,为了保证不同队伍都能取到快递,我们要对每个队伍做一些限流(比如一个队伍一次只能取一个人)。在你取走快递时,驿站会记录是谁取走了哪个快递,方便后续追查。
这段时间,菜鸟驿站服务开始升级,不仅可以取快递,还提供快递送货上门的服务。除此之外,不同种类的快递对应的货架也变得不同,比如生鲜食品,货架是冷藏冰箱,文件、信封,货架就是文件柜。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

数据服务在数据建设中扮演着重要角色,不仅仅是简单的API提供,而是涉及复杂的产品功能设计和系统架构设计。本文介绍了数据服务的八大功能,包括接口规范化定义、数据网关、全链路打通、推和拉的数据交付方式、利用中间存储加速数据查询、逻辑模型实现数据复用、构建API集市实现接口复用。通过生动的菜鸟驿站取快递的比喻,读者可以形象地理解数据服务的功能。数据服务需要具备认证、权限、限流、监控等功能,同时维护数据模型到数据应用的链路关系,实现数据的推送和拉取,加速数据查询,实现数据复用和接口复用。这些功能对于设计数据服务或选择商业化产品都有很大帮助。通过本文,读者可以深入了解数据服务的重要性和复杂性,为数据建设提供了有益的指导。 文章介绍了数据服务的八大功能,包括接口规范化定义、数据网关、全链路打通、推和拉的数据交付方式、利用中间存储加速数据查询、逻辑模型实现数据复用、构建API集市实现接口复用。同时,通过云原生、逻辑模型和数据自动导出三个关键设计,展示了网易在实现数据服务时的系统架构设计。云原生的高可用性和弹性伸缩特性,逻辑模型的数据动态生成,以及数据自动导出的实时数据查询,为读者提供了架构选型方面的参考。数据服务化对于加速数据交付流程,以及数据交付后的运维管理效率有重要作用,也是数据中台关键的组成部分。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《数据中台实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(35)

  • 最新
  • 精选
  • 你好
    老师,逻辑模型映射物理模型,对于一对多的情况,会不会这多个物理模型是来源于多个存储(比如gp、mysql、hbase),如果是的话,是怎么实现的?

    作者回复: 你好,问的问题挺好的。 一对多的话,一个逻辑模型对应多个物理模型,有可能存在分散在不同的数据源的情况,比如一个是MySQL的表,一个是HBase的表,这个时候,我们就得实现跨数据源的查询,当然,是有限制的,比如只能基于主键做Join,你在构建逻辑模型的时候。 数据服务,接受到请求后,会根据逻辑模型和物理模型的映射关系,把逻辑模型拆分成多个物理查询请求,然后对返回结果进行聚合。这里面必须要限制查询的条数。

    2020-05-02
    2
    10
  • zhuxueyu
    要让数据服务成为数据中台的唯一出口,个人觉得要从三点收口: 1、数据中台的数据能基本覆盖业务的数据需求; 2、业务通过数据服务获取数据更便捷 3、公司层面统一数据出口 - 数据中台

    作者回复: 总结的不错~

    2020-05-17
    7
  • 无语飞涵
    老师留的问题我觉得是需要上升到整个组织架构和流程管理,如,每个业务部门提出的需求,需要经过组织中负责企业级数据的部门团队或者评审会,确认该需求是否是属于数据应用类,必须通过数据中台来实现。

    作者回复: 我觉得,有一个点,你说的很好,技术并不能解决所有的问题,很多问题需要管理机制来配合完成,但是技术本身可以降低管理的复杂性,增强管理的可落地性。 感谢你的留言~

    2020-05-18
    2
    5
  • Bill
    👍 到目前为止,几乎和我设想以及实践方式一致。 数据服务这块儿其实可以更简单 - 被动获取:通过1个API解决所有数据请求,只变响应结构即可 - 主动推送:按需按时推送到使用方,做数据增量/全量同步即可。

    作者回复: 感谢你的认可,看来你对这个问题也有深入的思考。数据服务,最早我们其实只提供了API的方式,但是其实发现很难满足业务的全部要求,比如实时数据推送的这个场景,你靠API就搞不定。所以我们又做了送货上门的推的服务。 感谢你的阅读,下一次留言区再会~

    2020-04-24
    3
    5
  • 风轻云淡
    老师,你之前说数据中台的核心是共享、服务和连接,连接怎么理解?

    作者回复: 其实,这门课,我并没有涉及到OneID的概念,比如都是一个用户,他在不同的app之间,是否可以唯一的标识,这个就是把不同业务系统的相同实体用唯一的ID打通,可以横向关联分析,这就是连接的内涵。另外一个用户,即使在同一个App内,登录前,登陆后,能不能标识成一个人,也属于OneID的概念。 连接、服务、共享,是中台思想的核,不仅仅是在数据中台,同样对应于其他中台。 感谢你的提问,祝好~

    2020-07-18
    4
  • 特种流氓
    实时部分如何融合到数据到数据中台里面来 与离线模型一起统一对外提供服务

    作者回复: 今年之前,网易的离线和实时数据架构,还是采用的Lamda架构,即实时采用kafka+flink的方式,离线采用spark+hdfs的方式,从ods原始数据开始,kafka会归档一份数据到hdfs,然后分别计算,在数据应用场景上,T+1的数据用离线计算的,T+0的数据用实时链路的。历史数据以离线计算为准。 今年,我们引入的iceburg,正在研发批流一体的实时数据中台架构,iceburg可以实现upsert功能,可以实时更新,避免merge操作。用iceburg统一离线和实时的存储,同时在计算引擎上,主要使用flink,然后辅助用Spark进行校验。目前整套数据湖的方案还在研发中,当然Iceburg也存在一些挑战,比如怎么和现有的impala mpp集成,怎么基于iceburg文件粒度的元数据统计优化计算引擎性能,都是我们目前正在推进的工作。 感谢你的阅读~祝好~

    2020-05-07
    4
  • Sandflass
    老师,请问一下对于实时的数据服务,比如您提到的实时直播场景,您只提到了最后的数据服务通过kafka推送,但是中间的数据源实时接入、数据实时加工应该采用何种技术方案呢?应该是有异于离线计算的方案吧?我们公司一些业务对于数据实时服务要求比较高,计算量并不大,这种场景应如何做技术选型呢?

    作者回复: 你好,数据服务,只负责数据的交付,数据的接入和加工,不是数据服务负责的范畴,是数据集成和数据开发中心负责的范畴。 实时数据集成,对于关系数据库,可以基于MySQL的二进制日志binlog,实时同步到kafka,然后基于flink对数据进行清洗加工,然后推送给最终的kafka数据,在实时直播场景下,常见的也有写入到redis,然后应用系统通过数据服务,高频率刷新读redis。 感谢你的提问~

    2020-05-02
    2
    4
  • 你好
    老师,数仓统计好的表在hive中,然后落地到hbase才能对外提供api,这个场景应该有吧。我想问的是怎么落地到hbase呢?(数据量大的话还得提前预分区hbase) ,两个库之间衔接问题。

    作者回复: 我们是基于数据传输这个工具,把数据从Hive抽取到HBase中的,数据传输工具是基于Spark实现的。

    2020-05-14
    3
  • ZSW
    老师,你好,对于实时数据和离线数据怎么结合这一部分有点疑问,现在离线和实时先分别计算,计算之后,数据是合并到一起呢?我大概想到2两种思路: 1、从物理存储上就合并在一起,离线数据统计结果写入A表,实时统计结果追加到A表?如果这种方式有什么好的实现方案吗? 2、物理存储层面分别存储, 如果分别存储,那如果一个查询查的时间跨度是“从历史数据查到今天的实时数据”,是不是在逻辑层分别取出来之后,再进行合并?

    作者回复: 你的问题涉及到批流一体了。批计算和流计算,有两种架构,一种是lamda架构,一种是kappa架构。 lamda架构目前在实际企业中落地最多。一般当天数据用实时,过往数据用离线。 kappa架构应该是未来一个趋势,现在数据湖概念比较火热,可以基于iceburg实现批流一体的存储层统一。

    2020-05-31
    2
  • Weehua
    感谢郭老师的分享。我提2个问题: 1. 数据中台的数据,大部分应该还是离线为主,这些T+1时效性的数据,可以用在核心的业务流程中吗? 2. 实时数据,数据中台和业务中台怎么划清责任边界呢?

    作者回复: HI, 你好,WeehuaZheng, 第一个问题: 实时数据中台一定是数据中台发展的下一站,解决了离线数据的共享和复用,实时数据的复用和共享将会是下一个阶段关注的重点。一般在使用过程中,T+1的统计数据使用离线数据,当天的数据使用实时数据。 第二个问题: 实时数据中台与离线数据中台,在方法论上也是相似的,实时数据中台同样也需要通过数据服务接口的方式对外暴漏服务。业务中台与数据中台的责任边界,数据中台负责统计分析型数据的展现。在大数据量下,业务系统去做实时数据的分析是非常耗资源的,而且还面临指标统计口径问题,所以统一由数据中台对接。 感谢你的提问,欢迎你在留言区与我交流~

    2020-05-23
    2
    2
收起评论
显示
设置
留言
35
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部