对于这么大的流量入口，需要做合理的模型设计，防止重复读取的过度消耗。另外还要在数据源读取和标准化过程中，极致压榨性能保障入口流量的稳定执行。 第二个特点是诉求多样化。...另外，实时计算场景下，活动出现洪峰时能否快速消费，也是一个未知数。最后，DWD 层的重复消费对于实时侧的资源挑战也很大，在选择数据源和依赖关系时需要考虑资源问题。...第一项操作是拆分场景，由于实时数仓没有分区表的逻辑，所以场景拆分的目的是生成子 topic，防止重复消费大 topic 的数据。...拆分到链路层面，又可以从 Flink 任务的输入、处理和输出三个方面进行分析：输入核心关注延迟和乱序情况，防止数据丢弃；处理核心关注数据量和处理数据的性能指标；输出则关注输出的数据量多少，是否触发限流等...读取压测的数据源 topic 并经过作业处理生成新的 topic 后，如何判断压测是否真正通过，有三个标准：第一，确保作业输入读取延迟为毫秒级，且作业本身无任何反压。
从数据链路来看此架构图，从下往上来看，首先视频内容由内容中心通过消息队列给到我们，经过一定的处理入库、建索引、生成正排/倒排数据，这时候在存储层可召回的内容约有1千万条。...基于此架构，我们需要设计一套召回/倒排索引，能够以实时/近实时的延迟来处理所有数据。 三、方案设计 在旧方案中，索引是每半小时定时构建的，无法满足近实时的要求。...这个方案从数据链路上分为两大块。 第一块，先验数据链路，就是上半部分，我们的数据源主要来自内容中心，通过解析服务写入到CDB中。其中这个链路又分为全量链路和增量链路。...此处监控间隔是10秒，可以看到，由于聚合窗口是1min，每分钟前10秒写入达到峰值，后面逐渐减少，然后新的一分钟开始时又周期性重复这种情况。...这么大的请求量如果直接打入ES，一定是扛不住的，那么如何来进行优化呢？ 由于大量请求的参数是相同的，并且存在大量的热门key，因此我们引入了多级缓存来提高召回的吞吐量和延迟时间。
二、实时任务运维 1、配置反压告警 场景：反压导致cp失败，数据出现延迟或者不产出。 排查方法： 1）借助Flink web-ui 提供的的反压功能查找具体的operatorChain。...2）查询Flink metric 'inPoolUsage、outPoolUsage' 来确定具体的反压算子。 2、配置cp失败告警 场景：cp失败导致数据无法真正落地，任务恢复间隔太长。...排查方法: 1）是否存在反压。 2）检查集群负载、IO、CPU、MEM 是否处于高负荷状态。...解决方法： 在数据解析和数据落库等代码中，对catch中的数据进行收集。当异常数据达到一定的量时，告警通知。线下离线修正结果数据。...4.如何使用：在提交任务的时候加上 -planner dtstack/flink即可。 ---- 本文作者：刘星（花名：吹雪），袋鼠云大数据开发工程师。
所以实时流处理系统必须能够解决发送速率远大于系统能处理速率这个问题，大多数实时流处理系统采用反压（BackPressure）机制解决这个问题。...low water mark时解除反压。...当缓冲区大小达到high watermark时触发反压，并保持有效，直到缓冲区大小低于low watermark。此设计的基本原理是防止拓扑在进入和退出背压缓解模式之间快速振荡。 5....下面我们会深入分析 Flink 是如何在 Task 之间传输数据的，以及数据流如何实现自然降速的。 Flink 在运行时主要由operators和streams两大组件构成。...如果没超过池子容量，则会继续留在池子中，减少反复申请的开销。 5.2 Flink 反压机制 下面这张图简单展示了两个 Task 之间的数据传输以及 Flink 如何感知到反压的： ?
指标、GC情况、作业反压等，出现异常告警。...例如： 数据源层出现背压时，导致数据源头（mq,Kafka）消息积压，积压严重时导致资源耗尽，进而导致数据丢失； 数据处理层数据加工未按照需求进行加工，导致目标有效数据丢失； 数据存储层的存储容量写满时...; 数据快速恢复性 数据在流转路径中因为异常导致流转中断，数据停止在某一个环节中，当异常解决，系统恢复正常时，停止的数据（停止的数据）需要快速恢复流转，并且这种恢复是正确的，不应该存在重复的消费和加工或者遗漏...自动运维 能够捕捉并存档缺失数据和处理异常，并具备定期自动重试机制修复问题数据 回到问题本身 再回答问题本身，我们可以从下面三个方面回答： 事前 本问题是从数据质量角度产生的问题，可以从数据质量监控的角度...年过半，社招和校招的经验之谈 大数据方向另一个十年开启 |《硬刚系列》第一版完结 我写过的关于成长/面试/职场进阶的文章 当我们在学习Hive的时候在学习什么？
二、看点视频推荐整体架构 从数据链路来看此架构图，从下往上来看，首先视频内容由内容中心通过消息队列给到我们，经过一定的处理入库、建索引、生成正排/倒排数据，这时候在存储层可召回的内容约有1千万条。...基于此架构，我们需要设计一套召回/倒排索引，能够以实时/近实时的延迟来处理所有数据。 三、方案设计 在旧方案中，索引是每半小时定时构建的，无法满足近实时的要求。...，可以看到，由于聚合窗口是1min，每分钟前10秒写入达到峰值，后面逐渐减少，然后新的一分钟开始时又周期性重复这种情况。...高并发场景优化 由于存在多路召回，所以召回系统有读放大的问题，我们ES相关的召回，总qps是50W。这么大的请求量如果直接打入ES，一定是扛不住的，那么如何来进行优化呢？...压测结果如下图所示： 根据压测数据，我们选择6作为主分片数，此时es的平均rt13ms，99分位的rt为39ms。
在召回阶段，首先筛选出和用户直接相关或间接相关的物品，将原始数据从万、百万、亿级别缩小到万、千级别； 在排序阶段，通常使用二分类算法来预测用户对物品的喜好程度（或者是点击率），然后将物品按照喜好程序从大到小依次排列...，筛选出用户最有可能喜欢的物品，这里又将召回数据从万、千级别缩小到千、百级别； 最后在调整阶段，需要过滤掉重复推荐的、已经购买或阅读的、已经下线的物品，当召回和排序结果不足时，需要使用热门物品进行补充，...获取用户历史点击行为数据，利用 ALS 模型计算得到用户对文章的偏好得分及文章列表，读取并过滤历史召回结果，防止重复推荐，将过滤后的偏好得分最高的 K 篇文章存入 Hbase 的召回结果表中，列族为 als...读取用户历史行为数据，获取用户历史发生过点击、阅读、收藏、分享等行为的文章，接着读取文章相似表，获取与发生行为的每篇文章相似度最高的 K 篇文章，然后读取并过滤历史召回结果，防止重复推荐，最后将过滤后的文章存入...读取 Kafka 中的用户实时行为数据，获取用户实时发生点击、阅读、收藏、分享等行为的文章，接着读取文章相似表，获取与发生行为的每篇文章相似度最高的 K 篇文章，然后读取并过滤历史召回结果，防止重复推荐
基于此架构，需设计一套召回/倒排索引，以实时/近实时延迟来处理所有数据。 3 方案设计 旧方案的索引每半小时定时构建，无法满足近实时要求。...如果这里先commit再进行redis写入，那么如果系统在commit完且写入redis前宕机了，那么这条消息将丢失掉；如果先写入，在commit，那么这里就可能会重复消费。 如何解决？...1min，每分钟前10秒写入达到峰值，后面逐渐减少，然后新的一分钟开始时又周期性重复这种情况。...4 召回性能调优 4.1 高并发场景优化 由于存在多路召回，所以召回系统有读放大的问题，我们ES相关的召回，总qps是50W。这么大的请求量如果直接打入ES，一定是扛不住的，那么如何来进行优化呢？...压测结果： 根据压测数据，我们选择6作为主分片数，此时es的平均rt13ms，99分位的rt为39ms。
防止出现任务从 Checkpoint 恢复不了的情况。但是你可以去修改 TTL 时长，因为修改时长并不会改变 State 存储结构。...5.5.生产环境中，如何快速判断哪个算子存在反压呢？或者说哪个算子出现了性能问题？ 将这个问题拆解成多步来分析： ⭐ 如何知道算子是否有反压？...上游算子在 web ui 显示有反压时，一般为下游算子存在性能问题。...5.7.经常碰到哪些问题会任务反压？ 总结就是：算子的 sub-task 需要处理的数据量 > 能够处理的数据量。一般会实际中会有以下两种问题会导致反压。...5.8.怎么缓解、解决任务反压的情况？ ⭐ 事前：解决上述介绍到的 数据倾斜、算子性能 问题。 ⭐ 事中：在出现反压时： ⭐ 限制数据源的消费数据速度。
我们认为Flink作业中止时，也是不可用的情况之一。 Flink作业在运行中不再处理数据 发生这种情况，一般是因为遇到了反压（BackPressure）。...虽然短时间内的反压不会造成数据丢失，但它会影响数据的实时性，最明显的变化是延迟这个指标会变大。 我们认为反压发生时是不可用的情况之一。...第三种情况当反压发生时，HeartBeat也会被阻塞在发生反压的上游，因此on-call也可以很快地发现反压发生并进行人工干预。 综上，Heartbeat可以很快监测出Flink作业的运行情况。...通过以上配置，可以限定每个TaskManager独占CPU和内存的资源，且不会多个作业抢占，实现作业之间的隔离。 4. 反压 我们运维Flink集群的时候发现，出现最多的问题就是反压。...由于Heartbeat只能监控出是否发生了反压，但无法定位到是哪个算子出了问题，因此我们定时地将每个算子的StackTrace打印出来，当发生反压时，通过StackTrace就可以知道是哪个算子的瓶颈。
我们希望通过丸音，让更多喜欢音乐的人能轻松地进行音乐创作，在丸音拥有属于你自己的音乐！ 丸音的库中有用户上传的海量音乐。我们的首要任务是如何基于用户的历史行为，从海量音乐中筛选出用户感兴趣的音乐。...| 选择特征向量检索工具 有了特征向量，剩下的问题就是如何在海量特征向量中找到指定向量的相似结果。关于特征向量检索工具，我们想到了 Faiss 和 Milvus。...| I2I 音乐推荐 前面已经介绍了丸音的 I2I 音乐推荐系统从歌曲本身下手，首先会将用户上传的新歌做音轨分离，也就是把人声（Vocal）和伴奏（BGM）分开，提取伴奏中的特征向量作为该歌曲的表征（音轨分离也基本解决了翻唱过滤需求...| 重复歌曲筛选 我们应用 Milvus 的另一个场景是重复歌曲筛选。有的用户会把同一首歌或者其片段上传多次，这些重复的歌可能会出现在某一用户的推荐列表里。...然后对相似向量进行召回，经过排序、重排后展现给用户。为实现实时召回推荐，我们使用了相较于 Faiss 更易用且更成熟的 Milvus 向量相似度检索引擎。
在各种会上，经常会被问到 Spark 和 Flink 的区别，如何取舍？ 下面从数据模型、运行时架构、调度、时延和吞吐、反压、状态存储、SQL 扩展性、生态、适用场景等方面来逐一分析。...，两个 netty 之间 keepalive，网络 buffer 是自然反压的关键。...，这种自然反压的方式非常合理。...Spark Streaming 是设置反压的吞吐量，到达阈值就开始限流，从批计算上来看是合理的。...视频流如果全部实时上传到数据中心，成本不划算，如果这些视频流数据能在摄像头上或摄像头周边完成人脸识别、物体识别、车牌识别、物体移动侦测、漂浮物检测、抛洒物检测等，然后把视频片段和检测结果上传，将极大节省流量
简介 反压（backpressure）是实时计算应用开发中，特别是流式计算中，十分常见的问题。反压意味着数据管道中某个节点成为 瓶颈，处理速率跟不上上游发送数据的速率，而需要对上游进行限速。...由于实时计算应用通常使用消息队列来进行生产端和 消费端的解耦，消费端数据源是 pull-based 的，所以反压通常是从某个节点传导至数据源并降低数据源（比如 Kafka consumer）的摄入速率...定位手段是因为这是从 Source Task 到 Sink Task 的第一个出现反压的节点，所以该节点是反压的根源节点。 下游的节点处理数据的速率较慢，通过反压限制了该节点的发送速率。...定位手段是从该节点开始继续排查下游节点。 注意事项： 因为Flink Web UI 反压面板是监控发送端的，所以反压的根源节点并不一定会在反压面板体现出高反压。...Buffer） 反压的原因及处理 注意：反压可能时暂时的，可能由于负载高峰，CheckPoint或者作业重启引起的数据积压而导致的反压。
因为这一期涉及到的几个问题，基本就能问出来候选人有没有实战经验了。 博主把这一期的面试题先贴出来，大家自己感受感受。 ⭐ 解决问题的能力：生产环境中，如何快速判断哪个算子存在反压呢？...⭐ 解决问题的能力：反压有哪些危害？ ⭐ 解决问题的能力：经常碰到哪些问题会任务反压？ ⭐ 解决问题的能力：怎么缓解、解决任务反压的情况？ ⭐ 数据保障的能力：实时数据延迟是怎么监控的？...将这个问题拆解成多步来分析： ⭐ 如何知道算子是否有反压？...上游算子在 web ui 显示有反压时，一般为下游算子存在性能问题。...5.怎么缓解、解决任务反压的情况？ ⭐ 事前：解决上述介绍到的 数据倾斜、算子性能 问题。 ⭐ 事中：在出现反压时： ⭐ 限制数据源的消费数据速度。
精排层：精排解决的是从千级别item到几十这个级别的问题 CTR预估：lr，gbdt，fm及其变种（fm是一个工程团队不太强又对算法精度有一定要求时比较好的选择），widedeep，deepfm...举个例子，主路召回学的不错，但是它可能由于某种原因，特别讨厌影视剧片段这一类内容，导致了这类视频无法上升到粗排上。那这样的话整个系统推不出影视剧片段就是一个问题。...第三种召回是u2i，即纯粹从user和item的关系出发。我们所说的双塔就是一个典型的u2i。...，先得到u2i的数据，再利用i2i的数据进行扩展，就可以从第一个节点，越过一个节点，到达第三个节点，实现推荐 中间的桥梁是item u2u2i：从一个用户，到达另一个用户，到达一个物品 先计算u2u：两种方法...一是：取用户的性别、年龄、职业等人工属性的信息，计算相似性，得到u2u； 一是：从行为数据中进行挖掘，比如看的内容和视频大部分很相似，就可以看作一类人； 也可以使用聚类的方法进行u2u
这些精彩看点的实时呈现，从平台内容生态来说，在某种程度上是对直播内容的补充，同时精彩看点产量也是对主播输出的一种隐式激励，激励主播持续产出高质量的直播内容，形成良性循环。...2 AI剪辑技术实践 主要的实践难点和挑战来自两个方面，1）如何搭建直播到视频的自动化生产流程，2）如何实现精彩识别和剪辑算法。...2.2.1 游戏品类：王者荣耀 预定义精彩片段类型20多种，主要为王者游戏中的高能事件（比如三连决胜/高能团战/残血反杀等）。...，利用回放视频片段数据训练视频分类模型，为回放片段打上不同类别的细分标签。...剪辑模块实时获取动画打点模块、细分标签模块和镜头切分模块的结果，来确定目标片段的起止点。
如果能看到 Source 有警告，这意味着 Sink 消耗数据的速度比 Source 生成速度慢。Sink 正在向 Source 施加反压。...关键词：Flink 反压 什么是 Back Pressure 如果看到任务的背压警告（如 High 级别），这意味着 生成数据的速度比下游算子消费的的速度快。...许多情况都会导致背压。例如，GC导致传入数据堆积，或者数据源在发送数据的速度上达到峰值。如果没有正确处理反压力，可能会导致资源耗尽，甚至在最坏的情况下，数据丢失。 看一个简单的例子。...消息缓存应该是持久的，因为在发生故障的情况下，需要重放这些数据以防止数据丢失。 ?...背压实现 采样线程 背压监测通过反复获取正在运行的任务的堆栈跟踪的样本来工作，JobManager 对作业重复调用 Thread.getStackTrace()。 ?
从架构层面看，做什么事情对推荐系统效果有提升呢？首先是特征系统的实时性。因为推荐系统在选择时，是基于内容之间进行 PK，PK 非常重要的一点是内容的特征实时生成，就像一个人的代谢越快就越健康。...内容服务和索引服务指在网上出现突发事件，新文章进入平台时，把内容入库。这里有一系列的流程，比如人工审核、NLP 打分、排重等等处理后，进入倒排能够被召回，进而线上进行曝光，这就是内容入库的实时性。...而如何减少日志的无效 IO，协议里面训练化和反训练化的开销如何减少，推荐链路非常长，协议也存在这样问题。 怎样优化代码逻辑？...通过一致性的 hash+版本号机制保证同步过滤数据一致，通过这样的设计重复率降低了一个数量级，基本上解决了高峰期重复的问题。...A：采用无锁的数据结构，整个索引只有单个写，没有并发写。 Q：召回推荐什么时候触发？ A：用户请求主 feed 就会触发 Q：推荐系统的架构如何保证时延要求呢？ A：架构层面优化和代码层面的优化。
Flink 任务一般运行在多个节点上，数据从上游算子发送到下游算子需要网络传输，若系统在反压时想要降低数据源头或上游算子数据的发送速率，那么肯定也需要网络传输。...19.1.2 利用Metrics定位反压位置 当某个 Task 吞吐量下降时，基于 Credit 的反压机制，上游不会给该 Task 发送数据，所以该 Task 不会频繁卡在向 Buffer Pool...反压时，可以看到遇到瓶颈的该Task的inPoolUage为1。 19.2 反压的原因及处理 先检查基本原因，然后再深入研究更复杂的原因，最后找出导致瓶颈的原因。...下面列出从最基本到比较复杂的一些反压潜在原因。 注意：反压可能是暂时的，可能是由于负载高峰、CheckPoint 或作业重启引起的数据积压而导致反压。如果反压是暂时的，应该忽略它。...对接从 Java 对象转为 Buffer 的中间对象是另一个抽象 StreamRecord。
第一在于设备指纹的典型应用场景反欺诈、营销追踪等都需要实时地给出匹配结果，也就是要在线，这就意味着数据来源不是数据库，而是数据流。...对于设备指纹技术，机器学习的方法从数据中学习，让数据说话，摒除了人工规则方法的偏见和不稳定性。但是机器学习的方法也面临一定的挑战，最重要的挑战就是在很多场景下，标注数据是不足的。...这是两个数据集A(25条)和B(20条)进行匹配的结果展示，从图中可以看出空的虚线框，即我们正确地作出的非匹配的判断，占绝大多数，但这却是我们最不关心的。...（2）由于H5页面发布在第三方金融超市中，用户申请时无法获得稳定的cookie信息，无法从设备的维度自动审核进件。 客户希望能够有一个能够在H5页面中识别重复请求的解决方案。...该客户与猛犸反欺诈合作将猛犸ID系统的SDK嵌入其应用中，在贷款请求事件发生时，向猛犸系统发送请求信息。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
腾讯会议
云直播
对象存储
