data_stream/ic/ic_spider_df.md

@@ -59,6 +59,8 @@ database "es: collie-ic-crawler-meta-*" #lightgreen
 @enduml
 ```
 
+# 目标处理流程
+
 ```plantuml
 @startuml
 
@@ -108,6 +110,9 @@ queue "topic: ic_ods_binlog"
 [topic: ic_ods_binlog] --> [udm: ic_update_data]: 多进程
 [udm: ic_update_data] --> [topic: ic_update_data]: digest + 子维度信息
 
+[topic: ic_ods_binlog] --> [udms: parse_changes]: 从变更记录解析曾用名，历史董高监等
+[udms: parse_changes] --> [company_...]
+
 [topic: ic_update_data] --> [ic]
 [topic: ic_update_data] --> [partner]
 [topic: ic_update_data] --> [employee]
@@ -118,3 +123,36 @@ queue "topic: ic_ods_binlog"
 @enduml
 ```
 
+# 目前工商上线流程的问题
+
+> mongo的ic表、股东、主要人员表等没有唯一约束，导致有数据重复
+> 多进程上线，新收录主体注册digest时冲突，导致主体重复
+> 每天采集的大部分数据是没有变化的，但都会更新mongo，且不知道哪些字段有变化
+> 由于mongo对同一个字段的类型没有统一约束，导致同一个字段有不同的数据类型
+> 有些再加工字段，由于不能监控实际有变化的记录，而都放在上线程序中处理，导致上线程序做了太多事情
+> 由于不知道实际有变化的数据信息，在更新对外输出表、联系方式表等时需要对采集的全部数据做处理，严重浪费资源
+> 更新mongo时处理逻辑复杂，上线代码维护难度大
+
+
+# 新的处理流程期望达到的效果
+
+1、统一所有字段的数据类型
+
+2、减少后续相关业务表要处理的数据量，即只处理实际数据发生变化的主体信息
+
+3、减少数据重复
+
+4、通过数据更新日志实现动态监控
+
+5、解决上述目前流程的其他问题
+
+## 待确定问题
+
+1、水滴上需要知道哪些主体去采集更新了，也即最后采集时间，也即现在爬虫结果的lastupdatetime，新的流程中怎么处理该字段
+
+2、注册digest时一个进程是否满足
+
+
+# ic_ods表结构
+
+## 
\ No newline at end of file