2.3 大数据战略的落地

如果企业在云原生数字化应用运营一段时间后，建立了持续创新的文化并积累了一定数量的数据，就可以考虑建立基于大数据且由AI驱动的高阶数字化战略。在第二代平台时代，企业部署IT系统的时候通常会有咨询公司提供同行的成熟案例。企业只要把同行成功实施的软件大体不变地安装下来，再加入少量定制功能即可。而在基于大数据和由AI驱动的高阶数字化战略中，不能照搬同行的成熟案例和经验。首先，行业领袖的数字化软件基本上是在PaaS平台自主开发的，它的软件不能被拷贝。即使可以拷贝，它的软件的升级速度也使得拷贝版本很难跟上。其次，企业的高阶数字化战略的输出通常是训练过的并且符合自身需要的数学模型的参数。即使将这些模型和参数拷贝到自己的企业，也与企业的核心优势不匹配。那么，成功地将高阶数字化战略落地的企业案例是否可以被学习呢？答案是依然可以，但需要进行更高层次的抽象，学习这些大数据企业高阶数字化战略成功背后的“元数据”。所谓元数据，是数据库里面描述其他数据的数据。本节将讨论高阶数字化战略成功背后的元数据：

❏大数据和AI人才

❏AI驱动的开发方法和文化

❏大数据基础设施

一旦企业建立了基于这些元数据的数字化战略，就能在基于大数据的智能应用上推陈出新并持续创新。

2.3.1 大数据和AI人才

第一阶段的数字化应用开发的主角是软件工程师。他们可以根据数字化业务的需求，在PaaS云上采用云原生的方式持续迭代应用开发。进入基于大数据和AI的高阶数字化阶段以后，企业需要引入两个新的角色：数据工程师（Data Engineer）和数据科学家（Data Scientist）。

数据工程师主要负责企业大数据基础设施的建设以及企业内部数据的收集。这个角色和传统的DBA角色类似，但是比起传统的DBA，他们管理的数据基础设施的规模更大，采集的数据量更大。更明确地说，传统DBA一般管理Oracle、MySQL和PostgreSQL等关系数据库系统下的事务型数据库，而数据工程师不仅要管理这些关系数据库，还要创建和管理Hadoop或者Greeplum等系统下的分析型大数据系统。在这些大数据系统里，还需要创建一定的数据模型来存储和管理企业的数据。这类分析型数据模型也与传统事务型数据模型有很大差别。以用户的收货地址为例，传统事务型数据模型只需捕获到用户的当前地址，而分析型数据模型通常需要捕获用户历史中所有更新过的地址。作者所在公司就有一个专门的数据工程师团队，他们帮助企业建立基于Greenplum的大数据系统，创建分析型数据模型，收集企业运营产生的数据。数据工程师的教育背景通常是计算机专业，或者受过计算机专业培训。

数据科学家对于大部分管理者而言是个全新的职能岗位。相比软件工程师和数据工程师，他们未必需要有计算机专业背景，而是可能来自于数学、统计和物理专业。其实，华尔街早年的量化分析师就算得上数据科学家，他们的主要工作就是创建各种数学模型。早期的数学模型主要建立在统计方法上面，现在的机器学习模型主要建立在大数据上。因为AI驱动的数字化战略的崛起，使得数据科学家的人才缺口急剧扩大。数据科学家作为正式的工种与大数据的概念同时产生。《哈佛商业周刊》在2012年的10月刊上曾发表过一篇名为《数据科学家：21世纪最性感的工作》的文章。文章给出了一个例子：斯坦福大学物理学博士毕业生Goldman通过自己创建的数据模型来给领英用户推荐可能认识的朋友。这个模型给出的推荐相较其他来源的内容在领英同一个页面位置的点击率要高出30%。IBM在2017发布的报告中曾预测美国的数据科学相关的岗位数量到2020年将增加364000个，总数将达到272万以上。可见，工作岗位需求的增长速度远高于人才供给增长速度。这也使得数据科学家的薪水涨幅惊人。

对于企业而言，建设数据工程师和数据科学家团队可以从以下两方面努力：

1）选择好的大数据和AI平台，尽量平民化数据模型，降低人才的进入门槛。

2）选择合作伙伴，在实践中培养人才。作者所在公司的数据科学家团队会通过结对方式，在实践中帮助转型企业建立他们的数据科学家团队。从供给端看，高等教育机构和产业领袖应重视数据科学人才的培养，并从产业和教育的角度共同促进人才培养。

因为数据工程师和数据科学家岗位的出现，企业通常会设置首席数据官（Chief Data Officer, CDO）来代表数据科学家出席公司执行层的圆桌会议。CDO在公司的战略建议权很大程度上能够反映该企业所处的数字化转型的阶段。如果CDO的决策影响力很大，通常意味着该企业已进入AI驱动的阶段。后面我们将在AI驱动的公司文化中深入讨论这个问题。

最后要强调的是，这三类人才不是互斥的。优秀的软件工程师通常具有扎实的计算机科学知识的功底，他们也可能同时擅长数据工程和数据科学。但是企业要同时在这三方面下功夫。原因有以下两方面：一是这类“三位一体”的通才可遇不可求；二是即使有这样“三位一体”的人才团队，也会因为工程量巨大而不得不分而治之。因此，作者建议，在人才培养方面，团队的每个成员都要有两方面知识的重叠。例如，软件工程师要懂得数据模型，数据工程师要懂得数据科学，数据科学家要懂得应用开发。这样的配置有助于提高团队的沟通效率，也能增强团队成员之间的同理心。

2.3.2 AI驱动的开发方法和文化

AI驱动的开发方法要求应用、数据和模型三位一体地螺旋迭代上升。《Cloud Foundry：从数字化战略到实现》一书中提到的测试驱动和持续交付的方法对此同样适用。这种情况下对于产品经理的要求比较高，他需要和各个团队的技术负责人一起协调创建产品开发的任务列表（Backlog）。为了确保敏捷性，在人才配备方面，应尽量确保人才具备应用、数据和模型这三种技能中的两种。各个团队在接口方面要保证一定的稳定性，例如，在模型团队的输入/输出比较明确的情况下，应用开发团队只要根据模型的输出来决定应用的输出即可。这样用户看到的应用输出就是稳定的，随着模型团队的改进，用户会感觉到应用的输出越来越智能。比如，前面提到过的新闻阅读终端的例子，用户会看到内容的版式相对稳定。同时，因为模型团队的精度提高，每个版面的内容将越来越精准地反映用户偏好。这里提到的方法听上去不难，但是要顺利实施，让这些方法发挥出最大的效用，企业的文化土壤也需要做出相应的调整。

AI驱动的开发文化要求企业在战略决策层面加入一个新的维度，即考虑如何将建立在大数据之上的模型智能第一时间通过数字应用反馈给用户。比如，新闻阅读终端的决策者要考虑如何根据用户的历史访问数据建立模型，以通过模型在第一时间把相关的内容推荐给读者；视频内容网站也要考虑同样的问题，因为准确的内容推荐会让用户消费更多的视频。

加入一个新的维度到决策过程中听上去很容易，但实施起来却非常困难。反过来考虑，如果这个事情很容易推进，那么传统的新闻浏览终端早就自动进化到类似于头条新闻这样的新一代新闻阅读终端。传统新闻阅读终端和现代应用终端的差别就在于我们所说的新维度：新的新闻终端从创立第一天就把竞争属性建立在用户内容推荐模型上。读者可以想象一下，假设一个提供传统新闻阅读服务的公司的董事长将一个知名的数据科学家引入公司担任首席数据官，让他帮助公司建立AI驱动的新闻阅读终端。很可能他进公司的第一天就要对各个业务部门提出各种要求：

❏新闻采编部门要对内容进行更加精细的标注。

❏应用开发团队需要注入大量的代码来获取用户阅读行为习惯数据。

❏数据工程团队要建立大数据基础设施以收集用户数据。

❏数据科学家团队要建立模型对内容进行推荐，应用开发团队要根据推荐呈现内容。

这个过程不是一次性完成的，而是螺旋性迭代的。更为糟糕的时候，在看到产出之前会经历一段时间的投资，甚至影响原有新闻终端发布内容的速度。用不了多久，原有的采编部门、开发团队和数据团队就开始向董事长抱怨，一次两次董事长可能坚持下来，但如果抱怨次数太多，董事长就可能放弃AI优先的战略。然后，得出一个错误的结论：现在实施AI驱动的战略为时过早。而事实上，AI驱动的战略是正确的，只是没有落地到对应的文化土壤。

在这样一种AI驱动的文化里面，CDO要从一开始就在公司执行层的圆桌会议中有一席之地，而且其他功能的主管（CIO/CTO）一开始就要习惯照顾到CDO的诉求。从公司战略层面，如果认为大数据和AI战略是突破性创新，按照《创新者的窘境》一书中的理论，最好还是成立一家新的机构。CDO成为那家新机构负责人，和现有的高管以业务关系合作，从而保持一定独立性。如果公司从战略层面认为大数据和AI还处于连续性创新阶段，那么CDO一开始就要避免设置过高的目标。在实施深度学习之前，可以利用高级分析功能找出一些小的改进点，采用持续改进的方法让其他高管看到效果。按照《Cloud Foundry：从数字化战略到实现》的方法论，其实软件应用开发的成功率已经非常高。但是相比软件应用开发，大数据和AI项目的失败率要高很多。

2.3.3 大数据基础设施的建设

前面提到，在大数据和AI驱动的企业数字化战略中，应用、数据和模型是螺旋式上升的。在企业实施大数据和AI战略之前，还有一项必要的前期工作，那就是大数据基础设施建设。通常，企业进入第一阶段的数字化转型以后，已经有了一些云上IT基础设施，包括一些简单的应用开发运维（DevOps）环境。这里将讨论建立第二阶段的大数据基础设施的必要性和实际选型中的考虑。

1．必要性

在讨论大数据基础设施的建设之前，我们先看看其他的物理基础设施。2008年，作者从美国回国度假，看到国内正在飞速建设高速公路和高铁的基础设施。当时正值美国房产泡沫危机，雷曼兄弟公司倒闭。作者在想：“国内这些设施的建设是以刺激经济为目标呢？还是以应用（例如电子商务和春运）需求满足为目标，或者兼而有之？”经过10年的建设，我们看到很多不可能成为可能：游客乘坐高铁可以在10个小时内从一个城市到达国内的大部分其他城市，电商的物流可以在12小时内完成产品投递（美国的亚马逊需要24～48小时）。10年前一个经营生鲜产品的企业无法想象如何在线上进行交易，而今天，生鲜产品也面临线上的激烈竞争。

在我国基础设施蓬勃发展的时候，美国的云计算基础设施也在蓬勃发展。2006年，谷歌提出云计算的概念以后，亚马逊推出了第一款公有云计算服务AWS，虽然分析界对其并不看好，但是硅谷公司确实看到了一个基础设施带来的时代变更。作者当时在甲骨文公司（Oracle）的服务器技术部门从事网格计算的资源调控（Grid Control）工作。2007年，甲骨文公司看到了时代变更，它的网格计算部门也开始大规模部署到云计算，为甲骨文云计算奠定基础。2010年，阿里云已经在虹桥机场附近树立起云计算的广告牌。现在，腾讯云、阿里云和华为云将中国云基础设施建设推向新高潮。笔者在2008年做企业调研，了解企业对于云计算的接受度时，大家普遍的观点是不会把自己的软件运行在外部。到2017年，阿里云的营收额达到了66亿人民币（美国的亚马逊云更达到了180亿美元之巨），公有云已经成为企业的影子IT部门（换言之，如果企业自己的IT部门做得不好的话，业务部门就会采购公有云）。

如果感觉现在谈公有云基础设施和交通基础设施有些事后诸葛亮的话，那么我们回归到大数据正题，它是当今世界正在发生的一场如火如荼的数字化基础设施的建设。在交通基础设施的建设上，美国的高速公路建设领先于中国，但是中国的高铁网通过跃背（leapfrog）效应领先美国；在云基础设施方面，中国的云供应商紧跟美国；而在大数据基础设施的建设上，中国则和美国齐头并进。

在前面关于ABC关系的讨论中提到过，机器学习和AI模型是一个特定类型的数学模型。这些模型随着数据量的上升，精度会相应提高。可以预见，未来企业的竞争要么基于模型，要么基于数据，要么兼而有之。一般企业不具备模型的基础理论研究能力，而且学术机构一旦在模型上有所突破就会很快向所有机构开放。所以，企业要想在机器学习的竞争中获得优势，大数据基础设施更为关键。大数据基础设施建设是企业可以操作且必须操作的。进取型企业为了在未来竞争中获得优势，已经开始脚踏实地建设大数据基础设施，这不仅有利于支持现有的机器学习应用，也为现在尚未知道的未来模型做好准备。就好像从前建设高铁和高速公路的时候，虽然没有预见到今天蓬勃发展的物流业，但是却为今天的物流创新做好了准备。

在作者接触过的中国500强企业中，大部分企业在大数据的基础设施中投入了千台以上的服务器，并且设有专门的数据基础设施团队。这些基础设施上一般运行了Greenplum和Hadoop等多个现代大数据平台软件，支持着企业业务团队的各种请求。同时，大数据基础设施也遵循独立原则，以保证数据的完整性和安全性。

2．选型

在今天五花八门的产品和技术当中，商业决策者选择一个适合自己的技术作为基础来投资十分重要。作者在为大型公司战略层提供咨询的过程中，通常建议它们从以下几个维度考虑：

❏硬件标准开放性

❏软件源代码开放性

❏原创技术团队稳定性

❏云化

（1）硬件标准开放性

虽然技术提供方可以直接提供生产好的硬件，但是企业应该考虑是否可以获得硬件配置规格，并且这个配置规格需要建立在商品化的硬件组件上面。所谓商品化，就是可以从市场上直接购买，而非定制生产和研发。这个考量可以帮助企业避免被锁定在特定的硬件上而失去自主可控的创新能力。

（2）软件源代码开放性

这是指技术提供方给出的基础源代码是否对外开源，而且是否建立在Apache许可等比较好的开源许可上面。通常，技术提供方的兴趣主要在于获得软件许可收入，所以他们提供的服务数量有限。基于开放源代码的技术一般有庞大的服务社群，企业能够获得更加丰富的第三方支持渠道。另外，开源也能避免企业被锁定在闭源软件上，从而丧失自主可控创新能力。

（3）原创技术团队稳定性

这一点可能是当今最重要的一个考量因素。在开源和开放经济学的理念下，企业支付的软件许可费最终是为了获得原创技术团队的创新能力，或者说是企业分摊原创技术团队需要获得市场定价的成本和合理利润。但市场上的开源技术有诸多误区：

第一种误区是继承技术供应商放弃开发的开源产品。市场上的很多开源软件产品是技术供应方不再想维护，从公益的角度将源码开放出来的。这意味着原创技术团队不再持续投入。继承这样的开源代码和自己从头开发的成本几乎等同乃至更高。

第二种误区是认为知名企业的团队创建的开源项目就是好技术。很多互联网公司本身的利润来源不是软件收入，所以为了提高技术团队的实力，公司会鼓励技术团队写出好的开放性代码并提供给社区。这样的产品和代码很难长时间保持热度，随着主业产品方向的改变，代码的原创团队很可能被分配到其他项目上而不再对源代码进行维护和改进。

第三种误区就是使用社区业余爱好者发起的开源产品。大家都希望看到兴趣爱好支撑的创新，这也是一个好的起点。如果社区团队不能探索出一套稳定的自治模式，最终会失去原创团队。在一个好的自治模式下，通常会出现一个持续稳定的商业公司来支撑对应的开源产品。举个例子，Redhat和Linux社群就是一个非常健康的关系。相比之下，OpenStack技术和Hadoop技术在多年之后还没有形成一个维系原创团队持续投入的模式。

（4）云化

目前主流的大数据技术都可以直接运行在物理硬件上，而且它们通常也实现了《Cloud Foundry：从数字化战略到实现》中定义的云计算的基本功能。例如，它们实现了软硬件分离、横向水平扩展等。具体来说，像Greenplum这样的大数据系统中的任何一个物理机器故障，插入新的硬件系统都可以重构这个故障的硬件，同时业务的增长也可以通过加入更多的服务器来满足。它的缺点是企业要维护两套系统：大部分数字化应用运行在一套基于I层云和P层云的云计算系统上；大数据系统运行在几百台服务器的物理裸机上面。这种配置会导致管理成本上升。现在的主流技术供应商都把大数据系统加入云计算的PaaS层云服务里面，例如AWS的Redshift和Alibaba基于开源Greenplum的HybridDB。截至本书完稿时，这个技术变迁还在进行中。

这里作者想强调的是，不要等待技术供应商把运行在物理机器上的大数据系统向I层云上迁移而成为PaaS云技术的一部分，作为数字化转型高阶阶段的管理者要关注把PaaS云的云原生应用迁移到PaaS云的大数据上。也就是说，不是从数字化应用的需要来考虑大数据的建设，而是要考虑大数据的建设能够为应用提供的可能，从而实现从满足需求到创造需求的观念转变。