费良宏：大家好，我想跟大家分享一下管理大数据的话题。我主要是围绕着在云计算环境里的数据模式的架构与实现，也说说我们十年实践的心得。
大数据大家都不陌生，对相关领域大家也有很多了解。但是回顾过去几年大数据发展，有一些明显态势需要大家重视。
第一个就是规模的膨胀。如果几年前我们认为大数据还只是GB、PB级别的话，接下来我们会看到，从TB到ZB的增长速度已经越来越快了。接下来5年、10年会有一个新的认知。
第二点，非结构化数据已经占据了主导地位。比如说基因工程、社交媒体。这样产生的更多数据是以非结构化形式存在的。我们熟悉的结构化模式，已经不太适用了。我们有必要谈一谈大数据，如何利用今天的技术和手段帮助我们解决这个问题。
从大数据应用场景来看，无非是几种应用模式：
1.批处理模式。从事大数据的人已经很熟悉了，在今天和过去都用这样的方法来操控大数据。
2.流处理。过去几年出现的，而且已经比较普遍了。流处理模式有其特定的历史渊源，主要来自于数据产生的特殊性以及处理的特殊要求。
3.机器学习。数据本身并不具有价值，如果把它变成一种知识，它的数据才会变得更有价值，这个关键就是机器学习。
今天的人工智能是很热的话题。机器学习是一种很真实，可以帮助我们去解决从数据到知识化的有效手段，所以我们要关心的是，在大数据的环境里，如何利用批处理、流处理、机器学习达成我们目的的一个目标。
实际上我们来观察云计算或者大数据的市场，我们看到了一个让我们眼花缭乱的市场。各种架构、工具、技术、实践案例，充斥着各种媒体，各种分享。其实对于我们从业者来说，从这些信息当中找到你所需要的内容和知识并不是一件非常容易的事情。我们面临的挑战包括几个话题：
1.对大数据来说我们有没有好的参考架构？通过这个参考架构我们达成目标。
2.在架构体系下选择哪种工具？工具上的相似形很大，我们要选择一个非常适当的工具。
3.如何做？毕竟工具不能替代我们。
4..我们从大数据能得到什么？为什么要这么做？
回到大数据的本质，我们可以抽象起来。大数据的流程无非是从数据的采集、存储、分析处理以及使用上来看对于存储和分析处理。可能会通过若干迭代的方式不断的进行循环，以及达成数据可用化的程度。在这个环节中，我们需要考虑的除了刚才的流程，以及完成流程的功能之外，要考虑吞吐量，以及非常重要的成本因素。如果把简化的大数据流程作为观察对象的时候，其实我们面临的问题就比较简单了，就可以从这几个角度谈一谈大数据的问题。
第一个需要跟大家分享的就是关于“数据温度”的话题。数据温度是比较有意思的话题。它是用另外一个角度衡量这个数据的。
天气预报里很熟悉，通过温度的方法感知外部世界的变化，数据有没有温度？我的观察是，数据也是有温度的。我们操控的大数据里有一些特点，有一些数据请求频率非常高，需要有特定的持久性的要求，延时在毫秒级别，这是热数据。相对来说也有冷数据，就是请求频率相对比较低，规模和体量非常巨大，某种意义上称之为归档数据。目前来看这样的数据体量会越来越大。还有温数据，正好处于冷热之间的范畴。
有了这样的定义之后，我们才知道究竟应该选择哪种工具，哪种方法来管理数据。非常重要的是，大家需要关心不同的工具以及存储的方法，在成本方面有很大的差异性。只有考虑到数据的温度，有可能在成本上做最经济化，最适当的选择。
其次谈到流处理概念，流就存在着存储的概念。随着今天应用场景的变化，诸如像移动互联网、物联网、社交媒体，它呈现了一种数量巨大，但是尺寸不是很大的特性。这类叫流数据。这种使用是一种很独特的应用场景，用传统大数据处理方式对这些数据进行处理恐怕不是非常有效果。所以我们提出了流式数据处理的概念。可以通过流这样的存储模式，实现数据的解耦。我们往往对大数据要做持久化的缓冲，流恰好是持久化缓冲最佳的选择。
在采集方面，尤其像物联网、移动互联这样的场景里，有多种数据采集的应用特点。这个特点里，与之相对应的最好技术手段就是流的技术和手段了。在流的应用场景里，我们需要关注的是，是不是要确保数据的一致性和顺序的一致性，以及是不是需要并行处理，是不是需要通过PapReduce方式处理，这解决一些方法和特点以及现状的概括。
选择大数据处理工具的时候我们面临着一些困境。今天的工具不是缺乏而是过多了，归纳起来这些工具和手段无非是这样几种类型：
第一是内存中存储的工具In memory，另外是NoSQL数据库，第三类SQL关系数据库，第四种是检索方法。从数据来讲，我们放到内存里处理的速度最快，延迟最少，但是代价最高。关系数据库大家都很熟悉了，它仅对关系型数据才能有效实施。非关系型数据，可以用非检索工具来做。
我们也有几个考虑角度，第一是数据结构的问题，是不是有固定的schema，还是键值方式。另外存取方式，有按列存储的，这样的数据模型他们在使用上就有一些特定的要求。如果我用传统按行的方式读取、处理，效率不是最高的，这里范式考虑。另外结合数据的温度，按照冷、热、温的特点去选择工具操作，最重要的就是成本的考虑。规模不大的时候成本不是主要考虑的因素，但是规模很大的时候，成本就是非常重要，甚至是致命的因素了。
内存数据上我们会看到，NoSQL是不二选择，最好的就是关系数据库。对非结构化数据，一定是通过检索化方式。简单化的模型，在我们的选择上是很好的选择。参考工具对不同的技术来说有深远的影响，我们对不同的技术应用手段放在表里能看到，针对不同请求的成本、数据容量，可以看到不同的数据手段有偏好、擅长的领域。NoSQL更适合于弱数据的处理。比如说S3对象存储模式，更适合温数据或者冷数据处理，了解这一点我们再把数据手段和工具结合起来，选择判断会更容易。
典型分析处理框架有很多种。典型的是批处理模式，利用集群，实现周报、日报、月报处理。第二点是查询，利用一些交互式工具，实现业务场景和分析的需要。第三个是流式计算消息处理，可以实现实时或者准实时的大数据处理能力。最后一类就是机器型应用，利用机器学习的算法，把数据中的价值给抽取、提炼出来。
对于这样的应用场景，市面上充斥着各种各样的工具，我们也会针对这个场景提供托管服务，对于云计算用户来讲，就是在选择工具上有优势。
对于大数据架构谈了很多话题，引入了很多概念，如何将概念应用到真正的架构里？基于云计算平台上也有一个大数据参考架构。这个架构里就像刚才谈到的四个不同的环节流程，涵盖数据采集、存储这些环节。包括数据温度由低到高，数据存储方式的复杂到简单都有针对性的选择。
一个好消息，去年8月份AWS在中国区的服务已经落地商用了，大家可以通过中国区云计算的服务提供的内容，可以体验一下AWS提供的大数据所展现的魅力。
对于这样一个架构，大家已经有一些了解了，最后想跟大家分享一下大数据在实践中的设计范式。这也是过去十年里云计算、大数据应用得到的心得。
在软件架构里，最近一段时间大家谈到的架构设计原则就是解耦。利用松耦合方式增加系统的弹性。数据解耦对大数据来说是非常重要的设计原则。传统深擦作大数据的时候更习惯把大数据的存储、计算放到同一个环境下，在存储和处理上没有明显的解耦，但是这种方式存在着弊端。比如说对于数据的管理和处理流火性方面，或者不同的处理要求对数据的拷贝、管理上，存在天生的弊端很难解决。有时候企业里面为了解决这个问题，不得以会将数据有多份存储，无形增加了开销和不确定因素。
我们提出的建议方法，就是将数据解耦。大数据存储、处理，再存储，再处理的过程中，有不同的计算环境将数据剥离开，这样数据就成了独立数据，不同的业务场景和分析工具都会共享同一份数据来达成处理目的。
另外建议大家，在很多场景里使用发布订阅的设计模型和范式，可以实现数据解耦和一部分灵活性。另外可以用逻辑化视图，物化视图来进行处理，针对大数据海量数据环境下可以提供问题的解决。利用物化方式，加速处理的能力。
还有数据温度的问题，这是我反复强调，因为成本的问题，管理特殊性的问题，所以我们也需要考虑到如何利用数据温度的特殊性，在经济性，灵活性，工具选择上做出最好的搭配。这个搭配就要针对不同的场景，比如说实时处理、交互处理都会有不同的方式做选择。
大数据里有几种应用场景：第一种是实时处理，就是引入流的概念，利用一些流的服务和产品，提升我们数据的处理能力，以及将我们处理的延迟降到最低。第二是交互和批处理，在这种查询环境里最重要的就是集中化数据管理能力。
过去两年里，渐渐兴起广为大家熟悉的概念是数据湖，某种意义上强调企业建立一个全数据的集中管理能力。利用目前云计算和大数据的处理能力，真的可以为企业提供全数据的概念，利用全数据我们在大数据的操作、分析，不同主题的应用里，就具备了真正意义上的大数据的处理。
归纳起来，大数据的设计架构原则无非是几点：
第一点就是解耦的数据线，将数据的存储、处理、分析和得到的答案，这几个环节在数据层面做到真正的解耦，配合好的软件架构，应该能满足今天的需要，并且有很大的伸缩灵活性。
第二是选择适当的工具。每个工具都有自己擅长的领域，我们要考虑数据是什么结构，结构化还是非结构化，是毫秒级别还是分钟级别的，以及吞吐量和访问模式的问题。这些有明确说法的时候，你依据标准选择工具的话，恐怕就不是很困难的事情。
第三个是有效利用云计算。因为我们今天谈到了数据概念已经不再是GB、TB的概念，恐怕是ZB的概念，管理大数据真的不是简单的事情。所以现在越来越多的大数据可以跟云计算结合在一起，各位选择环境和平台的时候从今天就要开始，如何利用云计算提升的可用性、弹性、大数据托管工具等等，来实现大数据的解决方案。这一点是在很多案例中被证明的。
第四个是以日志为中心的设计模式，大数据的核心就是对日志的管理。如果日志数据的有效管理是大数据的关键因素，我们在设计之初就要考虑到这些数据的特殊性。比如说在日志管理方面，存储处理方面，选择一些不可变日志和物化视图方法，会更有效。
最后一点是成本的意识。成本是大数据非常关键的因素，如果不能有效权衡成本，也许在项目之初，尝试阶段就不能有效解决这个问题。当有一定规模和积累的时候，这个办法可能就没有办法解决了，因为你会被成本拖累。