1. 项目概述为什么一个真实的NLP流水线必须“长在云上”我带过六届实习生也帮三家公司从零搭过生产级NLP系统。每次新人问“本地Jupyter跑得好好的为啥非得上云”我都会先让他们试一次用笔记本跑完5万条推文的语义聚类再手动点开任务管理器看CPU和内存曲线——通常不到十分钟风扇就吼得像拖拉机Python进程开始假死而你刚导出的CSV里第32784行后面全是空值。这不是代码问题是物理限制。真实业务场景里NLP流水线从来不是“跑通就行”的Demo它是一台必须每天凌晨三点准时启动、处理5万条新数据、生成可交付报告、然后安静关机的工业设备。AWS不是炫技的玩具它是让这台设备不依赖你个人电脑、不被你合盖休眠中断、不因你重装系统而报废的基础设施。这个项目的核心关键词非常明确NLP流水线、AWS、EC2、snscrape、sentence-transformers、UMAP、Plotly、自动化调度。它解决的不是“怎么用BERT做分类”这种教科书问题而是“如何让一个需要768维向量计算K-Means聚类高维降维的Python脚本在无人值守状态下连续365天稳定产出主题分析报告”。适合三类人直接抄作业一是正在实习或刚入职的数据工程师需要快速交付一个能写进简历的端到端项目二是中小团队的技术负责人手头没有专职运维但又必须让AI能力变成可复用的服务三是独立开发者想验证某个NLP创意但不想被本地环境反复折磨。它不讲抽象理论只讲我在EC2上敲错三次chmod权限后才记住的实操细节讲snscrape在AWS上抓推文时被限流的真实应对策略讲为什么t2.small是成本与性能的黄金分割点——这些文档里不会写但线上崩过三次你就刻骨铭心。2. 整体架构设计与关键决策逻辑2.1 为什么放弃Lambda直跑坚持用EC2做核心计算节点很多人看到“云上NLP”第一反应是AWS Lambda。毕竟无服务器、按需付费、自动扩缩容听起来完美。但我实测过用Lambda跑整个流水线会卡死在三个地方第一sentence-transformers模型加载。这个库依赖PyTorch和transformers光是解压和初始化模型参数就需要1.2GB内存和近90秒冷启动时间。Lambda默认内存上限是10GB但超过3GB后单价飙升且冷启动超时风险极高。第二UMAP降维。它需要大量矩阵运算Lambda的vCPU是共享型实际计算力波动大5万条向量降维耗时从2分钟到12分钟不等根本无法满足“每天固定时间出报告”的SLA。第三snscrape的网络稳定性。Lambda的出站IP是动态池Twitter对高频请求的IP封禁策略极其严格本地测试OK的脚本一上Lambda就触发429错误排查起来毫无头绪。EC2则完全不同。t2.small实例提供2个vCPU、2GB内存、EBS通用SSD存储按需付费仅0.023美元/小时2024年最新价比原文的0.04更优最关键的是——它给你一个完全可控的Linux虚拟机。你可以预装所有依赖配置swap分区防内存溢出设置ulimit避免文件句柄耗尽甚至用systemd守护进程监控Python进程状态。我做过对比测试同样处理5万条Covid-19相关推文EC2稳定在18分23秒完成全流程Lambda在70%概率下超时失败。所以架构图里EC2是绝对的主干Lambda只做“开关机指令员”EventBridge是“闹钟”这才是符合工程直觉的分层设计。2.2 为什么选t2.small而非更小的t2.micro或nanot2.micro只有1GB内存t2.nano更是只有0.5GB。表面看跑Python脚本绰绰有余。但sentence-transformers的all-MiniLM-L6-v2模型单次推理需要约1.1GB显存虽不需GPU但PyTorch会占用大量RAM做张量缓存。当你批量处理5万条文本时内存峰值会冲到1.8GB以上。我用t2.micro实测过前1000条顺利到第3200条时系统开始疯狂使用swapI/O等待时间飙升最终OSError: Cannot allocate memory报错退出。t2.small的2GB内存刚好卡在安全阈值之上——预留200MB给OS1.8GB给Python实测内存占用稳定在1.6GB左右全程无swap。更重要的是t2.small支持增强联网Enhanced Networking网络吞吐比t2.micro高40%这对snscrape这种IO密集型爬虫至关重要。别省这每天0.55美元它换来的不是省钱是流水线不死机的确定性。2.3 为什么Topic Modeling必须用Sentence-Transformers而非传统TF-IDFLDA传统方案里LDALatent Dirichlet Allocation是主题建模的常客。但它有个致命缺陷依赖词袋Bag-of-Words表示完全丢失语序和语义。比如“苹果手机”和“苹果公司”在LDA里可能被分到同一主题因为都含“苹果”而“机器学习”和“深度学习”因词汇重叠少反而被拆散。我们处理的是推文短文本、口语化、大量缩写和emojiLDA效果极差。我用同一组5万条推文对比过LDA生成的200个主题中有67个是“无意义词簇”如“the, and, of, in, to”32个是“情绪词堆砌”如“love, amazing, great, happy”真正可解读的行业主题不足40%。Sentence-Transformers则完全不同。它把整句话映射成768维稠密向量向量空间里“苹果手机”和“iPhone”距离很近“机器学习”和“ML”紧挨着“疫苗接种”和“vaccination”语义相似度高达0.89。K-Means在这种空间里聚类结果是几何意义上的“相近”不是统计意义上的“共现”。我导出过聚类中心的top-5关键词200个主题里183个能用一句话精准概括如“#CovidTesting政策争议”、“远程办公技术故障吐槽”、“疫苗副作用个人经历分享”。这才是业务方能看懂、能行动的分析结果。代价是计算量大但EC2正好补上这个缺口。2.4 为什么可视化必须用UMAPPlotly而不是PCAMatplotlibPCA主成分分析是降维老将但它的线性假设在NLP向量空间里是灾难性的。768维的句子向量其内在流形manifold是高度非线性的。PCA强行用两个线性组合去逼近会把原本聚类清晰的簇硬生生拉平、扭曲。我用PCA降维后的散点图做过测试200个K-Means簇在PCA图上严重重叠边界模糊肉眼根本无法区分。而UMAPUniform Manifold Approximation and Projection专为保留局部结构设计它认为“邻居的邻居还是邻居”降维后同一主题的推文依然紧密抱团不同主题之间有清晰鸿沟。Plotly则是唯一选择——静态图如Matplotlib无法交互而业务方最常问的是“这个蓝色簇里具体有哪些推文”Plotly的hover提示、zoom缩放、legend筛选功能让一张图变成可钻取的数据仪表盘。当客户指着屏幕说“把第三簇的TOP10推文导出给我”你点三下鼠标就能完成这才是生产力。3. 核心模块详解与实操避坑指南3.1 EC2环境搭建从裸机到可运行NLP的完整链路创建EC2实例绝不是点几下“Launch Instance”就完事。我见过太多人卡在第一步安全组Security Group配置错误导致SSH连不上或者Python脚本无法访问Twitter API。以下是我在生产环境验证过的最小可行配置首先AMIAmazon Machine Image选Ubuntu Server 22.04 LTS。它比Amazon Linux 2更新对Python 3.10和PyTorch 2.x兼容性更好且官方长期维护。实例类型锁定t2.small网络选默认VPC子网选公有子网Public Subnet确保能直接访问互联网。关键在安全组必须开放入站Inbound规则——SSH端口22源IP设为你办公室或家庭IP切勿0.0.0.0/0出站Outbound规则保持默认全开因为爬虫和模型下载都需要外网。实例启动后首要任务不是写代码而是加固环境。登录后立即执行sudo apt update sudo apt upgrade -y sudo apt install python3-pip python3-venv git curl -y接着创建专用用户禁止root直接登录sudo adduser nlpuser sudo usermod -aG sudo nlpuser sudo sed -i s/PermitRootLogin yes/PermitRootLogin no/ /etc/ssh/sshd_config sudo systemctl restart sshd然后切换到nlpuser创建项目目录并初始化虚拟环境su - nlpuser mkdir -p ~/nlp-pipeline cd ~/nlp-pipeline python3 -m venv venv source venv/bin/activate提示永远不要用sudo pip install这会导致权限混乱后续cron定时任务会因找不到包而失败。虚拟环境是隔离的基石。安装核心依赖时顺序和版本有讲究。先装torch因为它对sentence-transformers是底层依赖pip install torch2.0.1cpu torchvision0.15.2cpu torchaudio2.0.2cpu -f https://download.pytorch.org/whl/torch_stable.html注意指定cpu后缀因为我们没GPU。接着装sentence-transformers和snscrapepip install sentence-transformers2.2.2 pip install snscrape0.9.2这里版本锁死是血泪教训。snscrape1.0版本改用异步HTTP与旧版Twitter API不兼容而我们的推文采集基于旧API规则。sentence-transformers2.2.2是最后一个全面支持all-MiniLM-L6-v2且无内存泄漏的稳定版。最后装可视化套件pip install umap-learn0.5.3 plotly5.18.0 pandas1.5.3注意umap-learn必须用0.5.3新版0.5.4在多线程环境下有随机崩溃bug我在t2.small上复现过3次。3.2 推文采集模块snscrape的稳健用法与反限流策略snscrape是神器但Twitter的反爬机制让它像走钢丝。直接用snscrape.TwitterSearchScraper(covid lang:en since:2024-06-01 until:2024-06-02).get_items()大概率在1000条后返回空结果。原因有三IP被临时标记、请求头缺失、速率过快。我的解决方案是“三层防护” 第一层请求头伪装。Twitter会检查User-Agent默认的snscrapeUA太明显。在代码里显式设置import snscrape.modules.twitter as sntwitter import time import random # 自定义UA池模拟真实浏览器 USER_AGENTS [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.2 Safari/605.1.15, Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 ] # 构造带UA的scraper scraper sntwitter.TwitterSearchScraper( covid lang:en since:2024-06-01 until:2024-06-02, userAgentrandom.choice(USER_AGENTS) )第二层动态延迟与指数退避。不追求速度追求成功率def safe_scrape(scraper, max_tweets50000): tweets [] count 0 for i, tweet in enumerate(scraper.get_items()): if count max_tweets: break try: # 只取关键字段减少内存占用 tweets.append({ id: tweet.id, content: tweet.content[:500], # 截断过长文本 date: tweet.date, username: tweet.user.username, likeCount: tweet.likeCount }) count 1 # 每100条停800ms模拟人类操作 if i % 100 0: time.sleep(0.8) except Exception as e: print(fError at tweet {i}: {e}) # 遇错暂停3秒再继续 time.sleep(3) continue return tweets第三层本地缓存与断点续传。万一中途断电不能重来。每写入1000条就保存一次CSVimport pandas as pd def save_batch(tweets, batch_id): df pd.DataFrame(tweets) filename ftweets_batch_{batch_id}.csv df.to_csv(filename, indexFalse, modea, header(batch_id0)) print(fSaved {len(tweets)} tweets to {filename}) # 在safe_scrape循环中调用 if len(tweets) 1000: save_batch(tweets, batch_id) tweets.clear() # 清空内存 batch_id 1这样即使EC2意外终止你也能从最后一个batch_id继续损失不超过1000条数据。3.3 主题建模与聚类Sentence-Transformers的高效调用技巧sentence-transformers加载模型是最大瓶颈。model SentenceTransformer(all-MiniLM-L6-v2)这行代码首次运行要花45秒下载模型并编译。如果每次脚本启动都重载5万条推文的处理时间会暴涨30%。解决方案是模型单例批处理。在主脚本顶部全局加载一次模型from sentence_transformers import SentenceTransformer import numpy as np # 全局变量只加载一次 model None def get_model(): global model if model is None: print(Loading sentence-transformers model...) model SentenceTransformer(all-MiniLM-L6-v2) print(Model loaded.) return model # 批处理函数避免逐条编码 def encode_texts(texts, batch_size256): model get_model() embeddings [] for i in range(0, len(texts), batch_size): batch texts[i:ibatch_size] # 使用model.encode的batch模式比循环快8倍 batch_emb model.encode(batch, show_progress_barFalse, convert_to_numpyTrue) embeddings.append(batch_emb) # 批间加微小延迟减轻CPU压力 if i batch_size len(texts): time.sleep(0.05) return np.vstack(embeddings)batch_size256是t2.small的黄金值。太小如32导致PyTorch频繁启停太大如1024会触发OOM。实测256时GPU利用率虽无GPU但CPU向量化计算稳定在85%内存占用平稳。K-Means聚类时n_clusters200是经验起点但必须验证。肘部法则Elbow Method在这里不适用因为SSESum of Squared Errors随K增大单调下降。我用轮廓系数Silhouette Score作为指标from sklearn.cluster import KMeans from sklearn.metrics import silhouette_score def find_optimal_k(embeddings, k_rangerange(50, 301, 50)): scores {} for k in k_range: kmeans KMeans(n_clustersk, random_state42, n_init3) labels kmeans.fit_predict(embeddings) score silhouette_score(embeddings, labels) scores[k] score print(fK{k}, Silhouette Score{score:.4f}) optimal_k max(scores, keyscores.get) return optimal_k, scores # 运行后发现K180时分数最高0.421而非200 optimal_k, _ find_optimal_k(embeddings)最终选用180簇比硬编码200更科学。聚类后为每个簇生成可读标签不用人工看from sklearn.feature_extraction.text import TfidfVectorizer from collections import Counter def get_cluster_keywords(texts, labels, cluster_id, top_n5): cluster_texts [texts[i] for i in range(len(texts)) if labels[i] cluster_id] # 用TF-IDF提取关键词过滤停用词 vectorizer TfidfVectorizer(stop_wordsenglish, max_features1000, ngram_range(1,2)) tfidf_matrix vectorizer.fit_transform(cluster_texts) feature_names vectorizer.get_feature_names_out() # 统计词频 word_freq Counter() for text in cluster_texts: words text.lower().split() word_freq.update([w for w in words if w in feature_names]) return [word for word, freq in word_freq.most_common(top_n)] # 对每个簇生成标签 cluster_labels {} for i in range(optimal_k): keywords get_cluster_keywords(all_texts, labels, i) cluster_labels[i] .join(keywords)这样cluster_labels[0]可能是“vaccine side effects headache fatigue”业务方一眼就懂这是什么主题。3.4 数据可视化UMAP降维与Plotly交互图的落地实现UMAP降维不是黑箱参数选择直接影响效果。n_neighbors15和min_dist0.1是t2.small上的最佳实践。n_neighbors太小如5会过度关注局部噪声把同一主题撕裂太大如50会抹平主题差异让所有簇挤在一起。min_dist0.1保证簇间有合理间距0.01太密看不清0.3太散失去关联性。降维代码要加异常处理因为UMAP对输入敏感import umap def safe_umap(embeddings, n_components2, n_neighbors15, min_dist0.1): try: reducer umap.UMAP( n_componentsn_components, n_neighborsn_neighbors, min_distmin_dist, random_state42, n_epochs500, # 增加迭代次数提升质量 metriccosine # 用余弦距离更适合文本向量 ) embedding_2d reducer.fit_transform(embeddings) return embedding_2d except Exception as e: print(fUMAP failed: {e}, falling back to PCA) from sklearn.decomposition import PCA pca PCA(n_components2, random_state42) return pca.fit_transform(embeddings) embedding_2d safe_umap(embeddings)Plotly绘图的关键是轻量化。5万点全画出来网页会卡死。我的方案是只画每个簇的质心centroid和前100个最具代表性的点按聚类置信度排序import plotly.express as px import numpy as np # 计算每个簇的质心 centroids np.array([ np.mean(embedding_2d[labels i], axis0) for i in range(optimal_k) ]) # 为每个簇选top100点按到质心距离排序 sampled_points [] sampled_labels [] for i in range(optimal_k): cluster_points embedding_2d[labels i] if len(cluster_points) 100: sampled_points.extend(cluster_points) sampled_labels.extend([i] * len(cluster_points)) else: # 计算到质心距离取最近100个 dists np.linalg.norm(cluster_points - centroids[i], axis1) top_idx np.argsort(dists)[:100] sampled_points.extend(cluster_points[top_idx]) sampled_labels.extend([i] * 100) # 转为DataFrame df_plot pd.DataFrame(sampled_points, columns[x, y]) df_plot[cluster] sampled_labels df_plot[label] df_plot[cluster].map(cluster_labels) fig px.scatter( df_plot, xx, yy, colorlabel, hover_data[label], titlefNLP Topic Clusters (n{len(sampled_points)} points), width1200, height800 ) fig.update_traces(markerdict(size4, linedict(width1, colorDarkSlateGrey))) fig.show()这样最终HTML文件小于2MB任何现代浏览器都能流畅交互。点击图例可单独显示某主题悬停点看具体推文关键词右键Zoom聚焦细节。这才是给业务方的交付物。4. 全流程自动化从手动执行到每日凌晨三点准时出报告4.1 Shell脚本封装让Python流水线变成一行命令所有Python模块写好后必须用Shell脚本统一调度这是自动化基石。创建run_pipeline.sh#!/bin/bash # 设置环境 export PATH/home/nlpuser/nlp-pipeline/venv/bin:$PATH cd /home/nlpuser/nlp-pipeline # 时间戳用于日志和文件名 DATE$(date %Y-%m-%d) LOG_FILE/home/nlpuser/nlp-pipeline/logs/pipeline_${DATE}.log echo Pipeline Start: $(date) $LOG_FILE # 步骤1采集推文 echo Step 1: Scraping tweets... $LOG_FILE python3 scrape_tweets.py --date $DATE 2 $LOG_FILE if [ $? -ne 0 ]; then echo ERROR: Tweet scraping failed $LOG_FILE exit 1 fi # 步骤2主题建模 echo Step 2: Running topic modeling... $LOG_FILE python3 topic_modeling.py --input tweets_${DATE}.csv --output clusters_${DATE}.csv 2 $LOG_FILE if [ $? -ne 0 ]; then echo ERROR: Topic modeling failed $LOG_FILE exit 1 fi # 步骤3生成可视化 echo Step 3: Generating visualization... $LOG_FILE python3 visualize.py --input clusters_${DATE}.csv --output plot_${DATE}.html 2 $LOG_FILE if [ $? -ne 0 ]; then echo ERROR: Visualization failed $LOG_FILE exit 1 fi echo Pipeline Success: $(date) $LOG_FILE关键点export PATH确保调用的是虚拟环境里的Python2 $LOG_FILE把stderr也记入日志方便排错每个步骤后检查$?失败立即退出不污染下游。赋予执行权chmod x run_pipeline.sh。4.2 cron定时任务在EC2上实现真正的“无人值守”EC2自带cron但新手常犯两个错一是用root的crontab导致路径和环境变量错乱二是没写绝对路径脚本找不到文件。正确做法是用nlpuser的crontab# 切换到nlpuser su - nlpuser # 编辑crontab crontab -e添加一行# 每天凌晨3:00执行UTC时间注意时区 0 3 * * * /home/nlpuser/nlp-pipeline/run_pipeline.sh /home/nlpuser/nlp-pipeline/logs/cron.log 21 /home/nlpuser/... 21把stdout和stderr都导入日志这是排错唯一依据。/home/nlpuser/是绝对路径杜绝相对路径陷阱。测试是否生效crontab -l查看列表systemctl status cron确认服务运行。注意EC2默认时区是UTC。如果你在东八区想北京时间凌晨3点运行cron时间应设为0 19 * * *UTC 19:00 北京时间次日3:00。用timedatectl确认当前时区。4.3 LambdaEventBridge远程控制EC2开关机的精简实现让EC224小时开着不划算。最佳实践是Lambda在每天任务前10分钟启动EC2任务完成后10分钟关闭。这需要两个Lambda函数start-ec2和stop-ec2。start-ec2函数Pythonimport boto3 def lambda_handler(event, context): ec2 boto3.client(ec2, region_nameus-east-1) # 替换为你EC2所在区域 instance_id i-0abcdef1234567890 # 替换为你的EC2实例ID try: ec2.start_instances(InstanceIds[instance_id]) print(fStarted EC2 instance {instance_id}) return {status: success} except Exception as e: print(fError starting instance: {e}) raise estop-ec2函数类似调用ec2.stop_instances()。部署后在EventBridge控制台创建规则Rule name:daily-pipeline-scheduleSchedule:rate(1 day)或cron(0 3 ? * * *)UTC每天3:00Targets: 添加两个目标第一个是start-ec2Lambda第二个是stop-ec2Lambda但设置Input Transformer为stop-ec2添加10分钟延迟EventBridge不支持原生延迟需在Lambda内time.sleep(600)或用Step Functions但太重此处简化。更优雅的做法是start-ec2启动后不直接调用stop-ec2而是在EC2的run_pipeline.sh末尾用AWS CLI发送SNS通知由SNS触发stop-ec2。这样确保EC2只在任务真正完成后才关机。CLI命令# 在run_pipeline.sh末尾添加 aws sns publish --topic-arn arn:aws:sns:us-east-1:123456789012:pipeline-complete --message Pipeline doneSNS Topic需提前创建并授权Lambda订阅。这比硬编码延迟更可靠。4.4 日志与监控让流水线“会说话”没有监控的自动化是盲人骑马。我在/home/nlpuser/nlp-pipeline/logs/下建立三级日志体系pipeline_YYYY-MM-DD.log: 每日全流程日志含时间戳、步骤、成功/失败。cron.log: cron调度日志记录每次触发时间和返回码。error_summary.log: 每日汇总用脚本自动提取当日所有ERROR行# daily_error_summary.sh DATE$(date %Y-%m-%d) grep ERROR: /home/nlpuser/nlp-pipeline/logs/pipeline_${DATE}.log /home/nlpuser/nlp-pipeline/logs/error_summary_${DATE}.log每周一上午用cat error_summary_*.log | sort | uniq -c | sort -nr生成错误TOP10针对性优化。5. 实战问题排查与独家避坑经验5.1 常见问题速查表问题现象根本原因解决方案验证方式snscrape返回空结果无报错Twitter IP限流返回HTTP 429在safe_scrape中加入time.sleep(5)并捕获HTTPError重试3次用curl -I https://api.twitter.com/...模拟请求看响应头Retry-Aftersentence-transformers加载慢内存爆满模型未预加载每次调用都重复初始化将model SentenceTransformer(...)移到脚本顶层全局单例ps aux --sort-%memUMAP降维后所有点挤成一团min_dist参数过大如0.5改为min_dist0.1n_neighbors15用np.std(embedding_2d, axis0)检查x,y坐标标准差应1.0Plotly图打开空白控制台报Uncaught ReferenceErrorHTML文件引用了外部CDN而EC2无外网或被拦截在fig.write_html()中加include_plotlyjscdn改为include_plotlyjsTrue内联JS查看HTML源码确认script标签内有完整JS代码cron任务不执行日志无记录crontab编辑后未生效或用户权限不对su - nlpuser -c crontab -l确认内容systemctl status cron确认服务运行手动执行su - nlpuser -c /home/nlpuser/.../run_pipeline.sh看是否报路径错5.2 我踩过的五个深坑与填坑方法坑一EC2磁盘空间悄无声息耗尽t2.small的默认EBS卷只有8GB。snscrape缓存、模型文件、中间CSV、Plotly HTML一周就能撑爆。df -h显示/dev/xvda1使用率98%但du -sh *却只看到几个GB。真相是journalctl日志占了大头。解决sudo journalctl --disk-usage查占用sudo journalctl --vacuum-size100M清理旧日志并永久配置/etc/systemd/journald.conf中SystemMaxUse100M。坑二K-Means聚类结果每天漂移同一组推文周一跑出180簇周二跑出175簇主题标签不一致。原因是random_state42虽固定但snscrape采集顺序受网络影响输入文本顺序变K-Means初始质心位置微调导致最终簇分配不同。填坑在聚类前对文本列表sorted()按ID排序确保输入顺序绝对一致。坑三Plotly交互图在手机端失灵客户用iPad打开HTML缩放失效。原因是默认responsiveTrue在移动端有bug。填坑显式设置fig.update_layout(responsiveFalse, autosizeTrue)并用fig.write_html(..., config{responsive: False})。坑四Lambda调用EC2失败报AccessDeniedstart-ec2Lambda角色缺少ec2:StartInstances权限。但新手常只加策略忘了在Lambda执行角色Execution Role里附加。填坑在Lambda控制台→Configuration→Permissions→Execution role点击角色名进入IAM附加AmazonEC2FullAccess策略生产环境应细化为最小权限。坑五cron时间不准任务总晚1小时EC2系统时区是UTC但date命令显示本地时间造成错觉。填坑timedatectl set-timezone Asia/Shanghai根据实际时区然后sudo systemctl restart cron。验证crontab -e里写* * * * * date /tmp/test.log看/tmp/test.log时间是否匹配。5.3 性能调优实录从22分钟到14分钟的压缩之路初始版本耗时22分37秒。通过三次调优压到14分08秒第一次-3分snscrape的batch_size从默认100改为200减少网络往返time.sleep(0.8)改为0.6因实测Twitter响应更快。第二次-4分sentence-transformers的encode函数增加batch_size256和show_progress_barFalse关闭进度条输出I/O耗时。第三次-1.5分UMAP的n_epochs500改为300牺牲微小精度换取速度visualize.py中px.scatter的size_max4改为3减少渲染负担。