老汤姆来到这家发展速度越来越快的电商公司后，面临的一个问题就是数据获取效率。在业务快速发展的时候，已经涌现出了大量的数据需求，这些大量的临时需求数据开发工程师已经招架不住，而由于前期数据基础建设不充分，导致维度表和事实表等主题数据架子没有搭起来，数据获取成本和速度都很大，有的时候甚至要研发重复去原始表处理数据，既浪费了人力，又影响了效率。搞得研发和分析师觉得自己像工具人，天天都在跑数据需求，业务的数据需求还不断，一眼看不到头，同时还觉得自己没成长，甚至有些人已经有了离职的想法，这种状态是不可持续的，必须要想一个方案快速解决。
除了自己内部部门反馈的这些困扰和问题，业务部门提了这么多需求，由于都是依赖人力，导致交付的需求很慢，效率很低，大家的评价也不高，这样就好导致恶性循环，长期被数据需求压得喘不过气来，更别提发挥数据价值了。
老汤姆觉得不能再重复这种状态了，于是拉着小诺和研发，一起开了个闭门会议，一起来聊下如何解决当前的问题，老汤姆开门见山的说到：
“部门内部人员和业务部门都和我反馈咱们数据需求处理速度慢，数据获取效率低的问题，基于这个背景，我约大家来聊一下提升获取数据效率的问题，大家可以先发表下自己的看法。”
负责数据中台化建设的小风首先张口：
“首先，之前的数据开发都是烟囱式的方式，来了需求都垂直开发一套，为了提高人效，就得先改变这种状态，就得实现数据的分层和建模，完成数据中台化，由数据中台开发和提供统一的指标体系和数据服务。例如，建设数据指标中心、数据模型中心、数据资产中心、元数据中心等数据中台产品体系，并最终基于完善的数据中台，最终实现数据服务中心，完成对整个数据的服务化，规范数据的统一出口，提升整体数据服务交付效率和研发速度。”
老汤姆赞同的点点头，补充说到：“小风说的数据中台化很重要，是我们提升数据质量和效率的基础，这块我们可以统一规划起来，做个产品方案和项目计划，我们单独做个数据中台化项目，重点来看一下吧”
小风做了一个OK的手势，并在会议纪要上给自己记下了一个待办事项。
负责数据产品化建设的小诺接着说：
“同时，针对大量的数据提取需求，有些指标类的，有些需要明细数据，针对不同主题指标的展示需求，其实市面上已经有很多方案，例如神策、tableau等，都是基于指标数据，来创建不同样式的可视化报表，针对固化类的需求，做成指标展示给用户，大家自己查看报表提取数据。而针对用户的提取明细数据需求，其实开源工具也做了一些，例如HUE等工具，可以支持用户自己输入SQL来差查响应的数据，但是，通过HUE自己查询会有一些问题，首先，并不是所有用户都有SQL基础，很多人不会写SQL，或者自己写的SQL根本不对，查的数据很可能是错的，其次，用SQL查数据，首先要有表权限，这就有一定的安全风险。为了进一步提高数据的获取效率和安全性，还需要针对SQL和数据表进一步封装，实现一款明细取数工具，让用户可以拼凑筛选查询条件，查询数据，来很快的查询到明细数据结果。”
老汤姆投来了赞许的目光，对小诺说到：
“小诺说的很对，我们当前阶段，最缺少一款BI平台，首先要实现的第一个工具，就是能够让业务方自己通过数据中台提供的数据，自己实现可以自助化配置日常报表，而不要再依赖研发人力开发，同时，还可以结合一些SQL模板等功能，实现一款对业务方友好的明细取数功能，真正解决业务同学又要快速看到指标数据，又要能够快速查询到明细数据的需求，解放人力的同时，提升大家的工作效率。小诺，接下来你作为数据工具产品化的主要负责人吧，来负责在产品工具层面，来提升获取数据的效率问题。”
小诺点点头，认领了这个项目。
就这样，老汤姆的会议结束了，会议定下了数据产品工具化+数据中台的双线战略，所谓的数据产品工具化，就是通过通过自助式分析+取数，来提高通用数据相关需求的获取效率，让业务方自己完成，而不必再耗费研发的资源，这样进一步解放研发的人力可以更多的放在数据中台这条线上。所谓的数据中台，就是通过建设底层数据质量和基础建设，完成数据的模型设计，在数据处理阶段，可以快速的完成业务方的数据需求，或者分析师可以快速的使用数据。
数据产品工具化+数据中台架构图
本次会议，是数据部门主动出击的第一步，只有在数据产品工具化+数据中台的双线战略的基础上，才能实现高效获取数据的目标，提升数据部门的工作效率，真正解放大家，也只有这样，数据部门才会节省更多时间，用来探索数据赋能业务，产生更多数据在业务价值上的应用。
发表评论 取消回复