数据科学正快速成为各行各业开发人员和管理人员的关键技能，同时它似乎也非常有趣。但它也相当复杂——有太多的工程分析技术，你很难知道自己做得是否正确或者哪里存在陷阱。在该系列文章中，我们将探讨如何利用数据科学——从已经采用并成功实施数据科学的人们那里，了解数据科学的适用场景，以及如何让它成为你的资产。
本文要点
- 将大数据和数据科学技术应用到企业组织里是变革性的项目，它有点类似向敏捷组织转型，同样充满了挑战。
- 如果能获得高层领导的支持并让利益相关者参与进来，那么使用敏捷方法进行此类业务转型会有显著的效果。
- 在谈论技术选型之前，首先要关注战略性的业务产出以及企业组织对新功能的需求。让每个利益相关者对新功能的优先级排序都有发言权，并就后续技术选型进行合作。
- 避免在既不能跟上需求变化又不能获得额外收益的技术上加倍投入。
- 要注意在开放数据和保持数据安全之间存在的矛盾。在安全问题上，觉察力(perception)也很重要，不仅要遵守而且要格外注意。
企业组织现在越来越多地采用数据科学和高级分析技术，也越来越多地影响着决策、产品和服务。因此经常有人问到：数据科学最好的工具集是什么?从表面上看，这个问题似乎是关于技术之间的比较。结果你可能需要审阅一长串关于R、Spark ML及其相关技术(如Jupyter或Zeppelin)的利弊列表。我们的确可以写出一系列有关技术比较的文章。然而，对企业组织而言，首要问题是什么功能能够支持其未来的业务目标。关注这些可以让技术选型变得更容易，并且降低浪费时间和精力的风险。
我们如何才能达成共识，以务实和富有成效的方式进行有关技术选型的讨论?在这篇文章中，我们通过实际案例来探讨什么才是合适的框架。对企业组织来说，最典型的切入点是那些大量存在的数据孤岛(silos)和过度采用的技术。你不想仅仅因为利益相关者的要求而增加更多的技术和数据孤岛。新的技术和基础设施应取代现有技术并替换数据孤岛。但在现今的大环境下要做到这点并不容易，因为传统分析技术和商业智能供应商声称他们拥有针对新挑战的解决方案，同时还有大量的新技术出现，其中许多是开源的，这提供了更多的选择。新技术通常都宣称能取代传统工具，并提供传统工具无法企及的功能。而传统技术则反驳说它们能提供更好的企业品质，比如安全和支持。
我们在这里讨论的现实案例中的客户在一年多前与我的雇主联系，他们在短期和长期的战略需求方面面临着巨大挑战。这家FTSE 100公司正处于其生命周期中的转型时刻。它的整个组织结构发生了显著变化，需要重新改造其部分现有平台，因为它分裂的组织结构和依赖项不可维护，无法创造商业价值。在我们来看，客户的迫切需求是：在极短的期限内，用一种完全透明的方式，混合集成历史数据，解决高级报告和新数据平台分析技术所面临的问题。客户现有的数据仓库技术基于应用技术，十分昂贵且有局限性。如果不投入大量资金并且增添新兴的分析功能，新的报告和高级分析功能执行起来会极其缓慢甚至无法执行。
成本和局限性是重点关注对象。我们的客户意识到由于可预见的突破性技术变革，市场竞争正变得越来越激烈，从长远来看，源于核心业务活动的价值将不可避免地缩减。企业组织的领导者意识到他们迫切需要开发新的功能，以便在处理完当前的紧急需求后立即为企业的未来发展做好准备。
我们与主要利益相关者合作制定了一个计划，将主要数据集集中在一个中心区域，便于在企业未来的新一轮变革中灵活处理和分析。值得注意的是，我们并没有放弃核心数据仓库，只是把它还原到原先的角色。然而，我们仍然会逐步淘汰大量的旧系统，这些系统大多数存有数据并且难以访问。同时，要保证数据在不同平台上正常流动，以确保监管和安全。我们因此把高级分析技术和数据科学技术问题延后讨论。这是可行的，因为新平台可以在必要时根据需要采用那些相关技术。采用这种方法给客户带来的好处是显而易见的。未来的业务仍在不断变化，而眼前的业务需求需要马上得到解决。将决策和实施分阶段实施，且不阻碍平台的创新，这是一个双赢的解决方案。
第一个教训是避免在跟不上需求变化的技术上加倍投入。此外，尤为重要的是不要进行一对一的技术匹配。比如不要用一种相似的技术替换原有技术，这样做得到的效益十分有限。我们要考量这些技术给组织带来的成本支出和它们所能为组织提供的功能。大家总是希望借由更少更便宜的技术来降低成本，并指望它们能提供更多业务功能。理想情况是我们可以两者兼顾。在这个案例中，我们在淘汰旧系统的同时减少了数据仓库占用的空间，节省下来的资源可用于新的分析技术平台，这反过来取代了一些原有功能并增加了相关的新功能。
有了这个概念，我们就可以专注于我们正在努力实现的目标。现在的企业和以前的企业所面临的挑战是相同的。他们必须降低成本，提高盈利能力，不断改进以保持合规，并且在这个被服务自动化和商品化所驱动的环境里，可能还需要重新定义其核心业务。例如，过去几年中，数据和对数据的有效利用正在成为应对这些挑战的关键机会。
问题在于大多数企业组织不知道该如何寻求答案甚至不知道问题出在哪里。在各个业务领域内通常都有一些唾手可得的短期机会，它们将给现状带来完全可预期的改进。但大多数利益相关者已经习惯于自身的局限性，他们需要打破这种局限。当问及他们想要实现什么时，他们要么把思考局限在企业组织现有的功能范围内，要么为了解决未来的未知需求而要求那些不切实际的东西。
因此那些包括重新定位自身核心业务在内的长期基础性需求通常很难甚至无法得到满足。所以第二个教训是不要着眼于办不到的事情上，不要试图去预测未来，而是应该对眼下出现的需求灵活以对。在我们的案例中，你可以看到我们在不限制条件或不返工的情况下，为平台将来的迭代扩展留下空间。这是通过规划多个增建(buildout)步骤做到的。可以在合适的时机往这些步骤里添加一系列的功能。这里从诸多的功能中列出其中的两项，比如流处理功能或键值存储(key values stores)功能。
然而，如果我们完全以技术为驱动，指望使用各种技术来取代事后的内部反思(inward reflection)和需求收集，这是有风险的。我们可能最终采用了没有任何商业目的或价值的技术，导致高额的成本和高度复杂性，更糟糕的情况是导致项目完全失败。大数据和数据科学的流行促使利益相关者在这种情况下容易陷入炒作陷阱。他们认为采用技术可以解决业务目标、功能和需求方面的问题。对利益相关者来说，至关重要的是必须在大数据和数据科学方面提出正确的问题，以避免困惑和失望。这些问题是先决条件，包括具体的战略业务目标和需求。虽然战略目标必须从一开始就明确，但是如我们的案例所示，需求可以随着时间反复推导。
企业组织可以使用适当的大数据战略来评估当前形势，明确需求，并采用有关数据存储、处理和分析的新功能。事实上，这种敏捷性是以数据为驱动的现代组织的基础，它让企业能够在快速发展的技术环境中良好运作。数据科学可以利用组织在评估和采用这些技术方面所具备的能力。数据科学还为来自两方面的挑战提出了深入的见解，并给出了恰当的解决方案。这两方面的挑战一个是更多、更快、更多元化的数据，另一个是人们对这些数据在驱动产品、服务、洞察力和决策方面无限增长的期望。
在我们的案例中，传统的数据仓库解决方案正面临着挑战，因为它在单独完成第一个任务时，缺乏足够的灵活性来解决任何未知需求。不过这种解决方案也不是一无是处，因为这项特定业务在金融行业中运作，带有敏感数据并且受到高度监管。这项业务需要得到更深入的挖掘，而这又必须允许众多数据科学家和商业用户访问数据。大多数企业组织都存在这种矛盾，既要让所有潜在消费者都能接触到所有数据，但同时要确保数据的安全，不被滥用或泄漏。
对政府、医疗保健和金融客户来说，他们还得经受得住新闻媒体的考验，因为任何数据安全方面的问题，不管是真实发生了抑或是有发生的迹象，都可能成为灾难性的新闻头条。因此，安全问题不仅存在于现实中，也存在于意识中。有趣的是，这也是为什么许多客户对云技术犹豫不决的原因，因为在云技术里，随着安全的改进，感知和现实越来越互相偏离。有些公司可能要顾虑合规性，比如在哪里存储数据。另外，云服务供应商把越来越多的区域纳入监管范围来满足合规需求。
我们的客户选择了使用本地部署方案，我们为他们列出了解决当前问题需要的关键性功能，并为他们设计了一个将来可灵活扩展的平台。首要目标是构建一个平台，这个平台以Hadoop及其生态系统为核心，获取新旧数据，使用掩码和加密确保数据安全，然后基于这些数据生成报告。该方案所需的分析工具很简单，通常会利用SQL接口把那些遗留工具接入Hadoop生态系统，并使用Apache Hive。 Hive是第一选择，因为它是整个分布式系统不可分割的一部分，它稳定而且对SQL支持良好，遗留系统可以通过标准连接访问它，它还跟分布式安全模型紧密集成。此外，第一阶段的性能要求与用于分析和报告的大小批次的数据更为相关。
核心平台的构建和集成，以及必要的PCI合规性，是现阶段的关键挑战。由于时间紧迫，我们必须立即开展工作，所有利益相关者都很乐意通过“失败排除法”(fail fast)对平台关键要素的落地实施进行验证，以迅速找到组织性阻碍和技术限制。自然而然地，只有当所有发现的问题都得到了解决，“失败排除”才是有效的。因此，无论是否能够达到某个里程碑，我们都需要在工作中举办一些研讨会，比如学习一些新的知识、引入新的业务，让技术利益相关者参与进来，一起解决问题或者为下一步的发展制订计划。
虽然有时也会遭遇困难，但是这种方法在高层领导支持下会比较有效。现有的流程和技术以及已建立合作的供应商可能需要被作为解决方案的一部分进行评估。有时候这会导致与供应商和企业利益相关者在如实处理失败情况时对话困难，无论问题是来自于组织自身还是来自供应商和合作伙伴。高层利益相关者要强势进行战略审查和问题分析，因为身处数据驱动的发展最前沿，他们也是少数几个应该负责找出问题根源的人。这是唯一可行的建设性合作方法。因此必须让利益相关者加入研讨会并倾听他们的需求和进程，能在概念验证环境下进行反复验证，进而探讨各种可行或不可行的方法，这是极其重要的，这才能使我们迅速在工作上获得进展。
对敏感数据加密工具和屏蔽工具的选择是快速淘汰机制的一个很好的例子。一个有名的市场参与者推出了他们的解决方案，并坚称他们在金融方面的成功案例让他们成为客户的第一选择。然而事实证明，市场已经远离了他们。同时，Hadoop生态系统的新功能，比如透明数据加密与多租户模式的结合，对他们的产品和安全机制来说改变太大，无法适用。快速淘汰机制的良好运作以及在概念验证环境中引入新供应商的能力让延迟变得可控，并且这项选择工作在新一轮对另一提供商的评估之后取得了进展。
随着第一阶段的工作即将完成，整个组织的需求增加了，比如，访问平台和数据，增加工具以便更好地支持数据科学家和高级业务分析师。这些需求涵盖了探索性分析、几近实时的高级报告以及智能应用和产品。满足这些需求需要许多功能和工具。此外，许多数据科学家偏好不同的工具，包括R，Python(scikit-learn)，Spark ML(使用Python，Scala或Java)，以及各种商业解决方案和笔记工具(比如Jupyter或Zeppelin)。还有很多还不是很明确的初步需求和偏好，需要跟能够达成它们的工具进行匹配。我们还要注意监管、安全性、业务持续性、软件和数据集开发生命周期以及成本、复杂性和风险等这些常被忽略的问题。简而言之，组织要么在低风险的情况下以一种及时且可盈利的方式持续创新，要么被技术淹没。
创新灵活性太高和肆意采用技术会带来风险，使组织瘫痪。组织里的数据可能由于缺乏监管和安全性不足而泄漏或质量下降。当企业组织需要支持太多技术时，可能会导致资源缺乏和集成不可控。另一方面，紧密而简约且只考虑安全性的技术选型将会扼杀组织创新，造成人才流失、功能缺失，组织将最终发现自己无法应对新的机会和风险。另一种与上述完全不同的理念是通过漫长的瀑布迭代流程来制订完美解决方案。这种理念在无法收集需求、技术能力不断改变的创新环境下不占优势。
当我们将组织设想为一个拥有有限资源并旨在从中获得最大相关功能的实体时，敏捷式方法将成为最佳选择。其发展框架类似于我们用来评估技术选型和解决核心平台开发和构建时所出现问题的研讨会。我们可以将相关业务部门的各种数据科学和分析技术的利益相关者汇聚到一起进行讨论。什么是易于理解的用例?它们的优先等级和对组织的影响是什么?实施它们需要具备哪些条件?还有不太为人所了解的未来创新理念和潜在的功能需求?第二部分是技术问题。团队的技术偏好和现有技能是什么?对于各种必须得到满足的要求和组织标准，它们在开发生命周期方面有什么样的需求?理想情况下，技术问题能得到来自安全、基础设施、运营以及软件开发等部门的利益相关者的支持。
我们的客户比较先进，已经有显著的独立性，因为它的一些重要高层领导是大数据和分析技术专家。然而，他们也希望得到外部支持，得到同一领域专家的独立指导和评估。对于顾问而言，当客户接受你作为权威和值得信赖的独立顾问，这是梦寐以求的结果。我们一起举办了一个为数据科学工作做准备的研讨会。我们收集了各类信息，并且在研讨会期间，我们就能够做到对各个业务部门的工作按照优先级排序，并淘汰不合适的技术。
练习的效果是立竿见影的。所有利益相关者都互相认识，了解彼此的愿望和喜好，这本身就是有价值的。此外，基于几近实时流数据，我们还能够识别重要工作和决策服务。这可以为各方所用，也就是说，每个人在某些情况下都需要用到这类服务。我们能够避免类同开发，集中精力并将其作为试点项目优先安排。在缺乏监管的状态下，会出现不同业务部门使用不同的技术开发出同一个服务的不同版本。而采用上述的方法，我们就能够整合精力和工具选择。
我们的下一步计划是选择第一组要添加到数据科学工作平台的技术，特别是用于流数据的Spark ML、Java、Python以及Kafka。这些技术引入了现有用户案例所需的功能，并且还将涵盖一些未来和次要的用例。这个选择是在研讨会讨论最终候选技术并且考虑了运营和组织方面的问题之后做出的。例如，我们需要确定哪些技术受到最为广泛的支持和采用，并且最为成熟。是否得到广泛采用是在我们在这个阶段选择Java而不是Scala的一个影响因素。
重要的是不要排除任何可能性，并让利益相关者参与建设性讨论。如果备选方案看起来不可行，我们可以通过上述框架来降低它们的优先级。
我们即将参与服务的开发。可预见的好处是这为组织带来了一系列技术及其功能。我们会立即在关键业务项目中评估其非功能性能力，例如，围绕安全性、可靠性和性能来评估。此外，如果能证明这些技术有效和可用，它们可能被业务利益相关者采纳，减少对重叠替代方案的需求。有了正确的选择和成功的表现，持续采用更多技术的需求将逐渐淡去，而采用现有成熟可用的解决方案将变得越来越普遍。
我们将来的计划是继续使用该框架，并收集利益相关者和用户反馈，以便在现有功能不足的情况下进行评估和进一步采用技术。随后的研讨会将自然地从广泛的技术选型讨论转移到维护问题的讨论，最终我们将讨论在市场不断发展的情况下逐步淘汰技术的话题。
本文作者：Christian Prokopp博士
来源：51CTO