本文已参与「新人创作礼」活动，一起开启掘金创作之路。
背景
Redash是款优秀的大数据可视化开源工具。在我eBay工作的第二年里面，这个Redash是重心的重心。 Redash的代码分为两部分：前端和后端。 后端的本领之一是“七十二变”，能够将各种数据源整合进来；前端的本领是各种精美的控件，搭配后端数据源，能将枯燥的大数据分析后以图形方式展示。
都说数据是21世纪的财富，我觉得光数据本身不能算财富，数据被智慧体分析后产生的洞察insight才是财富。 就拿这套系统来说，运营通过可视化，获得更好的洞察，并以洞察来调整资源的运用（在MarkingTech里面主要是Campaign的投向），从而大大提升了效果，产生了X亿美元的利润。
这是个大系统，有较多同事一起参与。我在其中负责缓存系统部分。虽然大数据系统目前还是以批为主，但是为了达到“秒开”的效果，我们采用预加载方式装入分析后数据，所以缓存在这个系统中的角色比较吃重的，算核心域而不是支撑域。每天的运行情况要监控，我突然想到，比起传统的脚本或者ES方式，枯燥地打几行日志，为何不用Redash技术栈本身，构造一个可视化的监控系统？
说干就干！
需求分析步骤
- 数据来源是日志：下载到云上，用脚本或者工具方式分析；结合源头直接数据库写入
- 自动出一个可视化的报告--比较便捷的方式是导入某种数据库，通过sql查询，然后redash报表
- 所有数据源都是可配置，大大提升报表的灵活性；前端复用Redash控件，必要时单独开发
选型：
数据库用mysql（使用广泛，环境比较多，之前mock阶段也是用mysql，数据量不大所以场景上合适，另外我也比较熟悉）
架构：
怎么样更快？
- 批量运行时记录，不要先引入mysql包（一是编码量大，二是jar体积变大），先写成insert sql语句的方式（到另外一个文件），采用手工导入
- 结果文件下载到本地，手工分析，甚至mock些数据，不要去解析日志
三个维度：
- 批量时间：年 月 日
- 业务维度：Experiment treatment measurementWindown
- 可视化维度：dashboard query
发出的请求记录下 返回的记录： 花费时间 返回状态 返回报文
CREATE TABLE cache_refresh_run_record_redash (
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
query_id VARCHAR(10) NOT NULL,
dashboard_id VARCHAR(10) NOT NULL,
experiment_id VARCHAR(30) NOT NULL,
treatment_id VARCHAR(30) NOT NULL,
measurement_window VARCHAR(30) NOT NULL,
batch_date VARCHAR(20) NOT NULL,
event_date VARCHAR(20) NOT NULL,
request VARCHAR(200),
job_id VARCHAR(100),
duration INT UNSIGNED,
status VARCHAR(10),
result_id VARCHAR(10),
message VARCHAR(2000),
create_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
)
复制代码后来发现要加上control_id
alter table cache_refresh_run_record_redash add control_id VARCHAR(30);
复制代码结果页面展示
这监控页面非常清晰，获得了同事们好评。每天一上班我就打开这个页面，像是欣赏一幅画作。我们是工程师，我们爱自己的劳动工具，Redash之于大数据工程，就像博世电钻机之于装修工程。