大数据开放平台搭建，难点何在？
http://www.infoq.com/cn/articles/build-big-data-open-platform/
实现技术融合的关键
用大数据的眼光看数据，会跟平常我们看数据会有什么不同呢？用大数据的眼光看数据，会发现【数据会分成两种基本属性。一个是Schema，一个是Partition】。在Partition和Scheam下应该支持多种文件的数据存储格式，包括文本格式，Avro格式，列存储，数据库文件。
编者按：Hadoop于2006年1月28日诞生，至今已有10年，它改变了企业对数据的存储、处理和分析的过程，加速了大数据的发展，形成了自己的极其火爆的技术生态圈，并受到非常广泛的应用。在2016年Hadoop十岁生日之际，InfoQ策划了一个Hadoop热点系列文章，为大家梳理Hadoop这十年的变化，技术圈的生态状况，回顾以前，激励以后。本文整理自去年4月份的QCon大会演讲“以Hadoop为核心的大数据开放平台建设”。
大数据发展趋势
大概在08年左右，Hadoop从Nuch里的一个package开始的独立出来，不断的被大家所关注，它本身不断的进化，包括对压缩算法的Native实现，Checksum机制的优化，还有ShortCircuit Read（支持直接文件的内置的短读），这算是读取性能的优化。在这些不断的优化下，Hadoop逐渐变得健壮。Hadoop的2.3版本，是一个架构上的根本变化，把资源管理提到了一个很高的高度，就是我们新一代的Yarn&Mapreduce2.0。还有一个HDFS上的架构优化，就是NameNode Federation。NameNode分布式管理，可以极大的增进机群的可扩展性。
Hadoop本身不断完善，围绕着Hadoop的生态系统也在不断的完善，像Oozie，就是与Hadoop结合非常紧密的一个工作流引擎；Flume是围绕Hadoop的日志收集类的ETL工具；Hive是一个SQL On Hadoop的实现，也是最早的一个实现，现在已经有很多了；Pig类似Hive，但是是一个内置脚本、有自己独立语法，相对来说是一个优化版的Hive实现。但是它的语法，相对来说要比Hive性能高一些，在Facebook内部使用比较多。另外Cloudera推出了SQL On Hadoop的Impala的实现。另外还有Spark 也是新兴的一个内存计算模型的技术。
大数据技术应用，困难何在？
围绕着Hadoop的周边的生态系统在不断的完善，运维管理工具上也得到了极大的进展。因为在早期，大家部署一个Hadoop系统会非常麻烦；从08年到现在，我经历过大大小小的系统，自建的，内建的，包括公司各种平台项目里面建的，不计其数，特别的辛苦。包括脚本，权限设置，一些目录权限的设置，安装一个系统大概要半天左右到一天左右时间。非常熟练之后也要半天左右时间。现在像Apache Ambari，Cloudera Manager，已经把整个机群的部署变得非常简单，基本上几分钟就能把我们需要花几十分钟的机群部署起来，甚至是一个几十台机器规模的机群。
大数据技术在不断的发展，但是它还是有些天生的不足。首先是技术本身在百花齐放，生态系统里面的技术在不断的完善，包括Hadoop，Hive，Spark等等，那么就会存在选择上的困难--如何应用好每一项技术，就是一个难题。另外，大数据技术本身内部的融合性也是不太够的。现在有一种趋势，每一个开源工具都在强调自己的性能有多好，都想围绕着自己去建立生态系统。另外就是怎么合理的使用这些技术。比如说我们以前的系统是围绕着一种技术建立的，然后又引入了一个新的技术，两个技术怎么实现融合，这就是一个很大的难题。
相关厂商内容
中国技术开放日广州站暨小蛮腰科技大会——移动开发技术前沿论坛（免费报名）
关于红包、SSD云盘等核心技术集锦！
下一代 DB2更加突出 BLU Acceleration
58集团架构与大数据应用创新专场
Cloudant DBaaS技术概述
另外一个就是大数据技术与其他传统技术的融合性不够。传统技术，比如以前使用的数据库，一些其他的服务，Solr检索服务什么的，也没有成熟的融合方案。在实践中会比较陌生，没有一套成熟的体系支撑。你可能需要去翻很多的文档，自己做很多开发，才能实现这些功能。那么我们现在缺少什么呢？缺少一个能融合现有大数据技术的技术，这个真的是非常非常关键的。
技术领域是怎么来面对这个问题的？
大概在13年，Doug cutting做过一次技术分享，The State of the Apache，这个文档大家可以在百度百库上可以检索到。他当时提出了一个概念叫Apache Hadoop Ecosystem。Ecosystem，E应该是代表Easy，CO是Cross，System系统平台。这在他的论文里面摘录的几句关键的话。
文档本身的介绍非常简单，寥寥几页，但很经典。我觉得他说得非常在点子上。我的解读，这个总体来说应该是这样一个思想：以Hadoop为核心，融合其他技术的平台级系统，Avro将是实现融合技术的关键技术。
在行业内，Cloudera应该是Hadoop就是围绕着大数据Big Data这种解决方案的一个国外很有影响力的一个公司。Cloudera是在做Hadoop的应用体现，想让Hadoop越来越容易被大家所应用。他提供了两个解决方案。首先，建立了Hue这套系统，提出Use Hadoop with Hue。另外就是Administer Hadoop，就是运维管理Hadoop。建立了叫Cloudera Manager这一整套的工具。像Hue和Administer已经是说解决了两方面的问题，Hue用来调度管理任务。Administer是管理和运维平台。
这是Cloudera给出的答案，在科大讯飞的实际开发过程中，我们是怎么应付和解决这些难题的呢？我们围绕着Doug Cutting提出的ECoSystem的思想上，我们也开始逐渐建立自己的大数据开放平台Maple。
我们的实现以数据导向为理念。数据导向为理念是一个思想。以前我们在做一件事情的时候都会考虑，做这件事情要使用什么样的技术。因为首先大数据是围绕着数据去做的，很多时候会偏离数据，而去考虑很多技术的细节问题。但是在做实际业务开发的过程中，我们需要围绕着数据去想问题，而不是围绕着技术去想问题，这就是需要数据导向为理念。我们所有的业务开发围绕着数据，数据是什么样的，我们就怎么处理。整个系统平台是以Hadoop为核心，这也是符合Doug Cutting提出的EcoSystem的思想。
最后我们提出了以EcoSystem设计理念，以Hadoop为核心，融合优秀的技术，因地制宜的使用技术。综合来看，每个技术都有它的特长，因地制宜的使用技术，才能让这个技术得到更好的发挥。我们还需提升大数据的应用体验。如果你是早期接触的话，在它上面开发任务，提交任务，整个的流程管理是相当复杂的。
科大讯飞的大数据平台
我们大数据开放平台分成三部分。1.基础机群，围绕着Cloudera发行版本CDH来构建的。2.我们上层构建了自己的Maple SDK，是面向开发者提供的开发包。3.是Maple BDWS。
大数据平台的整个的架构。
从上层的应用层到ETL层，到我计算和存储层，这是整个的数据流。以这个上面的这些设计为基础开展大数据开放平台的工作。非常的值得去借鉴是我们架构上不仅定义了数据流向，也定义了开发的过程，Maple BDWS应该是我们整个大数据开放平台的一个门户，解决代码托管，编译部署，工作流设计，任务调度，数据和任务信息浏览。特性：支持多集群管理，支持多版本Hadoop，支持多项目管理，在线编译部署（one button to use）。整个平台是用Python去做的，支持了Python扩展。可以在线的测试和运行Python的代码。
Maple BDWS是我们整个大数据开放平台的一个门户，Maple SDK就是我们整个大数据开放平台的灵魂。
在设计SDK的时候，我们的目标是为了实现Integration Technical，就是融合技术，希望能把各种技术都提供一种标准的开发方式，开发模板。通过在实践中应用成熟以后，把开发模式，融合的编码规范分享出去。围绕着SDK，我们融合了Hbase，oozie，Flume、Avro这样的技术。SDK里面包含一套数据建模的功能，基于Avro的Mapreduce编程库。还有一套Flume-ng的扩展组件。统计分析也是一个常见的业务，Maple-Report是一个统计分析解决方案。另外还含有一个分布式索引的库，叫Maple-Index。大数据建模系统Data Source，适用于大数据的动态自动建模系统。
实现技术融合的关键
用大数据的眼光看数据，会跟平常我们看数据会有什么不同呢？用大数据的眼光看数据，会发现数据会分成两种基本属性。一个是Schema，一个是Partition。在Partition和Scheam下应该支持多种文件的数据存储格式，包括文本格式，Avro格式，列存储，数据库文件。
Avro是融合整个技术的关键，在我们内部大量使用了Avro的数据存储格式。我们要围绕着DataSource去建立数据导向的API，提供一个清洗过程的API。另外提供两个DataSource实现Merg和Join的功能。还围绕DataSource实现跟外部数据这种交互。建立了HiveQL On Datasource这样的API，支持Spark去Load处理，Impala On Datasource，Pig On Datasource等。
了解Avro可以看官网的Introduction。Avro经常会被跟Thrift和Protobuf这两个序列化系统做比较。因为Avro本身也是一个序列化系统。那么我们就要提出一个问题，在Thrift和Protobuf已经很成熟的这种基础上，为什么要选择Avro？在08年，10年左右，我关注这个项目，后来发现所有的代码的提交修改记录，全是Doug Cutting，里面有90%的工作都是Doug Cutting本人去做的。Doug Cutting早期是Lucene的项目的创始人，也是Hadoop的创始人，一手把Hadoop开源项目带起来，甚至都是他亲身去开发的。他花费那么多精力去搞Avro，必有其独到之处。
Avro开发中代码生成是可选的，这是一个跟其他系统，就是跟Thrift和Protobuf有很大区分的一个特性。另外Avro支持通用数据读取，不依赖于代码生成。有了这两个特性，Avro就更能适应大数据变化的特性。Doug Cutting当时是在Thrift和Protobuf很成熟的基础上开始着手建立Avro的，是非常有想法的。
Avro在讯飞大数据开放平台的应用
首先我们有一套Avro-Mapreduce编程框架，围绕Avro这种Mapreduce开发。Avro为整个Mapreduce过程提供了高性能的数据系列化，是在整个Mapreduce生命周期里面一个非常关键的环节，也是非常影响性能的。Avro-Mapreduce是一个简化的，面向对象的，富于设计的Mapreduce编程库。支持Generic、Specific、Reflect三种模式。
Avro还用在整个大数据的数据存储上，这种数据存储是支持通用数据读写，支持多语言读取，内置了很多的压缩算法。因为它内置了很多压缩算法，我们可选，如果适当选择压缩算法，它与传统的文本相比，同样的内容可以节省10倍的空间，这个也是非常关键的。它还有更高的读取性能，因为它有内置的压缩，比较精简，它的序列化性能又很高，所以这个数据读取的性能非常高，这是我们现在目前Avro在数据存储上的应用。我们Avro还用在数据收集的环节。我们在数据收集上也支持多语言的开发，因为前端的应用有很多，包括PHP，Java，还有C等各种语言。
另外，我们以Flume-ng融合，实现了结构化的日志收集。Avro提供了这种对结构化数据格式的支持，可以更高效的传输数据。
下面说一些我们融合技术的一些具体案例。我们依赖于Flume+Avro实现了内部的ETL方案，分布式结构化日志收集。目前我们部署的节点已经超过了一千个，每天数据的收集超过上千亿。我们用Avro封装了FlumeEvent，实现了结构化日志收集。以前在Log中大部分日志都是文本，但是现在支持Log自定义的数据结构体。另外也支持一些通用的Array或者Map等这种数据类型。我们得益于Avro，它传输数据更简洁，速度更快。现在我们每天的千亿数据都通过这种方式实时收集。在数据收集阶段，我们还要注意一些流处理与其他系统去做对接。Flume-ng提供了一个支持二次开发的SDK，方便业务类功能扩展。
围绕Flume-ng的优化
围绕着Flume-ng还做了很多的优化工作，其实我们在一开始做技术选型的时候，Flume-ng当时还不太成熟，也遇到了很多问题。我们没有放弃，比如说我们以AvroFile为缓存，实现了一个新的File ChannelPlus，极大的提升了速度和稳定性。它本身的File ChannelPlus，出于安全和可靠性的保障，性能比较差，并且经常出问题。后来我们就重写了一个File ChannelPlus。现在FileChannelPlus吞吐基本上达到每秒钟6万左右的TPS。
我们还改进了HDFS的端的存储接口，支持了Stable。我们数据收集上来要跟后面的数据处理流程要做对接。如果数据在接收并且在写一个文件的过程中，后面永远不会知道这个数据什么时候该处理。所以我们在这个Sink上实现了一个Stable的机制，数据会定时的被放到一个Stable的目录，让这些数据变成可处理的状态。后面就会写触发条件去处理Stable的数据，就跟传输层能做一个很好的隔离。
另外我们还实现了分布式的节点监控和智能的配置管理服务，就是因为Flume-ng配置非常灵活，在上千个节点的部署上管理起来是非常麻烦的，那么我们实现了一个整个的配置管理中心服务，然后弥补了Flume-ng配置管理复杂上的这些问题。如果大家在实际开发过程中应用Flume的话，应用层应该是没有什么问题的，如果大家遇到什么样的问题，可以按照我们的思路，尝试着对它进行扩展。
日志收集系统Loglib，用了Flume、Avro和Solr技术，实现了我们的分布式的实时日志检索的。我们每天的日志的索引量超过15个亿，一天的独立的索引记录数超过15个亿，支持几个月的记录，最近又改成了两个月。我们每天保证15亿的索引的稳定。另外我们做到了即用即搜。
开放平台统计分析
接下面来介绍核心的语音项目Sunflower，语音云统计分析平台，和开放统计分析平台，是用什么技术来融合去做的呢？我们用了Datasource + Avro-Mapreduce + Spark，来实现了语音云统计分析系统和开放统计分析系统。最一开始，我们面临的问题是日两亿次PV，现在语音的服务量大概在两亿次左右。我们要每天在这个数据量上做大概7大类，50多个小的类的统计工作，综合指标大概有上千个左右。最开始，我们尝试基于Hive去实现这样的统计分析工作，后来我们发现通过分解所有的需求，分解出来的Sql语句都有上千句，运行非常缓慢。我们又尝试基于Pig，但是Pig的脚本也有几百行，执行速度也非常慢。我们开始对分布式技术进行一些思考，为什么Hive和Pig会这么慢？根本点在什么？因为我们有很多的指标，很多纬度。在指标和维度分解出来以后会形成很多的Pig和Hive语句。每个语句在执行的时候，都要对数据进行Load，进行分布式处理。同一份数据被反复的Load，非常耗费时间。对同一份数据的不同纬度和指标的统计分析，能否一次完成任务？计算结果的中间数据是否能够被重复利用？根据小时报表，其实可以重新计算出来日报表。我们围绕这些优化方向，形成了我们新的一个Maple-Report，全新的统计分析解决方案。
我们通过报表定义与计算的分离，实现了多引擎的支持。Report Engine目前支持Avro-MapReduce，依赖于Mapreduce这样分布式计算的实现，还有Spark这样的更高速的实现，依赖于内存的实现。我们也真正的实现了同数据源的多维度，多指标，一次性计算完成，小时日周数据可以循环依次利用。20分钟左右就能得到日志报表，同样周报表得到的时间也非常短，月报表，甚至半年报表也没有什么困难。Maple-Report综合解决方案，我们上线运行很长时间了。语音云统计分析系统，和开放统计分析系统，都是依赖于我们这套方案去做的。
整个Maple承载着公司级的大数据战略，像现在整个云平台
、研究院、平嵌、移动互联和智能电视，都通过我们的Maple平台进行数据和技术的共享。另外，我们面向互联网的好多产品，包括讯飞开放平台、语音输入法、灵犀、酷音铃声，所有的数据均汇集到了Maple开放平台。然后很多小组都使用这个系统去分享挖掘数据。整个系统还在不断的发展中，公司整个战略是要把所有的产品线上的数据都汇集到一个平台上，将来能够都提供技术&数据分享，能够深入的挖掘数据的价值。
总结致敬
最后我想发表一些感慨，向那些以Doug Cutting为代表的，依然耕耘在技术前线，勤于Coding的前辈表示敬意。他们的分享和贡献精神，带给了我们实实在在的大数据技术。国内有一个很不好的一个想法，我也听过很多人讲，就是我多少多少岁以后就不做开发了。其实这个思想，我觉得大家应该适当的有些改变，应该以前辈为表率，去学习他们那种无论到什么时候，都能埋头去Coding这种精神！我到现在也在做Coding的一些事情，这是我们需要在整个技术上面需要形成这种风气。
演讲嘉宾
孙利兵,科大讯飞云平台研发部资深大数据架构师，早期就曾接触Hadoop分布式计算技术，对Mapreduce分布式计算亦有很深刻的理解。精通Avro技术，在2008年曾编写了应用于实际环境的AvroMapreduce编程库，对Doug Cutting的以Hadoop为核心，Avro为关键技术的EcoSystem构想非常向往，并推进在科大讯飞云计算组工作中进行实践，打造了Maple（大数据开放平台）。
