导读：本文将介绍过去15年中，网易大数据团队在应对不断涌现的新需求、新痛点的过程中，逐渐形成的一套逻辑数据湖落地方法。内容分为五部分：关于网易数帆为什么做逻辑数据湖怎么做逻辑数据湖未来规划精彩问答--01关于网易数帆网易数帆是从网易杭州研究院孵化出来的。网易杭研的重要职责是公共技术的研究和产品孵化。下图是网易数帆的整体产品架构。1.网易大数据发展历史网易是国内领先的互联网技术公司，从2006年就开始对大数据相关技术进行探索。2009年为了支撑网易博客等产品的海量数据，开始了分布式文件系统、分库分表中间件（网易DDB）等技术的研发，并且于当年引入了Hadoop进行探索。2014年到2017年，网
导读：本文将介绍过去15年中，网易大数据团队在应对不断涌现的新需求、新痛点的过程中，逐渐形成的一套逻辑数据湖落地方法。内容分为五部分：关于网易数帆为什么做逻辑数据湖怎么做逻辑数据湖未来规划精彩问答--01关于网易数帆网易数帆是从网易杭州研究院孵化出来的。网易杭研的重要职责是公共技术的研究和产品孵化。下图是网易数帆的整体产品架构。1.网易大数据发展历史网易是国内领先的互联网技术公司，从2006年就开始对大数据相关技术进行探索。2009年为了支撑网易博客等产品的海量数据，开始了分布式文件系统、分库分表中间件（网易DDB）等技术的研发，并且于当年引入了Hadoop进行探索。2014年到2017年，网
背景字节跳动DataCatalog产品早期，是基于LinkedInWherehows进行二次改造，产品早期只支持Hive一种数据源。后续为了支持业务发展，做了很多修修补补的工作，系统的可维护性和扩展性变得不可忍受。比如为了支持数据血缘能力，引入了字节内部的图数据库veGraph，写入时，需要业务层处理MySQL、ElasticSearch和veGraph三种存储，模型也需要同时理解关系型和图两种。更多的背景可以参照之前的文章。新版本保留了原有版本全量的产品能力，将存储层替换成了ApacheAtlas。然而，当我们把存量数据导入到新系统时，许多接口的读写性能都有严重下降，服务器资源的使用也被拉伸
背景字节跳动DataCatalog产品早期，是基于LinkedInWherehows进行二次改造，产品早期只支持Hive一种数据源。后续为了支持业务发展，做了很多修修补补的工作，系统的可维护性和扩展性变得不可忍受。比如为了支持数据血缘能力，引入了字节内部的图数据库veGraph，写入时，需要业务层处理MySQL、ElasticSearch和veGraph三种存储，模型也需要同时理解关系型和图两种。更多的背景可以参照之前的文章。新版本保留了原有版本全量的产品能力，将存储层替换成了ApacheAtlas。然而，当我们把存量数据导入到新系统时，许多接口的读写性能都有严重下降，服务器资源的使用也被拉伸
哪个营销任务、营销渠道的引流用户更多？买量用户的活跃、留存情况如何？哪个营销任务引流的用户后续的加购、下单转化最多？HMSCore分析服务作为广告转化跟踪工具，广告主可实现从“曝光、点击、下载、激活、注册、留存、收藏、加入购物车、下单、开始结算、支付成功、复购”的全链路监测，让市场营销同学从繁杂的数据收集、整理中解放出来，监测营销效果，快速找到高质量用户，专注于思考投放策略的调整方向。便捷回传，高效归因：无缝衔接HUAWEIAds，后链路转化事件便捷回传，让归因更高效，实现投放成本与获客效率的双向优化；行业定制，多维指标分析：深挖行业痛点，提供体系化电商强关联埋点方案，并基于此配备多样、核心的
哪个营销任务、营销渠道的引流用户更多？买量用户的活跃、留存情况如何？哪个营销任务引流的用户后续的加购、下单转化最多？HMSCore分析服务作为广告转化跟踪工具，广告主可实现从“曝光、点击、下载、激活、注册、留存、收藏、加入购物车、下单、开始结算、支付成功、复购”的全链路监测，让市场营销同学从繁杂的数据收集、整理中解放出来，监测营销效果，快速找到高质量用户，专注于思考投放策略的调整方向。便捷回传，高效归因：无缝衔接HUAWEIAds，后链路转化事件便捷回传，让归因更高效，实现投放成本与获客效率的双向优化；行业定制，多维指标分析：深挖行业痛点，提供体系化电商强关联埋点方案，并基于此配备多样、核心的
开心一刻 有个问题一直困扰着我：许仙选择了救蛇，为什么杨过却选择救雕（而不救蛇） 后面想想，其实杨过救神雕是有原因的，当年神雕和巨蛇打架的时候 雕对杨过说：杀蛇，杀蛇，杀蛇！ 蛇对杨过说：杀雕，杀雕，杀雕！ 杨过果断选择了杀蛇业务场景 业务描述 业务上有这样的需求，张三、李四两个用户，如果互相关注则成为好友 设计上有两张表，关注关系表： tbl_follow 朋友关系表： tbl_friend 我们以张三关注李四为例，业务实现流程是这样的 1、先查询李四有没有关注张三 2、如果李四关注了张三，则成为好友，往 tbl_friend 插入一条记录；如果李四没有关
开心一刻 有个问题一直困扰着我：许仙选择了救蛇，为什么杨过却选择救雕（而不救蛇） 后面想想，其实杨过救神雕是有原因的，当年神雕和巨蛇打架的时候 雕对杨过说：杀蛇，杀蛇，杀蛇！ 蛇对杨过说：杀雕，杀雕，杀雕！ 杨过果断选择了杀蛇业务场景 业务描述 业务上有这样的需求，张三、李四两个用户，如果互相关注则成为好友 设计上有两张表，关注关系表： tbl_follow 朋友关系表： tbl_friend 我们以张三关注李四为例，业务实现流程是这样的 1、先查询李四有没有关注张三 2、如果李四关注了张三，则成为好友，往 tbl_friend 插入一条记录；如果李四没有关
业务背景跟第三方系统做对接，双方通过ActiveMQ进行通信，消息之间是有内在关联的，也就是消息本来应该是有业务顺序的，但由于一些原因，现在收到消息是乱序的，这种情况下做业务处理就有一点小问题了方案一：自己重排序收到消息后，自己在内存排序，然后按顺序丢到队列中，自己控制消息的发送和接收保证收到按发送的顺序来收到消息。如果自己排序的话就要对每个消息标记一个顺序，同时还要指定预先定义好哪些消息属于一类并且相互之间有依赖顺序。具体实现的话，可以这样做：1、收到一条消息，封装一下加个序号，放到Redis中，用列表或者有序集合来存储，同时用字符串类型存一下这个业务单号的当前最小序号（默认是1）2、如果是
业务背景跟第三方系统做对接，双方通过ActiveMQ进行通信，消息之间是有内在关联的，也就是消息本来应该是有业务顺序的，但由于一些原因，现在收到消息是乱序的，这种情况下做业务处理就有一点小问题了方案一：自己重排序收到消息后，自己在内存排序，然后按顺序丢到队列中，自己控制消息的发送和接收保证收到按发送的顺序来收到消息。如果自己排序的话就要对每个消息标记一个顺序，同时还要指定预先定义好哪些消息属于一类并且相互之间有依赖顺序。具体实现的话，可以这样做：1、收到一条消息，封装一下加个序号，放到Redis中，用列表或者有序集合来存储，同时用字符串类型存一下这个业务单号的当前最小序号（默认是1）2、如果是
