发表于 | 分类于 ，
字数统计: 29.5k | 阅读时长 ≈ 135
全文检索引擎Elasticsearch-23 Elasticsearch分词详解ES分词介绍12345678ES中在添加数据，也就是创建索引的时候，会先对数据进行分词。在查询索引数据的时候，也会先根据查询的关键字进行分词。所以在ES中分词这个过程是非常重要的，涉及到查询的效率和准确度。假设有一条数据，数据中有一个字段是titile，这个字段的值为LexCorp BFG-9000。我们想要把这条数据在ES中创建索引，方便后期检索。创建索引和查询索引的大致流程是这样的： 123456789101112131415161718图中左侧是创建索引的过程：首先对数据进行空白字符分割，将Le ...
阅读全文 »

发表于
字数统计: 1.6k | 阅读时长 ≈ 6
Flink新版本1.12以上-3Checkpoint与State剖析123前面我们已经掌握了Checkpoint和State使用，下面我们来从底层原理层面深度分析一下Checkpoint和State的细节流程。首先是checkpoint的生成过程 Checkpoint的生成过程 12345678910111213141516171819202122232425262728我们先整体看一下这个图：首先看图中左边的内容，这块内容表示是输入数据流中的数据以及对应的偏移量。其中里面的send、follow是具体的数据，下面的1、2、3、4、5、6是数据对应的偏移量。这个输入数据流表示是直播 ...
阅读全文 »

发表于
字数统计: 318 | 阅读时长 ≈ 1
找工作知识复习直播平台三度关系推荐123451.技术选型：数据采集聚合数据分发数据存储数据计算 12.整体架构 13.Neo4j安装，概念，创建节点和关系，查找，更新，索引，批量导入 14.数据来源分析，模拟产生 15.zookeeper,kafka启动->创建topic->数据分发->数据落盘 16.第二个任务：实时维护粉丝关注 Java常识1继承->extends->protected->super->构造函数第一行应该是父类的某个构造函数，否则默认父类无参数构造函数->限制继承final和sealed、permits- ...
阅读全文 »

发表于 | 分类于 ，
字数统计: 12.8k | 阅读时长 ≈ 43
第十八周 直播平台三度关系推荐v2.0-3数据中台的前世今生什么是中台12中台是2019年开始火起来的一个概念，它最早是由阿里在2015年提出的“大中台，小前台”战略中延伸出来的概念，灵感来源于一家芬兰的小公司Supercell——一家仅有300名员工，却接连推出爆款游戏，是全球最会赚钱的明星游戏公司。2015年年中,马云带领阿里巴巴集团高管,拜访了位于芬兰赫尔辛基的这家移动游戏公司，这家看似很小的公司，设置了一个强大的技术平台，来支持众多的小团队进行游戏研发。这样一来，他们就可以专心创新，不用担心基础却又至关重要的技术支撑问题。恰恰是这家小公司，开创了中台的“玩法”，并将其运用到了极致 ...
阅读全文 »

发表于 | 分类于 ，
字数统计: 6.2k | 阅读时长 ≈ 30
第十八周 直播平台三度关系推荐v2.0-2每周一计算最近一周内主活主播的三度关系列表(任务六)12345使用Flink程序实现每周一计算最近一周内主活主播的三度关系列表创建子module项目：get_recommend_list在项目中创建scala目录，引入scala2.12版本的SDK创建package：com.imooc.flink在pom.xml中添加依赖 子项目pom12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565 ...
阅读全文 »

发表于 | 分类于 ，
字数统计: 10.8k | 阅读时长 ≈ 55
第十八周 直播平台三度关系推荐v2.0-1V1.0架构存在的问题1234567891011121314V1.0这个架构里面其实存在三个主要的问题SparkStreaming程序的实时性不够其实说实话，针对目前的粉丝实时关注数据，使用SparkStreaming程序来维护问题也不大，但是我们程序猿是要有追求的，既然有更好的方案，那我们肯定不能使用差的，所以这块我们我们需要使用Flink来实现，它可以提供真正意义上的实时。三度关系推荐数据适合存储在缓存系统中(Redis)咱们前面把最终计算好的三度关系数据保存在了MySQL中。其实这种数据是比较适合存储到一些基于内存的缓存系统中的，对查询 ...
阅读全文 »

发表于 | 分类于 ，
字数统计: 18.3k | 阅读时长 ≈ 85
第十八周 直播平台三度关系推荐v1.0-3数据计算之实时维护粉丝关注(第二个任务) 1接下来我们来看一下数据计算中的第二步，实时维护粉丝关注数据。我们的实时粉丝关注数据呢，来源于服务端日志，因为当用户在直播平台中对主播进行关注和取消关注的时候呢，会调用服务端接口。所以说服务端会记录这些操作日志。具体的数据格式呢，是这样。这是一个json格式，fuid就代表了粉丝。uid代表的是主播。好，这个timestamp，它表示这个具体你这个关注行为，或者你取消关注行为，它产生的时间。这个type呢，表示这个数据是什么类型的数据，它是粉丝关注相关的数据。那具体这条数据是关注还是取消关注，我们要根 ...
阅读全文 »

发表于 | 分类于 ，
字数统计: 22.5k | 阅读时长 ≈ 81
第十八周 直播平台三度关系推荐v1.0-2数据采集架构详细设计 1234567大家好，下面呢，我们就从我们整体架构里面的第一个模块数据采集模块开始。注意，在实际过程中，数据采集模块不是只针对某一个项目而言的，而是一个公共的采集平台，所有项目依赖的数据全部都来源于数据采集模块，所以在设计采集模块的时候要考虑通用性。不能仅仅是为了这一个项目而服务。咱们前面在分析整体架构的时候说过，filebeat采集的数据到达kafka以后，会通过flume再做一下分发，为什么要有这个分发这个过程呢？这个分发过程实现了什么功能呢？我们来看一下这张图。这个图里面呢，针对数据采集模块做了详细的分析，把数据采集模 ...
阅读全文 »

发表于 | 分类于 ，
字数统计: 17.6k | 阅读时长 ≈ 62
第十八周 直播平台三度关系推荐v1.0-1项目123456789101112大家好，下面我们开始正式学习直播平台三度关系推荐系统这个项目，这个项目分为1.0和2.0这两个版本。本周我们先学习1.0这个版本。首先我们来看一下项目效果。大家呢，可以在这里面扫码体验。这个就是我们直播平台的首页，当我们点击某一个主播，会进入到主播的详情页，我们在点击这个follow关注按钮的时候。这里面呢，会插入一个模块，它里面显示的是关注了此主播的人，也关注了哪些主播。这就是三度关系推进的效果。这页面上看起来只是把数据展现出来，很简单，但是具体这些数据是怎么来的，如何保证推荐的主播也是用户感兴趣的，这才是 ...
阅读全文 »
0%