- 博客(45)
- 收藏
- 关注
RSS订阅
原创 【智能问数系统拆解·2】问完就忘——Learn系统让AI学会“长记性“
本文探讨了智能问数系统的学习机制设计。作者通过分析两个成熟系统的实现，发现学习功能应内置于查询引擎而非响应层，记忆应作为独立消息类型而非拼接在提示词中，并需统一的学习内核取代碎片化子系统。基于这些发现，作者设计了Learn V2双层架构，包含核心SDK和应用层组件，通过事件分组、五级评分和生命周期管理实现分析套路的复用与进化。系统能自动识别相似问题并复用历史分析模式，显著提升响应效率。研究表明，显式结构化学习机制比传统隐式学习更有效，对话资产应沉淀为可管理的数据而非仅存在于模型内部。
2026-06-11 14:44:55
330
原创 【智能问数系统拆解·1】用户跳过澄清，下一轮直接400——4轮调查才找到根因
摘要：本文拆解了一个隐藏4轮才被发现的400错误Bug。用户点击"跳过澄清"后，下一轮请求神秘返回400，根源在于运行时重建对话历史时静默丢弃了无锚点的function_call_output。深层暴露了系统架构问题——查询状态（query state）缺乏明确归属，散落在prompt、模型记忆和应用层之间。作者提出让SDK成为状态唯一持有者，通过QuerySessionState集中管理跨轮次状态，避免状态丢失。该案例揭示了智能问答系统的核心在于有状态管道的设计，而非单纯依赖LLM。（149字）
2026-06-11 14:37:13
78
原创 【智能问数·1】从0到1搭建智能问数系统：LLM只是个翻译，QueryEngine才是大脑
本文作者分享了开发智能问数系统的完整过程，从最初设想到最终架构的演进。文章分为三个阶段： 初期错误：作者最初认为简单使用LLM将自然语言转为SQL即可，但在测试中发现三大问题：指标歧义、多轮状态丢失和元数据映射错误，原因是过度依赖LLM处理所有复杂逻辑。 深入调研：作者研究了两种架构——系统A的Pipeline设计和系统B的单体设计，发现关键在于构建一个多轮状态机（QueryEngine）而非简单的线性流程。 最终方案：采用七层Pipeline架构，将查询过程分解为澄清引擎、状态管理等独立阶段，通过Cont
2026-06-10 14:08:31
232
原创 【实时数仓·3】你还在用二元链式JOIN？Flink早就多元并行了——但你得先升到2.1
本文分析了Flink多表JOIN导致状态爆炸的问题及解决方案。作者在处理10张MySQL CDC表关联的实时任务时，发现状态从几百MB暴涨至12GB。问题根源在于Regular JOIN会永久保存中间状态，TTL设置面临两难：太小会导致数据丢失，太大则内存爆炸。 Flink 2.1提出的MultiJoin方案通过"零中间状态"设计（用计算换存储）从根本上解决问题，但当前生产环境（Flink 1.17）无法使用。作者采用分层治理策略：对低频变化的维度表使用Event Time Temporal JOIN，对事
2026-06-08 13:51:07
230
原创 【实时数仓·3】Flink多表JOIN状态爆炸——Event Time Temporal JOIN + TTL分层治理
实时数仓中Flink多表JOIN状态爆炸问题及分层治理方案 问题描述：一个出库包裹实时任务因10表JOIN导致状态从几百MB暴涨至12GB，引发Checkpoint过大和RocksDB写入阻塞。初期通过设置TTL（10天或30天）尝试解决，但面临数据丢失或内存爆炸的两难局面。 根因分析：问题源于Regular JOIN机制需永久保存两侧状态，10表JOIN导致状态数据指数级增长。TTL仅作为补救措施，无法根本解决状态爆炸问题。 分层解决方案： Event Time Temporal JOIN：适用于低变化的
2026-06-08 11:05:46
786
1
原创 【实时数仓·2】CDC到Doris数据对不上——Sequence Column解了吗？
本文总结了使用CDC工具从MySQL同步数据到Doris时遇到的乱序问题及解决方案。作者发现虽然CDC、Flink日志正常，但Doris数据异常，最终定位到是Doris Unique Key模型在乱序写入时后到数据覆盖先到数据的问题。通过为Doris表配置Sequence Column（如update_time字段），确保按业务时间顺序正确覆盖数据。文章还指出CDC涉及源库、网络、SQL引擎和存储引擎四个层面，排查问题需逐层分析，并分享了Doris 2.0.14版本的相关Bug及解决方案。最后强调对于频繁变
2026-06-04 16:18:29
313
原创 【实时数仓·1】实时数仓选型：Paimon火了，Doris还能撑多久？
文章摘要： 本文对比了实时数仓中Doris与Paimon的技术选型。Paimon作为Apache流式数据湖存储，支持流批一体、行级更新、Changelog和Time Travel，与Flink深度集成，适合多业务线共享数据、复杂更新及历史追溯场景。Doris则更简单高效，适合稳定且需求单一的链路。作者团队因现有Doris链路稳定、迁移成本高暂未切换，但指出未来若需流批一体、频繁更新或数据回滚，Paimon是更优选择。技术选型应基于实际业务需求，而非单纯技术热度。
2026-06-03 15:11:05
255
原创 【数据中台·8】数据中台怎么落地？8步踩出来的路线图
数据中台建设的关键在于以业务需求为驱动，而非单纯技术堆砌。本文通过两年实践总结出8步建设路线图：数仓分层、数据质量、服务化、元数据、数据治理、数据地图、资源治理和权限分割。核心教训是第三步"服务化"最易受阻——当技术团队预先构建能力却缺乏业务场景时，往往遭遇"这不是我要的"困境。成功经验在于调整策略：先选择典型业务场景实现端到端闭环（如网点运单分析），用实际效果说服业务方配合。最终建成的中台包含1362张分层表、200+质检规则和四种服务方式，但真正价值在于形成"业务提需求-技术响应-业务使用"的良性循环。
2026-06-02 09:21:40
200
原创 【数据中台·7】数据推出去就完了？服务化的四个坑
本文总结了数据服务化实践中的常见问题与解决方案。文章指出，数据服务化的核心不在于技术实现，而在于统一管理。作者列举了四种数据服务方式（自助查询、财务报表、智能问数和定制化报表）在实际运用中遇到的四大典型问题：数据推送时未建立唯一键导致重复数据、业务方导出数据时因系统限制产生截断、不同平台指标口径不一致，以及权限管理分散。针对这些问题，文章提出了具体解决措施：建立唯一键更新机制、限制明细数据导出并增加数据量提示、统一所有平台的数据源口径，以及基于组织架构统一权限管理。最终强调，有效的服务化需要制定并严格执行统
2026-05-30 10:00:00
388
原创 【数据中台·6】血缘关系之那些踩过的坑
文章摘要：本文探讨了数据中台血缘关系建设的实践与挑战。作者通过排查报表数据问题的案例，揭示传统血缘系统仅展示物理依赖关系而无法有效定位影响范围的痛点。针对字段映射混乱、全局血缘视图信息过载等问题，团队创新性地采用逐层展开的交互方式，分离前置/后置血缘存储，通过SQL解析+人工兜底实现1362张表的自动化维护。最终形成的解决方案聚焦核心需求——快速评估数据变更影响，在完整性和可用性间取得平衡，使血缘系统真正成为数据治理的有效工具。（149字）
2026-05-29 08:58:57
361
原创 【数据中台·5】数据质量校验
数据质量校验的三大陷阱与应对策略 摘要：本文通过真实案例揭示了数据质检中的常见漏洞：1）默认值变更导致空值检测失效；2）业务新增枚举值未被覆盖；3）历史数据删除未被发现。作者总结出质检规则需从"有没有"升级到"对不对"，提出分级质检方案：核心表强依赖阻断、非核心表弱依赖告警，并强调业务规则需由业务方定义。最终指出数据质检的本质矛盾——数仓掌握技术规则但不懂业务逻辑，业务方了解逻辑却不愿参与规则制定，建议建立跨部门协作机制。文章附有质检流程图和SQL检测示例，为数据治理提供实操参考。（149字）
2026-05-28 10:59:07
379
原创 【数据中台·4】维度资产管理
本文探讨了数据中台维度资产管理中的关键问题及解决方案。核心痛点在于维度变更导致历史报表数据不一致，表现为网点归属调整后历史报表自动变化。文章指出当前维度管理存在三大缺失：缺乏资产清单、版本控制和变更通知机制。 针对这些问题，作者提出三管齐下的解决方案：1）采用维度拉链表保留历史版本，确保按业务日期获取正确维度快照；2）结合每日快照分区提升查询性能；3）建立变更通知机制自动广播维度变动。实施建议包括区分维度类型决定是否拉链、分批迁移新旧系统并行运行、保留回滚能力等。该方案既解决了历史数据准确性问题，又考虑了实
2026-05-26 16:35:44
469
原创 【数据中台·3】数仓分了五层，三层在越权，分层分了个寂寞
数据中台分层架构中常见的越权问题：ODS层擅自做业务映射导致历史数据无法修改，DW层越权JOIN维度表使DWD层失去作用，DWD层顺手聚合引发DWS层直接COPY数据，最终导致ST层绕过DWS直接查询DWD产生数据不一致。文章提出三条核心禁令解决分层混乱：ODS禁止业务映射、DWD禁止聚合、ST禁止直接查询DWD。通过明确各层职责边界（ODS原样接入、DW去重标准化、DWD维度JOIN、DWS聚合、ST只读DWS），避免连锁反应造成的数据治理困境。
2026-05-26 11:14:18
370
原创 【数据中台·2】建完指标体系没人认？这三个坑方法论里没写
摘要：指标体系在借鉴阿里OneData方法论时遭遇三大挑战：1）修饰词与维度边界模糊，通过SQL语法（WHERE条件为修饰词，GROUP BY为维度）实现清晰划分；2）命名规范与业务可读性冲突，采用"规范英文名+中文注释+BI层映射"的折中方案；3）口径统一后使用方不认可，通过指标卡片、自动校验SQL和口径代码化推动落地。最终87个指标精简优化，23个重复口径合并，11个同名异义指标统一。实践表明，指标体系建设的核心在于技术与业务的持续对齐，而非单纯的技术实现。
2026-05-25 10:34:52
361
原创 【数据中台·1】数据中台到底该不该搞？
本文结合企业依托集团技术底座、小团队运维的现状，论证轻量化数据中台落地可行性。企业无需重构底层基座，核心聚焦业务数据资产中台建设。针对现存数据质量差、指标口径混乱、取数低效、数据争议频发等痛点，依托现有业务数据基础，采用先落地业务价值、后规范建模的迭代思路，通过数据治理、统一口径、搭建OneData体系，实现低成本、轻量化的数据中台落地。
2026-05-22 16:49:48
385
原创 用CASE WHEN实现横向迭代，节点数据串行推算
摘要：本文分享了用SQL处理物流节点时间横向迭代计算的实战经验。面对错发运单导致静态路由表失效的问题，作者采用6步临时表串行推算方案，每步依赖上一步结果。核心难点在于处理5种班次规则（隔日班、周班等），通过多层CASE WHEN判断最近班车时间。最终方案结合Presto快速调试和Spark动态分区写入，实现了复杂业务场景下的横向迭代计算。文章揭示了SQL处理层级依赖数据的局限性，展示了临时表+CASE WHEN的实用解法。
2026-05-13 15:15:32
376
原创 运输时效预测模型：静态路由时效的计算与验证
物流时效预测模型通过静态路由时效表计算运单计划时效，结合扫描轨迹提取的实际时效数据进行验证。模型基于运单路由信息和节点计划时间累加计算总时效，并通过偏差分析评估预测准确性。数据架构涵盖从扫描轨迹到时效宽表的多层处理，最终输出各线路预测准确率和偏差分析。该模型存在路由变化、异常事件和数据质量等局限，需通过实际路由重算、异常标记和数据兜底等方法优化。时效预测是数据驱动的计算与验证过程，为物流运营提供决策支持。
2026-05-11 16:42:22
346
原创 DataX增量同步的2个坑：分区错位 + 删除无感
摘要： 数据仓库增量同步中常见的两个坑：1) 时区混乱导致数据切错分区，业务库、代码和数仓使用不同时区，导致凌晨数据被误分到前一天。解决方案是增量时间窗口前后留1小时缓冲；2) 业务物理删除记录导致数仓数据不准，业务直接DELETE签收记录后重录，但数仓无法感知删除，导致及时率计算错误。最终建议增量同步遵循三条铁律：时区留缓冲、感知物理删除、避免业务时间戳作为增量字段。
2026-05-08 11:21:09
417
原创 事实表设计
数据报表中常见的三种事实表各有适用场景：事务事实表记录事件（可能重复），周期快照表反映每日状态（不保证链路完整），累积快照表跟踪订单全流程（未完成则为NULL）。计算转化漏斗应使用累积表，但要注意不同业务口径（如签收率可按签收时间或创建时间计算）。关键是要根据业务问题选择合适的表类型，并清楚理解数据粒度和统计口径。
2026-04-28 11:10:18
334
原创 改了1个费率，3年历史报表全错了——我补了张拉链表
文章摘要： 财务发现历史报表数据异常，原因是费率配置表未采用拉链表设计，导致历史结算报表全部使用了当前费率而非历史值。本文介绍了拉链表（SCD Type 2）的核心价值在于保留历史版本数据，确保历史报表能按当时数据计算。详细讲解了拉链表的设计要点，包括核心字段、分区策略和查询方法，并重点说明了两步走的增量更新流程：先关闭历史记录，再新增生效记录。这种设计能有效解决配置变更导致的历史数据污染问题，保证报表数据的准确性。
2026-04-28 10:17:18
567
原创 3套系统3个利润，差了20万——我用4张表把对账从3天压到1小时
文章摘要： 本文介绍了一个冷链物流企业的财务对账系统优化案例。原本需要3天的人工Excel对账（涉及NC财务系统、结算系统和ERP运营系统），通过数据整合方案缩短到1小时自动完成。核心解决方案包括： 建立统一映射表：将三个系统的不同编码转换为标准化管报指标，解决口径不一致问题。 设计四级数据流水线： st层：原始数据采集 dws层：数据翻译、去重和合并 输出层：生成36项标准化财务指标 解决重复计算：通过LEFT JOIN逻辑消除总部数据的重复汇总。 SQL自动化处理：关键脚本实现多系统数据自动匹配和汇总。
2026-04-27 15:07:10
386
原创 从315投诉到供应商：我用4步LEFT JOIN追到了跨仓链路
文章摘要： 本文以消费者投诉过期冷冻汤圆为案例，详细介绍了如何通过4步LEFT JOIN实现跨仓链路溯源。首先分析了跨仓物流的物理结构，指出每个仓库同时作为上下游节点的特性。接着提出4种精确匹配规则（ERP单号/运单号+生产日期/SKU/货主），并说明不同场景下的优先级和降级策略，特别强调rn=1去重和过滤占位数据的重要性。最后给出ETL实现路径：从种子表开始，通过迭代LEFT JOIN依次关联上游仓库数据，最终追溯到供应商源头。文中包含完整的SQL实现方案和实际踩坑经验，为解决物流溯源问题提供了可落地的技
2026-04-23 17:00:53
344
原创 一箱过期汤圆怎么在数仓溯源
文章摘要： 本文探讨了仓储系统中入库单与出库包裹的溯源链路设计。核心问题在于入库流水号（inbound_flow_code）的完整性校验缺失导致溯源中断，需通过ETL链路将入库、拣货、出库数据串联。重点分析了三种入库场景（采购入库、调拨入库、退货入库）的差异化溯源路径，提出以入库纵表为核心的技术方案，通过多表关联实现从供应商到消费者的全程追踪。文中还提供了关键SQL实现逻辑，强调入库流水号作为核心枢纽字段的重要性，以及批次号标准化对溯源准确性的影响。
2026-04-22 12:21:25
93
原创 物流大数据平台架构设计实战
《物流大数据平台架构设计与实践》摘要： 物流行业数字化转型面临海量数据处理挑战，日均千万级订单和实时轨迹追踪需求催生了新一代大数据平台建设。该架构采用分层设计：数据采集层通过Kafka实现业务解耦；存储层融合HDFS、ClickHouse等组件满足不同场景；计算层基于Flink实现实时预警，Spark处理离线分析。技术选型注重高吞吐与低延迟，如Kafka3.4+Flink1.17组合。特别针对物流行业脉冲式流量特征，系统需具备弹性扩展能力，支撑大促期间10倍流量增长。最终目标是构建数据快速流动、智能决策的物
2026-03-31 10:54:26
542
原创 《低成本开启AI实践：聊聊2026年个人开发者的云上第一课》
时长：约18-20分钟风格：搞钱干货+轻幽默+紧迫感核心目标：推广阿里云云小站 https://www.aliyun.com/minisite/goods?userCode=zg2tbduyBGM：紧张感电子乐，像倒计时主播A（老K）：“问你个事——2026年，38块钱能买什么？”主播B（阿紫）：“两杯奶茶？一张电影票？还是…”老K：“停。我今天用38块，买了一台全年无休的AI服务器，能跑DeepSeek，能自动搞钱，还能当我的数字员工。”阿紫：“等等，服务器？那种大公司才用的东西？”老K：“
2026-03-30 15:50:10
386
原创 数仓主题域划分
数据仓库主题域划分方法与实践 本文探讨了数据仓库建设中主题域与数据域的划分方法。主题域是从业务视角对数据进行分类的集合，可通过业务过程、部门或系统进行划分（如运输、操作等业务过程）。数据域则从技术视角管理数据。文章提出主题域划分应聚焦核心业务节点（如订单、运单等），并强调需与业务语言对齐，通过"业务大图"梳理关键流程。主题域建设需遵循"从业务中来，到业务中去"的原则，确保数据模型能反哺业务决策。合理的主题域划分能提升数据易用性、统一指标口径，并为数据仓库的分层架构提供
2025-07-25 17:00:12
1080
原创 数仓规范体系的构建
本文探讨了数据仓库建模的核心目标与建设内容。数仓建模旨在解决数据源不统一、命名歧义、指标口径不一致等问题，通过分层架构、词根设计、指标体系、主题域划分等方法实现高效数据管理。重点介绍了五层架构（ODS、DW、DIM、ADS）及各层规范，强调分层设计有利于数据清晰度、血缘追踪和复用性。同时分享了主题域划分实践经验，提出按业务系统划分主题域的方法。最后指出采用数据字典替代传统词根管理，通过标准化字典库解决命名规范问题。文章强调数仓建设需结合业务特点，建立稳定框架以支持业务发展和数据驱动决策。
2025-07-25 16:58:53
1048
原创 Doris集群安装部署
本文介绍了Doris集群的安装部署过程，主要包括： 环境准备：规划三节点集群架构（1个FE leader、1个FE follower、1个FE observer），所有节点同时部署BE和BROKER组件。 前期准备： 下载稳定版Doris安装包（推荐2.1.6版本） 系统环境配置（关闭防火墙/SELinux/swap，调整文件描述符和内存参数） JDK环境变量配置 安装部署步骤： 创建元数据和存储目录 配置FE参数（jdbc驱动目录和网络设置） 设置环境变量并启动FE主节点 验证启动状态 扩展部署FE fo
2025-06-12 09:34:59
3918
原创 sql 中 where 和 on 分别区别
left join dws_ll_ewb_vehicle_temperature_info b on a.task_transport_no=b.task_transport_no and b.temp_standard_flag = '达标'and a.temp_standard_flag = '不达标'执行结果：发现 结果有6条 很明显是不对的 我要的是没有结果才对。子句是必要的，以明确指定如何将不同的表连接起来，而。子句则是可选的，用于进一步过滤连接后的结果集。用于定义表之间的连接条件。
2024-11-06 08:59:46
630
1
原创 SparkSQL电商案例
Pandas是python的一个数据分析包（numpy，matlab），最初由AQR Capital Management于2008年4月开发，并于2009年底开源出来，目前由专注于Python数据包开发的PyData开发team继续开发和维护，属于PyData项目的一部分。Pandas最初被作为金融数据分析工具而开发出来，因此，pandas为时间序列分析提供了很好的支持。
2024-06-06 10:47:57
1134
原创 SparkSQL 基本操作及自定义UDF函数
用户可以根据需求自己封装计算的逻辑，对字段数据进行计算# 导入window类 定义窗口# 1、生成SparkSession对象# 2、获取sparkcontext对象# 3、 读取文件数据转为rdd# 4、查看rdd数据# 5、对每行数据进行切割# 6、rdd转df# 7、定义 表信息df.show()# 自定义函数# x,y 接受传递字段的数据# 每次接受一行数据data = x+y# 注册到spark中使用# 第一个参数 指定注册的函数名。
2024-06-06 10:30:02
597
原创 CTE语法 和 临时表 都有其特定的用途和优缺点
综上所述，在Hive中，CTE和临时表都有其各自的优缺点。选择使用哪种技术取决于具体的应用场景和需求。在需要重用查询逻辑和模块化查询时，CTE可能是一个更好的选择；而在需要持久化存储、索引支持和并发控制时，临时表可能更有优势。
2024-02-02 15:59:57
1592
1
原创 Apache Hive函数高阶应用、性能调优
侧视图的原理是将UDTF的结果构建成一个类似于视图的表，然后将原表中的每一行和UDTF函数输出的每一行进行连接，生成一张新的虚拟表。这里的严格模式指的是开启之后 hive会禁止一些用户都影响不到的错误包括效率低下的操作，不允许运行一些有风险的查询。Hive的默认执行引擎是MapReduce，因此通常所说的Hive压缩指的是MapReduce的压缩。在实际开发中，可以根据需求选择不同的文件格式并且搭配不同的压缩算法。因此在Hive中，调整MapTask的个数，直接去HDFS调整文件的大小和个数，效率较高。
2024-02-01 16:49:10
1105
1
原创 解释性AI：打开AI决策过程之门的金钥匙
可解释性AI（XAI）旨在提高人工智能系统的透明度和可理解性，使人们更好地理解AI的决策过程和原理。通过提供清晰、详细的解释，XAI可以帮助用户更好地理解模型的决策过程，提高模型的信任度和应用效果。由于人们往往对不透明的算法决策过程感到不安，XAI旨在提供一种方法，使AI的决策过程更易于理解，从而提高人们对AI的信任。因此，在实现解释性AI的过程中，需要充分考虑数据的质量和多样性，并采取适当的措施来减少潜在的偏见和歧视。通过提供合理的解释，可以增加判决的公正性和透明度，并减少对AI决策的质疑和争议。
2024-01-26 12:46:59
1235
1
原创 Spark代码案例
用户可以根据需求自己封装计算的逻辑，对字段数据进行计算# 导入window类 定义窗口# 1、生成SparkSession对象# 2、获取sparkcontext对象# 3、 读取文件数据转为rdd# 4、查看rdd数据# 5、对每行数据进行切割# 6、rdd转df# 7、定义 表信息df.show()# 自定义函数# x,y 接受传递字段的数据# 每次接受一行数据data = x+y# 注册到spark中使用# 第一个参数 指定注册的函数名。
2024-01-24 18:34:24
1638
1
原创 SparkSQL和rdd的使用详解
Spark SQL是 Apache Spark 用于处理结构化数据（DataFrame和Datasets）的模块。
2024-01-11 17:46:43
1462
2
原创 Spark核心--checkpoint、 广播变量、累加器介绍
spark的shuffle的两个部分shuffle wirte 写shuffle read 读会进行文件的读写，影响spark的计算速度spark的shuffle方法类是spark封装好的处理shuffle的方法spark1.2版本前使用的类spark2.0后引入sortshuffle，删除了hashshuffle优化的hashshufulle和未优化bypass模式版本和普通模式版本bypass模式版本不会排序普通模式版本会排序进行shuffle。
2024-01-10 17:47:33
1297
1
原创 spark-rdd实例
x 数结构rdd中每个元素数据，元素是是什么类型，就进行什么类型的计算操作。可以选择指定master，appName。
2024-01-10 13:59:57
568
1
原创 Spark核心--RDD介绍
rdd 弹性分布式数据集 是spark框架自己封装的数据类型，用来管理内存数据数据集：rdd数据的格式 类似Python中 []。hive中的 该结构[] 叫 数组rdd提供算子(方法) 方便开发人员进行调用计算数据在pysaprk中本质是定义一个rdd类型用来管理和计算内存数据分布式 ： rdd可以时使用多台机器的内存资源完成计算弹性： 可以通过分区将数据分成多份 2 3 4，每份数据对应一个task线程处理python 也有自己的数据类型 使用的是单机资源管理数据。
2024-01-09 15:01:36
1382
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人