数据只有被看见，真相才浮出水面，数据跳动在大盘，洞察才形成预判。
今天 2023/1/7，到小菜整整 2 年半，看到团队在数据报表量产和可视化上面有了新的成果，这些年来也了解到前端后端面对不计其数的数据报表和后台可视化大盘，真心苦不堪言，就趁这个节点，跟大家聊聊两年半来我们是如何从前端来驱动数据报表量产和可视化大盘的技术探索。
首先上结论：
公司的数据仓库（简称数仓）要投人力持续建设，它是报表及可视化的基础
前端自研报表及可视化会有较高的成本，需要谨慎再谨慎，竞品调研再调研
魔改 Metabase 是一个不错的选择，需要前端学习 Clojure 和熟悉 React
简而言之，先推动技术团队把数据仓库建设到基本成熟，再来基于 Metabase 魔改出自己的报表和可视化业务后台，这是一个可取的套路，得出这个结论，是因为两年半的探索我们有斩获也有疼痛的教训。
当然一路自研过来，我们也调研了很多方案，无论是商业付费还是开源，对第三方可替代竞品的选择标准如下：
代码开源免费，有团队/人持续在维护
产品交互流程易用可定制，有设计感
技术栈对前端友好，学习上手成本低
阅读两篇旧文，有助于大家理解下文：
技术驱动：量产数据报表的工具如何搭建
技术驱动：业务大盘数据可视化技术探索
为什么数据报表是刚需不管是 toB 还是 toC 的公司，无论是 +互联网还是互联网+，都对数据报表有着近乎疯狂的依赖，这不仅仅是像马老师说的我们正在进入 DT 时代，数据运营甚至数据智能价值挖掘和应用越来越普及，而是对于任何一家高速迭代的互联网公司，在产业互联网的大背景下，在中早期各种红利逐渐消逝的前提下，基于数据的成本意识和精细化运营能力越来越考验一家公司在所谓寒冬活下去的实力。
业务现场无时无刻都在产生着数据，通过什么途径观测业财健康直接决定一个公司/一条业务线的顶层决策，顶层决策有何等重要，促成决策的数据报表就有多重要，所以一个公司只要上了信息化系统，数据报表都会成为绝对刚需。
基于这个刚需，有的公司招专门的 BI 工程师，组建算法团队甚至大数据团队，有的则是业务方直接把要看的字段丢给开发团队，让前后端工程师，一个写跨库跨表的 SQL API，一个写能筛选日期和排序的 DataTable 页面。
显然小菜早期，就是以 SQL -> API -> DataTable 的流程开发报表，效率极低，成就感极弱，前后端成长极慢，带来的影响有很多，比如工程师更不稳定，比如业务决策等待的周期更长，比如报表的零散维护出错率更高...
第一波探索 - SQLEditor启动数据报表是在 2017 年 7 月份，届时市面上还没有较为成熟的开源方案可选，包括目前的 Metabase，调研无果后，我们选择了纯自研，目标是让产品经理/后端开发可以快速在线制作报表并渲染出来。
方式是参考数据仓库业务表的文档，在系统上快速的定义报表列的中文名称以及对应的库表字段的查询（比如产品经理可以不借助开发资源，自行查询销售的周市调次数和周个人交易单量这样的简单报表），由于是取代运营本地人肉的 “搭表格”，因此这个系统取名叫做 “大表哥”，它的技术栈的进化如下：
早期技术栈前端：React + Ant
后端：Node.js/Koa2/MongoDB/RDS
服务器：1 台 2 核 4G Centos
功能清单：
报表需求提交（看某业务的哪些数据）
报表加工（在后台网页编辑 SQL)
过滤组件（基于某字段做数据筛选过来）
报表查看（按照一套模板渲染报表）
报表导出（Excel 格式导出）
技术栈缺点：
Koa2 是一个精巧精简的 Node.js 框架，不是一个企业级的框架，从 0 开始配置开发，成本还是比较高
产品交互易用性：
前端页面的交互未经过设计，前端自行设计，比较粗糙难用
中期技术栈前端：React + Ant + Apollo + React Native
后端：Node.js/Egg/Python
服务器：1 台 2 核 4G Centos
功能清单：
报表需求提交/加工/查看/导出优化，及