在数据开发领域做了两年左右的时间，因为工作原因，视野只是集中在离线数仓搭建这一小块内容上。两年时间并没有看到更多广阔的发展空间，导致数据开发的工作面越来越窄。为了扭转这个局面，特写此文从宏观上去重新审视这个领域的机会点在哪里。
分析框架：从得到APP上舶来的“点线面体”分析视角。个人理解，每提升一个维度，都应该有给上一维度“赋能”的能力。
一张图概括
graph TD
A[数据集成]-->C;
B[数据开发]-->C;
K[数据质量]-->C;
L[数据安全]-->C;
M[数据服务]-->C;
C[离线数据生产线]-->E;
O[实时PV]-->D
I[实时UV]-->D
D[实时数据生产线]-->E;
E[存储和查询: 数仓理论体系]-->Z
F[挖掘关系:知识图谱]-->Z
J[挖掘能力:机器学习]-->Z
Z[数据价值]
点
点是最具体的，可以直接交付的产品。 对应到数据仓库开发，就是一个一个具体的指标，离线的 or 实时的。其它领域了解不深入，需要找专家补充。
线
线应该是点的串联而不是点的和。 在数据开发领域，对应的就是离线生产线上的一层层的表以及任务调度系统，它们串联了所有的数据指标需求，又抽象了业务实体表，为不同的指标提供统一的数据源。
面
面既要向上赋能，又是体的组成部分。 这一层是理论沉淀最多的一层，每一个“面”都应该能独立地为其上的“点”组成的生态赋能。数据仓库建设的一些规范和原则算是这一层的，它保障了无论业务多么复杂，数据都能被合理地（最小认知负担，最小沟通成功，最小存储成本）存储和组织。
体
体是整个问题域。 “体”定义了问题的边界，一个“体”的沉浮决定了以上几个维度是否还有讨论的必要。在数据开发领域体现为：数据到底有没有价值？体现在哪？是否被不懂数据的人认可？
数据的价值和数据技术的价值
提到“数据价值”，心里还是有点慌的，因为大多数人心里的数据并没什么具体的价值，在他们眼里，只不过是年终的一份数据报告，或者一个可以查更多数据的“MySQL”而已。
数据技术更是被认为搭一下Hadoop，然后写各种长SQL出报表就是全部能力了。
大部分时候，这可能是现状，但这不应该是全部。
数据的价值在于可以从非业务的视角去看业务，给出“原来还可以这么做！（e.g. AlphaGo / Zero）”“原来A和B之间有一层这样的关系！（e.g. 协同过滤推荐）”这样的答案。只有做到这些，才算是“数据”提供了独有的价值，否则为什么要再去存储这么多的历史数据？
数据技术也是一样，应该先具备数据的视角和数据处理能力，然后用数据的能力去解决业务同学靠勤奋都不能解决的问题。而不是本末倒置，没技术没视角，天天钻业务细节，最后只能给对应的业务线一些众所周知、隔靴搔痒的建议。业务团队不需要多一个特别懂业务的人，团队需要的是能站在新的视角，发现和解决那些业务团队再勤奋也会忽视的问题的人。这才是数据技术的价值所在。
