简介Discovery软件介绍与安装演示文稿面向石油行业地质研究人员、油藏工程师及计算机相关学习者系统介绍其在数据管理、地震解释、测井研究和地质分析等场景中的核心功能与安装要点。资源共1个pptx文件压缩包大小7.73MB便于直接放映或二次编辑适合用作入门培训、技术分享或项目汇报材料。内容重点覆盖Manager System、GesXplorer、SeisVision、PRIZM等模块包括项目管理与井震数据管理、平面图/剖面图/砂体连通图等地质制图分析、地震迭后处理及时深转换、多井测井解释等典型功能并配有界面和操作流程示意。读者可借此快速理清Discovery软件的整体架构与模块职责了解其在油气勘探开发中的实际应用路径对需要快速上手或向团队普及该工具的石油地质与计算机交叉领域人员具有实用价值。当前已有96人学习该资源适合作为入门参考。1. discovery软件是什么一份演示文稿背后要讲清楚的三个问题discovery软件这个名字近几年在企业内部数字化选型里经常出现。如果你手头正在准备一份名为《discovery软件介绍与安装》的演示材料那你需要在幻灯片里交代的其实只有三件事它能解决什么数据问题、怎么把它装到自己的服务器上、装完以后如何验证它真的在工作。它不是数据库也不是传统意义上的报表工具而是定位在数据连接与探索式分析中间的那一层把散落在不同数据源里的数据接进来让人能拖拖拽拽地做探查而不是每次分析都写一遍 SQL。适合谁适合手上有多个业务库、但缺一个统一分析入口的团队也适合正在评估私有化部署的选型项目。下面按安装这条线往下走。2. discovery软件的架构与版本选型装之前先决定怎么装2.1 自托管部署与SaaS两种交付方式怎么选discovery软件在市面上常见两种交付方式。一种是你直接登录对方提供的云端地址开箱即用数据也放在对方环境里另一种是把整个服务端部署到你们自己的服务器上数据不出内网。标题既然写的是“安装”那多半意味着你需要面对的是自托管这条路。我一般建议优先评估自托管理由很直接这类软件处理的是业务数据很多团队对数据出域有硬性约束SaaS形态再方便这关过不了也白搭。自托管并不等于完全自己从零搭。常见做法是拿到一个包含服务端程序和依赖描述的自包含安装包你负责准备一台机器、一个数据库和一个对象存储位置。架构上它通常由三块组成负责接收请求和调度的服务端进程、存元数据的业务库、存数据快照和导入文件的对象存储。搞清楚这三块后面配置时就不会对着配置文件发怵排错时也能一眼看出问题出在哪一层。这种三块结构几乎是数据类软件的通用套路。服务端进程负责干活数据库负责记账对象存储负责存货。你在安装阶段要做的所有事情本质上就是把这三角色安排好、把权限给对、把地址填准。后面章节的每一个步骤都可以对应到这三块里遇到问题先定位是进程、数据库还是存储出错排查效率会高很多。2.2 软硬件基线给部署环境划一条最低线先给一个我平时做部署评估时常用的配置表。注意这是“能让软件跑起来”的基线不是“跑得好”的配置。如果你的机器低于这张表后续数据导入、交互式分析都会变得非常难受甚至直接失败。组件最低配置建议配置说明CPU4 核8 核以上数据解析和索引构建是 CPU 密集操作内存16 GB32 GB 以上探索式分析会把数据集加载到内存做交互磁盘100 GB 空闲500 GB SSD日志、缓存、对象存储快照都会占空间JDK1717新版本驱动依赖 JDK 17低版本容易出 NoClassDefFoundError数据库PostgreSQL 13 或 MySQL 8按发行说明匹配只做元数据存储不需要大库但别用 SQLite 跑生产对象存储本地目录或 S3 兼容协议配好生命周期策略存快照和导入文件磁盘不够最先挂的是这里内存这条最容易翻车。discovery软件在导入数据时会解析原始文件、建列式缓存数据集一大JVM 堆占用立刻上去。我见过有团队按普通 web 应用的标准给了 8 GB导入一个几十万行的 CSV 就频繁 Full GC。如果你拿不准直接在基线基础上加一倍内存是这类软件最值得投入的资源。2.3 版本选型从 Release Notes 里读出该装哪个版本拿到安装包之前先花十分钟看版本。不要一上来就下载最新版也不要因为习惯用熟了就把版本钉在旧版不动。下面这张表是我选版本时逐项对照的清单基本能帮你确定该装哪个版本。判断点做法理由缺陷修复看 Release Notes 中近期修复的缺陷列表你遇到的数据源连接、中文字段问题往往已经有人踩过驱动更新确认内置 JDBC 驱动覆盖你目标数据库的大版本数据库升级后连接不上多半是驱动太老维护窗口选仍处于维护期内的版本别选即将 EOL 的装上就失去更新后续出问题只能自己扛配套组件对照发行说明确认对象存储、鉴权组件的兼容范围企业环境里常有单点登录等外围组件版本匹配要提前确认我个人的习惯是选发布两三个月之后的次新版本。这个时间点足够社区把首发版本里最明显的安装问题反馈出来同时这个版本离维护截止还很远后续小版本更新也能平滑升级。装之前把发行说明里标记为严重级别的修复条目扫一遍如果里面有你正在用的数据源类型那这个版本基本就是你的目标版本。3. discovery软件服务端安装从环境初始化到健康检查全流程3.1 准备工作目录与运行账户别让服务跑在 root 下安装第一步不是解压而是造一个专用的运行账户。用 root 直接跑这种带数据引擎的服务一旦进程被入侵或者误操作删文件影响面是整个机器单独账户配合目录权限能把事故范围缩在一个目录里。这是生产环境的基本卫生习惯没有这个习惯后面所有日志排查都会变得混乱。# 创建专用运行账户禁止登录 shellhome 目录指定到 /opt/discovery sudo useradd --system --home /opt/discovery --shell /usr/sbin/nologin discovery # 创建安装目录并交给 discovery 账户 sudo mkdir -p /opt/discovery sudo chown -R discovery:discovery /opt/discovery # 解压安装包包名按你实际拿到的文件替换 sudo -u discovery tar -xzf discovery-server-xxx.tar.gz -C /opt/discovery第一行创建的是系统账户--shell /usr/sbin/nologin表示这个账户不能登录终端只能被服务用来切换身份。第三行解压时用sudo -u discovery执行确保解压出来的文件属主是 discovery后面启动脚本不会因为权限问题报 Permission denied。如果你把安装包解压到了 root 属主的目录后果就是服务进程写不了日志目录启动时日志里会连续出现一堆文件访问异常排查起来非常绕。3.2 解压安装包并修改核心配置端口、时区、内存一次设对解压完先别急着启动先把配置里三个关键项改对监听端口、时区和 JVM 内存。时区这个坑会在后面第五章单独讲这里先设对能省掉一天排查时间。端口则是越早规划越好不要等到启动报错才回头改。# 进入安装目录修改主配置 vim /opt/discovery/conf/application.yml需要重点确认的配置项如下表。改的时候按你的实际环境来别照抄默认值。配置项默认值建议改成说明server.port8080按实际端口规划8080 太容易被已有应用占用改成 18080 之类更省心spring.datasource.url本地内存库jdbc:postgresql://你的数据库地址:5432/discovery生产环境必须指向独立数据库spring.datasource.username / password空专用账号不要用数据库 root 账号JVM 堆内存按机器自动取-Xms4g -Xmx8g堆太小直接导致数据导入卡死堆太大容易抢掉系统内存默认时区跟随系统Asia/Shanghai避免时间轴偏移 8 小时JVM 参数通常在启动脚本里单独配置不在 application.yml 里。改完脚本后可以用下面这条命令确认参数已经进入进程这一步很多人会跳过导致后面调参无效却不知情。# 启动服务前台运行便于看日志确认没问题再改后台 /opt/discovery/bin/start.sh run # 另开一个终端查看进程的 JVM 参数是否生效 ps -ef | grep discovery | grep -v grepstart.sh run是很多服务端程序都带的前台运行模式第一次启动建议先这样跑方便直接看控制台日志。如果进程没有正常起来先看是不是配置语法出了问题YAML 多一个空格都可能让整个配置加载失败控制台通常会打印配置解析错误的行号。3.3 初始化数据库与对象存储先建库再启动discovery软件启动时会自动往配置的数据库里建表但它不会替你创建数据库本身。所以你要先手工建一个空的业务库并创建一个权限受限的账号而不是直接用数据库管理员账号。下面以 PostgreSQL 为例MySQL 8 的写法稍有不同。-- 创建独立数据库字符集按需设置 CREATE DATABASE discovery ENCODING UTF8; -- 创建专用账号密码换成你自己的强密码 CREATE USER discovery% IDENTIFIED BY change_this_password; -- 只授予 discovery 库的权限避免账号能访问其他业务库 GRANT ALL PRIVILEGES ON DATABASE discovery TO discovery;注意 MySQL 和 PostgreSQL 语法不完全一样。上面的CREATE USER ... IDENTIFIED BY在 MySQL 8 里要先执行再 GRANTPostgreSQL 则用CREATE ROLE ... LOGIN配合GRANT CONNECT来实现。建完库后还要检查对象存储位置如果你用的是本地目录就在配置里指定一个绝对路径比如/data/discovery/objects然后确认该目录属主是 discovery 账户且有写权限。这一步漏了后面导入数据时会在日志里报对象存储初始化失败而且是数据快照阶段才报很难往回查。3.4 启动服务并通过健康检查接口确认可用库建好、配置改完、目录权限就位这时候才适合启动。我一般会先看一眼启动日志的前部分确认数据库连接和对象存储初始化都显示成功再去做健康检查而不是直接跳到健康检查接口。# 后台启动 /opt/discovery/bin/start.sh # 跟踪启动日志看到 started successfully 说明起来了一半 tail -f /opt/discovery/logs/discovery.log # 健康检查接口返回 200 说明对外服务可用 curl -s -o /dev/null -w %{http_code}\n http://127.0.0.1:18080/api/health这条 curl 命令的-o /dev/null是丢弃响应体-w %{http_code}是只输出 HTTP 状态码。不同版本的 discovery软件健康检查路径可能不同有的是/api/health有的是/actuator/health第一次装可以翻一下日志里启动时打印的接口列表。健康检查返回 200 只代表服务进程活着不代表数据引擎完全就绪更可靠的验证方式是继续做一次真实的数据导入这个放到下一章。4. discovery软件客户端接入与许可配置把软件真正用起来4.1 浏览器端与桌面客户端不同角色用哪个入口服务端起来之后接入方式一般有两种浏览器直接访问配置的端口或者安装一个桌面客户端连接同一台服务端。浏览器端适合大多数业务人员打开地址就能登录不用管客户端版本和升级桌面端适合需要频繁做数据建模、本地预览大图的角色交互响应更快但要在每台电脑上维护客户端版本。我的一般判断标准是团队超过十个人就统一用浏览器端省去客户端升级的维护成本如果只有三五个分析人员做深度数据探索可以给他们装桌面端。两种入口连的是同一个服务端授权和用户体系是共通的不存在装了桌面端就多占一份许可的说法这点在选型汇报时经常被问提前知道能少解释半天。4.2 授权激活的三种常见场景与操作discovery软件的许可是按服务端粒度授权的不是按客户端数量算。拿到授权文件后常见操作用下面三条命令就能覆盖不需要在界面上点来点去。# 场景一首次导入授权文件 /opt/discovery/bin/discovery-cli license install /opt/keys/license.dat # 场景二查看当前授权状态和有效期 /opt/discovery/bin/discovery-cli license show # 场景三授权到期或更换节点后重新加载 /opt/discovery/bin/restart.shlicense install的作用是把授权文件复制到服务端配置目录并做一次签名校验失败时会直接输出原因最常见的是授权文件绑定的机器特征码和你当前服务器不匹配。换机器或换网卡后激活失效不需要重新申请授权通常在授权条款里允许有限次数的节点变更联系厂商做重置即可。license show的输出里注意看两个字段有效期和功能模块范围。功能模块范围决定了你界面上能不能看到数据挖掘、自动化编排这类高级入口看不到不一定是你权限不够可能就是模块没授权。4.3 接入第一个数据源用一条连接串验证端到端链路服务端健康、授权就绪接下来最重要的验证是接入一个真实数据源。我建议第一步不要连生产大库先在一个测试库里放一张几百行的表把链路走通再增加复杂度。数据源连接配置一般长这样name: erp_sales_test type: jdbc config: jdbcUrl: jdbc:postgresql://192.168.10.20:5432/analysis?sslfalsecurrentSchemapublic username: discovery_reader password: read_only_pwd driverClass: org.postgresql.Driver这段配置里有几个参数要留意。jdbcUrl里的currentSchema指定默认 schema避免同一连接下访问错表sslfalse只在测试环境用生产环境数据库通常开了 SSL需要换成证书连接串discovery_reader账号建议只给只读权限不要让数据接入账号拥有写权限降低误操作风险。保存后点测试连接返回成功再保存为正式数据源。如果这一步能通说明服务端、数据库驱动、网络、账号权限这一整条链路都是通的。接下来再去界面上做一次数据预览拖两个字段进画布在线图里看到数据分布那这次安装的闭环就算真正完成了。到这一步前面的辛苦才算真正落地。5. discovery软件安装中的避坑记录五个常见问题与排查思路5.1 默认端口冲突导致服务反复重启现象启动脚本执行后进程活了十几秒就退出日志里出现 Address already in use或者健康检查一直不通但进程列表里能看到进程存在。原因默认端口 8080 太常见机器上已有的 Nginx、Java 应用或监控组件占用了同一个端口。自托管场景下目标机器往往不是干净的这个冲突概率比我预想的高得多。尤其是那种已经跑了好几个业务应用的服务器8080 几乎被默认的 web 容器占据。解决先确认占用端口的进程再决定改谁的端口。# 查看 8080 端口被谁占用 sudo lsof -i :8080 # 如果是已有业务占用给 discovery 换端口 # 修改 application.yml 里的 server.port重启 sudo netstat -tlnp | grep 8080这个坑的麻烦在于服务可能不是启动时报错而是启动后注册到调度中心时才发现端口不对。我遇到的情况是端口被一个内网监控探针占用进程没退出但健康检查 URL 打到了探针上返回的是探针的响应排查了半小时才意识到端口张冠李戴。所以第一次部署时先把目标端口用 lsof 查一遍再做配置几十秒的事能省掉半小时的困惑。5.2 时区配置错误导致时间轴整体偏移现象数据导入后在时间序列图里看到的时间比业务实际时间晚了 8 小时或者按天聚合时数据落到了前一天。原因JVM 默认时区跟随操作系统的 UTC或者数据库连接串里的时区参数没指定。discovery软件在解析带时间字段的数据时如果源数据不带时区信息会按 JVM 默认时区解释UTC 和北京时间的偏移就是整整 8 小时。解决在启动脚本的 JVM 参数里显式指定时区同时在数据库连接串上也加时区参数。# 修改启动脚本在 JAVA_OPTS 里加时区参数 export JAVA_OPTS-Duser.timezoneAsia/Shanghai -Xms4g -Xmx8g # MySQL 连接串额外指定 serverTimezone # jdbc:mysql://192.168.10.20:3306/discovery?serverTimezoneAsia/Shanghai这个坑隐蔽在数据层面服务启动完全不报错界面也正常只有你拿业务数据做时间维度对比时才暴露。而且它会污染已经导入的数据重新导入才能修正。现象出现后先别急着改数据先确认时区配置再重导否则改完配置老数据还是错的重导两次才发现是同一个原因。5.3 中文字段名导致数据导入静默失败现象从 CSV 导入数据时预览里能看到文件内容但导入完成后字段列表是空的或者中文列名变成乱码部分行直接丢失。原因CSV 文件本身的编码不是 UTF-8而服务端默认按 UTF-8 解析另一个常见原因是文件带 BOM 头字段名第一个字符被解析成了不可见字符。这类问题不会报错因为在解析器看来只是列名有些特殊。解决统一预处理文件编码并尽量在导入前把中文字段名映射成英文字段名。# 先用 file 命令确认 CSV 编码 file your_data.csv # 如果不是 UTF-8用 iconv 转换以 GBK 为例 iconv -f GBK -t UTF-8 your_data.csv your_data_utf8.csv # 去掉 BOM 头 sed -i 1s/^\xEF\xBB\xBF// your_data_utf8.csv如果 CSV 文件特别大iconv 转换会占不少内存和 IO建议在数据上传前的预处理阶段完成而不是放到导入机器上现转。中文列名本身不是不能用但后续写分析表达式时要带引号维护成本高。我的习惯是导入阶段就映射成英文别名显示名可以保留中文内部字段名用全英文能避免后面一堆引号问题。5.4 内存堆设置过小导致频繁 OOM现象导入几十万行数据时界面卡死服务日志里出现 OutOfMemoryError或者系统整体卡顿负载飙升。原因启动脚本里 JVM 默认堆太小而数据集解析和缓存都在堆内进行。更隐蔽的情况是机器内存看着很大但 JVM 只拿到了默认的 1/4比如 32GB 机器默认堆只有 8GB跑大一点的数据集就顶不住。解决先看当前进程实际堆大小再修改启动脚本并重启验证。# 查看进程实际堆配置 jcmd $(pgrep -f discovery-server) VM.flags | tr \n | grep -E MaxHeapSize|InitialHeapSize # 修改启动脚本 JAVA_OPTS 后重启 export JAVA_OPTS-Xms8g -Xmx16g注意 Xms 和 Xmx 不要设成同一个值。设成同一个值虽然启动时一次性占用完整堆看起来性能更均匀但会占掉大量物理内存操作系统在内存压力大时会先杀其他进程。我一般让 Xms 设为 Xmx 的一半给操作系统和文件缓存留出余地。改完务必用 jcmd 确认参数生效这个在第六章会再提一次因为它值得单独养成习惯。5.5 JDBC 驱动与数据库大版本不匹配导致连接池报错现象数据源测试连接一直失败报错包含 Unsupported major.minor version 或 Connection is not available, request timed out但用数据库客户端工具连接同一个地址却完全正常。原因discovery软件内置的 JDBC 驱动版本太老不认目标数据库新版的认证协议或加密参数。最常见的是数据库大版本升级后老驱动握手失败。解决手动替换驱动 jar路径在安装目录的 lib 或 drivers 目录。# 找到现有驱动 find /opt/discovery -name *postgresql*.jar # 备份旧驱动放入新驱动重启服务 mv postgresql-old.jar postgresql-old.jar.bak换驱动有一个容易忽视的连带问题新驱动可能依赖更高版本的 JDK。如果你还在用 JDK 11驱动版本就只能选兼容 JDK 11 的不能无脑换最新版。判断驱动是否生效可以在重启后看日志里数据源初始化时打印的 driver version或者直接再点一次测试连接。这个坑处理起来不复杂难在第一时间想到是驱动问题而不是去翻网络配置。6. discovery软件装好后的日常维护与调优从能用到好用服务装完、链路跑通只能算完成了一半。真正让 discovery软件在业务量下持续好用的是装好后三天内的参数验证和监控接入。先做一次内存参数验证。改完 JAVA_OPTS 后不要只看启动日志用 jstat 连续观察堆的占用曲线确认数据导入时堆使用率没有逼近上限# 每 10 秒打印一次 GC 统计观察 Full GC 次数是否持续上涨 jstat -gcutil $(pgrep -f discovery-server) 10000如果 Full GC 次数在普通操作下每隔几分钟就增加说明堆还是偏小或者某个数据集快照占用了太多内存。其次是日志轮转。服务端程序的日志增长比我预想的快尤其是数据导入阶段每一行解析日志都写盘。把日志轮转策略配成按大小切割单文件超过 200MB 自动滚动保留最近 10 个文件能避免日志把磁盘写满。这个参数一般藏在日志配置节里滚动策略名称通常是 maxFileSize。最后把健康检查脚本纳入系统监控。脚本不需要复杂能定时探活并在失败时落一条日志就够了#!/bin/bash # discovery_health.sh —— 健康检查脚本接入你的定时任务 HEALTH_URLhttp://127.0.0.1:18080/api/health HTTP_CODE$(curl -s -o /dev/null -w %{http_code} $HEALTH_URL) if [ $HTTP_CODE ! 200 ]; then echo $(date %F %T) health check failed: $HTTP_CODE /var/log/discovery_monitor.log fi这个脚本看起来简单但它把“服务有没有活着”变成了一个可以被监控系统采集的信号。我吃过一次亏曾经调大内存参数后没有验证业务高峰期 GC 停顿把数据导入卡了十分钟而健康检查一直没有纳入监控问题半小时后才被发现。后来养成习惯任何参数改动都先看 jstat 输出再跑一轮真实导入最后确认监控里有数据才算一次完整的变更闭环。希望帮到你。本文还有配套的精品资源点击获取