大数据平台架构技术选型与场景运用

一、大数据平台 

大数据在工作中的应用有三种： 
与业务相关，比如用户画像、风险控制等； 

• 与决策相关，数据科学的领域，了解统计学、算法，这是数据科学家的范畴；
• 与工程相关，如何实施、如何实现、解决什么业务问题，这是数据工程师的工作。

数据工程师在业务和数据科学家之间搭建起实践的桥梁。本文要分享的大数据平台架构技术选型及场景运用偏向于工程方面。 

 

如图所示，大数据平台第一个要素就是数据源，我们要处理的数据源往往是在业务系统上，数据分析的时候可能不会直接对业务的数据源进行处理，而是先经过数据采集、数据存储，之后才是数据分析和数据处理。 

从整个大的生态圈可以看出，要完成数据工程需要大量的资源；数据量很大需要集群；要控制和协调这些资源需要监控和协调分派；面对大规模的数据怎样部署更方便更容易；还牵扯到日志、安全、还可能要和云端结合起来，这些都是大数据圈的边缘，同样都很重要。 

二、数据源的特点 

 

数据源的特点决定数据采集与数据存储的技术选型，我根据数据源的特点将其分为四大类： 

• 第一类：从来源来看分为内部数据和外部数据；
• 第二类：从结构来看分为非结构化数据和结构化数据；
• 第三类：从可变性来看分为不可变可添加数据和可修改删除数据；
• 第四类，从规模来看分为大量数据和小量数据。

内部数据 

来自企业内部系统，可以采用主动写入技术(push)，从而保证变更数据及时被采集。 

 

外部数据 

企业要做大数据的话肯定不会只局限于企业内部的数据，比如银行做征信，就不能只看银行系统里的交易数据和用户信息，还要到互联网上去拉取外部数据。 

外部数据分为两类： 

• • 一类是要获取的外部数据本身提供API，可以调用API获取，比如微信；
  • 另一类是数据本身不提供API，需要通过爬虫爬取过来。

 

这两类数据都不是我们可控制的，需要我们去获得，它的结构也可能跟我们企业内部数据的结构不一样，还需要进行转换，爬虫爬取的数据结构更乱，因此大数据平台里需要做ETL，由ETL进行数据提取、转换、加载，清洗、去重、去噪，这个过程比较麻烦。爬虫爬过来的数据往往是非结构性的、文档型的数据，还有视频、音频，这就更麻烦了。 

结构化数据 & 非结构化数据 

 

结构化和非结构化数据在存储时的选型完全不同，非结构化数据偏向于文件，或者选择NoSQL数据库；考虑到事务的一致性，我们也可能选择传统的数据库。 

不变可添加数据 

如果数据源的数据是不变的，或者只允许添加（通常，数据分析的事实表，例如银行交易记录等都不允许修改或删除），则采集会变得非常容易，同步时只需要考虑最简单的增量同步策略，维持数据的一致性也相对变得容易。 

对于大数据分析来说，我们每天在处理的数据大部分是不可变更的。正如Datomic数据库的设计哲学就是数据为事实（fact），它是不可变的，即数据是曾经发生的事实，事实是不可以被篡改的，哪怕改一个地址，从设计的角度来说也不是改动一个地址，而是新增了一个地址。交易也是如此。 

可修改可删除数据 

银行的交易记录、保险单的交易记录，互联网的访客访问记录、下单记录等都是不可变的。但是数据源的数据有些可能会修改或删除，尤其是许多维表经常需要变动。要对这样的数据进行分析处理，最简单的办法就是采用直连形式，但直连可能会影响数据分析的效率与性能，且多数数据模型与结构可能不符合业务人员进行数据分析的业务诉求。如果采用数据采集的方式，就要考虑同步问题。 

大数据量 

针对大数据量，如果属于高延迟的业务，可以采用batch的处理方式，实时分析则需要使用流式处理，将两者结合就是Lambda架构，即有实时处理、又能满足一定的大数据量，这是现在比较流行的大数据处理方式。 

 

三、数据存储的技术选型 

大数据平台特征：相同的业务数据会以多种不同的表现形式，存储在不同类型的数据库中，形成一种poly-db的数据冗余生态。 

先把数据源进行分类，然后根据其特点判断用什么方式采集，采集之后要进行存储。数据存储的技术选型依据有三点： 

• 第一点取决于数据源的类型和采集方式。比如非结构化的数据不可能拿一个关系数据库去存储。采集方式如果是流失处理，那么传过来放到Kafka是最好的方式。
• 第二点取决于采集之后数据的格式和规模。比如数据格式是文档型的，能选的存储方式就是文档型数据库，例如MongoDB；采集后的数据是结构化的，则可以考虑关系型数据库；如果数据量达到很大规模，首选放到HDFS里。
• 第三点是分析数据的应用场景。根据数据的应用场景来判定存储技术选型。

场景一：舆情分析 

做舆情分析的时候客户要求所有数据存放两年，一天600多万，两年就是700多天×600多万，几十亿的数据。而且爬虫爬过来的数据是舆情，做了分词之后得到的可能是大段的网友评论，客户要求对舆情进行查询，做全文本搜索，并要求响应时间控制在10s以内。 

我们后来选择用ES，在单机上做了一个简单的测试，大概三亿多条数据，用最坏的查询条件进行搜索，保证这个搜索是全表搜索（基于Lucence创建了索引，使得这种搜索更高效），整个查询时间能控制在几秒以内。 

 

如图所示，爬虫将数据爬到Kafka里，在里面做流处理，去重去噪做语音分析，写到ElasticSearch里。我们做大数据的一个特点是多数据库，会根据不同的场景选择不同的数据库，所以会产生大量的冗余。 

场景二：商业智能产品 

BI产品主要针对数据集进行的数据分析以聚合运算为主，比如求合、求平均数、求同比、求环比、求其他的平方差或之类的标准方差。我们既要满足大数据量的水平可伸缩，又要满足高性能的聚合运算。选择Parquet列式存储，可以同时满足这两个需求。 

 

场景三：Airbnb的大数据平台 

Airbnb的大数据来自两块：一是本身的业务数据，二是大量的事件。数据源不同，采集方式也不一样。日志数据通过发送Kafka事件，而线上数据则通过Sqoop同步。数据存储选择HDFS集群，然后通过Presto对Hive表执行即席查询。S3是一个独立的存储系统。 

 

四、数据处理 

 

数据处理分为三大类： 

• 第一类是从业务的角度，细分为查询检索、数据挖掘、统计分析、深度分析，其中深度分析分为机器学习和神经网络。
• 第二类是从技术的角度，细分为Batch、SQL、流式处理、machine learning、Deep learning。
• 第三类是编程模型，细分为离线编程模型、内存编程模型、实时编程模型。

结合前文讲述的数据源特点、分类、采集方式、存储选型、数据分析、数据处理，我在这里给出一个总体的大数据平台的架构。值得注意的是，架构图中去掉了监控、资源协调、安全日志等。 

 

左侧是数据源，有实时流的数据（可能是结构化、非结构化，但其特点是实时的），有离线数据，离线数据一般采用的多为ETL的工具，常见的做法是在大数据平台里使用Sqoop或Flume去同步数据，或调一些NIO的框架去读取加载，然后写到HDFS里面，当然也有一些特别的技术存储的类型，比如HAWQ就是一个支持分布式、支持事务一致性的开源数据库。 

从业务场景来看，如果我们做统计分析，就可以使用SQL或MapReduce或streaming或Spark。如果做查询检索，同步写到HDFS的同时还要考虑写到ES里。如果做数据分析，可以建一个Cube，然后再进入OLAP的场景。 

这个图基本上把所有的内容都涵盖了，从场景的角度来分析倒推，用什么样的数据源、采用什么样的采集方式、存储成什么样子，能满足离线、内存、实时、流的各种模型，都能从图中得到解答。 

-------------------------

日前，eBay公司隆重宣布已经正式向开源业界推出分布式分析引擎：Kylin（http://kylin.io）。作为一套旨在对Hadoop环境下分析流程进行加速、且能够与SQL兼容性工具顺利协作的解决方案，Kylin成功将SQL接口与多维分析机制（OLAP）引入Hadoop，旨在对规模极为庞大的数据集加以支持。

背景信息

eBay公司当前面临的主要挑战在于，数据规模正随着用户群体的多样化拓展而水涨船高。我们的用户——比如在分析与业务部门当中希望能在保持最低延迟水平的前提下继续使用自己所熟悉的工具方案，例如Tableau与Excel。 
 
有鉴于此，我们与公司内部的分析部门进行紧密合作，并勾勒出eBay眼中足以构成成功产品的基本要求：
1.数百亿数据行的查询延迟需要保持在次秒级别。  
2.能够为使用SQL兼容性工具的用户提供ANSI SQL。  
3.完整的OLAP方案以实现各类高级功能。  
4.拥有对高基数与超大规模业务体系的支持能力。  
5.面向成千上万用户的高并发性处理能力。  
6.能够处理TB乃至PB级别分析任务的分布式横向扩展架构。 

我们很快意识到，没有任何一种外部解决方案能够切实满足我们的具体要求——特别是在开源Hadoop社区当中。为了解决企业业务面临的这一系列紧急状况，我们决定从零开始自主打造一套平台。在优秀的技术团队与部分试点客户的通力配合之下，我们已经能够在将Kylin平台引入生产环境的同时、为其发布一套开源版本。 

重点特性概述

Kylin 是一套卓越的平台方案，能够在大数据分析领域实现以下各项特性： 

•  规模化环境下的极速OLAP引擎: Kylin的设计目的在于削减Hadoop环境中处理超过百亿行数据时的查询延迟时间。  
• Hadoop上的ANSI SQL接口:Kylin能够在Hadoop之上提供ANSI SQL并支持大部分ANSI SQL查询功能。  
•交互式查询功能:用户可以通过Kylin以秒级以下延迟水平实现与Hadoop数据的交互——在面对同一套数据集时，其性能表现优于Hive查询机制。  
•  利用MOLAP cube（立方体）对数百亿行数据进行查询: 用户能够在Kylin当中定义一套数据模型对其进行预构建，其中所能包含的原始数据记录可超过百亿行。  
•  与商务智能工具进行无缝化集成:Kylin目前能够与多种商务智能工具相集成，包括Tableau以及其它第三方应用程序。  
•  开源ODBC驱动程序: Kylin的ODBC驱动程序从零开始逐步构建而成，而且能够与Tableau实现良好的协作效果。我们也已经对这部分驱动程序进行开源处理并发布至技术社区当中。  

其它特性：

• 任务管理与监控机制
• 通过压缩与编码机制降低存储容量需求 
• cube的增量式更新 
• 利用HBase协处理器实现查询延迟控制 
•  对不同计数进行近似查询的能力（HyperLogLog） 
• 提供易于使用的Web界面，旨在对cube进行管理、构建、监控与查询
• cube/项目层面对ACL进行设置的安全功能 
• 支持LDAP集成 

基本设计思路

Kylin平台的设计思路其实并非全新产生。在过去三十年当中，已经有很多技术方案使用到同样的理论依据来实现分析流程加速。具体而言，此类技术包括将预先计算完成的结果保存起来以备分析查询、利用所有可能的维度组合为每个层级生成cuboid（基本方体）、或者是在不同层级上对全部指数进行计算。 
 
下面这幅图片所示为cuboid的拓扑结构，供大家用作参考： 

当数据规模变得越来越大时，预计算处理机制就会变得无法实现——即使硬件性能再强大也于事无补。不过在Hadoop强大的分布式计算能力支持下，计算任务能够借助成百上千个计算节点的总体资源。这就保证了Kylin能够以并发方式对这些计算任务进行处理，并通过合并生成最终结果——这能够显著降低整体处理时间。 

从关系型到键-值型 

下面举一个实例，假设Hive表当中所保存的几条记录代表着一套关系型结构。当其数据规模增长到极其巨大的水平时——例如上百亿甚至过万亿行数据——那么像“2010年我们在美国本土售出了多少套技术类方案”这样的简单问题也将带来涵盖巨大数据量的表内容扫描，给出应答的延时状况也会变得无法接受。由于每一次运行查询时所需要的值是固定的，因此我们完全可以预先进行计算并对结果加以存储、以备日后随时调用。这项技术被称为从关系型到键-值型（Relational to Key—Value，简称KV）处理。处理过程将生成所有维度组合并如下图所示将测得值显示出来——图片右侧为计算结果。图片的中间一列内容由左至右表示的是这类大规模数据处理流程中数据是如何由Map Reduce进行计算的。  
                 
Kylin的构建正是以这套理论为基础，而且在对大规模数据进行处理时充分发挥了Hadoop生态系统的强大能力:

1. 从Hive当中读取数据（这些数据被保存在HDFS之上）  
2. 运行Map Reduce任务以实现预计算  
3. 将cuba数据保存在HBase当中  
4. 利用Zookeeper进行任务协调 

架构

以下图表所示为Kylin的高层架构。  
                    

以上图表勾勒出Cube构建引擎（Cube Build Engine）是如何以离线处理方式将关系型数据转化成键-值型数据的。其中的黄线部分还表现出在线分析数据的处理流程。数据请求可以利用基于SQL的工具由SQL提交而产生，或者利用第三方应用程序通过Kylin的RESTful服务来实现。RESTful服务会调用Query Engine，后者则检测对应的目标数据集是否真实存在。如果确实存在，该引擎会直接访问目标数据并以次秒级延迟返回结果。如果目标数据集并不存在，该引擎则会根据设计将无匹配数据集的查询路由至Hadoop上的SQL处、即交由Hive等Hadoop集群负责处理。 

以下为关于Kylin平台内所有组件的详细描述。 
 
•元数据管理工具（Metadata Manager）: Kylin是一款元数据驱动型应用程序。元数据管理工具是一大关键性组件，用于对保存在Kylin当中的所有元数据进行管理，其中包括最为重要的cube元数据。其它全部组件的正常运作都需以元数据管理工具为基础。  
•任务引擎（Job Engine）: 这套引擎的设计目的在于处理所有离线任务，其中包括shell脚本、Java API以及Map Reduce任务等等。任务引擎对Kylin当中的全部任务加以管理与协调，从而确保每一项任务都能得到切实执行并解决其间出现的故障。  
•存储引擎（Storage Engine）: 这套引擎负责管理底层存储——特别是cuboid，其以键-值对的形式进行保存。存储引擎使用的是HBase——这是目前Hadoop生态系统当中最理想的键-值系统使用方案。Kylin还能够通过扩展实现对其它键-值系统的支持，例如Redis。  
•REST Server:  REST Server是一套面向应用程序开发的入口点，旨在实现针对Kylin平台的应用开发工作。 此类应用程序可以提供查询、获取结果、触发cube构建任务、获取元数据以及获取用户权限等等。  
•ODBC驱动程序:为了支持第三方工具与应用程序——例如Tableau——我们构建起了一套ODBC驱动程序并对其进行了开源。我们的目标是让用户能够更为顺畅地采用这套Kylin平台。  
•查询引擎（Query Engine）:当cube准备就绪后，查询引擎就能够获取并解析用户查询。它随后会与系统中的其它组件进行交互，从而向用户返回对应的结果。  
在Kylin当中，我们使用一套名为Apache Calcite的开源动态数据管理框架对代码内的SQL以及其它插入内容进行解析。Calcite架构如下图所示。（Calcite最初被命名为Optiq，由Julian Hyde所编写，但如今已经成为Apache孵化器项目之一。） 

Kylin在eBay公司中的应用

在对Kylin进行开源化处理的同时，我们已经在eBay公司的多个业务部门当中将其应用于生产实践。其中规模最大的用例就是对由120多亿条源记录所生成的超过14TB cube数据进行分析。90%的查询请求都能在5秒钟之内获取到返回结果。现在，我们拥有更多面向分析师以及业务用户的用例，他们能够访问这些分析机制并轻松通过Tableau仪表板获取相关结果——而不再需要借助Hive查询或者shell命令等复杂机制。 

下一步发展规划

•  在高基数维度上支持TopN算法（即对大量对象进行排序并从中选取前N位结果）:目前的MOLAP技术在高基数维度上进行查询时的表现尚算不上完美——例如对单一列中的数百万个不同值进行TopN运算。 

与各类搜索引擎类似（正如众多研究人员所指出），倒排索引是此类预构建结果的理想匹配机制。  
•  支持混合OLAP(简称HOLAP):MOLAP在历史数据查询领域拥有出色的实际表现，但由于越来越多数据需要以实时方式加以处理，因此我们需要尽快将实时/近实时处理结果与历史结果结合起来、以作为业务决策中的参考信息。很多内存内技术方案已经能够以关系型OLAP（简称ROLAP）的方式满足上述需求。而Kylin的下一代版本将成为混合OLAP（简称HOLAP），即结合MOLAP与ROLAP双方的优势以带来单一一套面向前端查询的入口点方案。 

开源

Kylin已经以开源姿态被交付至技术社区。为了以Kylin为核心发展出更为强大的生态系统，我们目前正提议将Kylin转化为Apache孵化器项目。在Owen O’Malley（Hortonworks公司联合创始人兼Apache成员）与Julian Hyde（Apache Calcite缔造者，目前供职于Hortonworks公司）等Hadoop开发者社区支持者的鼎力协助，我们相信Kylin足以乘开源社区这股强劲的东风顺利跨入新的纪元。 

我们欢迎大家加入到Kylin贡献者阵营中来，感兴趣的朋友请点击以下链接以访问Kylin网站并获取更多详尽信息：http://kylin.io. 

作为起步，大家并不一定马上就要对核心代码库进行开源贡献，从以下方面着手也是不错的选择：
  
1.  Shell客户端
2.  RPC服务器
3.  任务调度
4.  工具

要获取更多细节信息或者进一步探讨上述议题，大家可以在twitter上关注我们@KylinOLAP或者加入我们的谷歌群组：
  
https://groups.google.com/forum/#!forum/kylin-­‐olap 

总结

Kylin已经在eBay公司内部融入生产环境，专门负责处理规模极端庞大的数据集。这套平台拥有显著的性能优势，实践证明其能够帮助分析师们轻松借助自己所为熟悉的工具对Hadoop当中的数据进行充分利用。我们也乐于推出Kylin的开源版本。欢迎大家给出自己的反馈与建议，我们期待着您参与到这个开源大家庭中来。

http://www.csdn.net/article/2014-10-25/2822286