前言
多年以来我参与实施了多个数据仓库、企业报表、管理驾驶舱、数据治理等数据类型的项目，一直以来数据领域都是传统的套装软件，中心化的数据管理占据主导，但是从2014年的大数据规划项目至今，我发现世界不一样了。
数据能力的建设面临着巨大的变化的需求，这两年在建立和发展精益数据创新体系的过程中，我越来越深刻地意识到这一点。
这个摸索的过程中，我发现了我们的全球CEO 郭晓先生写于2015年的一篇文章，关于如何建设数据能力的看法，和我们现在的方向和思路如出一辙，原文是英文，我把他翻译成中文。
文章的题目是如何构建企业的数据能力，但是我翻译下来，感觉翻译成《过去我们把CRISP-DM的经念歪了》更合适
郭晓本身是中国人，是同类型全球科技咨询公司里面少数的中国区走出去的全球CEO。
郭晓
我们的技术战略中有一个方向就是要将数据变成我们的基本能力。总的来讲，我们希望将数据能力建成熟，然后无缝集成到我们的业务中，将ThoughtWorks变成数据驱动的公司，让数据能力去支撑我们的招聘、销售、资源调度，管理的流程。
所以，什么是数据能力？我们如何把这个能力应用到我们为客户提供的解决方案中？
我尝试使用这篇文章来回答这些问题。
这不是一篇复杂的数据技术蓝图的研究报告，和往常一样，我听取了一些数据方面的同事的想法，参加了一些会议，阅读了一些相关书籍和文章，这个文章是我学习和思考过程的一个总结。
1.在这个新时代，我们希望从数据中获得什么样的业务价值？
数据从信息技术行业产生的那一刻起就一直存在，毕竟信息技术是基于信息的，而信息是来自于数据的。通常提到数据的时候，首先出现在我脑海的是数据库，一种结构化的数据存储系统，提供了一系列数据的定义、获取和更新。数据库，关系型数据库，和数据管理员（DBA）已经成为计算科学和信息技术的一个专业领域。在一段时间内，数据能力被特指为数据库能力。当然，我们今天所讲的不止于此。
这是我们所提到的技术趋势中关于数据的部分，“随着几何级的数据量的增长，我们开发了各种方法去采集、处理存储和分析数据。Hadoop和专有的大规模并行数据处理技术（比如Oracle)都在持续的发展和成熟，而这两种技术在向高响应和实时处理的方向融合。相比较于传统的BI报表，技术和框架在不断推进对海量数据的处理，这样业务必然也会获从中获得更多的对于客户行为的洞察。参与生产的每一个人都要知道数据的重要性和利用数据能够产生什么。”
这个核心是采用高响应和实时处理的新的方法去处理和分析几何级增长的数据和数据之间的联系，从而从数据中获取更多的洞察和知识，帮助业务作出更好地决策。
获得的业务价值是从数据中产生更实时的洞见和知识，从而更好的决策
2.为什么我们做了这么多年，仍然无法做到这一点？
数据挖掘，数据仓库，商务智能已经被众多企业实施了很多年，并且在很多年以前就承诺要帮助业务获得更多的价值。
但是我们也听到了很多企业在实施商业智能和数据仓库过程中的挑战。我们经常听到企业实施数据仓库和商业智能项目的失败率超过50%甚至70%。
就像Jeff Smith(IBM的首席信息官所说）“数据仓库和商业智能系统占据了CIO预算中的巨大的部分，并没有产生对应的业务价值”
是什么导致数据仓库和商业智能解决方案不适用于现在的情况了呢？
我们可以从行业经典的数据挖掘的方法论（CISP-DM）开始探讨，CISP-DM是一种数据挖掘和知识探索的项目标准，虽然我不是一个数据挖掘的专家，但是我觉得CISP-DM还是很优雅的。
图一:CRISP-DM
这幅图清晰的表达了迭代是CRISP的核心基础，CRISP的核心理念是探索。它从对业务和数据的理解，基于一系列的假设而开始，但是结果远不是确定的。对每一步和每一次迭代结果的评估都会回改变业务理解和方法和理论。
这个方法论的根本目的是通过数据分析和迭代，去发现新的知识和洞察从而帮助业务做出基于更多信息的决策也就是数据驱动的决策，而不是通过工程方法去实现一个顶层设计。
从本质上讲，这也是“敏捷”方法的一个典型样板。但是，实际的情况，众多大型传统企业的数据挖掘和商业智能项目都成为了大型的瀑布项目，谈不上响应力和实时性，所以也就无法满足当前的也无需求。
下面是主要的原因：
1）技术和工具
传统的商业智能和数据仓库技术大部分是基于关系模型和SQL语言。
关系模型和SQL语言数据技术的一个突破，让数据被结构化成表格从而可以用标准的语言去查询和访问。但是，在海量数据的今天，关系型数据库的垂直扩展模式让存储成本几何倍数增长，并且不方便维护，也不够灵活。现在有越来越多的非结构化的数据要去处理，这就突破了传统的关系型模型的限制，因为关系模型需要在数据被存储和分析前就被定义好结构。一种尝试去解决这个问题的而方法是分布式MPP SQL数据仓库，也就是被称为“新SQL”，它尝试去使用COTS存储并采用大规模共享数据列去解决扩展性问题。这也是现在大部分数据库厂家重新设计和重新定义现有产品的方法。但是同样也有将这种方法利用在Postgres和MySQL的方式（比如，亚马逊Redshift就是采用这种方式利用了Postgres的核心版本）.尽管如此，到现在为止，这样的方法仍然无法突破关系模型的约束并不能很好地处理非结构化数据。
信息化系统从处理数据的角度可以分为两个类型，OLTP和OLAP.OLTP(在线交易处理型)系统的事物处理相对比较简单，而数据量和准确度要求较高。而OLAP(在线分析型)系统是分析数据，从数据中获取信息和知识的。在OLAP的场景下，过去通常会使用商业智能和数据仓库的工具。通常情况下，依赖于ETL模型（抽取、转换和加载）来识别，组织，建立索引，切片从而让数据容易被分析。通常情况下，这是一系列的批处理过程，而这个过程往往处理时间很长，比较复杂，所以成本很高，并且调试困难，而一旦这个失败了，也就很难被干预。这是因为这个过程是依赖于一个中心数据仓库的基础上，改变和干预比较困难，而且过程中数据是被提前被汇总好的，所以很难去获取和加入新的源数据。
我们经常发现当我们希望让DBA团队向报表中加入一列数据哪怕是一个简单的变化，往往都会需要几个月的时间去处理。最近一个大数据的会议上，我又一次听到熟悉的抱怨，“一个数据科学家95%的实践是在等待数据被准备好（在他们能够利用这些数据去训练、和测试他们的模型之前）”
传统的沉重，独有，昂贵并且不能实时响应的商业智能和数据仓库的处理工具和技术已经成为了阻碍CRISP模型所涉及的迭代和实时的瓶颈。
图二着重表明了这些挑战。
2)文化和流程
首要的问题是技术驱动还是业务驱动：
今天，大部分的商业智能和数据仓库项目是由信息技术部门驱动的。部分是因为技术的限制需要中心化的实施方法，但是这又是一个关于忽视了沉默成本的误区-BI项目前期预算越大那么信息技术的影响和控制力就越强。但是不幸的是，在众多企业，由于预算流程和结果导向，瀑布的实施方法主导者那些规模比较大比较重要的项目。而在绩效体系中，按时按预算比快速产生业务价值和更早得到投资回报更重要，于是当IT部门常按照预算和最初的计划按部就班的管理百万级的商业智能和数据仓库的项目的时候，业务部门就需要等待数月才能得到第一个真实的业务场景的结果。而当业务部门希望发生一些改变的时候，他们需要把数据结构做修改，新的数据做抽取转换和加载，又是一轮数月的等待。
这样的方法设计的初衷就不是到高响应，用户为中心甚至谈不上业务驱动。单一的技术驱动项目某种角度上是阻碍从数据科学中探索到业务价值的。
第二个问题是组织结构的壁垒。
随着业务和技术越来越复杂，越来越多的专业角色被产生，也围绕这些专业角色形成了一个个组织结构的孤岛。在数据驱动决策的场景下，通常有四类典型角色：业务负责人，业务分析师，数据科学家和数据工程师。这些角色需要不同的技能，关注点也不一样，但是基础的特质是一样的那就是数据和业务的理解能力。太强的专业性降低了通用的理解能力，对于创新和探索能力是一种损害。
除了专业知识的孤岛，不同角色也会导致现实世界的孤岛。在流程式的协作模式下，一个目标被分解成子任务然后被分配到不同的团队，然后一项子任务被完成后丢给下一个团队去继续，我们已经从众多其他软件开发的相似方法中总结了这样流程化的弊端，很多情况下大家关注子任务的成功高于关注于整体目标的达成。
下面是一些通用角色的总结描述：
-业务负责人，这是那些提出业务问题并且希望依据这些问题的答案去解决问题的哪些人。举个具体的情景，我们发现有20%的用户一旦协议到期可能就不会在续签新协议。我们设计了一个特殊的保留方案，但是这个方案成本太高，不可能给到每一个用户，那么我们如何找出哪些最合适接受这个保留方案的用户呢？
-业务分析师，这也可以是业务负责人自己或者是其他哪些关注在分析业务问题，提供业务背景，和数据科学家一起去设计解决方案的人。这个角色不仅需要很好的掌握业务领域知识，并且需要理解数据，具备创新能力和解决问题的能力。这个角色需要帮助数据科学家去分析如何讲一个业务问题转换成一个或多个数据科学问题。
-数据科学家，数据科学家和业务负责人/业务分析师一起去将业务问题分解成子任务，也就是那些可以用特定的算法去做挖掘数据的任务，从而产生可以回答业务问题的模型。关联到刚才那个具体的业务场景，这个模型最终是用来预测哪些用户是最可能流失的。
这样的过程需要很好的数据理解能力，包括数据的可用性，约束和成本，从而能够利用统计和数学去设计出合适的数据挖掘子任务。这几个角色需要和数据工程师紧密协作去帮助数据工程师准备数据，测试数据，并且持续的设计数据处理链和模型，他们需要理解和掌握一些编程语言，比如R/Python.
对于数据科学家来讲，除了数据建模、算法、统计、机器学习这些核心技能外，数据科学家依然需要掌握一些业务理解，程序开发，创新问题解决能力，这就是为什么好的数据科学家是非常稀缺的原因。
- 数据工程师
数据工程师这个角色大部分情况下关注在数据的处理上-获取，转换，清晰，提取和可视化。如果出现海量的非结构化数据的时候，数值分析， 分布式系统，并行计算和开源的工具都会被使用到。不论我们喜不喜欢，现实的情况就是在CRISP的循环里，大部分的时间会消耗在数据工程师的数据准备和测试上。对于大部分企业来讲，数据的质量和灵活的获取数据是一个很大的工程挑战。
图例3 CRISP循环的孤岛
3.如何让这些变得更好
当我们谈论一个成功的现代大数据最佳实践的时候，很少不提到Netflix和亚马逊，Netflix和亚马逊可以作为样板来参考。大部分成功的案例都包含在技术和文化/流程的两部分的内容。
1）技术和工具
Hadoop和NonSQL技术彻底的改变了传统的数据存储和处理，是自关系型数据库和SQL以来的第二次数据领域的技术革命。它主要做了两件事情，第一个革命是基础架构层面，将传统的大型数据集的中心化处理通过Mapreduce的方式拆分成小事务从而能够让大量的计算机并行处理，最后将所有的处理结果进行聚合。这样的模式将传统的垂直扩展转换成水平扩展，通过增加计算机而非扩容大型服务器的方式去处理更多的海量数据。
在我参加的一个数据类会议中，前德国电信的首席技术官提到，通过Hadoop为基础的开源架构提供了高扩展性的数据存储能力，但是只需要花原来传统的存储架构的5%的成本。
第二个革命是从程序开发角度，通过“Scheme on read”实现了敏捷。在关系型数据库系统中，数据规范最重要的。数据规范需要很小心的被设计和维护，因为它给与了数据库管理员以控制和修改结果的权利。所有符合规范的数据将被存储其他的数据将被抛弃和丢失。改变数据规范是一个巨大的事件，在6-12个月的操作性数据仓库系统中，一般很少会修改数据规范。
但是Hadoop就是不一样的，当你写数据的时候，没有数据规范。只有当这些数据被一些应用所使用的时候，才需要数据规范，这就是“Schema on Read”的概念。应用Hadoop，存储一个新的数据类型和创建一个文件然后把文件丢进去一样简单。他不需要一个重新设计一个数据库规范在更新存储系统。根据不同的数据应用需求，不同的数据规范可以被用在读取数据上就好像一个相机在不同的场景下更换不同的镜头一样。
这样的设计模式支持NoSQL数据库使用Key-Value，文档，图结构替代传统的关系型数据结构，比如Neo4J，MongoDB等。
现在更多的开源工具在爆发，有的已经超越了Hadoop，比如SPARK，一种基于内存的集群计算框架，更快，更适合机器学习算法的技术。
随着Hadoop和NoSQL这样的数据处理和存储技术的成熟，企业级数据仓库的行业版图也在发生变化。很多人从传统的结构化孤岛架构转向企业级数据湖架构。
下面的图是从德国电信CTO的演讲中摘取的一页，就是一个很好的例子。
(这篇文章写于2015年，那个时候还是数据湖刚刚兴起的时候，但是现在我们对于数据湖的观点已经有了进一步的理解)
2）精益企业和敏捷方法
我参加的一次大数据会议上，一个演讲者讲到了大数据的最佳实践，他的一页片子中提到很重要的一点，将数据科学家和数据工程师一起结对工作，就像敏捷软件开发中的开发人员一样。
作为听众，我当然很开心的听到这样的观点。如果我们回到CRISP循环的最初的样子，让数据科学家，数据工程师和业务负责人/分析师一起工作，这就是敏捷能够带来的最佳实践了。一系列的工程实践可以在这样的场景下发挥价值，比如迭代开发、协同工作，跨功能团队，CD/CI等。
如下图4所描述的，通过对CRISP循环做一些小的调整，增加一些角色，我们可以拥有一个非常敏捷的分析方法。这里介绍我的同事Ken Collier的书《精益数据分析-一种价值驱动的商业智能和数据仓库的分析方法》
在组织文化和流程层面，精益企业的方法和企业其他数字化战略方法一样重要。为了更好地发挥数据的能力，建立数据驱动的决策，企业需要提升自己的响应力，从财务管理，绩效管理到公司文化乃至系统架构。
精益企业这本书则提供了很好的框架从各个视角帮助我们去改进和优化。
有一个很有意思的现象，在一个大数据的主题会议上Netflix的高管分享了他们的企业文化。很多的观点和我们所提倡的敏捷和精益企业是完全一致的。以下是分享中的一部分观点：当我们在谈论Netflix技术有多么成功的时候，不能忽视了建立成功的文化的重要性。你能从Netflix的创始人的PPT中找到这一页。
4.ThoughtWorks在数据领域的解决方案是什么？
最终回到我当初设定的问题，经过这些研究和理解，我相信我们不应该只提供商业智能项目服务，或者只提供数据科学分析团队，我们应该努力帮助客户建立数据驱动的决策能力，成为客户的赋能者和伙伴。
我们需要从理解客户的业务，数据和他们的信息技术能力开始，帮助他们设计清晰的战略去实现数据驱动的决策，这里包括：
组织和文化（精益企业）
知识发现和管理协作的方法（敏捷/精益）
提供或优化关键的能力（业务分析/数据工程/数据科学）
对于我们自己来说，希望我们能够在数据领域建立长期持续的差异化的竞争力。
为什么我们在长远来看关注在数据工程领域呢？从流程和文化角度来讲，在一个阶段能改进的是有限的。对于大部分组织来讲，在特定的领域建立和应用数据科学和数据工程的能力不是特别困难的事情。不久以后，95%的瓶颈会在数据工程领域，如何提供更高的响应力，更实时的反馈，从而去驱动数据驱动的决策。在未来的市场，领先的技术能力是稀缺资源，这就是我们ThoughtWorks能够借助我们的技术能力，卓越的工程交付方法，从其他的竞争者中脱颖而出。我们在早期扮演数据驱动决策的赋能者，逐渐的成为客户长期的数据驱动决策的战略伙伴。
我们需要建立什么样的能力？
- 数据思维能力：数据思维是所有的角色都需要建立的，包括理解数据的能力，约束，和成本
- 业务分析能力：BA和技术组长需要掌握业务分析技能，包括理解业务和理解数据
- 数据科学能力（业务理解，创新思维，算法，建模，统计，编程等）
- 高阶数据工程能力，比如Hadoop，Spark，NoSQL，数据可视化等 后记，中心化的数据管理思想已经无法满足企业对于数据能力建设和应用的需求，所以在过去两年的基础上，我们摸索出了精益数据创新的体系。
另外，大家猜猜凯哥先发这篇公众号的时候在哪里，我在海外的一个机场候机厅，工作环境是这样的：
当我从包里掏出笔记本，插上电源，打开笔记本支架，然后带上耳机开始站着写文章的时候，我听到了旁边老外们的诧异的笑声和交头接耳，我猜想他们肯定是再说，“我靠，看这个骚操作”
关注凯哥讲故事，获得原创的数字化转型思考
