diff --git a/问题排查/doris/Doris 数据倾斜.md b/问题排查/doris/Doris 数据倾斜.md
new file mode 100644
index 0000000..965228c
--- /dev/null
+++ b/问题排查/doris/Doris 数据倾斜.md	
@@ -0,0 +1,43 @@
+如果一张表数据非常大，并且分桶数量有问题就会出现数据倾斜。
+
+分桶（Bucketing）的根本目的是**将数据打散，使其均匀地分布到所有BE节点上**。每个桶就是一个数据分片，在Doris中称为**Tablet**。
+- **数据均匀分布**：可以避免数据倾斜，防止单个BE节点成为写入或查询的瓶颈。这对于高成本的**主键模型（Merge-on-Write）** 尤为重要。
+- **最大化并行处理**：当查询或写入发生时，Doris可以同时在多个BE节点上的多个Tablet上并行执行任务，从而大幅提升效率。
+
+### 黄金法则：分桶数与节点数的关系
+
+#### 法则1：分桶数应该是BE节点数的整数倍
+
+这是为了保证每个BE节点上的Tablet数量完全相等。
+
+- **场景**: 3个BE节点，副本数通常为3。
+- **如果分桶数为10**: Doris会尝试均匀分配，但无法做到绝对平均。可能会出现类似 `BE1: 4个Tablet, BE2: 3个Tablet, BE3: 3个Tablet` 的情况（这只是一个示意，实际分配更复杂），导致轻微的负载不均。
+- **如果分桶数为12 (3的倍数)**: Doris可以精确地为每个BE节点分配 `12 / 3 = 4` 个Tablet（的主副本）。这样在数据写入和查询时，负载可以完美地均分到3个节点上。
+
+#### 法则2：总Tablet数量要适中
+一个分区的总Tablet数 = **分桶数 × 副本数**。 单个BE节点上的Tablet数 = **分桶数** (在副本数为3，BE节点为3的典型情况下)。
+
+Doris官方和社区的最佳实践建议：
+
+- **单个BE节点上的Tablet总数不宜过多**：过多的Tablet会增加FE的元数据管理压力，增加RPC开销，并可能导致Compaction调度不及时，产生大量小文件。
+- **单个Tablet的数据量不宜过小或过大**：
+    - **太小（< 100MB）**: 说明分桶太多，增加了管理开销，且无法发挥Doris列存和压缩的优势。
+    - **太大（> 10GB）**: 可能导致单Tablet的Compaction时间过长，或者在节点故障时，单个Tablet的迁移恢复时间过长。
+    - **理想范围**: 单个Tablet的数据量建议保持在 **100MB ~ 1GB** 之间。
+
+###  如何计算最适合你的分桶数？
+
+这是一个自上而下的推算过程：
+
+1. **预估分区数据量**: 评估一下您的表，单个分区（通常是一天或一个月）的数据增量大概是多少？例如，我们预估一天的数据量是 `50 GB`。
+    
+2. **设定理想Tablet大小**: 我们选择一个理想的Tablet大小，比如 `1 GB`。
+    
+3. **计算理想分桶数**:
+    - 理想Tablet总数 = 分区数据量 / 理想Tablet大小 = `50 GB / 1 GB = 50` 个。
+    - 因为总Tablet数 = 分桶数 × 副本数，所以：
+    - 理想分桶数 = 理想Tablet总数 / 副本数 = `50 / 3 ≈ 16.7`。
+4. **结合“法则1”进行调整**:
+    - 我们计算出的理想分桶数是 `16.7`。
+    - 我们需要找到一个最接近 `16.7` 并且是 `3` 的倍数的数字。
+    - `15` 和 `18` 都是很好的选择。在这种情况下，选择 `18` 会让Tablet更小一些，更灵活；选择 `15` 会让Tablet更大一些，管理开销更小。两者都是合理的。
\ No newline at end of file
diff --git a/问题排查/doris/StreamLoad 超时.md b/问题排查/doris/StreamLoad 超时.md
new file mode 100644
index 0000000..98444e4
--- /dev/null
+++ b/问题排查/doris/StreamLoad 超时.md	
@@ -0,0 +1,29 @@
+已crjry表为例，主键模型并且分桶为1。现象为：当表为空的时候一开始写入很快，随着数据量增加，StreamLoad变得越来越慢，到最后超时。
+
+## 问题一、主键模型写放大
+在Doris中，主键模型（Unique Key Model）的实现方式是 **Merge-on-Write (MoW)**。理解它的工作原理，就能明白为什么您的问题会如此严重。
+
+**Merge-on-Write 工作流程（对于更新或插入操作）**：
+
+1. **读取 (Read)**: 当新数据写入时，Doris需要先根据主键找到对应的旧数据行所在的底层文件。
+2. **合并 (Merge)**: 在内存中，将旧数据行标记为删除，并与新数据行合并。
+3. **写入 (Write)**: 将合并后的新数据（包含被删除的旧行和新行）写入一个新的文件版本（Rowset）。
+
+这个过程也叫 **“读后写”** 或 **“写放大 (Write Amplification)”**。一次逻辑上的写入，在物理层面变成了一次“读取+写入”的操作，其资源开销远大于直接追加数据的模型（Append Model）。
+
+## 问题二、数据倾斜
+1. **底层机制 (Ingredient 1)**: 您使用了**主键模型 (Merge-on-Write)**，这决定了每次写入的成本都很高。
+2. **写入模式 (Ingredient 2)**: 您的Java应用在进行**高频次的Stream Load**，这意味着在短时间内有大量的“读后写”请求被触发。
+3. **致命缺陷 (The Catalyst)**: 您的表存在严重的**数据倾斜**，导致所有高频写入请求都砸向了**同一个Tablet** (`tablet_id=1173992`)。
+
+## 故障拆解
+
+1. **热点Tablet过载**: 所有高频的、高成本的“读后写”操作全部集中在单一的Tablet上。这个Tablet所在的BE节点的CPU和磁盘I/O被瞬间打满。
+2. **Compaction不堪重负**: 每次写入都会为这个Tablet生成一个新的小文件版本（Rowset）。后台的Compaction任务拼命想把这些小文件合并起来，但它的速度远远跟不上写入生成的速度。Compaction和写入操作激烈地争抢系统资源，进一步加剧了BE节点的负载。
+3. **写入超时 (Doris端)**: 在极高的负载下，某一个写入事务的最后一步——`Publish Version`（让版本生效），无法在规定时间内完成。于是，Doris BE日志中出现了第一个关键错误：`PUBLISH_TIMEOUT`。
+4. **版本链断裂**: 这个超时的事务虽然在FE（元数据）层面可能被认为是成功的，但在BE（数据）层面，它的版本没有被成功应用。这就造成了Tablet版本链上的一个“空洞”。例如，成功了版本`325762`，但版本`325763`超时失败了。
+5. **连锁失败 (Doris端)**: 后续所有发往这个Tablet的写入请求，比如想写入版本`325764`，都会发现`325763`版本缺失，于是Doris拒绝写入，并抛出第二个关键错误：`version not continuous`。
+6. **请求超时 (客户端)**: 与此同时，您的Java应用程序还在苦苦等待Doris返回Stream Load的成功响应。但由于Doris内部已经陷入“超时->版本不连续”的恶性循环，根本无法处理完这个请求。最终，Java客户端的HTTP `ReadTimeout`被触发，应用日志中抛出了我们看到的异常：`java.net.SocketTimeoutException: Read timed out`。
+
+**结论：主键模型对数据倾斜和高频更新场景极其敏感**
+
diff --git a/项目/盛视科技/河口人员核查.md b/项目/盛视科技/河口人员核查.md
new file mode 100644
index 0000000..b43d1a5
--- /dev/null
+++ b/项目/盛视科技/河口人员核查.md
@@ -0,0 +1,54 @@
+  
+河口测试版本
+[http://172.100.40.184:1000/hekou/ryhc-v4/#/home/homepage](http://172.100.40.184:1000/hekou/ryhc-v4/#/home/homepage)
+
+
+## 任务
+
+### 2025-07-21 与昆明边检总站沟通数据层问题
+
+![[Pasted image 20250722091905.png]]
+
+昆明总站考虑增加数据层：
+待沟通问题如下（信科处）：
+1. 公安网与数据层如何通信（隔离）？
+2. 数据层能否提供机器用于安装数据库及其他软件；如果不能的话，只提供PG，相当于现有的软件架构需要重构涉及到费用（商务层面）
+3. 应用是否要求全部部署在数据层，如果要求的话，河口定位数据及海康人流量监控数据目前在视频网，视频网与数据层如何通信？
+
+上述问题沟通清楚后，评估现有河口人员核查架构是否需要调整，如何调整
+
+--------------------------------
+沟通情况如下（与信科处刘科）：
+1.要求数据不出总站,在数据层提供了PG数据库
+2.数据层与公安网直接有防火墙隔离，可以做双向通信
+3.数据层由于没上云，现有服务器资源不足，无法提供要求配置（32G 1T 3台）的机器用于部署doris，只能提供PG。
+4.应用不要求全部部署在数据层, 看具体需要
+
+待确认问题：
+1.通过梅沙数据计算出来的其他数据是否要求存储在数据层
+2.总站能否系统国产化操作系统
+3.PG库的配置情况
+
+#### 2025-08-01 沟通情况如下
+
+昆明总站信科处给出的数据层临时解决方案：重新提供三台公安网云服务器（C86或X86），安装国产化操作系统，然后部署所需组件（doris\mysql\kakfa等），  
+并提供MS数据库用于查询。 河口、磨憨、金水河、清水河边检站的勤务平台复用这三台云服务器。 综上，需要根据每个站的数据量评估云服务器配置（尽快）。另外我司是否能提供国产化操作系统，如果不能提供，总站默认使用开源欧拉或麒麟系统。
+
+
+
+### 2025-07-29 河口出差
+- [ ] minio 迁移 
+	- [x] 新minio 部署及配置mc mirror 🔺 ✅ 2025-08-02
+	- [ ] 切换minio 地址
+	- [ ] 剩余服务器挂载磁盘并分区🔽 
+- [ ] doris-manager 部署及版本升级
+	- [x] 部署doris-manager 🏁 ✅ 2025-08-02
+	- [x] 版本更新至2.1.10 ✅ 2025-08-02
+	- [x] 压力测试 ✅ 2025-08-02
+	- [x] 编写运维手册 ✅ 2025-08-02
+- [ ] openRPA
+	- [x] openRPA 部署 2025-08-01 ✅ 2025-08-02
+	- [ ] 对接综查系统并测试
+- [ ] 评估新GAW云服务器配置并对接昆明BJ总站
+	- [ ] 收集4口岸数据量，并以河口为基准评估资源占用情况
+	- [ ] 准备数据部署及迁移计划