之前用Flask写过python项目，关于日志部分使用了比较通用的配置方式——按天生成，大致观察它按天生成日志文件，有输出就没怎么在意。然而突然的有一天，发现貌似日志级别在记录上是不正确的，起初以为是我的打开方式不对，google了多方优秀人士的配置方式，具体配置大致长这样：
import logging
import time,sys
from logging.handlers import TimedRotatingFileHandler
logger = logging.getLogger('yyx')
logger.setLevel(logging.DEBUG)
formatter = logging.Formatter("%(asctime)s - %(name)s - %(levelname)s - %(message)s")
log_file_handler = TimedRotatingFileHandler(filename="log", when="S", interval=2)
log_file_handler.setFormatter(formatter)
log_file_handler.setLevel(logging.DEBUG)
logger.addHandler(log_file_handler)
stream_handler = logging.StreamHandler(sys.stdout)
stream_handler.setFormatter(formatter)
logger.addHandler(stream_handler)
彷徨过一段时间，可能是每个人工作一段时间之后都会产生一个瓶颈期，浑浑噩噩，感觉干不起什么大事儿，掀不出风浪来。打游戏，逛新闻，刷视频，一天转眼就过去了，实属惊心。渐渐的内心有个声音也提醒自己不能如此以往，想要提升影响力，没机遇的情况下只能提高实力。又突然受到友人打鸡血的激励，特有感恐须阅读优秀的源码来学习深层次的架构之美，故有此文章。
2019年过去大半，心境不悲不喜，机遇不痛不痒，心忧所惑。
接着上篇，数据的落地需要Kudu，继而做多数据源查询分析。之前的架构是从多数据源经过kafka,再spark streaming做处理，奈何此数据内容是运维场景，日志记录几十M都有可能存在。而通过spark 同时处理几十个Topic的上百个分区出现了数据不定时延期、数据倾斜等异常现象，不满足业务监控的时间差。从而从之前的状态中采取第二种可控的方案——重写flume sink直接插入Kudu(控制频次)。
2019年过去大半，心境不悲不喜，机遇不痛不痒，心忧所惑。
业务场景比较杂，美其名曰是自动化运维，奈何数据不规范，跨部门太复杂，不得不采用二梯度的法子。说起关系数据库的数据采集，一般是Mysql的binlog,Sqlserver的CDC,Oracle的ogg等。
由于实时采集方案不满足现有业务的监控需要，退而求其次进行增量数据的抽取。面对多种数据源的增量抽取，同时时间戳规范不一致(时间戳,DateTime格式都有)，通用的方案有kafka connector,Logstash自定义，Flume自定义等。鉴于数据技术栈现有体系包含Flume的情况下，采用Flume增量抽取的方案。
Flume-ng本身对于增量抽取是没有适配，尤其是包含多种数据源的时间格式不规范的情况，针对flume-ng-sql-source的开源项目进行修改,修改部分:
2018年过去了，而我也在2018年换了工作环境，机会成本在人生中是个重要部分，人因为选择而伟大。2018年有过冲动，有过犹豫，当然也有坦然。
新公司新气象，独立部门重新开始。鉴于当前的业务范围和行业发展，部门开始准备自研客服机器人的计划。当然，对于NLP来说，我算是个门外汉，一切重新开始，总不算太晚