一个公司的业务运营，不论规模大小，什么行业，都离不开数据的支撑。既然要数据，那么就得取数，谁来取数，怎么取？可能是一个销售人员在用Excel取，可能是一个DBA从生产数据库中查，也可能是一个数据开发人员写SQL或者写程序从数据仓库中取。
作为一个多年从事数据相关的开发者，深受“临时数据提取”之苦，自己也是用尽十八般武艺，目的就是想尽可能的解决取数难、取数慢的问题。在此总结一下多年来对于取数的一些方法（更多是针对公司有自己的数据团队），大概包含以下几个方面：
固定报表是最常见、最简单的取数方式。通常是需求方在经过对数据调研之后，形成固定的数据报表需求，然后提给数据开发团队，由数据开发团队安排资源实施完成。报表形成后，定期更新数据，报表一般通过WEB界面（自研或者使用开源）来呈现，有些则是通过邮件（Excel）方式每天定时发送。
然而需求方的数据需求并不总是固定格式的，他们希望从所有可能的维度去探索数据，因为很多时候，他们自己一开始也不知道最终想要的数据。这时候，依靠固定报表显然无法满足需求。
OLAP系统开始发挥他们的长处，数据开发团队依据业务和数据，在OLAP系统中设计相应的CUBE，定期更新，而需求方则可以在OLAP系统中，基于设计好的CUBE，自己选择需要查询的维度、指标、条件等等，进行探索分析查询。
一个比较好的OLAP系统需要依赖以下方面：规整的数据仓库模型（事实表、维度表），不错的OLAP引擎，Nice的OLAP前端工具。
为了进一步减少数据开发的工作量，让需求方能更加自助和自主的去完成一些取数，我们开发了自助分析系统（ http://lxw1234.com/archives/2016/12/819.htm）。用户可以自己上传Excel、文本，接入数据仓库数据，接入自己数据库数据，自助建模（相当于定义Cube），然后来探索分析数据。
另外，该系统也适用于那些没有数据开发团队的小公司。
慢慢的，又遇到问题了。OLAP系统和自助分析系统，都需要定义CUBE，而CUBE对数据模型（事实表，维度表）有一定的要求。对于一些数据需求，很难固化成数据模型去支持查询。
刚开始，直接提供SQL接口让需求方去提交SQL去查，但问题是他们不太会SQL，即使会，提交过来的SQL执行性能很有问题。因此，我想增加一种功能，让需求方只去操作界面，后台根据界面操作，转换成SQL去执行。这个问题看似简单，但是我想做的更灵活简单一些。
数据开发人员去配置一个自助取数模板，这个模板核心由一段SQL和一些变量组成。
变量有三种类型：维度、指标和常量。
数据开发人员定义好模板后，需求方可以在自助取数任务页面使用模板，提交取数任务。
在取数任务页面，常量是必填字段，维度和指标可以随意组合选择，也可以增加过滤条件。选择好后，由后台根据任务条件，替换模板中的变量，生成SQL，产生结果供下载。
这个过程，更像是一个动态虚拟CUBE，虽然离线运行SQL并生成结果需要一段时间，但灵活性更好，也收到了比较好的效果。
尽管为了满足取数需求，减少数据开发工作量，我们做了上面很多的努力，但仍然有小部分的需求，需要由数据开发人员来完成。
其实依靠平台化、系统化、自动化去解决80-90%的数据需求，已经非常不错了。
如果觉得本博客对您有帮助，请 赞助作者 。
转载请注明： lxw的大数据田地 » 谈谈”取数”的那些事儿