MarkLogic数据架构师Kurt Cagle分享了他的洞见

编者按：MarkLogic数据架构师Kurt Cagle分享了他的洞见，缺乏良好的数据收集、整理、储存过程，数据分析的结果只能是垃圾。

大约四年前，兴起了数据科学家这一不可或缺的行当。搞技术的纷纷扔掉读大学时老旧的统计学课本，花了很多时间重新学习Python Pandas和R，还有最新的机器学习理论，添置了新款的白大褂。我知道我就是这么做的。

如果你曾经是个Hadoop开发者，那数据科学也是一个好去处。毕竟所有人都以为不会map/reduce的数据科学家不是一个好数据科学家。这甚至可能延缓即将到来的Hadoop企业的崩溃到几年之后，伴随着印度程序员作坊大量炮制数以千计的新Hadoop程序员和数据科学“专家”，以赶上下一个大趋势。

公司以最高的价格为此买单。Nasdaq上的每家公司都给数据科学家开出高薪，以免因为后知后觉而受到竞争对手的冲击。同时销售经理和C开头的那些执行官也可以指望早上启动iPad后可以实时看到公司运转得有多好。控制面板曾经变成一大社会地位象征——资深的执行官享有超级奢侈的执行面板，基于3D可视化技术和实时动画散点图，而相对初级的同事得到的是2D平面版本，只有最少的总结。

然而，到目前为止，并没有什么真正的改变。数据科学家（大多数是高学历人士，在制药分析和高级材料工程这样的领域具有多年经验）将逐渐意识到，他们需要处理的数据的质量……好吧，不带任何贬低地说，糟透了。人们被引导了，相信因为他们有遍布各处的成千个数据库，因此他们的组织有海量的数据，并且大部分——如果不是全部的话——数据是有价值的。

那些数据科学家将发现，情况与此相反，大部分数据都是过时的，格式不对，数据模型适用于创建数据的程序员当时需要的应用。大量数据是在电子表格中，在缺乏任何流程、控制和远见的情况下，被反复修改。这些记录离真相很远，有太多数据是缺乏文档的一次性数据，列名会是MFGRTL3QREVPRJ之类的，键也绝对是不一致的。

换句话说，他们拥有的数据基本上对任何分析而言都毫无用处，离那些擅长制药试验日常测试结果分析的人心目中的分析更是差了十万八千里。

现在你拿着15万美元的年薪为业务代表提供控制面板，这些业务代表对统计学一无所知，但对需要百万美元和授权才能玩转的事情无能为力。你的数据杂乱不堪，还有相当多的数据完全无用，但是说服业务代表重建数据库会吓哭他们的，因为这需要几百万美元，而且看起来并不必要。你当然可以直接向他们撒谎，草草装配一个随机数生成器，说不定提供给他们的数据还比他们知道得要准确一点。但和数据打交道的人可不习惯撒谎，因为这和他们的基本目标——尽可能地精确背道而驰。那么你会怎么做？

现在我得戴上我语义布道师的帽子，告诉你应该开发一个语义数据仓库。你真的应该这么干，它并不没有那么难，却能提供一些实实在在的收益。不过我也会说它不是一个魔法般的解决方案。它让你更容易以易于处理的格式获取数据（或者有助于查明哪些数据是垃圾，可以直接删除）。然而，现实是，这并不是一个数据科学问题——这是一个数据品质和本体工程问题。

所以，让我说得更清楚一点，让那些穿着执行官的衣服的人也可以理解。你有数据问题。你的数据科学家具备各种有用的工具可以呈上数据分析的结果，然而没有优质的数据，他们产出的东西完全是无意义的。这不是他们的错。这是你的错，你期望酷炫的控制面板能为你赢得一千万美元的合同的每一天，都是在浪费时间，都是看着钱从你那里流走的一天。

你的工作可不简单。你需要做的是首先确定你实际需要追踪的信息，接着花时间和你的数据科学家以及数据本体学家（data ontologist）讨论下需要哪些数据。别指望指着一个数据库，然后数据会魔法般地出现在那里。

数据库总的来说是让程序员用来编写应用的，而不是提供公司内部的深层测度的。坐下来查看下你现在具备的资源，你需要理解那些依赖这些数据库完成他们的工作的人会非常不情愿给你访问权限，特别是这些权限可能导致他们担责的时候。此外，你还需理解大多数数据库的文档都很糟糕（这已经算好的了，其实大多数数据库根本没有文档），因此需要基于隐晦的参考进行侦破。这称为病理计算，大多数程序员都讨厌干这个，因为这意味着猜测其他程序员的大脑，这些程序员很可能已经离职了，水平不明，忘记了十年写的东西是什么意思。

关系数据湖（relational data lake）并没有解决这个问题。数据湖解决的问题是让同一个主机可以访问所有数据。对于病理计算而言，这是必要的部分，但它既不是最难的部分，也不是最昂贵的部分。最昂贵的部分是搞明白数据到底意味着什么，甚至仅仅是识别出分散的数据集谈论的同一件事。这一问题没有现成的解决方案，如果任何人告诉你有，那他们在忽悠你。

我要再一次植入语义方案的广告——graph triple store、RDF、ontology management等等。这些不是开箱即用的解决方案，却是使病理分析得以实行的工具，并能将管理这些过程的手段交到程序员手中。

然而，你需要理解，这一切经常需要你重新思考数据流的整个流程，理解在一开始如何捕获信息并及早传入合适的管道。它需要你的程序员和数据库管理员放弃部分自治，基于一个中央化的联合存储工作。它也意味着你作为执行官需要更熟悉数据管理和数据来源。

对大多数商业人员而言，这都是一个相当激进的转变，比让部分商业人员做一些IT工作要激进得多。然而，今天的商业正在转变（大部分已经转变）为碰巧销售货物或服务的数据管理公司。比起管理销售，今天的CEO的角色需要更多地关注所在组织的数据输入和输出，确保数据的品质尽可能好。这并不仅仅是为了应对合规性要求，而是因为数据的完整性对这些公司在市场上的成功至关重要。

这意味着你需要和你的执行数据团队确定你需要知道和想要知道的信息的范围，以及哪些信息是无关的，然后确立必要的流程收集和商业需求相关的数据。直接指向数据库的一个接口，提取它的内容，除了增加磁盘存储开销外毫无影响，雇佣数据科学家分析垃圾数据只会产生垃圾分析。如果你在意的话，它可能很美观，充斥着梯度和3D特效，但毫无作用。