Cloudera Manager 5.10.0离线部署与Parcel分发避坑-北京尧图网络

简介面向大数据运维、开发及教学实验人员的 Cloudera Manager 5.10.0 CentOS7 x86_64 安装包用于简化 CDH 集群的部署、服务配置、运行监控与故障排查适合需要复现 Hadoop 生态管理平台的中高级用户。压缩包约 615.94MB收录约 2000 个文件包含 cm-5.10.0 与 cloudera 两个核心目录文件以 Python 运行时文件py、pyc、pyo、HTML/JS 前端页面、JAR 依赖、DDL/SQL 建表脚本、properties/XML/conf 配置、so 动态库和 sh 启动脚本为主覆盖服务端、代理端、Web 管理界面及数据库初始化等组成部分。已有 825 人学习可作为 CM 5.10.0 环境搭建、组件依赖核对、配置模板查阅和排错思路整理的参考包。1. 一个 1.6 GB 的 tar.gz为什么还有人从零解压 CM 5.10.0一间没有外网出口的机房四台 CentOS 7.2 系统的旧机器一堆必须跑起来的离线计算任务。装集群的人手里的全部筹码就是 Cloudera Manager 5.10.0 的离线 tar.gz 压缩包加上几个 CDH 的 parcel 文件。tar.gz 里装的是 Cloudera Manager 的 server 和 agent 二进制它自己不含任何 Hadoop 组件CDH 的 parcel 需要另外放。这个包解决的是“没有 yum 源、没有外网、机器还不能重装”的落地问题解压、配置、启动全程不依赖仓库。它适合维护存量集群、做离线演示环境、需要把整套栈封在一个目录里搬来搬去的人不适合追求新版本、需要官方支持合同的场景。下面按我在 CentOS 7 上反复搭环境的顺序讲从解压前的机器准备一直到 7180 首页打开。2. 解压前先定路线tar.gz、RPM 与 parcel 到底谁管什么2.1 三条路线管的是两件事别混新手最容易犯的错是把 CM 的安装方式和 CDH 的安装方式当成同一件事。Cloudera Manager 本体有三种安装方式RPM 包、apt 包、tar.gz 压缩包CDH 那堆服务HDFS、YARN、Hive也有两种分发方式parcel 和 package。这两层是独立的可以交叉组合。cloudera-manager-centos7-cm5.10.0_x86_64.tar.gz这个名字里带的是 cm它只负责管理平台不包含任何 Hadoop 组件。很多人解压完发现没有 HDFS就以为包下错了其实是因为还没放 CDH 的 parcel。路线适用条件离线友好度后续升级典型痛点CM tar.gz无内网 yum 源、机器不能联网高拷贝目录即可手动替换目录所有主机都要手工解压部署 agentCM RPM有内网 yum 仓库或本地仓库中要自己建 repoyum 升级方便依赖冲突、GPG key、版本锁死CDH parcel与 CM 安装方式无关高放目录即用界面里切换 parcel校验文件、权限、分发卡住CDH package需要和系统包管理统一低几十个包需整体升级包依赖极难对齐选择判断的参考条件如果机房里连一台内网 yum 源都没有tar.gz 就是唯一省事的办法代价是所有节点都得手工解压一遍 agent。如果已经有内网仓库RPM 反而更省心升级和回滚都有迹可循。2.2 先tar -tzf看一眼再决定解压到哪不要一上来就tar -xzf。先列目录确认顶层结构和版本号避免解压出一堆散落在当前目录的文件。# 只看前 30 行确认顶层是不是 cm-5.10.0/ tar -tzf cloudera-manager-centos7-cm5.10.0_x86_64.tar.gz | head -30 # 统计条目数估算解压后体积 tar -tzf cloudera-manager-centos7-cm5.10.0_x86_64.tar.gz | wc -l # 确认后解压到统一前缀不要解到 /root 下 mkdir -p /opt/cloudera-manager tar -xzf cloudera-manager-centos7-cm5.10.0_x86_64.tar.gz -C /opt/cloudera-manager # 看看解压后都有什么 ls -l /opt/cloudera-manager/cm-5.10.0/逻辑说明-C指定解压目标目录压缩包内自带一层cm-5.10.0/顶层目录所以解压后会得到/opt/cloudera-manager/cm-5.10.0/。这个路径后面会反复出现建议直接定义成变量或固定前缀别用相对路径。参数说明-t是只列出不解压-z是 gzip-f指定文件名三个参数顺序不能乱。解压后典型能看到cloudera-scm-server/、cloudera-scm-agent/、etc/某些版本还带cloudera-scm-server-db/内置 PostgreSQL只适合测试。确认目录里同时有 server 和 agent说明这个包是给全手工部署用的不是给 RPM 补丁用的。2.3 三条版本红线JDK、Python、MySQLCM 5.10.0 是 2016 年前后的产物对运行时版本很敏感。装之前把这三样对齐能省掉后面一半的排查时间。组件要求检查命令不满足的后果JDK1.7 或 1.8建议 1.8.0_1xx 中较早的小版本java -version新小版本可能收紧 TLS 策略agent 心跳握手失败Python2.7agent 脚本与主机检查依赖python -V主机检查脚本报语法错误检查项全部异常MySQL5.5 / 5.6 最稳5.7 需放宽 sql_mode8.0 不建议mysql --version建库脚本失败或启动时驱动报错JDK 这条要单独强调。很多人拿最新 1.8.0_3xx 去装 5.10.0server 能起来agent 却永远连不上日志里只有一行 SSL 握手异常。这不是配置问题是 JDK 后续版本把一批旧密码套件列进了禁用列表。稳妥做法是把 JDK 锁在一个确定能跑的小版本并把$JAVA_HOME显式写进启动配置而不是依赖 PATH 里的默认 java。提示把 JDK 装在固定路径比如/usr/java/jdk1.8.0_xxx并在/etc/default/cloudera-scm-server里用JAVA_HOME显式指向它。系统里同时存在多个 java 时出现的问题最难排查。Python 这条也不可省。CentOS 7 默认带 2.7但如果有人为了跑别的脚本把/usr/bin/python软链到 python3Cloudera Manager 的主机检查脚本会大面积失败报错看起来像“主机不可用”实际只是解释器版本不对。装之前先python -V确认一遍比出事再回头查便宜得多。3. CentOS 7 系统基线解压之前要改的 8 项3.1 主机名、hosts 与时间同步三件套一次定型Cloudera Manager 对主机名极度较真必须是全限定域名FQDN必须能被所有节点正反解析否则主机检查怎么都过不去。# 1) 设置 FQDN必须是可解析的名字不要用 localhost hostnamectl set-hostname cm01.lab.internal # 2) 所有节点写入同一份 hosts包含全部集群节点 cat /etc/hosts EOF 10.0.0.11 cm01.lab.internal cm01 10.0.0.12 cm02.lab.internal cm02 10.0.0.13 cm03.lab.internal cm03 EOF # 3) 验证正反解析两条都必须有输出 getent hosts cm01.lab.internal getent hosts 10.0.0.11 # 4) 时间同步CentOS 7 用 chronyd yum install -y chrony # 离线环境用本地 rpm systemctl enable --now chronyd chronyc sources -v逻辑说明hostnamectl改的是持久化主机名重启不丢/etc/hosts必须每个节点都写全不要指望 DNS离线机房经常没有可用 DNS。第 3 步是自检getent hosts两条都返回结果才算解析通了只通一条会在后面某次主机检查里突然出错。参数说明chronyc sources -v里每个源前面有^*表示已同步。集群节点之间时间偏差过大会导致 Kerberos如果后续启用和监控数据错乱主机检查也会给出时钟偏移告警。没有外部时间源时把一台节点配成本地时间服务器其余节点指向它即可。3.2 SELinux、firewalld、THP、swappiness改还是不改这四项里前两项建议直接关后两项建议按官方建议调但要有可回滚的做法。# SELinux 临时关闭永久关闭 setenforce 0 sed -i s/^SELINUX.*/SELINUXdisabled/ /etc/selinux/config getenforce # firewalld 关闭内网环境并禁止开机自启 systemctl stop firewalld systemctl disable firewalld systemctl status firewalld --no-pager # 透明大页关闭两处都要写 echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defrag # 持久化 THP写进 rc.local 并确保可执行 cat /etc/rc.d/rc.local EOF echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defrag EOF chmod x /etc/rc.d/rc.local # 降低 swap 倾向 echo vm.swappiness1 /etc/sysctl.d/99-cm.conf sysctl -p /etc/sysctl.d/99-cm.conf逻辑说明SELinux 关闭必须两步setenforce 0只对当前运行生效改配置文件才对重启生效只做前一步下次重启又回来排查时会以为配置丢了。firewalld 在内网集群里通常是多余的如果一定要开就得把 7180、7182、以及各服务的端口一个个放行这部分容易遗漏先关掉更省事。THP 是 Hadoop 生态的老问题开启时 JVM 的内存分配会出现不可预期的暂停表现为任务偶发卡顿而这种卡顿没有明确日志属于典型的兜底难问题。两处都要置为neverdefrag那项容易被漏掉。vm.swappiness1是常见做法不要把 swap 完全关掉保留少量交换空间在内存紧张时比 OOM Killer 更温和。3.3 建账号、铺目录、放开文件句柄tar.gz 安装不像 RPM 那样自动创建用户和目录这几步必须手工补齐漏一步后面就要花时间猜。# 创建运行账号禁止登录不建 home useradd --system --home/opt/cloudera-manager/cm-5.10.0/run/cloudera-scm-server \ --no-create-home --shell/bin/false --comment Cloudera SCM User cloudera-scm # 目录属主交给该账号 chown -R cloudera-scm:cloudera-scm /opt/cloudera-manager # 日志与运行时目录server 和 agent 各一套 mkdir -p /var/log/cloudera-scm-server /var/log/cloudera-scm-agent mkdir -p /var/run/cloudera-scm-server /var/run/cloudera-scm-agent chown -R cloudera-scm:cloudera-scm /var/log/cloudera-scm-* /var/run/cloudera-scm-* # 放开文件句柄数 cat /etc/security/limits.d/90-nofile.conf EOF * soft nofile 65536 * hard nofile 65536 cloudera-scm soft nofile 65536 cloudera-scm hard nofile 65536 EOF ulimit -n逻辑说明--home指向 run 目录是为了让进程有地方写临时文件--no-create-home避免多出一个没用的家目录。目录属主统一给cloudera-scm后面启动脚本以该账号运行属主错了会出现“无法写入日志”而日志目录不可写时进程往往直接退出界面上只表现成 7180 打不开。参数说明limits.d里的*对所有用户生效单独再给cloudera-scm写一遍是因为某些环境下 systemd 或 su 会重置限制。ulimit -n在已登录会话里查的是当前值配置文件改完要重新登录才生效别拿旧会话的输出下结论。这三节做完机器才具备解压的条件。中途跳步是后面 90% 翻车的源头。4. 从 tar.gz 到 7180 首页CM Server 与 Agent 的落地4.1 解压、复制默认配置把路径钉死解压之后不要直接跑启动脚本先把默认配置落到/etc下让所有路径都指向固定位置。export CM_DIR/opt/cloudera-manager/cm-5.10.0 # 默认配置文件复制到系统目录启动脚本从这里读 cp $CM_DIR/etc/default/cloudera-scm-server /etc/default/ cp $CM_DIR/etc/default/cloudera-scm-agent /etc/default/ # 服务端配置目录 mkdir -p /etc/cloudera-scm-server chown -R cloudera-scm:cloudera-scm /etc/cloudera-scm-server # 核对关键变量是否指向解压路径 grep -E CMF_(CONF|LOG|VAR)_DIR|JAVA_HOME /etc/default/cloudera-scm-server逻辑说明tar.gz 版本的启动脚本在$CM_DIR/etc/init.d/下它会 source/etc/default/里的同名文件。默认文件里的路径是相对解压位置写的如果解压路径改过这里必须同步改否则启动时找不到配置目录报错信息往往只有一句“找不到目录”不容易联想到是路径问题。参数说明CMF_CONF_DIR决定db.properties写在哪CMF_LOG_DIR决定日志写在哪CMF_VAR_DIR是运行时 pid 和临时文件的位置。三者都建议保持系统默认/etc/cloudera-scm-server、/var/log/cloudera-scm-server、/var/run/cloudera-scm-server这样网上的排错经验能对应上。JAVA_HOME必须显式写不要留空。4.2 MySQL 建库、驱动 jar 与 scm_prepare_database.sh 的四个参数数据库是 CM 启动前的必要条件。5.10.0 需要的不止一个库第一次装的人经常只建了 scm后面加服务时又回头补。-- 建库字符集用 utf8不要用 utf8mb4 CREATE DATABASE scm DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE amon DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE rman DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE hue DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE metastore DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE sentry DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE nav DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE navms DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; CREATE DATABASE oozie DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; -- 统一账号生产环境按库拆账号更规范 GRANT ALL PRIVILEGES ON scm.* TO scm% IDENTIFIED BY Scm#2016; GRANT ALL PRIVILEGES ON amon.* TO scm% IDENTIFIED BY Scm#2016; GRANT ALL PRIVILEGES ON rman.* TO scm% IDENTIFIED BY Scm#2016; GRANT ALL PRIVILEGES ON hue.* TO scm% IDENTIFIED BY Scm#2016; GRANT ALL PRIVILEGES ON metastore.* TO scm% IDENTIFIED BY Scm#2016; GRANT ALL PRIVILEGES ON sentry.* TO scm% IDENTIFIED BY Scm#2016; GRANT ALL PRIVILEGES ON nav.* TO scm% IDENTIFIED BY Scm#2016; GRANT ALL PRIVILEGES ON navms.* TO scm% IDENTIFIED BY Scm#2016; GRANT ALL PRIVILEGES ON oozie.* TO scm% IDENTIFIED BY Scm#2016; FLUSH PRIVILEGES;逻辑说明字符集必须是 utf8utf8mb4 在旧版 MySQL 上会因为索引长度限制导致建表失败而这个失败发生在 CM 启动过程中间报错信息很长容易被误判成驱动问题。库名是固定的服务在初始化时会按名字找库写错一个字母就得重来。参数说明%表示允许任意来源内网环境够用如果 DB 和应用不在同一台机器上务必确认bind-address不是 127.0.0.1。密码要避开 MySQL 5.6 之前的保留字符组合也避开 shell 特殊字符因为这些密码后面会在脚本里以参数形式传递。驱动和建库脚本# 驱动 jar 必须放在这个位置并按固定名字命名 ls -l /usr/share/java/mysql-connector-java.jar # 找不到建库脚本时先定位 find $CM_DIR -name scm_prepare_database.sh # 执行建库初始化四个关键参数-h 库地址、-u 账号、-p 密码、--scm-host 服务端主机 $CM_DIR/share/cmf/schema/scm_prepare_database.sh \ mysql -h 10.0.0.11 -P 3306 -u root -p \ --scm-host cm01.lab.internal \ scm scm Scm#2016 # 检查生成的连接配置 cat /etc/cloudera-scm-server/db.properties chown cloudera-scm:cloudera-scm /etc/cloudera-scm-server/db.properties逻辑说明--scm-host是 CM Server 自己的 FQDN不是数据库地址这个参数最常被写混。脚本跑通后会在/etc/cloudera-scm-server/db.properties写一份明文连接串里面带密码所以要立刻改属主为cloudera-scm权限收紧到 600。参数说明-h是数据库主机-P是端口-u/-p是数据库账号-p单独写表示交互式输入密码不要跟密码连写以免进 shell 历史。最后三个位置参数依次是库名、库用户、库密码。如果驱动 jar 名字不对脚本会直接报找不到驱动类此时把 jar 补到share/cmf/lib/下再试一次。4.3 Agent 的 config.ini 与第一次启动该盯哪几个日志Server 只是管理端真正干活的是每台机器上的 agent。tar.gz 方式下所有节点都要手工解压一份 agent 目录。# 每台 agent 节点上改这一行指向 server sed -i s/^server_host.*/server_hostcm01.lab.internal/ \ $CM_DIR/etc/cloudera-scm-agent/config.ini # 确认端口默认 7182 grep -E ^server_host|^server_port $CM_DIR/etc/cloudera-scm-agent/config.ini # 启动 server 与 agent $CM_DIR/etc/init.d/cloudera-scm-server start $CM_DIR/etc/init.d/cloudera-scm-agent start # 首启阶段盯这两个日志 tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log tail -f /var/log/cloudera-scm-agent/cloudera-scm-agent.log逻辑说明server_host必须是 server 的 FQDN写 IP 在证书校验和后续重定向时会出问题。启动顺序建议先 server 后 agentserver 首次启动会建表、初始化数据库通常要几十秒到几分钟这段时间 7180 端口是不通的不要以为失败了就反复重启。参数说明server_port默认 7182是 agent 主动上报心跳的端口方向是 agent 到 server所以防火墙只需在这一侧放行。日志里首启阶段关注两类关键词数据库连接相关的错误出现在最前面说明db.properties有问题Started之类的完成标记出现后再去浏览器访问http://cm01.lab.internal:7180默认账号密码都是 admin。5. Parcel 离线分发repo 目录、sha 校验与主机检查5.1/opt/cloudera/parcel-repo的放置规则与权限Parcel 是 CDH 组件的分发单位一个 parcel 就是一个大压缩包CM 负责把它推送到每台机器的/opt/cloudera/parcels/下。# 服务端的 parcel 仓库目录 mkdir -p /opt/cloudera/parcel-repo chown -R cloudera-scm:cloudera-scm /opt/cloudera/parcel-repo chmod 755 /opt/cloudera/parcel-repo # 放入 parcel 与对应的 sha 文件文件名必须完全一致 cp CDH-5.10.0-1.cdh5.10.0.p0.45-el7.parcel /opt/cloudera/parcel-repo/ cp CDH-5.10.0-1.cdh5.10.0.p0.45-el7.parcel.sha1 /opt/cloudera/parcel-repo/ chown cloudera-scm:cloudera-scm /opt/cloudera/parcel-repo/* # 校验哈希确认文件没在拷贝中被截断 sha1sum /opt/cloudera/parcel-repo/CDH-5.10.0-1.cdh5.10.0.p0.45-el7.parcel # 各 agent 节点上的解压目标目录 mkdir -p /opt/cloudera/parcels chown -R cloudera-scm:cloudera-scm /opt/cloudera/parcels逻辑说明parcel 文件名里的版本段和校验文件必须一一对应.sha1文件后缀在不同版本里可能是.sha两种都能被识别。哈希校验不能省几个 GB 的文件跨机器拷贝时被截断是常有的事CM 在分发阶段只会说“校验失败”不会告诉你哪一段坏了。参数说明属主必须是cloudera-scm用 root 拷贝过去很容易忘记chown表现是界面里 parcel 一直显示“未分发”。chmod 755保证 agent 端能读parcel 不需要可执行权限。5.2.sha文件与manifest.json的生成逻辑.sha1文件里只应该有一行哈希值不要带文件名。多了内容CM 解析时会认为校验失败。# 检查 sha 文件内容应当只有一串十六进制 cat /opt/cloudera/parcel-repo/CDH-5.10.0-1.cdh5.10.0.p0.45-el7.parcel.sha1 # 如果只有 parcel 没有 manifest重启 server 触发自动生成 $CM_DIR/etc/init.d/cloudera-scm-server restart sleep 30 ls -l /opt/cloudera/parcel-repo/manifest.json # 也可以手工核对 manifest 里登记的哈希与文件是否一致 python -c import json m json.load(open(/opt/cloudera/parcel-repo/manifest.json)) for p in m[parcels]: print(p[parcelName], p[hash]) 逻辑说明CM 启动时会扫描 parcel-repo 目录如果发现 parcel 但没有manifest.json会自动生成一份。所以标准做法是只放 parcel 和 sha让 CM 自己生成 manifest避免手工编辑 JSON 时字段写错。文件放进去后必须重启 server 或刷新 parcel 列表否则界面里看不到。参数说明上面的脚本只是用来读 JSON 做比对不修改任何文件。如果 manifest 里的 hash 与sha1sum输出不一致说明 sha 文件内容错了重新生成一份即可不要手改 manifest。5.3 主机检查阶段的红叉清单与处理顺序主机检查是 CM 对每台机器做的一次体检红叉不处理完服务分配不下去。处理顺序建议按依赖关系来先网络与解析再系统参数最后账号与权限。检查项常见表现处理动作主机名解析Hostname not resolvable补/etc/hosts确认 FQDN 正反解析都通时钟同步时钟偏移告警启动 chronyd确认chronyc sources有^*透明大页THP 未关闭两处都写 never 并持久化swappiness值过高vm.swappiness1sysctl 生效SSH 免密无法连接对端server 到各节点配 root 免密或配 sudo 免密单用户模式提示 single-user mode改/etc/inittab或 systemd 默认 target 为 multi-user操作系统版本Unknown OS或版本不受支持见下一章的排查记录这张表照着从上往下处理基本能一次过。SSH 这一项经常被忽略CM 需要通过 SSH 在各节点执行命令如果节点间没有免密检查能过但后续部署会失败报错位置离根因很远。6. CM 5.10.0 部署避坑5 个翻车现场的现象、原因与解法6.1 7180 打不开日志里只有数据库连接错误现象server 进程起来了ps能看到但 7180 端口不通cloudera-scm-server.log里反复出现数据库连接失败的堆栈。原因三种可能。db.properties里的主机地址写成了主机名但本机解析不到MySQL 只监听了 127.0.0.1数据库账号的授权主机对不上。还有一个隐蔽的驱动 jar 名字不对脚本建库能过但 server 启动时找不到驱动类。解决先用mysql -h 10.0.0.11 -u scm -p从 server 机器上手工连一次能连上再去看db.properties内容。连不上就查 MySQL 的bind-address和skip-networking。驱动问题看日志里有没有ClassNotFoundException有的话把 jar 补到/usr/share/java/和share/cmf/lib/两处属主改cloudera-scm。6.2 Agent 心跳不上日志里是 SSL 握手异常现象agent 进程在跑server 界面里主机一直“未知”状态agent 日志里出现SSLHandshakeException或密码套件不匹配。原因JDK 小版本较新时默认禁用了旧版密码套件而 CM 5.10.0 的 agent 与 server 之间用的正是被禁用的那批。这不是配置写错属于版本兼容问题属于那种光看日志看不出所以然的疑难问题。解决优先换一个较早期的 JDK 8 小版本成本最低。如果必须用当前 JDK就去改$JAVA_HOME/jre/lib/security/java.security把jdk.tls.disabledAlgorithms里的3DES_EDE_CBC之类条目去掉然后重启 server 和 agent。改之前备份原文件这是典型的后悔药改错了要能退回去。6.3 主机检查报操作系统版本不支持现象系统明明是 CentOS 7主机检查里却给出操作系统版本不受支持或者直接显示Unknown OS。原因CM 5.10.0 发布时只认到 7.2 左右的版本号后续 7.x 小版本更新了/etc/redhat-release里的版本串CM 的识别逻辑匹配不上。解决短期本文还有配套的精品资源点击获取

Cloudera Manager 5.10.0离线部署与Parcel分发避坑

相关推荐

五连杆轮腿平衡小车：运动学解算、姿态滤波与串级VMC控制

Linux管道机制：原理、优化与实战应用

操作系统管道原理与应用全解析

更多资讯

数据结构大作业：教务管理系统核心结构与避坑指南

ADS Doherty功放仿真与回退效率调优

Cocos2d-x游戏逆向分析实战指南

构建可落地的RAG智能助理：从PDF到生产级知识问答

3D等变扩散模型实现靶点导向的分子生成与亲和力预测

从端口到拥塞控制：传输层TCP/UDP核心机制与抓包排障

今日更新

基于YOLOv11的石油泄漏智能检测系统开发实践

AI行业变局：合规、Mod化与上下文管理的实战启示

计算机视觉与AI原生应用融合的技术实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？