任何成规模的公司，都会有很多数据岗位，例如：数据开发工程师、数据仓开工程师、数据分析师、数据挖掘工程师、数据产品经理、数据运营工程师、数据运维工程师。不同的岗位对数据的认知不同，对数据的定位不同，对数据的关注点不同。那么是否有一套内容可以分享出来，大家对数据的共同认识的基本点？不同岗位对数据认识的不同点是什么？数据开发同学有没有必要去了解数据分析师关心的数据？数据产品经理更看重什么样的数据？本篇文章和大家分享10年的大数据开发管理经验。
先抛出几个问题，看看大家对数据的掌握程度
- 每天的数据增量是多大？
- 目前公司的数据集群有多少台机器？
- 整个数据规模是多大？
- 每年的数据是什么样的增长模式？
- 公司的核心数据是什么，核心数据的分布情况怎么样？
- 数据仓库接入的业务部门有哪些？每个部门的数据是怎么分布的？
如果你的领导哪天跟你聊天的时候，向你提出这些问题。恰恰你不知道，或者只知道一部分，那么给领导的印象是：你就是个干活的，没有大局观，暂时还不能委以重任。如果你对这些问题都能对答如流，那么可能还有接下来的新问题。
- 如果你知道每天的数据增量是多大，那么工作日数据的波动是多大呢？设置多大的预警阈值监控报警比较合适呢？
- 目前这些数据集群的节点是怎么分布的呢？还有多少空额可以用？为什么总有人说机器不够用呢？
- 如果你知道目前的数据规模，那么这些数据是压缩前还是压缩后呢？压缩比是多少呢？怎么压缩的，采用的什么算法，是否还有更好的算法能提高压缩比？为什么不采用？
- 如果你知道之前每年的数据增长量，那么你知道为了一年我们将要增加多少台机器呢？
- 你知道数据的分布情况，那么我们通常采用的维度分析有哪些呢？按照地域？年龄段？兴趣点？还有没有其他呢？
- 如果你知道数据仓库一共接入了哪些业务方，那么你清楚每个业务方之间有哪些公用的数据吗？他们公用的一致性指标有哪些，我们是怎么建立的？
数据链路
每个岗位都有自己的认知
公司的数据团队越大，相应的数据岗位就越多。如果是数据开发和数据仓开工程师，他们关注点也会有所不同。数据仓库工程师更关注的是数据仓库的分层设计、数据维度定义、数据主题的设立；数据开发工程师更关注的是数据的接入方式，数据性能的优化，数据存储结构的选型。数据运维工程师更关注的是怎么保证数据的稳定性。数据运营和数据产品经理更关注的是如何从既有的数据中提取有价值的数据，做真正的数据赋能。
- 数据开发工程师肯定知道目前接入的业务方数据有哪些，有哪些数据还没有接入，每天每个业务方接入的数据量有多大，所有业务方整体的接入数据有多少，接入数据的形式有哪些（json、text、图片、视频）。数据的生命周期有哪些（30天、90天的数据表有哪些），集群中日增量数据有多大，目前的集群规模是多少，还有多久会数据爆炸？
- 数据仓开工程师对上面的事情知道的就没有这么明确，他们只关心自己在数据建模过程中会用到哪些数据，数据的分布情况。比如按照地域、性别、爱好进行分类。他们还关注的就是数据计算口径，如果数仓出的数据和原始数据的规则不一致，那么数仓的可用性就大打折扣。
- 数据仓库工程师更关注，某一天落地的数据某个维度的数据急剧下降（上升）或者清0，那么会不会有问题呢？如果数据剧增（肯定会导致数据倾斜，怎么处理）。
- 数据开发工程师还有个更要关注的点，数据是否延迟，数据如果延迟，什么时候能补完全部数据。
如何掌握数据接入量
不能闷着头干活，来个需求就接，而自己对数据却一无所知。如果是这样，那你确实得早做打算，如果哪天领导向你咨询前面我提到的问题，咱们的集群有多大？目前使用率有多少？接入了哪些业务方？数据的日增量是多少？核心的业务的数据量是多大？按照目前的数据接入速度，我们的集群还能撑多久，多久要加多少台机器呢？
集群使用量统计
数据的核心维度分布
所谓核心维度就是日常中经常用到的维度，领导和产品经理关心的维度。比如用户的兴趣爱好，地域分布，或者基于用户画像表做的维度信息。
数据质量监控
同比：“同比”就是同期相比的意思，一般指今年的某月和去年的同一个月份相比。
环比：以一个周期为一环，比如本月环比上月。
数据质量
数据血缘关系
数据血缘可以理解为某张表或者某个业务数据的生成过程，它依赖了哪些表，这些表的依赖层级关系。掌握了血缘关系，我们才能更好的使用数据，一旦某张表的数据有问题，我们可以根据血缘关系查到下游所有被影响到的指标。以便顺利修正问题。
数据血缘关系会帮助大家更加容易的理解数据，知道数据的俩龙去脉。
