- 博客(85)
- 资源 (1)
- 收藏
- 关注
RSS订阅原创 故事串讲OpenAgents的核心特性
摘要：OpenAgents是一个智能助手平台，通过模块化设计实现多功能集成。其核心特性包括：1）可插拔模块（Mods）按需组合，如PPT生成、差旅安排等专业功能；2）支持多种协议（HTTP/WebSocket/EVM/IPFS），连接数字与物理世界；3）事件驱动系统实现自动化工作流。该平台采用开放生态设计，允许功能持续扩展，将复杂的多应用操作简化为自然语言指令，成为连接现实世界的智能枢纽。
2025-12-18 08:48:10
430
原创 StarRocks PB 级日增量数据模型优化：注意点、调优策略与风险防控
摘要： StarRocks处理PB级日增量需平衡高吞吐导入与低延迟查询，从数据模型、分区分桶、导入策略、存储优化及资源调度五维度系统优化。关键点： 模型选择：按业务场景选明细/聚合/主键模型，避免全表扫描或聚合开销； 分区分桶：时间分区+高基分桶键，单分区50-200GB，分桶数按数据量动态计算； 导入优化：StreamLoad分批写入（≤10GB/批），错峰调度，限流防OOM； 查询加速等等
2025-12-09 11:09:23
1006
原创 web3区块链-加密小镇的 “十年庆典徽章”：ERC-721 全流程故事（含所有核心接口）
摘要：加密小镇为庆祝建镇十周年发行100枚限量纪念徽章，采用ERC-721标准解决数字资产确权与流通问题。通过mint铸造唯一徽章，ownerOf验证所有权，tokenURI展示徽章详情，transferFrom实现安全转让，approve/approveForAll完成授权管理。ERC-721标准化接口使限量徽章具备防伪、可追溯、跨平台流通的特性，为数字收藏品建立了通用规范，让"独一无二"的资产在区块链上实现安全高效的流转与管理。
2025-12-02 21:26:26
1010
原创 web3区块链-小镇店铺的 “借力办事”：call 与 delegatecall 的区别与联系
摘要：本文通过水果店Alice和管理咨询店Bob的类比，解释Solidity中call和delegatecall的区别。两者都用于合约间调用，但关键差异在于操作谁的存储：call执行被调用合约的代码并修改其存储，而delegatecall执行被调用合约的代码但修改调用合约的存储。call适用于修改对方状态（如调用USDT转账），delegatecall适用于复用逻辑并修改自身状态（如代理合约升级）。存储结构必须对齐是delegatecall的特殊要求。
2025-12-02 14:41:10
916
原创 隐私计算 - 三家蛋糕店的 “秘密协作“：多方计算（MPC）的诞生与原理
故事环节MPC 对应概念核心作用三家店的销售额敏感私有数据多方需要协作计算的原始数据，不可泄露拆分销售额为随机碎片秘密分享（Secret Sharing）将原始数据拆解为无意义碎片，分散存储各自计算碎片和分布式计算参与方仅对本地碎片计算，不接触原始数据汇总碎片和得到总销售额结果聚合公开局部计算结果，聚合得到最终答案没人能偷看 / 作弊安全模型满足 "半诚实 / 恶意模型"，抵御作弊和数据窃取。
2025-12-01 18:26:25
1195
原创 Iceberg、Paimon 与 Hudi：数据湖三剑客的初心与进化
数据湖三剑客对比分析 摘要：Iceberg、Hudi和Paimon是当前主流的数据湖解决方案，各有特色。Iceberg(Netflix开源)专注批处理可靠性，适合PB级离线分析；Hudi(Uber开源)强调实时更新，实现流批平衡；Paimon(Flink社区)则为流式处理优化，提供毫秒级延迟。三者分别采用清单文件、COW/MOR和LSM-Tree架构，在事务控制、Schema演变等方面各具优势。选型需考虑场景需求：离线分析选Iceberg，流批平衡选Hudi，Flink实时数仓则首选Paimon。未来三大项
2025-12-01 16:07:40
1128
原创 web3区块链的交易是怎样物化形式记录在区块中的
比特币区块链采用结构化存储方案实现高效交易验证：每个区块由80字节区块头和约1MB区块体组成，后者以二进制格式存储4,194笔交易。交易通过Merkle树构建索引，叶子节点存储交易哈希，最终生成32字节Merkle根存入区块头。这种设计使轻节点仅需下载区块头即可验证交易，全节点则存储完整二进制交易数据。交易数据包含版本号、输入输出列表等字段，通过双重SHA256哈希生成唯一txid。Merkle树验证机制确保任何篡改都会被检测，分布式节点网络保障数据安全，实现去中心化、高效验证与防篡改的平衡。
2025-11-27 11:21:57
608
原创 Web3比特币区块链：10 分钟区块与 7 TPS 的关系解析
比特币区块链的7TPS源于其核心设计：10分钟出块时间和1MB区块大小限制。这是中本聪为平衡安全性与去中心化做出的刻意选择，而非技术缺陷。计算显示1MB区块10分钟出块自然产生约7TPS。10分钟间隔保障网络安全，防止51%攻击，同时控制比特币发行速率。交易需6次确认（约1小时）以确保不可逆。相比Visa的高吞吐中心化系统，比特币优先考虑去中心化和安全性。扩容方案如BCH增大区块或闪电网络可提升TPS，但需权衡其他特性。7TPS体现了比特币"数字黄金"的设计哲学。
2025-11-26 13:49:38
879
原创 Web3 重入攻击：银行提款机的 “漏洞抢劫案”
《智能合约中的重入攻击漏洞分析》 本文通过GoldBank案例揭示了Web3智能合约中的重入攻击漏洞。该漏洞源于合约在提款时先转账后更新余额的错误顺序，使黑客能通过恶意合约的回调函数重复提款。攻击者利用receive()函数在转账时再次调用提款函数，由于余额尚未清零，导致合约重复转账。防御措施包括：1）先更新状态再执行外部调用；2）使用ReentrancyGuard锁；3）限制外部调用gas量。
2025-11-26 11:01:40
451
原创 Web3-智能合约-零知识证明：不晒钱包也能进专属社区的秘密
摘要：Web3社交平台"星巢"通过零知识证明技术解决了NFT持有者身份验证中的隐私泄露问题。传统验证要求用户公开钱包地址，导致资产明细暴露和安全风险；而零知识证明允许用户在不透露钱包地址的情况下，通过数学验证证明NFT持有权。该技术满足完备性、可靠性和零知识性三大特性，已应用于隐私交易、资产确权等多个Web3场景，实现了"既证明身份又不泄露隐私"的平衡，成为Web3隐私保护的核心工具。
2025-11-25 11:34:01
1444
1
原创 Web3-智能合约-整数溢出攻击：“凭空造币”的秘密
《Web3安全警示：绿芽币合约整数溢出漏洞分析》摘要： 小李开发的环保主题ERC20代币"绿芽币"因合约漏洞遭遇黑客攻击。虽然合约设定了100万枚总量上限和单次1万枚兑换限制，但未对整数溢出进行防护。黑客小张通过精心计算，利用uint256类型变量的溢出特性，仅用不到1分钱的ETH就绕过了总量限制检查，成功铸造99万枚代币并抛售，导致市场崩盘。该案例揭示了Web3开发中整数溢出漏洞的危害性，建议开发者采用SafeMath库、升级Solidity0.8+版本或严格限制输入范围等防护措施。智
2025-11-25 11:07:07
933
原创 使用多AI Agent赋能大数据资产治理-0章
本文探讨了数据资产管理中的重复建设与规范性问题，提出了一种基于LangGraph的Agent工作流解决方案。该方案结合规则与智能分类，从三个维度构建数据资产标签体系：OneData规范标签（包括模型/指标重复、跨层依赖等）、业务标签（业务域、主题域等）和访问分级标签（访问频率、就绪时间等）。系统支持多种数据源输入，包括元数据API、业务文档等，旨在通过智能化手段解决传统全规则或全Agent方法在灵活性、准确性方面的不足，提升数据资产管理效率。
2025-11-21 11:31:26
36
原创 使用多AI Agent赋能大数据资产治理-总章
本文提出了一种基于LangGraph的数据资产标签自动化系统设计方案。系统采用"路由-并行-聚合"模式，整合规则引擎和AI Agent，通过确定性逻辑（血缘依赖、访问统计）与模糊推理（语义理解、业务归类）的协同处理，实现数据资产的智能标签化。方案详细定义了状态流转机制和工作流节点，包括知识库准备、规范处理、业务理解和访问分析四个并行分支，最终聚合输出完整标签。关键技术难点通过Schema Embedding、RAG增强和分位数统计等方法解决，并建议分阶段实施验证。
2025-11-21 11:20:05
198
原创 怎样把MCTS算法应用于多Agent动态编排中
摘要：MCTS算法能高效解决多Agent动态编排问题，通过将多Agent协同转化为多分支搜索问题，采用"试错-反馈-优化"循环寻找最优策略。其优势在于无需穷举所有可能，支持动态环境调整，并平衡探索与利用。关键是将Agent状态、动作和奖励映射到搜索树节点，通过模拟与回溯优化决策。典型应用场景包括任务分配、工业机器人协作和故障恢复。针对多Agent特性需优化并行处理、动态探索率等，虽面临状态空间大等挑战，但通过状态抽象等方法可有效应对，实现复杂环境下的自适应协同。
2025-11-12 15:20:36
850
原创 故事化场景讲清楚AI领域的MCTS算法的原理与应用场景
MCTS算法是一种适用于复杂决策问题的智能搜索方法，通过"选择-扩展-模拟-回溯"的循环机制逐步优化解决方案。该算法首先评估当前最优选项，然后扩展未探索的新分支，快速模拟其潜在价值，最后回溯更新决策依据。这种机制特别适合大模型文本生成、游戏AI决策等需在众多可能中快速找到较优方案的应用场景。MCTS的优势在于不需穷举所有选项，而是通过迭代学习不断修正策略，兼顾效率与效果，最终实现智能化的渐进优化。
2025-11-12 15:17:10
682
原创 数据湖的 “双雄记”：Hudi 与 Iceberg 的诞生故事与使命抉择
摘要：Apache Hudi与Apache Iceberg分别针对数据湖的不同痛点提出解决方案。Hudi专为实时场景设计，通过时间线管理、双更新模式（CoW/MoR）和布隆索引等机制优化低延迟写入与增量更新，适用于用户画像、IoT等需要快速响应的业务。Iceberg则专注于批量分析的可靠性，采用四层元数据架构、快照隔离和字段ID等设计，确保查询效率、版本兼容和多团队协作，适合企业数仓、日志分析等场景。
2025-11-06 15:55:59
757
原创 Hudi和Iceberg的Specification规范角度详细比较异同点
摘要：Apache Hudi和Iceberg作为主流数据湖框架，在事务管理、版本控制和数据读写方面存在显著设计差异。Hudi采用扁平时间线+DeltaLog的元数据结构，通过Instant实现乐观锁和单阶段提交，更侧重流式更新；而Iceberg采用树状快照+清单文件结构，通过多阶段提交实现快照隔离，强调通用性和多引擎兼容性。两者在索引机制、Schema演进和数据更新方式上各有侧重：Hudi侧重主键索引和写时合并，Iceberg则提供更灵活的二级索引和强Schema兼容性。
2025-11-05 16:58:58
632
原创 hudi 的clustering的策略与业务场景
ApacheHudi的Clustering机制通过触发策略和执行策略优化数据布局。触发策略包括：1)基于文件数量(num_files)，解决高频小文件问题；2)基于文件大小(file_size)，均衡文件体积；3)基于时间间隔(time)，定期维护数据质量；4)手动触发(manual)应对特殊场景。执行策略则包含：1)合并范围控制（分区内或全局）；2)按业务字段排序提升查询效率；3)文件分组策略防止OOM；4)增量/全量模式选择。策略组合需匹配业务特点：IoT数据推荐num_files触发+设备ID排序，电
2025-11-05 14:41:26
919
原创 AI问数架构supersonic简介
Supersonic是一款结合ChatBI（LLM驱动）和HeadlessBI（语义层驱动）的新型BI平台，通过语义层增强自然语言查询的可靠性。其架构基于SpringBoot3.x，支持多数据库和自定义扩展，优化了性能与效率。核心功能包括模型知识库、语义解析器、修正器等组件，实现从自然语言到SQL的精准转换。平台提供开箱即用的BI界面、多轮对话支持、三级权限控制和灵活的扩展机制，为业务用户和分析师提供高效的数据查询与分析体验。
2025-11-04 17:25:59
732
原创 从文件结构、索引、数据更新、版本控制等全面对比Apache hudi和Apache paimon
ApacheHudi与Paimon作为主流数据湖框架，在架构设计与应用场景上各具特色。Hudi采用DeltaLog+数据文件的两层结构，提供Copy-on-Write和Merge-on-Read两种更新模式，擅长低延迟增量处理，适合实时数据服务和频繁更新场景。Paimon基于LSM树的三层架构（Manifest+Snapshot+数据文件），通过"增量写入+后台Compaction"机制优化批量读写，更适用于大规模分析和高吞吐混合场景。核心差异体现在索引机制（Hudi侧重主键查询/Pai
2025-10-30 18:01:19
1117
原创 celery beat和celery worker的区别和联系是怎样的
CeleryBeat和CeleryWorker是Celery任务调度系统的核心组件，二者分工明确又相互配合。Beat作为"任务生产者"负责按预设时间规则生成定时任务并发送到消息中间件，而Worker作为"任务消费者"则从消息队列获取任务并执行具体业务逻辑。它们通过Broker协作完成"调度→分发→执行→结果存储"的全流程，共同实现可靠的定时任务处理。实际部署时建议将Beat和Worker分开运行，并注意保证Beat进程的唯一性以避免任务重复执行。
2025-10-30 15:03:54
755
原创 场景化讲一下celery task里面的bind是什么
Celery任务中bind参数的作用在于控制是否将任务实例(self)作为首个参数传递。当bind=False(默认)时，任务仅接收业务参数；当bind=True时，任务函数第一个参数必须是self，通过它可以访问任务属性和方法(如重试机制self.retry()、任务ID等)。bind=True适用于需要重试、获取任务元信息等复杂场景，而简单任务可省略该参数。这个参数的设计体现了Celery在任务控制灵活性上的考量。
2025-10-29 16:13:40
328
原创 pulsar各概念之间的关系
文章摘要： 该文提炼了消息队列中5个核心组件的分层解耦关系：1）Topic按1:N拆分为固定Partition实现负载均衡；2）Partition与Broker动态1:1绑定，支持故障迁移；3）Partition强绑定1个ManagedLedger作为专属存储容器；4）ManagedLedger由多个动态创建的Ledger组成；5）Ledger以多副本形式分散存储于Bookie集群。设计通过上层数据分片、中层计算存储衔接、下层多副本持久化，既保证Partition内数据有序性，又实现存储层独立扩容能力，形成
2025-10-29 11:01:18
507
原创 pulsar与kafka的架构原理异同点
摘要： Apache Pulsar与Kafka均属分布式流处理平台，支持高吞吐、持久化及分区机制，但架构差异显著。Pulsar采用计算与存储分离设计（Broker无状态+BookKeeper独立存储），扩展性更优，支持多租户和灵活消费模式；Kafka耦合计算存储（Broker有状态），依赖分区迁移扩容，生态更成熟。选择建议：Pulsar适合需弹性扩展、跨地域复制的场景；Kafka适合追求极致吞吐或依赖成熟生态的系统。核心差异在于架构理念，Pulsar以分离换灵活性，Kafka以耦合换性能。
2025-10-28 17:23:28
687
原创 pulsar针对数据扩容一般是怎样处理来保障后续keyed partitioned消费不会乱序
Pulsar数据扩容时需重点处理Topic分区扩容以避免消费乱序。核心方案分三阶段：1）扩容前评估必要性并选择整数倍扩容；2）扩容中生产者双写新旧Topic，消费端优先处理旧数据；3）旧数据处理完后切换到新Topic，按时间戳有序合并数据。Broker/Bookie扩容因架构特性（无状态、存储分离）不影响消费顺序。
2025-10-28 16:41:49
976
原创 LangGraph的Agent长短时记忆的原理有什么区别，分别适用于什么业务场景
LangGraph的长短时记忆机制通过状态分层存储实现工程化设计。短时记忆基于Thread内的Checkpoint实现，适用于单流程内的临时状态复用（如多轮对话、分步任务），生命周期与Thread绑定，数据随流程结束而销毁。长时记忆通过Store接口实现持久化存储，支持跨流程/会话复用关键信息（如用户偏好、全局配置），需手动定义存储逻辑。二者的核心差异在于记忆是否突破Thread边界，实际应用中常结合使用：短时记忆处理流程内临时数据，长时记忆沉淀跨会话重要信息。
2025-10-27 19:57:51
608
原创 基于AI框架LangGraph对比Workflow模式与Agent模式
LangGraph是LangChain生态中的工作流和智能体构建工具，提供两种核心模式： Workflows：基于预定义路径的固定流程，支持链式执行、并行处理、动态路由等模式，适用于文档翻译、多任务处理等确定性场景。 Agents：具备动态决策能力，通过LLM自主选择工具（如算术计算、API调用），适用于未知问题求解等灵活场景。
2025-10-27 14:51:03
2117
3
原创 基于AI Agent的数据资产自动化治理实验
本文提出了一种基于LangChain+RAG+LLM的数据资产自动化治理方案，通过构建五层架构实现标签归类和重复识别。核心流程包括：1）构建业务知识向量库作为治理依据；2）封装元数据查询和依赖关系工具；3）设计治理Agent协调知识检索、工具调用和决策推理；4）采用Prompt模板规范输出格式。方案通过批量处理资产清单实现自动化治理，同时支持人工校验优化模型。该方案能完成80%的标准化工作，显著提升治理效率，并可通过扩展工具增强功能。
2025-10-26 22:32:15
996
原创 AI Agent常用的RAG有哪些种，分别适用于什么情况
RAG（检索增强生成）技术根据核心能力可分为多种类型：1）按检索精度分为基础RAG、HyDE（假设文档嵌入）、多向量RAG和分层RAG，适用于不同查询复杂度；2）按数据动态性分为静态RAG（低频更新）和动态RAG（实时同步）；3）按模态分为文本RAG和多模态RAG（支持跨模态检索）；4）按架构分为简易RAG（原型验证）和工业级RAG（高可用生产环境）。选择时需综合考虑数据特性、需求精度、业务规模和资源成本，如电商客服适合多模态+动态+工业级RAG，而小团队文档查询适合文本+静态+简易RAG。
2025-10-26 22:20:36
1050
原创 吃透大数据算法-量体裁衣-HNSW场景化参数调优
HNSW（分层可导航小世界网络）调优需根据业务场景平衡速度、精度、索引大小和构建效率。核心参数包括M（邻居连接数）、efConstruction（构建候选数）、efSearch（查询候选数）和距离度量。不同场景推荐配置：实时推荐（小M+小ef）、高精度检索（大M+大ef）、通用场景（中M+中ef）、亿级数据（中M+分层ef）和动态数据（中M+小ef）。调优步骤：先确定距离度量，再设定M值，依次调整efSearch和efConstruction，最后验证召回率、延迟和索引体积。避免常见错误如参数不匹配、距离度
2025-10-24 15:33:19
1013
1
原创 吃透大数据算法-百万商品库的 “闪电匹配”：HNSW 算法的电商实战故事
电商技术团队通过HNSW算法优化"拍图找同款"功能，解决了高维向量搜索的性能瓶颈。传统暴力搜索在100万商品库中耗时3秒，而HNSW通过构建多层导航图（底层精确匹配、高层快速定位），将搜索时间降至80毫秒。该算法利用概率分层和动态插入机制，支持618期间10万新商品的无缝扩容，并通过调整M（连接数）和efSearch（候选数）参数平衡速度与精度。HNSW的"先粗后精"搜索策略不仅适用于电商，还可广泛应用于RAG问答、图像检索等需要高维向量匹配的场景。
2025-10-24 14:47:10
1101
原创 字节多Agent架构Aime—— 让多个 AI 像 “灵活团队” 一样干活的新系统
摘要：字节跳动团队开发的"Aime"是一个创新的AI协作框架，通过四个核心模块解决多AI协作中的三大痛点。动态规划器像"项目经理"灵活调整任务；智能体工厂按需快速生成专用AI；动态智能体以"思考-行动-反馈"方式执行任务；中央进度管理模块确保信息同步。实验证明，Aime在复杂问答、代码修复等任务中表现优于传统单一AI系统。该框架使AI团队能像"灵活的小团队"一样协作，有效应对突发情况，有望提升复杂任务的处理能力。
2025-10-23 17:22:44
1330
原创 Flink中的Lookup join和Temporal join 的语法是一样的吗？
LookupJoin和TemporalJoin虽然语法相似（都使用FORSYSTEM_TIME_ASOF），但存在本质区别：LookupJoin用于流数据查询静态/缓变维表（如商品信息），仅需处理时间对齐；TemporalJoin则用于关联维表历史版本（如商品价格），需要维表具有版本化特性。核心差异在于维表是否需版本管理，前者补充静态属性，后者解决历史状态回溯问题。语法相似性是表象，实际应用场景和底层逻辑完全不同。
2025-10-23 11:11:47
1034
原创 Flink 的 checkpoint 对 key state 是怎么样存储的？
Flink状态管理机制摘要：KeyState按KeyGroup划分存储，通过StateBackend实现本地和检查点持久化。HeapStateBackend直接序列化内存状态到HDFS，RocksDBStateBackend则采用增量快照上传策略。故障恢复时，系统会重新分配KeyGroup到可用节点，从检查点下载对应状态数据（堆内存反序列化/RocksDB快照恢复），确保状态一致性。整个恢复流程包括故障检测、KeyGroup重分配、状态下载验证及数据源位置恢复等关键步骤。
2025-10-22 23:06:47
1123
原创 Flink的checkpoint interval与mini-batch什么区别？
摘要： Flink中checkpointInterval与minibatch均涉及批处理，但目标不同：前者通过定期生成barrier实现容错（故障恢复），后者通过攒批优化吞吐（减少数据传输）。checkpointInterval仅间接影响事务性sink的输出频率，而minibatch直接控制算子攒批与输出节奏。实现“每分钟稳定输出”需二者协同：配置minibatch.allow-latency=1min控制输出间隔，配合checkpointInterval=1min及事务性sink（如Kafka/JDBC）
2025-10-22 16:57:33
925
原创 Flink重启策略有啥用
摘要：Flink重启策略适用于临时性故障（如外部系统短暂不可用、资源临时不足、网络抖动等），通过重试可自愈；不适用于永久性故障（如代码Bug、配置错误、外部系统永久失效等），需人工修复。重启策略包括固定延迟、指数延迟（推荐生产环境使用，平衡恢复效率与系统保护）、失败率及不重启策略。判断标准为故障是否短期偶发、重试后能否恢复。核心逻辑是区分故障根源，避免无效重试。
2025-10-21 21:35:03
922
翻译 深入探讨 Apache Flink 中的可扩展状态（译）
本文深入探讨了Apache Flink中有状态流处理的核心概念和实现机制。文章首先区分了无状态和有状态流处理的差异，指出状态是流处理中实现复杂业务逻辑的基础。随后详细介绍了Flink中两种状态类型(Operator State和Keyed State)的设计原理，特别聚焦于状态重缩放(rescaling)时的重新分配问题。对于Operator State，Flink通过列表检查点接口实现状态的有意义分区；对于Keyed State，则采用keygroup作为状态分配的原子单位，确保高效的重分配。
2025-10-21 20:38:38
39
原创 Spark的shuffle类型与对比
Spark提供多种Shuffle机制，核心包括：1）广播机制通过内存复制小表避免Shuffle，适用于Join且小表≤10MB（默认）；2）HashShuffle（已淘汰）为每个Reducer生成独立文件，文件数爆炸（M×R）；3）ConsolidatedHashShuffle优化为Executor共享文件（C×R）；4）SortMergeShuffle（当前默认）对数据排序后合并，仅生成2M文件（数据+索引），适合大数据量；5）BypassMerge作为其子机制在Reducer≤200时跳过排序
2025-10-21 16:29:24
1020
原创 大数据计算引擎-Hudi对Spark Catalyst 优化器的RBO、CBO做了什么
摘要：Hudi通过改造RBO和CBO优化查询性能。RBO方面，实现过滤下推、分区修剪和投影下推，利用Hudi的文件结构、索引和分区特性减少数据扫描。CBO方面，收集文件级和列级统计信息，帮助查询引擎准确估计代价，选择最优计划。源码层面通过HoodieFileIndex、HoodieRelation等类实现与Spark等引擎的集成，最终降低查询IO和计算开销。
2025-10-20 20:38:23
1218
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人