从定制研发的方式将数据给到业务人员、到主题式服务，数据服务追求的是一步步从“授人予鱼”走向“授人予渔”。而能够从业务视角建设准、快、全、统、通的体系而言，OneService体系起到了关键作用。
在授人予鱼的阶段，数据部门处于弱势，业务部分处于强势；业务部门处在主导地位。因此，数据对业务的支撑就变成了给数式服务。
为了解决这样的问题，必须在数据统一、服务统一两个方面同时着手，两手都要抓，两手都要硬。
2012年前后的数据服务
提供给数式服务，首先根据业务需求烟囱式开发满足需求。然后将数据表同步到查询数据库中，再基于查询数据库定制化封装面向一个个应用需求的API。当应用调用API时，将其解析为SQL指向制定物理表，实现API的定制化和独享化。
2014年前后的数据服务
因为OneData体系确保了数据指标的标准性和唯一性，那么所有的数据指标在同步到查询数据库以后是去重的，并且是可以被唯一识别的。
因此可以在查询数据库中按照查询统计维度，将相同统计维度的不同物理表中的指标配置到同一逻辑表中，因为数据指标是唯一的，所以配置到同一逻辑表中的数据指标是唯一的。
所以在调用一个API时，对该API数据调用解析出来的SQL语句会通过逻辑表指向多个物理表，进而找到唯一的数据指标，从而实现API的共享，形成“授人予渔”的主题式服务。
2016年前后的数据服务
思考OneData和OneService体系融合，不再先试用OneData体系处理好数据，然后同步到查询数据库中，再通过OneService体系中配置逻辑表实现API服务。
开始思考基于逻辑模型的自动化、智能化数据件建模。OneService体系基于逻辑模型，而逻辑模型内数据指标则是通过自动化、智能化实现的。
每当应用调用一个API时，对该API数据调用解析出来的SQL语句就会通过逻辑模型而非逻辑表直接发起一个数据指标的查询请求，而请求结果返回则是一个智能黑盒基于逻辑模型实现的。
查询请求，而请求结果返回则是一个智能黑盒基于逻辑模型实现的。
