replay/lake_20200521.md

+# 20200521会议总结
+## 参会人员：吴一博、范召贤、李林坳、宋志鹏、郭本江
+## 会议主题：数据处理任务经验以及教训总结
+## 会议记录：范召贤
+## 会议结果：
+### 一.数据处理前的准备
+1.要以产品的角度理解业务逻辑。数据的维度、业务逻辑、竞品展示的优缺点、主要数据字段（列表展示的字段）的重要程度等要素要清晰明确。
+行动：[行成数据生产指南](http://tech.pingansec.com/granite/project-lake/wikis/basic_guidelines)
+
+2.数据表设计。要参考业内的通用模板，理解专业词汇。
+
+3.选择正确的开发工具。根据数据的大小，复杂性选择正确的开发工具，比如hadoop适合批处理逻辑简单的大量数据，几十天的存量FTP结果去重适合用hadoop；load data into table 可以快速将存量CSV数据导入到MYSQL。
+
+4.每个数据源保持数据的独立性。作为各自的单独业务逻辑，不应该将数据糅合到一块处理，按照数据源推送的特点，要将推过来的数据按照各自的源数据特征恢复成最新的全量结果。
+
+### 二.数据开发时遵循的原则
+1.代码复用。处理例行和存量尽量让代码通用，减少2次开发。
+
+2.让数据处理没有返工。（1）表设计问题：原始数据的全量中存在一些特殊的数据格式（字段长度），应该参考原始表的结构；（2）每一步结果交付标准。校验结果：数据量统计，抽样，日志、报警信息等。
+
+### 三.数据工具的改进建议
+1.日志模块的通用性。不够友好：日志级别、外部定制等做的不够好、分离日志中的kafka、更好适应于开发过程。
+
+2.通用工具模块的修改和新增。要先发布文档要实现的功能并通知全组人员，确保别人没有实现过而且要兼容老的功能。功能靠考虑通用性，完成后要形成文档，组内评审。
+
+3.SQLReader性能指标。SQLReader大表操作的性能和复杂业务的链接状态控制目前还不够清晰，需要出具一个指导文件说明这些性能参数。需要突破的方向：MySQL的缓存原理、SQL如何在数据库中解析、客户端和服务端如何通信；sqlreader的极限测试，性能指标。
+
+4.data_pump加入清洗逻辑后，如何处理错误数据。
+
+5.工具模块的解耦。目标是让新加入的开发人员不需要了解具体实现，只根据文档使用功能，这个目标还没有实现。
+
+6.consumer和data_pump的标准化和推广，解决环境依赖和易用性，发布1.0版本。
+
+7.collie项目的重构只保留通用功能 ，不能再追加具体的业务逻辑。
+
+8.data_pump来控制执行成功的标志位文件，减少shell的脚本。
+
+### 四.其他建议
+1.supervior和topic的控制，无效配置文件的清除、废弃topic的回收；deploy的部署：一个项目的部分重新部署。
+
+2.consumer驱动多个模块的开发。
+
+3.各个数据维度的关联统计任务做成定时任务，定时出具数据报告。
+
+4.信息归集、标签体系、公司画像。
+
+5.涉诉信息、行业分类等维度的挖掘整理。
\ No newline at end of file