谈谈”取数”的那些事儿

一个公司的业务运营，不论规模大小，什么行业，都离不开数据的支撑。既然要数据，那么就得取数，谁来取数，怎么取?可能是一个销售人员在用Excel取，可能是一个DBA从生产数据库中查，也可能是一个数据开发人员写SQL或者写程序从数据仓库中取。

作为一个多年从事数据相关的开发者，深受“临时数据提取”之苦，自己也是用尽十八般武艺，目的就是想尽可能的解决取数难、取数慢的问题。在此总结一下多年来对于取数的一些方法(更多是针对公司有自己的数据团队)，大概包含以下几个方面：

固定报表

固定报表是最常见、最简单的取数方式。通常是需求方在经过对数据调研之后，形成固定的数据报表需求，然后提给数据开发团队，由数据开发团队安排资源实施完成。报表形成后，定期更新数据，报表一般通过WEB界面(自研或者使用开源)来呈现，有些则是通过邮件(Excel)方式每天定时发送。

OLAP系统

然而需求方的数据需求并不总是固定格式的，他们希望从所有可能的维度去探索数据，因为很多时候，他们自己一开始也不知道最终想要的数据。这时候，依靠固定报表显然无法满足需求。

OLAP系统开始发挥他们的长处，数据开发团队依据业务和数据，在OLAP系统中设计相应的CUBE，定期更新，而需求方则可以在OLAP系统中，基于设计好的CUBE，自己选择需要查询的维度、指标、条件等等，进行探索分析查询。

一个比较好的OLAP系统需要依赖以下方面：规整的数据仓库模型(事实表、维度表)，不错的OLAP引擎，Nice的OLAP前端工具。

自助分析系统

为了进一步减少数据开发的工作量，让需求方能更加自助和自主的去完成一些取数。用户可以自己上传Excel、文本，接入数据仓库数据，接入自己数据库数据，自助建模(相当于定义Cube)，然后来探索分析数据。

另外，该系统也适用于那些没有数据开发团队的小公司。

自助取数系统

慢慢的，又遇到问题了。OLAP系统和自助分析系统，都需要定义CUBE，而CUBE对数据模型(事实表，维度表)有一定的要求。对于一些数据需求，很难固化成数据模型去支持查询。

刚开始，直接提供SQL接口让需求方去提交SQL去查，但问题是他们不太会SQL，即使会，提交过来的SQL执行性能很有问题。因此，我想增加一种功能，让需求方只去操作界面，后台根据界面操作，转换成SQL去执行。这个问题看似简单，但是我想做的更灵活简单一些。

数据开发人员去配置一个自助取数模板，这个模板核心由一段SQL和一些变量组成。

变量有三种类型：维度、指标和常量。

数据开发人员定义好模板后，需求方可以在自助取数任务页面使用模板，提交取数任务。

在取数任务页面，常量是必填字段，维度和指标可以随意组合选择，也可以增加过滤条件。选择好后，由后台根据任务条件，替换模板中的变量，生成SQL，产生结果供下载。

这个过程，更像是一个动态虚拟CUBE，虽然离线运行SQL并生成结果需要一段时间，但灵活性更好，也收到了比较好的效果。

临时数据提取需求

尽管为了满足取数需求，减少数据开发工作量，我们做了上面很多的努力，但仍然有小部分的需求，需要由数据开发人员来完成。

其实依靠平台化、系统化、自动化去解决80-90%的数据需求，已经非常不错了。

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：创新互联

猜你还喜欢下面的内容