【独家】首席数据官–数据产品和数据服务的总设计师

文|Dr. Chris Zhao 乐加信息科技首席数据官，数据仓库架构师，商业智能数据分析专家，普林斯顿数学博士。

168大数据特聘首席数据官，此文是168大数据独家首发，其他机构未经允许禁止转载。

        数据和分析推动各行各业不断转型升级。我们如何梳理清洗庞大的又脏又乱的数据，降低数据冗余度，提升数据的质量（Quality & Integrity）？ 如何促进 Web 应用和移动应用的个性化？我们如何改善客户在使用我们的各种渠道时的体验？天气情况和商品的摆放和搭配如何影响商店的销售？非结构化数据是否能够帮助我们提高预测风险和欺诈的能力？如何利用数据降低企业运营成本？

        世界各地的企业都在苦苦寻找上述类似问题的答案，并且时不我待，他们必须尽快找到答案，在竞争中占得先机，引领市场需求。首席信息官 (CIO)、首席运营官 (COO)和其他业务领导在这个方面基本上是单打独斗，完成更大的企业目标中各自承担的责任。但是，许多企业发现，这种零敲碎打的做法无法创造出大数据与分析预期的变革性价值。因为每个人都在搞数据和分析，甚至一些业务人员和非数据分析专业的编程人员也在搞，缺乏整体战略和统一责任制。因此，数据通常在“睡大觉”，或作用无法得到充分发挥。在这方面仍表现出各自为战的局面，通常由职能部门执行分析，而不是推动整个企业范围的发掘新领域和实现创新。决策仍是凭直觉和经验做出，或是根据简单的OLTP层面的数据处理分析、而不是根据深入的OLAP层面以及数据挖掘层面的分析洞察而做出。

由于新商机的出现，催生出新的最高层主管角色 - 首席数据官 (CDO)。作为变革的引领人，CDO 根据企业数据战略调动企业各方面的力量，创新数据使用方式，建立更大程度上由数据推动的创新，通过数据产品和数据服务更好的为企业创造价值。

       因此，首席数据官 (CDO) 应运而生。许多关于 CDO 的白皮书都强调数据监管和技术应用的重要性。CDO 需要肩负更多的使命：指导企业如何对数据进行架构设计、分析数据以及根据数据采取行动。为此，CDO 必须成为变革的引领人，推广由数据推动的方法。

       为了更好地了解这个不断发展、不断变化的新角色，我根据自己作为首席数据官的经历，撰写一点内容与大家分享一下我对这个角色的看法和观点，并引用一些自己在线上的所闻所读，解答大部分企业所关心的话题和问题。匆忙之间，一气呵成，难免有挂一漏万和不足之处，欢迎来信批评指正。

CDO需要具备什么能力、会做些什么、能给企业带来什么价值？

       首先CDO既要懂技术、又要有数据分析能力，还要有数据和业务的敏锐（Acumen）、又能构思数据产品和服务。CDO 可以将企业决策层的需求和目标转化为有效的解决方案。一个成功的 CDO 不仅要了解数据和分析的技术方面，还要能构想新的方法，以便满足业务需求，实现业务价值。

      CDO 需要具备三个方面的能力：

l  为企业构想并指导制定总体数据和分析战略。

l  通过使用数据和分析，激发变革，创造更大的价值，促进业务发展。

l  转变企业文化，重视分析的作用。

       一个CDO需要掌握的最重要的语言不是R, Python, SAS, SQL, NoSQL, MDX, Java, C++, … 等开发和分析语言，而是Business语言。（见《The one language a Data Scientist must master》作者 Matt Reaney） 进入一个新的业务领域，CDO需要像海绵那样快速的吸收并掌握足够的业务领域知识、业务逻辑和需求，能用业务语言毫无障碍的跟业务人员和业务经理交流沟通，想他们所想，心系他们的诉求。

       另外，数据管理、质量和完整性问题导致的风险是将 CDO 角色提升至最高管理层的“催化剂”。CDO 好比“乐队指挥”、或“数据领航者”。CDO 为企业提供有关如何将数据视为资产的战略指导，构想并协调企业愿景。

CDO 站在企业的高度看待数据和分析，在客户、市场、企业流程以及合规性方面发现新模式并提出新见解。当各个彼此隔离的业务部门中采集上来却在睡大觉的数据整合在一起发挥作用时，现代数据分析的真实价值便会显现出来。

       CDO 能够在繁复浩瀚的数据中准确辨别商机，这正是他们的与众不同之处。CDO 的职责不再仅仅局限于传统的数据工作，而是致力于为企业谋求新的价值增长点，从而提高企业竞争力。他们的工作不仅能够帮助企业快速实现投资回报，而且能够建立创造长期价值的平台。

       例如，CDO 不会只盯着现有数据，而是努力发掘企业内外新的数据源，以新的方式组合数据，提出问题，从而帮助他们的企业发现新的商机，在市场竞争中立于不败之地。

       另外，CDO 重要价值之一在于他们能够拉近数据和数据消费者的距离。我所说的数据消费者指的是数据分析结果（包括产品和服务）的享受者，这些人包括企业高管、市场营销经理、和终端客户、等等。通过发现创新的数据使用方法，尤其是移动及社交技术中新的数据流，CDO 可以帮助企业更好地了解客户体验，预测客户行为，从而最终建立更加稳固的客户关系。

例如CDO在研究了 CMO 的数据库后，就能够给他们讲解他们此前一无所知的信息，比如“客户究竟有什么样的特征，客户究竟想要什么样的产品，他们会做出怎样的购买行为。”

       CDO 还可以帮助企业将决策模式由直觉经验型转变为分析推动型 。这既是 CDO 面临的最大挑战，同时也是他们影响企业的最大机遇。人们往往会依赖以往经验，凭直觉作出决策，但 CDO 会利用数据纠正人们的这种主观偏差。这种转变让大家清楚地看到了数据背后巨大的业务价值。

       CDO 加入最高层主管队伍，有助于企业获得大数据和分析带来的持续、变革性的商业价值。CDO 作为企业内掌管数据和分析工作的第一把手，具备专业技术和业务知识，可帮助企业有效利用数据。CDO利用数据分析积极影响业务，激发企业变革，重塑企业文化，帮助企业的决策模式由直觉型转变为分析推动型。由数据推动的企业可以重新构想自己的业务，实现竞争优势。最后，CDO 会制定全面、系统的方法以用于管理数据和分析，实现企业中数据的复用，并简化数据流程和集成。CDO 和非 CDO高管一致同意制定统一的战略方针，促进“持续的、持久的竞争优势”。

很多企业关心的问题和普遍的错误认识（Misconception）

     “我们的数据分散在各个系统和服务器，冗余很大，也有很多质量问题。例如很多字段的内容由于手工输入存在差错，或者是空白。数据结构设计也存在一些问题。等我们内部把数据整合梳理好了，把这些问题都解决了，再考虑雇一个数据专家或CDO。”

       这是一个明显的misconception。因为一个数据专家或CDO首当其冲应是一个数据架构师，整合数据、梳理数据、提升数据质量、解决数据架构问题本身就是一个数据专家或CDO所需要做的事情。再者，数据日积月累越来越庞大，“等公司内部把数据整合梳理好了”的愿望就如同大多数世人：“等我挣了足够的钱”的愿望一样可望而不可及。在这种情况下，企业必须借助于数据专家或CDO的力量。

     “我们建了一些数据集市和数据仓库，但不知道下一步做什么，也没有看出数据仓库能给我们带来什么价值。现在的分析报告是直接通过数据仓库里的数据而产生的。”

        这就是企业普遍面临的一个困惑。很多企业缺少数据仓库专家，缺少真正懂ETL、OLAP和数据挖掘分析的开发人员，于是照着书本设计创建了数据集市和数据仓库，当然就不知道下一步怎么走了。因为他们本末倒置了。数据集市和数据仓库的设计是根据OLAP的需求和数据挖掘分析的需求来设计，而OLAP的需求和数据挖掘分析的需求是根据业务需求而来的。顺序不能颠倒。

再者，很多时候企业创建了数据仓库，却没有OLAP和数据挖掘分析，于是分析报表直接从数据仓库里读取数据，完全跳过了OLAP和数据挖掘，这样一来，不仅整个系统的performance很慢，而且产生分析报表的那些SQL代码或前端代码是相当的繁琐和累赘，enhancement 和maintenance的人力成本是相当的高。Why? 因为本该属于OLAP和数据挖掘层面的逻辑却在OLTP层面去实现，那当然很别扭。

        没有OLAP和数据挖掘分析，数据仓库失去了其主要目的，创建它是没有多大意义的。

        我曾经与一个客户开会，了解他们的数据仓库和OLAP的开发实施情况。他们雇了一个没有什么经验的人，边学OLAP / MDX边做，碰到很多任务做不出来或者效果不如意，最后怪罪OLAP / MDX技术，说OLAP / MDX不适合他们。我追究其中一个具体的问题，想弄明白为什么得出结论OLAP / MDX不适合他们，才发现那个人用SQL的思路写MDX代码，就如同一个人用中国象棋的规则去下国际象棋，自然会有很多frustration，于是才错误的认为OLAP / MDX不适合他们。

这件事情也促成了我后来思考和创立出来的SGCS (Solution Guaranteed Consulting Service) 服务模式。在这种模式下，我先了解客户遇到的一个具体问题或挑战。只有当我彻底解决了，客户才支付我的Consulting费用，否则客户不需要支付一分钱。技术虽然服务于业务，但不是万能的，总有它的limitation。有些时候就是没解，我可能投入了一些时间精力，但没有结果就没有pay，这种风险我自己承担。

        我的另外一个Consulting服务模式也因此事而诞生，那就是CCTS (Consulting Combined with Training Service) 服务模式，就是在为客户做项目干活的同时，通过mentor、coach、指导和培训的形式 – 如同一个研究生导师培养研究生那样 - 为客户招聘培养几个人出来。在培训方面，我就借鉴了我以前创办一家培训学校时所采取的HOPT培训方法（见另一篇关于HOPT的文章）。

“我们正在选择是创建数据仓库好呢，还是创建hadoop系统更好。考虑到Hadoop来势凶猛，更新更时髦，我们准备舍弃数据仓库模式，采用Hadoop大数据系统。”

        这是一个完全错误的认识。新的Technology层出不穷，不是每一个旧的Technology都能被新的Technology取代。我曾经在新泽西接手一个BI项目，客户要用OLAP / MDX 的手段去满足各种分析报表的需求。我深入到这个项目中之后发现，95%以上的分析报表的逻辑都是属于OLTP / SQL的。固然BI / OLAP / MDX比DB / OLTP / SQL更新颖，但他们是互补的，各有自己的优势。盲目的赶时髦、追捧新的技术，以为新的技术可以取代老的技术，那是非常错误的。

       那个新泽西的BI项目，我只干了几周就请辞了。一方面我劝他们不听，另一方面，我不认为我的BI专长能给他们带来价值。作为一名Professional Consultant，我不能明知错误却仍拿着客户的钱将错就错下去。最后那个项目以失败告终，被推倒重来。反而我的早期离开帮他们减少了一些资金的浪费（尽管他们不差钱）。

       同样的，在数据仓库和Hadoop之间，不存在谁替代谁的问题。他们各有他们的优势和劣势。到底采用哪一个，完全看具体情况。最主要的是看这几个方面：

1.      Data：现有的数据量、数据品种、数据状况、每天递增的数据量和数据状况；

2.      Business：业务诉求、业务逻辑和数据分析需求。

3.      Latency & Concurrency：对实时性和并发性的要求

4.      Deployment & Deliverable：部署和交付的结果

有时候，你可能两者都需要。关于数据仓库和Hadoop之间的比较，网上可以搜索到很多文章。在此，我推荐两篇文章：

No, Hadoop Isn’t Going To Replace Your Data Warehouse

http://timoelliott.com/blog/2014/04/no-hadoop-isnt-going-to-replace-your-data-warehouse.html

Hadoop vs Data Warehouse: Apples & Oranges?

http://data-informed.com/hadoop-vs-data-warehouse-comparing-apples-oranges/

     “我们知道不能让数据躺在那里睡大觉，我们也想盘活数据，充分的利用数据为企业创造价值，可我们现在腾不出人力团队来配合你做这件事情。”

       我常常把CDO比作大厨。给我食物材料（原始数据）- 不管多脏多乱，告诉我你们想吃什么（业务需求和诉求），我来给你们做一桌宴席（分析结果和展现）。从又脏又乱的众多材料（庞大原始数据），到一桌宴席（分析结果和展现），中间要做很多工作。有工作人员配合，当然最好。没有，我一个人也完全可以搞定。

        在美国，一个数据团队会有这些工作角色：Database Designer / Developer, DBA, Data Architect, SQL Programmer, ETL Developer, OLAP Designer / Developer, MDX Coder, Data Mining Developer, Algorithm Developer, Report Developer, Data Scientist, Business Analyst, User Rep, Project Manager。所有这些角色，我都深入的经历过。正因如此，一些客户项目为了节省成本，只雇我一个人作为Consultant，承担多个角色，从又脏又乱的原始数据开始，过滤、清洗、处理、转换、建模、挖掘、分析、预测，以及分析结果的展现和分析报表的开发，从构思、设计、到开发、测试、再到部署、维护和管理，以及用户支持，再到整个流程的部署和自动化，全由我一个人动手完成。这些项目经历把我锻炼成了一个“One Man Team”。

        通常当我接手一个新的数据项目，我努力对涉及到的业务领域知识吃深吃透。我先初步了解业务需求，然后开始探索数据。对于结构化的关系型数据，那就是了解每个表每个字段的业务含义。如果客户能提供数据词典，那就很有帮助，否则我就需要他们委派给我一个熟悉每个字段业务含义和业务逻辑的人，以便他能随时解答我的疑问。我并不需要占用他的100%时间。可能第一天我会占用他的50%时间，第二天占用他的30%时间。以后用到他的时间就会越来越少。

         由于深入到数据以及业务知识，我能创造性的产生自己的洞察和见解。所以我做过的很多项目到最后衍生出新的30 ~ 40%的业务需求，那就是来自于我的见解、思想和发挥。而这些新的见解和需求是客户未曾想到过的，但却是他们喜欢或想要的。再用大厨的比喻，你可能食欲不好，不知道吃什么好。因为我很了解你的肠胃和口味（业务逻辑和需求）并熟悉现有的食物材料（数据），有些菜没有，我甚至可以去买（采集新的数据源），于是我做出了一桌让你惊喜合你口味的菜（分析结果和展现），你的食欲（业绩）大增。

     “我们是中小型公司，承担不起一个CDO的全职薪水。”

        那就以专家顾问（Consultant）的形式雇一个CDO，只在用他的时候支付报酬。很多北美企业喜欢雇用Consultant。为什么呢？因为雇用employee的风险在于：您付出了成本（薪水、福利、培养等）却没有得到相应的productivity和results，可能得到了过程和一些进展。一旦换人，这些所谓的进展可能毫无利用之处，于是新的employee必须从头开始。雇用consultant从根本上保证了您的付出一定会得到productivity和results，因为没有productivity和results就等于consultant没有完成合同。雇Consultant还有另一个重要的好处。有些时候有些角色只是基于一段时间的需要，你没必要一辈子养着这个人。数据梳理好了，产品成型了，或者事情做完了，你不需要他了，就可以让他走人，或者把每周五天的需求降为每周一天的需求，你可以随意，没有任何顾虑、负担和累赘。倘若他是你的employee，你若这样随意，不仅会惹来麻烦，甚至还可能惹来官司。我在瑞士信贷做项目的时候，才知道他们的员工每年要维持一定比例以上的Consultant。