为什么数据管理工作很难成功？

摘要：人才始终是数据管理的第一要务。

大数据时代的到来，大家开始将数据当成资产，数据管理的意义也越来越大，但很多企业的数据管理工作，都难言成功，为什么？首先来看下数据管理的定义：

数据管理，即对数据资源的管理。按照DAMA的定义：“数据资源管理，致力于发展处理企业数据生命周期的适当的建构、策略、实践和程序”。这是一个高层而包含广泛的定义，而并不一定直接涉及数据管理的具体操作（摘自维基百科）。 与百度百科的定义比较，百度百科的定义针对的是数据应用过程中数据的管理，即传统的数据管理。 而维基百科的定义更高一层，针对的是企业数据全生命周期所涉及应用过程数据的管理，即对数据变化的管理，或者说是针对描述数据的数据（元数据）的管理，在此我们称之为面向应用的数据管理。

定义强调了数据管理的手段，但数据管理的最终目的是什么呢？虽然当前如DAMA等的数据管理书不少，但考虑到数据管理体系太过庞大，看这类书往往如盲人摸象，抓不到头绪。

笔者刚接触数据管理的时候，也是云里雾里，本文纯粹是个人的一点实践和主观看法，没有高大上的东西，视野也比较狭隘，算是抛砖引玉，实际上，每个企业都应该建立适合自己的数据管理体系。

首先，为什么要做数据管理？

个人认为，数据管理的目的就是让数据变现高效低成本的运作，正如企业管理一样，因此，没想清楚之前，不要盲目开展一个数据管理项目，更不要盲目采购数据管理产品，首先得问问，做这个事情，能带来什么价值？

那么，何谓高效低成本运作？

首先，要认识到每个数据的实际价值，即哪些核心业务与这些数据，这是定方向，其次，安排好数据优先级，确保正常出数，最后，淘汰过时和无用的数据，即以最小的代价带给业务最大的价值。

这个认识很重要，记得笔者刚开始做元数据管理的时候，是很盲目的，主要致力于工具的考虑，而未深究做事的本质，导致做了大量性价比很低的事情，比如总想着如何进一步提升SQL解析能力，将其作为系统成功的第一要务，但这个真的是最重要的吗？

数据管理，不是为了管理而管理，没有明确的目的，就不要开展数据管理工作。很多人谈到数据管理这类基础工作很难开展，比如领导不理解，做事没成效，原因往往是自己都说不清楚缘由，这为数据管理工作的失败埋下了祸根。

但有了目的和方向还不够。

搞数据的，做事量化是根本，无数据，不管理，数据管理工作，也需要用数据来决策。

以下举例：

数据模型的应用价值KPI-比如模型提供了哪些间接收入，规则可以自己定，但指标要能反映模型对于应用的支撑能力

数据模型的提供能力KPI-比如模型及时正常出数的情况，要能反映模型的及时率及正确率，是衡量运营能力的一组标准

数据模型的优胜劣汰KPI-比如关注投资效益比，要关注数据的生命周期管理，投资当然需要，但也要懂得节省，该转移或删除的数据，就要坚决的执行，一张每天10万数据的临时小表，一年就是3千多万，如果有100张，那也是不小的投资，家里有余粮，也不能滥用。

明确了目标和衡量指标，接下来就要制定一系列的规范和制度，所谓无规矩不成方圆。

数据管理规章制定很难，在起步的时候，不要东订一个，西订一个，最好的建制方式是围绕目标边制定边实践，没有最好的制度，只有适合自己的。

下面先做一个衡量数据管理能力的评估题目，注意回答不要泛泛而谈，一要量化，二要靠机器回答，三要半小时内回答。

能否直接给出每张表对于数据变现的价值？或假如这张表不出，会带来多少潜在损失？（虚拟指标都可以）。 能否直接给出每张表的运行质量报告？能否根据优先级给出运行优化的具体建议？ 哪些表能直接下线？

你会发现，要能回答这些问题，不仅仅是建个数据管理系统那么简单，需要制定对应的数据管理的规范和标准。

如果需要知道每张表对于数据变现的价值，必须有应用跟表的关系，因此，开发上线的时候必须制定规范，起码要提交映射关系，同时为了防止两张皮现象，必须依赖自动化的系统。

如果需要知道每张表的数据质量报告，必须制定相关的质量指标，并能够及时预警和处理，这个需要一套数据质量监控制度。

如果需要确定哪些表能直接下线，必须制定一套数据表生命周期管理制度，需要有表的比如血缘和影响分析，否则怎么知道有多大影响？

如果要让运维人员知道这些表谁是谁，则必须有好的数据字典，明确表命名规范和口径定义，以降低管理成本。

如果….

你看，所有的数据管理规章制度其实都是为了确保目的达成，由此会延伸出一个庞大的数据管理体系，但还是要懂得能抓住本质。因为一开始，不可能想到这么多，能做这么多，需从本源开始思考从何入手。

以下是XX公司制定的相关数据管理规范。

说完制度，接下来就提到数据管理工具了。

它是数据管理规范贯彻落地的强大保障，当前工具越来越重要，笔者的一个经验是，数据管理领域，很难靠人肉保障，大多不靠谱且不可持续，如果面对大数据，更加难以管理成功。

谈一个亲身的经历，曾经上线了一个ETL产品，然后项目经理告诉一切运行OK，然后我说每个接口的运行报告给一个看看，项目经理说报表拿不出来，因为产品没有这个统计功能，人肉看了几个大致没问题，然后全量核查发现，30%的接口有一致性问题，就是因为当时现场少了一个系统统计功能。

另数据管理的可视化其实也很重要，ETL任务多达上千个，因此，快速判断任务是否运行成功很重要，以前，管理者拿到的是运维者的报告，但里面可能是有水分的，某天我们做了运维可视化，发现运行情况远没有报告所称的那么理想，任务大量失败而挂起，运维疲于奔命去处理问题，而后提交一个完美的报告，而管理者还以为一切OK，冰山下隐藏的问题，远远超过管理者看到的冰山一角。

当前数据管理的产品不少，但很多其实难以达到要求，原因很简单，数据管理工具太靠近上游，越靠近用户的产品其实越难做抽象，也越难成功。比如一些元数据管理工具，很难解决产品中的元数据跟生产系统元数据两张皮的现象。

因此，笔者更倾向于采用半定制化的产品的，甚至认为，数据管理产品是偏垂直行业的，阿里以前发布了“数加”大数据系列产品，但其数据管理产品很难作为单独实体获得成功，只能平台捆绑。

怎么才算是好的数据管理工具呢？

个人认为是能够将数据管理能力渗透到数据生产流程中去。

比如以前生产建表，是开发人员写代码建表，虽然建表有规范，但开发人员是否执行是另外一回事，而且建表注释写得乱七八糟，往往需要靠事后稽核，但大家都知道这很不靠谱，现在，我提供一个可视化开发界面，将建表规范作为规则纳入系统，强制要求开发人员在该界面上建表，只要不符合规范就予以拒绝，比如注释缺乏，未有分区键，字段定义长度不符，字段命名不符等等。

如果有可能，将所有的数据管理规范提炼成规则，都纳入到系统中强制执行，数据管理就能实现与生产系统的无缝衔接，数据管理成为生产的一部分。

前面提到的很多元数据管理等工具之所以难以成功，往往因为它是一个外挂系统，所有的信息需要事后喂给它，而不是强制的，导致与生产系统变得越来越不一致从而失去信任直至死亡。

有人会质疑这对于数据管理平台要求太高，对于开发约束太多，存量改造太困难，的确，这些都是问题，数据管理本来就是个难度极高的工作，不做当然也可以，反正也能活，最多运维质量低一点，人肉多一点。

但如果希望更进一步，就需要付出代价，近和远，长痛还是短痛，还是需要依据企业的实际情况自己作出选择。

现在这类数据管理产品也逐步显现，比如亚信的DACP（不是做广告）等，也在往这个方向演进，提供从数据规划、定义、开发、预警、调度、安全等全套功能，并且具备跨平台的透明访问能力，我前面提到的半定制化就是指这类产品还需要不断根据客户要求去新增功能，比如H B A S E，R E D I S等各类组件的接入能力。

DACP这类产品，似乎也秉承了开发运维一体化（DevOps）的概念，在开发阶段就开始考虑数据运维中的大量问题，所以它能去做，也跟数据开发的一些特点相关，比如大多数据开发都遵循表-代码-表-代码这种逻辑，相对于其它领域要简单的多，而且，在开发和运维天生的矛盾中，也似乎能达到一种微妙的平衡，毕竟，做数据开发的，本身会非常关注业务和数据定义，而做数据运维的，理解业务往往也是必须的，毕竟要做大量数据稽核。

数据管理工具是种辅助手段，是否采用，采用哪种，都依赖于企业基于性价比去做选择。

接下来，提一个关键的一点，即管理者的态度。

数据管理是个系统工程，你去看DAMA，DIMM等内容，都将其上升到企业战略这个层面去谈，但企业即使有了数据战略又如何，再好的规划也赶不上变化。

管理者始终关注的是效益，数据管理也不例外，因此，说服管理者，也应该坚持“效益导向，能力建设”的原则，坚持向数据要收益，比如一个企业，垃圾数据和冗余数据占据了很多空间，做好这类管理可以省一大笔钱，核查问题也一样，原来看文档抓人，现在查系统，哪个更有效？现在IT企业人来人往，没个知识库，系统重翻或新人培养，代价有多大大家都清楚的很。

数据管理也涉及企业很多流程的再造和新机制的建立，比如规范开发流程，影响也是全方面的，必须获得管理者的支持，否则举步维艰。

最后，还是要提一下人。

这个是最最重要的是，数据管理是个专业化的工作，需要专门的人沉下心去做这个事，不要搞什么兼职（估计是常态吧），那也是扯淡的事情，一个数据管理项目的失败，往往是自己投入不足，坚持不足所致。

人才始终是数据管理的第一要务。