1 文本Embedding 将整个文本转化为实数向量的技术。 Embedding优点是可将离散的词语或句子转化为连续的向量，就可用数学方法来处理词语或句子，捕捉到文本的语义信息，文本和文本的关系信息。 ◉ 优质的Embedding通常会让语义相似的文本在空间中彼此接近 ◉ 优质的Embedding相似的语义关系可以通过向量的算术运算来表示： 2 文本Embedding模型的演进与选型 目前的向量模型从单纯的基于 NLI 数据集（对称数据集）发展到基于混合数据（对称+非对称）进行训练，即可以做 QQ召回任务也能够做 QD 召回任务，通过添加 Instruction 来区分这两类任务，只有在...

职场遇到不愉快的同事打小报告怎么办？看亚当大师。提前预判，找到领导说明英明神武并献上薄礼给领导孩子。🫶️团队氛围👨🏻‍💻工作环境

我向 121 位软件开发人员询问了这个问题，结果列出了 5 种方法。“如何提高 API 的性能？”[1] 缓存缓存的想法很简单。将经常访问的数据存储在缓存中，以便在需要时可以更快地访问。如果发生缓存未命中，则从数据库获取数据。它实际上非常有效，但缓存失效和决定缓存策略可能具有挑战性。[2] 使用负载平衡进行横向扩展如果一个服务器实例不够用，您可以考虑将 API 扩展为多个实例。那么问题出在哪里？您需要找到一种方法来在这多个实例之间分配请求。输入负载均衡器。它不仅有助于提高性能，而且还使您的应用程序更加可靠。但是，当您的应用程序无状态且易于水平扩展时，负载平衡器效果最佳。[3] 异步处理有时，你无法同时解决多个问题。最好的办法是将它们停放起来以备后用。通过异步处理，您可以让客户端知道他们的请求已注册并正在处理中。然后，您逐一处理请求，并将结果传达给客户端。这使得您的应用程序服务器可以稍事休息并发挥最佳性能。但当然，异步处理可能并不适用于所有需求。[4] 分页如果您的 API 返回大量记录，则需要探索分页。基本上，您限制每个请求的记录数。这可以提高 API 对消费者的响应时间。[5] 连接池API 经常需要连接数据库来获取一些数据。为每个请求创建新的连接可能会降低性能。使用连接池来设置可以在请求之间重复使用的数据库连接池是一个好主意。这是一个微妙的方面，但在高度并发的系统中，连接池会对性能产生巨大影响。那么，您认为提高 API 性能的首要方法是什么呢？

0 prompt engineer 就是prompt工程师它的底层透视。 1 学习大模型的重要性 底层逻辑 人工智能大潮已来，不加入就可能被淘汰。就好像现在职场里谁不会用PPT和excel一样，基本上你见不到。你问任何一个人问他会不会用PPT，他都会说会用，只是说好还是不好。你除非说这个岗位跟电脑完全无关。但凡说能用上电脑的，基本上都会用excel和PPT，你不会用的基本上都被淘汰了，逻辑一样。 人工智能虽有一些应用场景，好像跟普通人没关。如智能驾驶，人脸识别，好像跟普通人关系不太大，我们都是被动使用。但现在这大模型跟我们每个人都有关，它是一个强大提升工作效率工具。你不会用，将来就好像跟PPT...

由于不懂系统设计，我曾两次面试后端工程但都失败了。我很难接受我在学校学到的、通过的、并且每天都在做的事情竟然会让我失败。这件事发生过两次。于是，我决定更深入地学习它。听着，系统设计很简单，你可以学会。一切都归结为理解系统组件。看看下面的 TikTok 系统设计。你可以快速看到组成 TikTok 的组件（但不是全部）您可以发现 CDN（内容分发网络）、LB（负载均衡器）、RDB（关系数据库）、缓存等。系统由许多组件组成，在设计系统时，您的工作是通过以下方式充分利用它们：-了解每一个组件。-了解何时使用它们每一个。- 了解为什么使用它们中的每一个。-知道将每个组件放在哪里。

工程 | JOSH LONG | 0条评论 Java 22发布快乐！ Java 22 是一个重大的进步，是一个值得升级版本。有一些重大的最终发布功能，如 Project Panama及一系列更优秀的预览功能。我不可能覆盖它们全部，但我确实想谈谈我最喜爱的一些。我们将会涉及到许多功能。如果你想在家里跟着做，代码在这。 我爱Java 22，当然，我也爱 GraalVM，它们都在发布了新版本！Java 当然是我们最喜爱的运行时和语言，而 GraalVM 是一个高性能的 JDK 发行版，它支持更多语言并允许提前编译（它们被称为 GraalVM native images）。GraalVM 包含了 ...

一起入门 spark 吧！

0 Shark Spark 的一个组件，用于大规模数据分析的 SQL 查询引擎。Shark 提供了一种基于 SQL 的交互式查询方式，可以让用户轻松地对大规模数据集进行查询和分析。Shark 基于 Hive 项目，使用 Hive 的元数据存储和查询语法，并基于Hive进行了性能优化和扩展。 0.1 设计 灵感来自 Google 的 Dremel 系统: 将数据存储在列式存储引擎 使用分布式计算引擎进行查询 Shark 采用类似架构并使用 Spark 作为计算引擎，使 Shark 具有很高查询性能和可扩展性。 0.2 缺陷 Shark 在 Spark 1.0 发布之后被正式弃用，Shark ...

简单介绍“工作流事件模式：反应式架构”。这个想法很简单：生产者通过消息通道将数据异步传递给事件消费者。如果消费者在处理数据时遇到错误，它将将该错误委托给处理器并继续处理以下消息。Consumer 不会花时间处理错误，响应能力也不会受到影响。一旦工作流程处理器收到错误，它就会尝试找出问题所在。这可能是：- 静态且确定性的错误处理程序。- 一些机器学习算法分析消息以查看数据中的异常情况。处理器更改原始数据以尝试修复它，然后将其发送回原始队列。事件使用者看到此消息并尝试再次处理它。希望这次能取得一些成功。如果工作流处理器无法确定问题所在，它会将消息发送到“仪表板”。循环中的人员将处理仪表板中的案例并将它们重新提交到原始队列。这种模式是一种反应式架构。它有助于系统具有弹性并处理错误，而不影响响应能力。你愿意尝试一下吗？

优秀可靠的数仓体系，需要良好的数据分层结构。合理的分层，能够使数据体系更加清晰，使复杂问题得以简化。以下是该项目的分层规划。 1 设计要点 （1）ODS层的表结构设计依托于从业务系统同步过来的数据结构 （2）ODS层要保存全部历史数据，故其压缩格式应选择压缩比较高的，此处选择gzip （3）ODS层表名的命名规范为：ods_表名_单分区增量全量标识（inc/full）。 2 相关表 2.1 整车日志表（增量日志表） CREATE EXTERNAL TABLE ods_car_data_inc ( `vin` STRI...

0 前言数据仓库的逻辑模型指的是描述数据仓库中数据如何组织、存储和相互关联的高层次抽象模型。它不涉及数据在物理层面上的实现细节（例如具体的数据库表结构），而是关注于数据模型的设计与规划，以便于支持业务决策和数据分析工作。以下是数据仓库逻辑模型的两种常见设计方法：1 星型模式（Star Schema）星型模式是一种数据模型，其中包含一个或多个事实表和多个维度表。事实表存储量化的业务数据（事实），例如销售总额、交易次数等，并且通常包含大量记录。维度表用于存储描述性数据来提供上下文信息，例如时间、地点、产品信息等。这种模式的名称来源于其看上去像一个星星的形状——中心的事实表被各个维度表围绕。当表关系...

关注我，紧跟本系列专栏文章，咱们下篇再续！ 作者简介：魔都技术专家兼架构，多家大厂后端一线研发经验，各大技术社区头部专家博主。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。 负责： 中央/分销预订系统性能优化 活动&优惠券等营销中台建设 交易平台及数据中台等架构和开发设计 目前主攻降低软件复杂性设计、构建高可用系统方向。 参考： 编程严选网 1 背景 在视频推荐场景： 让新启用的视频尽可能快的触达用户，对新闻类内容尤为关键 快速识别新物品的好...

Feign 第一次调用耗时较长的主要原因包括：1. **初始化时间：** Feign 在第一次调用时需要进行初始化工作，包括加载配置、创建代理对象、建立连接等，这些操作都会增加调用的耗时。2. **服务发现和注册：** Feign 在第一次调用时需要进行服务发现和注册，将服务名称解析为具体的服务地址，并建立连接。这涉及到网络通信和 DNS 解析等过程，会增加调用的延迟。3. **线程池初始化：** Feign 在进行远程调用时通常会使用线程池来管理线程，第一次调用时可能需要初始化线程池，这会增加调用的启动时间。4. **类加载和代理生成：** Feign 使用动态代理来生成客户端代码，第一次调用时可能需要加载和生成相关的类，这会增加调用的启动时间。5. **连接池初始化：** Feign 通常会使用连接池来管理 HTTP 连接，第一次调用时可能需要初始化连接池，这会增加调用的启动时间。为了减少 Feign 第一次调用的耗时，可以采取以下一些措施：- **预热：** 在应用启动时进行预热操作，提前初始化 Feign 客户端对象，加载配置信息，建立连接等，以减少第一次调用的延迟。- **连接池管理：** 可以调整连接池的大小和参数，以减少连接池初始化的时间和资源消耗。- **延迟初始化：** 可以延迟初始化 Feign 客户端对象，将初始化工作放到第一次调用之后进行，以减少应用启动时间。- **异步初始化：** 可以使用异步方式进行 Feign 客户端的初始化工作，以提高初始化的并发度和效率。通过合理配置和优化，可以有效减少 Feign 第一次调用的耗时，提高系统的性能和可用性。

0 前言 机票查询系统，日均亿级流量，要求高吞吐，低延迟架构设计。提升缓存的效率以及实时计算模块长尾延迟，成为制约机票查询系统性能关键。本文介绍机票查询系统在缓存和实时计算两个领域的架构提升。 1 机票搜索服务概述 1.1 机票搜索的业务特点 机票搜索业务：输入目的地，然后点击搜索，后台就开始卷了。基本1~2s将最优结果反给用户。这个业务存在以下业务特点。 1.1.1 高流量、低延时、高成功率 超高流量，同时，对搜索结果要求也很高——成功率要高，不能查询失败或强说成功，希望能反给用户最优最新数据。 1.1.2 多引擎聚合，SLA不一 机票搜索数据来源哪？很大一部分来源自己的机票运价引擎。为补充...