除了1.1节说到的数据质量的问题，老汤姆来到这个发展速度越来越快的电商企业后，还面临着数据获取效率低的问题。在业务快速发展时，涌现出大量临时取数（提取数据的简称）的需求，数据开发工程师已经有些招架不住了。由于前期数据基础建设不充分，也没有对数仓进行分层设计，维度表和事实逻辑表等主题数据都没被搭建起来，数据获取的成本极高，有的时候研发工程师甚至需要重复地去原始表中处理数据，既浪费人力，又影响效率。这让研发工程师和数据分析师都觉得自己像个“工具人”，每天都在解决无穷无尽的数据需求，一眼看不到头；觉得自己没有成长，甚至产生了离职的想法。这种状态是不可持续的，数据部门必须想出一个解决方案。

除了自己部门反馈的这些困扰和问题，业务部门也经常抱怨数据需求总是延迟交付。造成这个问题的根本原因是大部分需求都需要依赖人力，导致开发时间长、效率低。

这样就容易形成恶性循环，数据部门长期被数据需求压得喘不过气来，数据的价值无法发挥。

老汤姆意识到了事态的严重性，赶快拉着小诺（负责数据产品化建设）和研发工程师一起开会，讨论如何解决数据部门当前面临的这些问题。刚进会议室，老汤姆就开门见山地说：“咱们部门的内部人员和业务部门的同事都向我反馈数据需求处理速度慢、数据获取效率低的问题，基于这个背景，我约大家来聊一下提升数据获取效率的问题，各位可以先发表一下自己的看法。”

这时，负责数据中台化建设的小风第一个发言：“之前的数据开发都是烟囱式的，每次来一个需求都垂直开发一套数据，为了提高人效，就得先改变这种状态，首先要实现数据的分层和建模，完成数据中台化，由数据中台开发和提供统一的指标体系和数据服务。例如，建设元数据中心、数据指标中心、数仓模型中心、数据资产中心等，并最终基于完善的数据中台，建立数据服务中心和自助分析平台，规范数据的统一出口，从而提升整体数据服务的交付效率和研发速度。”

老汤姆赞同地点点头，补充说：“小风说的数据中台化很重要，这是我们提升数据质量和数据获取效率的基础。在这个方面我们可以统一规划，做一个产品方案和项目计划。这件事由小风来负责，重点解决数据质量和数据获取效率的问题。”

小风做了一个OK的手势，并在会议纪要上给自己记下了一个待办事项。

不一会儿，小诺接着说：“小风刚才说的能够解决一部分问题，但是，有些用户需要提取指标类数据，有些用户需要提取明细数据。针对不同主题指标的展示需求，其实市面上已经有很多解决方案，如神策数据、Tableau等，都是基于指标数据来自助创建不同样式的可视化报表的，针对固化类的需求，做成指标展示给用户，让用户自己查看报表并提取数据。而针对用户提取明细数据的需求，其实开源工具也提供了一些解决方案，如HUE等工具支持用户自己输入SQL（Structured Query Language，结构化查询语言）来查询数据，但是这对不熟悉SQL的用户来说存在一些问题。首先，并不是所有用户都有SQL基础，很多用户不会写SQL，或者自己写的SQL不正确，导致查询的数据是错误的；其次，用SQL查数据，就要有表权限，这就存在一定的安全风险。为了进一步提高数据的获取效率和安全性，我们需要针对SQL和数据表在产品层面做进一步的封装，设计一款明细数据提取工具，让用户可以通过拼凑筛选查询条件，快速且高效地自助查询到明细数据。”

老汤姆投来了赞许的目光，对小诺说：“小诺说得很对，在当前阶段，我们最缺少的是一个自助数据分析平台。我们要设计一个工具，能够让业务方自己通过数据中台提供的数据，自助化配置日常报表，而不再依赖研发工程师人力开发，同时可以结合一些SQL模板等功能，实现对业务方友好的明细数据提取功能，真正满足业务方既要快速看到指标数据，又需要查询到明细数据的需求，在解放人力的同时，提升大家的工作效率。小诺，接下来你作为自助数据分析产品化的主要负责人吧，从产品工具层面来提升数据的获取效率。”

小诺点点头，认领了这个项目。

就这样，这个闭门会议愉快地结束了，会议定下了数据中台产品化的战略。所谓数据中台产品化，是指通过自助数据分析平台来提高数据的获取效率，让业务方自己完成数据的获取，而不必再耗费研发资源，这样可以进一步释放研发部门的人力，从而可以将更多的资源放在数据建设上。并且通过底层数据质量建设和基础建设，完成数据的模型设计，在数据生产环节，既可以快速地满足业务方的数据需求，又能满足数据分析师使用数据的诉求。数据中台产品架构如图1-2所示。

本次会议是数据部门主动出击的第一步。只有在数据中台产品化战略的基础上，才能实现高效获取数据的目标，提升数据部门的工作效率，真正释放研发的效能。也只有这样，数据部门才能节省更多的时间，探索数据赋能业务的场景，挖掘更多数据在业务价值上的应用。 k0VI31mfBg+W/wWEs8cn0S3eIaeEpg7MHGEqRgIU+nj/lYBunvbA8BtivnQ+w4Ak