DSH Data Agent 支持的数据源看着很多真到选型的时候其实只有两个问题库放在哪里以及用哪一类库。前者决定连接的复杂度和安全边界后者决定它能跑出什么样的分析。下面把这两个维度拆开看再把「用插件」和「自己写 SQL 加图表工具」这条老路放在一起比一比。支持范围先摆出来README 给的清单分三类关系型数据库MySQL、PostgreSQL、SQLite、Oracle、Microsoft SQL Server共 5 种分析型数仓 / OLAPClickHouse、Apache Doris、Apache Hive、Apache Impala共 4 种本地与轻量数据SQLite 数据文件即开即用无需额外服务这个边界同时也是「不支持什么」的答案非结构化文档、日志检索、图数据库都不在清单里。README 讲的「本机可访问目标数据库」范围就是上面这些。部署形态库放在哪里决定你要配什么本地 SQLite 文件即开即用零服务SQLite 被单独列成一类理由就是「即开即用无需额外服务」——库就是一个文件插件直接读不用起进程、不用配账号、不用过网络。这条路最适合两类人手里已经有导出的 SQLite 数据文件、想做一次性分析的人以及想先用一个小库把「数据模式」整条链路跑通、再接到真库上的人。代价也很清楚单机单文件多人协同和数据实时性都谈不上它更像分析的起点而不是终点。局域网数据库接的是团队内部资产把插件连到局域网里的 MySQL、PostgreSQL 或 Oracle是最常见的生产形态。这时候要处理的不是插件本身而是网络本机到目标库的端口通不通、账号权限够不够。插件的连接配置里有「测试连接」可以在提问之前先把连通性单独验掉。这一层真正需要留意的是账号权限。文档推荐用只读账号加只读模式这是在连内部库时最值得花五分钟做的一件事。云端数据库 / 数仓能力和配置成本同时上升云端库通常是 ClickHouse、Doris 这类分析型数仓或者托管的关系型实例。好处是数据量和聚合能力都上了一个台阶代价是网络与权限的配置项更多——白名单、内网地址、出口 IP 这些都可能成为「测试连接失败」的原因而问题往往不在插件这一侧。有一个跨形态通用的细节分析报告会落到工作目录的analysis-reports/下而不是某个固定目录。如果把插件部署在服务器上的不同工作目录里跑同类报告会散落各处选型阶段就该把「报告落在哪、谁来收」想清楚。关系型还是 OLAP5 种关系型和 4 种 OLAP 不是二选一的关系而是对应两类不同的分析。关系型MySQL、PostgreSQL、SQLite、Oracle、SQL Server是你的业务主库问的是「这个月各渠道转化率」「这批会员的复购周期」这类明细账问题特点是维度多、口径要严格。OLAPClickHouse、Doris、Hive、Impala是已经聚合好的分析层问的是「过去 90 天的小时级趋势」「某个维度的分布」这类大范围扫描问题特点是数据量大、聚合快。一个实用的判断方法是看你要问的问题在哪个库里能被回答得最省事。如果业务主库上跑一个大范围聚合已经很吃力那这个问题本来就更适合 OLAP 侧的宽表反过来口径类的复盘通常只有主库才有最细的明细。用插件还是自己写 SQL 加图表工具这是选型里最该认真比的一段因为两者省下的时间完全不在同一个环节。口径治理差别最大的一环自己写 SQL 时「净成交额怎么算」「活跃用户的定义是什么」这些口径每次都活在某个人的脑子里或者某个 SQL 文件的注释里。换个人、换个月口径就可能漂。data-agent 的工作台里有「数据治理」模块AI 扫描库表结构生成中文业务释义支持逐项确认、删除也可以手动补充业务指标定义README 举的例子就是「净成交额 订单金额 - 退款金额」。确认过的口径会被后续分析沿用。差别不在于「能不能写对一条 SQL」而在于口径是不是一个被沉淀下来、被审核过的东西。前者是个人技能后者是团队资产。报告分发从「截图」到「文件」自己写 SQL 的终点通常是一张截图或者一个需要对方有账号才能打开的在线图表。data-agent 的终点是一个.html文件Agent 生成单图或多维 Dashboard 后会把独立的离线 HTML 报告写到analysis-reports/里面内置全部图表样式与交互数据无需网络即可双击打开可以直接通过微信、邮件或钉钉发给不使用 DSH 的同事。「不需要对方装任何东西」这一点是它和自己搭图表工具在交付体验上的主要区别。自己写 SQL 仍然更好的场景把话说完整如果只是临时验证一条查询或者公司已经有一套统一 BI 平台、口径和分发都在那上面闭环那你没必要为了这一个小需求再引入一个对话入口。插件解决的是「从提问到可分享报告」这段搬运不是替代既有 BI 体系。连接前要确认的两件事第一只读保护要两处都配数据库侧用只读账号连接时开启「只读模式」。README 的原话是「推荐使用只读数据库账号并在连接时开启『只读模式』」——它是推荐加手动开启不是安装即生效的硬隔离。第二凭据与执行范围。连接密码仅在当前会话运行时使用不记录在明文历史中也不上报远程服务器查询与报告生成都在本地完成同时静态扫描判定插件「含敏感能力」证据显示它会读写、删除本地文件生成报告。所以它在你本地的权限边界取决于你给它的工作目录。选型时把这两件事当成前置条件而不是事后优化项接生产库会顺很多。各插件对不同数据源的支持范围、版本要求与安装形态整理在 完整插件清单与汉化避坑指南 里可以先横向比一遍。如果你还想看同类数据分析插件怎么处理口径与报告同样的 完整插件清单与汉化避坑指南 也把中文说明与安装差异放在了一起。总结数据源的选择可以拆成「库放哪里」和「用哪一类库」两个问题本地文件零成本、局域网与云端成本递增关系型看口径、OLAP 看规模想对照同类插件的中文清单与安装形态见 完整插件清单与汉化避坑指南。适合与不适合适合手上已有一份 SQLite 数据文件、想零配置先跑通的人需要连内部 MySQL、PostgreSQL 做渠道与漏斗复盘的分析师数据在 ClickHouse、Doris 等 OLAP 上、想要对话式大范围聚合的团队需要把分析结果以文件形式发给不使用 DSH 的同事的岗位。不适合公司已有统一 BI 平台、口径与分发都在其上闭环的团队数据是非结构化文档、日志或图数据、不在支持清单内的场景没有可连数据库、只想看看界面的用户。标签dsh-data-agent、DeepSeek Harness、数据源选型、SQLite 与 OLAP、口径治理本文由 DeepSeek Harness Hub 自动整理数据来源于插件详情页。