在业务发展的不同阶段中，业务对数据应用的诉求是不同的，一般会经历从满足基本的取数看数，了解业务发生了什么，到利用数据分析业务为什么发生，最后利用算法模型来预测将来还会发生什么；那么在这些不同的阶段中数据同学应该如何根据业务所需来提供适配的数据服务，本文主要就业务发展不同阶段的数据服务实践展开探索。
1、业务萌芽阶段
在业务发展初期，业务的商业模式在短时间内处于一个摸索尝试的阶段，会快速地根据业务效果调整业务方向和策略，所以这个阶段业务团队对数据的诉求特征一般体现为临时性、高频化、需要快速响应等；数据同学在这个阶段应该着重在熟悉业务、理解数据、高效支持业务数据诉求。
1.1、熟悉业务
1.2.1、理解业务，建立互信
数据同学在接手一块新的业务时，第一要务就是通过各类途径学习和了解业务，和业务同学、运营同学多沟通请教，理解业务的主要商业模式、业务主要环节过程中的各相关方，最好能通过笔记对一些核心的业务流程加深记忆理解，为将来的概念模型设计积累经验；在这个过程中加深和业务同学的相互了解，建立互信。
数据研发同学和单纯的技术开发同学相比，在具备大数据处理技能的基础上，还需要加深对业务的理解，这样才能在未来与业务运营同学就数据的深层次应用价值共同探索找到应用场景。
1.2、数据支持
1.2.1、理解数据
在熟悉业务的同时同步了解业务涉及的业务系统(日志)数据源，技术团队往往侧重于功能的实现，对一些业务过程类的数据不会刻意去存储，数据同学需要协同业务产品、技术团队尽可能保留业务核心流程产生的所有数据，不仅仅是结果类数据，过程类数据同样需要保留，开始着手绘制业务线的数据大图。
1.2.2、高效支撑
对于业务同学提出的临时需求需要高效地支持，采取短平快方法交付；同时在交付过程中需要做好需求的记录、对临时需求进行分类和梳理，抽象识别出这些需求中共性的东西，为后续平台化、产品化支持积累素材。
1.2.3、数据积累
在这个阶段数据的支持可以采取从ods层数据直接加工获取，数据仓库架构和建模的工作可以开始规划，做好对使用数据表的统计情况，做好标识，加深印象，为后续数据模型设计时逻辑模型的设计打好基础。
2、业务稳定阶段
在这个阶段，业务的商业模式阶段性趋于稳定，主要的核心流程也就是四梁八柱已经固定，如何判断业务已经发展到稳定阶段，需要我们数据同学根据和业务同学日常沟通获取的信息来判断，稳定不是绝对的，是阶段性相对的；业务的数据诉求将逐渐聚焦到一些核心数据项目共建上面，围绕高效看数、反哺业务，赋能业务等方向展开，临时取数需求的占比将逐步减少。
数据同学需要开始展开业务线数据基础建设工作，基于前期的对业务的理解以及在交付临时性取数需求时积累的数据统计信息开始数据仓库的设计和开发了，建设符合业务发展的数据体系。
2.1、数据基础建设
2.1.1、数据仓库架构
数据仓库是一个发展很多年的概念，比较成熟，数据仓库的建设思路业内有自上而下和自下而上两种建设思路；自上而下的思路多适用于比较稳定的业务，先统一规划建设企业级数据仓库，再建设数据集市；这样做的好处是可以全方位梳理整合企业数据，不足之处在于交付周期比较长；自下而上的思路主要是先利用维度建模方法建设维度一致的某个业务主题的数据集市，通过一致性维度讲数据集市连接在一起组成数据仓库；这样做的好处是建设迅速，短期内就可以支撑数据应用，不足之处在于不好维护，尤其是规范不严格执行的情况下会产生烟囱式开发的恶果。
两个思路没有孰优孰劣，仅仅是不同的选择，但不管哪种思路的选择，终究还是需要考虑自身业务形态以及平衡长期投入与短期产出的问题。这两种建设思路代表着数据仓库领域两位大师各自的观点，感兴趣的同学可以深入去了解他们的内在思路。
虽然各行各业业务形态有很大差异，但数据仓库的架构设计还是大同小异，整体遵循了上面两种思路，整体架构会包括贴源层、明细数据整合层、数据汇总层，只是根据自身的数据环境进行裁剪。
2.1.2、数据仓库模型设计
关于数据模型的理论定义很多，摘录一个比较认可的定义： 数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射。
关于数据仓库建模，我理解的意义有以下几点 ：
i、建模的过程中数据同学和业务同学一道对业务流程进行梳理，可以帮助数据同学全面了解业务的组织和运行情况；
ii、 对业务产生数据的全面梳理，沉淀业务数据资产，建立结构统一的数据规范和框架，消灭内部的信息孤岛和数据差异；
iii、数据模型是技术同学与业务同学沟通的一个桥梁，模型作为整体业务的抽象化载体，可以帮助业务理解技术，技术理解业务；
一般模型的层次会大致包含概念模型、逻辑模型和物理模型三个层次 ：
i、概念模型，主要是梳理业务的主要流程，对业务进行抽象概括，根据业务形态划分主题域；
ii、 逻辑模型，对主题域进行细化，识别出实体以及实体属性、事件、实体间的关系等，常以ER图展现；
iii、物理模型，主要是逻辑模型的物理实现，需要考虑数据库平台；
2.1.3、数据仓库建模思路
贴源层、明细数据整合层、数据汇总层每一层都有自己模型设计思路，在贴源层数据模型的结构一般与业务系统数据结构保持一致，仅有的变化可能在添加数据的更新时间戳；当数据仓库建设采取自上而下的数据仓库架构，则明细数据整合层会采用3NF范式建模的思路，数据汇总层一般会采用维度建模的思路；当数据仓库建设采取自下而上的数据仓库架构，则明细数据整合层和数据汇总层均会采用维度建模的思路。
关于3NF范式建模和维度建模两种建模思路的理念和方法，这里不展开；
数据仓库模型设计是一个非常哲学的话题，仁者见仁智者见智，总归还是要和业务形态和发展进程相结合，在兼顾效率如何服务好业务和模型规范两个点上做好平衡。
2.2、数据服务
在这个阶段业务同学对数据的诉求已经转向通过数据来驱动业务运营，数据同学可以通过赋能业务和产品化思维两个方向来支持业务；赋能业务是提高业务的数据技能，产品化思维是降低用户的数据应用门槛，提升效率，两者结合相得益彰。
2.2.1、赋能业务
赋能业务主要是围绕提升业务同学的数据应用技能展开，内容涵盖日常取数(基础sql语法)、制作报表、数据分析的技能，可以采取专项的数据技能培训班形式组织，在日常培训中纳入具体的业务场景让业务同学在实战中成长。
赋能业务体现的不仅仅是传道受业解惑，更重要的是在赋能的过程中，拉近与业务同学的距离，增强业务同学对数据的理解，激发他们在业务数据化运营背景下的参与感；通过数据赋能，数据化运营的主角由数据团队在背后推动变为业务团队在前方的牵引，方向目标感更强，点燃业务同学的数据火花，数据团队的角色由单纯的资源方逐渐过渡到业务同学合作伙伴，一起协同帮助业务成长。
2.2.2、产品化思维
这里的产品化思维主要是将产品运营的思路引入到日常的数据服务，核心聚焦在三个方向，分别是工具提效类、运营分析类和业务功能类。不同的产品化方向适用于不同的业务场景，但归根结底都是要从解决业务实际问题出发，切勿闭门造车；搜集业务运营过程中内、外部客户关于数据相关的诉求，梳理沉淀核心问题来选择相应的产品形态。
工具提效类的产品，通过平台化、系统化解决业务同学在数据应用过程中遇到的通用、高频类问题，提高业务同学数据应用的效率，同时解放数据研发同学的生产力，使其可以聚焦到更有价值的工作中，此类产品譬如数据运营平台、即席取数等。
运营分析类的产品：主要是围绕用户在看数以及数据分析领域，将日常业务分析决策的思路引入到报表设计开发过程中，对业务报表进行梳理整合，打造一站式看数、支撑业务数据分析的数据平台，此类产品譬如对内的各业务线的业务参谋、全链条业务监测，对外的数据管家等。
业务功能类的产品：从解决业务问题入手，充分利用数据的价值，引入孵化出基于数据为基础，算法为核心，解决业务问题为导向的数据产品，产品譬如商品价格监测平台等。
3、业务成熟阶段
在这个阶段，业务的商业模式已经稳定，业务同学对数据的诉求主要聚焦在数据如何帮助业务成长或者是如何解决实际业务中面临的问题，重要的是数据的价值和可以带来的效益；这就要求数据同学真正融入业务，理解业务痛点，把数据应用场景拓展到业务的毛细血管中，让数据在流动中发挥价值，数据化运营，帮助业务更智能，更健康。
数据驱动业务是数据化运营的重要方向，如何利用好现有积累的海量数据、大数据处理技术、丰富的数据算法模型来获取帮助业务成长的有效方法是数据同学需要重点思考的；没有固定的服务形态，在提高核心指标转化率、营收增长、风险管控、客户体验、内部提效等方面向数据要红利。
4、后记
撰写本文的初衷是对这些年数据研发/数据仓库建设工作做一个体系化的总结和思考，一家之说，不能以一概全；大数据已经是一个非常热门的话题，有时候常常思考数据到底能为业务带来什么样的价值，马总讲数据是新能源，既然定位为能源那必须要驱动业务发展方能证明自己，数据在业务发展中的价值要做到雪中送炭而不单单是锦上添花。
关于数据应用价值，曾教授曾经写过一篇关于智能商业的文章，非常受益，很好地将数据、产品、算法三者有机结合起来，创造出新的商业范式，这应该是未来大数据应用最好的方式吧！
附文章链接：http://www.pmcaff.com/article/index/2000000000010647
数据研发同学需要与时俱进，站在业务的角度，通过对数据的理解，不断拓展自己的视野和边界，技术、产品、算法，保持好奇心、主动性、勤于思考，勇于挑战！
