资讯频道 → 行业应用
阅读更多

2顶
0踩

行业应用

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

2017-06-21 10:59 by 副主编 jihong10102006 评论(0) 有15116人浏览
大数据

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

引用
导读：本文将大数据的工作角色分为三种类型，包括业务相关、数据科学相关和数据工程。大数据平台偏向于工程方面，大数据平台一般包括数据源、数据采集、数据存储、数据分析等方面。

讲师从数据来源、数据源结构、数据变化程度和数据规模等4个维度对数据源进行分类，数据源分类维度的不同决定最后的技术选型。讲师还对数据源分类的定义及选型方式进行详细讲解，最终联系到大数据的应用场景，让数据应用方式更加直观。

一、大数据平台

大数据在工作中的应用有三种：
与业务相关，比如用户画像、风险控制等；
  • 与决策相关，数据科学的领域，了解统计学、算法，这是数据科学家的范畴；
  • 与工程相关，如何实施、如何实现、解决什么业务问题，这是数据工程师的工作。
数据工程师在业务和数据科学家之间搭建起实践的桥梁。本文要分享的大数据平台架构技术选型及场景运用偏向于工程方面。

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

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

二、数据源的特点

数据源的特点决定数据采集与数据存储的技术选型，我根据数据源的特点将其分为四大类：
  • 第一类：从来源来看分为内部数据和外部数据；
  • 第二类：从结构来看分为非结构化数据和结构化数据；
  • 第三类：从可变性来看分为不可变可添加数据和可修改删除数据；
  • 第四类，从规模来看分为大量数据和小量数据。
内部数据

来自企业内部系统，可以采用主动写入技术(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的场景。

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

以上为本次分享的全部内容。

引用
作者：张逸，大眼科技CTO，先后就职于中兴通讯、惠普GDCC、中软国际、ThoughtWorks等中外企业，任职角色为高级软件工程师，架构师，技术总监，首席咨询师。目前致力于商业智能产品与大数据分析平台的开发与架构设计。
声明：本篇文章内容来自第八期魅族开放日大眼科技CTO张逸的现场分享，由IT大咖说提供现场速录，由msup整理编辑。
  • 大小: 125.5 KB
  • 大小: 40.6 KB
  • 大小: 33.1 KB
  • 大小: 73.3 KB
  • 大小: 163.7 KB
  • 大小: 173.4 KB
  • 大小: 160.7 KB
  • 大小: 119.5 KB
  • 大小: 31.8 KB
  • 大小: 44.7 KB
  • 大小: 193.3 KB
2
顶
0
踩
评论 共 0 条 请登录后发表评论

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

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

    Hadoop生态系统中的MapReduce和Spark是常用的批处理框架，Kafka和Flink是常用的流处理...根据具体的需求和场景，选择适合的技术组合，能技术组合，能够构建出高效可靠的大数据平台，为各行业提供数据驱动的决策支持。

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

    大数据平台偏向于工程方面，大数据平台一般包括数据源、数据采集、数据存储、数据分析等方面。 讲师从数据来源、数据源结构、数据变化程度和数据规模等4个维度对数据源进行分类，数据源分类维度的不同决定最后的技术...

  • 【转载】大数据平台架构技术选型与场景运用

    https://blog.csdn.net/qiansg123/article/details/80130106 

  • 大数据技术架构如何选型

    最后是运维成本，这个其实涉及到产品的应用形态，如果只是SaaS公有云，则是可控的，如果私有化部署的场景非常多，则运维成本会非常大，也可能在选型时起到决定性的作用。即做大数据是满足业务诉求的，业务诉求会有很...

  • 大数据平台架构及主流技术栈

    互联网和移动互联网技术开启了大规模生产、分享和应用数据的大数据时代。面对如此庞大规模的数据，如何存储？...经过十几年的发展，如今的大数据技术生态已相对成熟，围绕大数据应用搭建的平台架构和技术选型也逐

  • 天然气汽车供气系统减压装置毕业设计（cad+设计方案）.zip

    天然气汽车供气系统减压装置毕业设计（cad+设计方案）

  • PHP+SQL考勤系统安全性实现(源代码+论文+答辩PPT+指导书)

    PHP+SQL考勤系统安全性实现(源代码+论文+答辩PPT+指导书)

  • NumPy 的用途是什么

    NumPy 的用途是什么

  • 毕业设计 基于javaweb的在线答题平台

    毕业设计 基于javaweb的在线答题平台

  • 基于MATLAB的pca人脸识别.zip

    基于MATLAB的pca人脸识别.zip

  • 课设毕设基于SSM的信息类课程教学知识管理系统LW+源码可运行.zip

    课设毕设基于SSM的系统源码可运行

  • JAVAWML信息查询与后端信息发布系统实现-WML信息查询设计(源代码+LW).zip

    JAVAWML信息查询与后端信息发布系统实现——WML信息查询设计(源代码+LW)

  • 毕业设计[整站程序]情感家园站 v3.0 For 个人版_qgweb30fp.zip

    毕业设计[整站程序]情感家园站 v3.0 For 个人版_qgweb30fp.zip

  • 熊猫脚本助手V1.8.zip

    可以自动刷课，执行重复的脚本工作，内有详细操作教程。支持WIN7---WIN10系统。

  • Java项目之实验室计算机故障报修系统（源码）

    Java项目之实验室计算机故障报修系统（源码） 开发语言：Java 框架：ssm 技术：JSP JDK版本：JDK1.8 服务器：tomcat7 数据库：mysql 5.7（一定要5.7版本） 数据库工具：Navicat11 开发软件：eclipse/myeclipse/idea Maven包：Maven3.3.9

  • 使用hapi框架搭建 基于协同过滤的美食推荐系统——后台.zip

    协同过滤算法（Collaborative Filtering）是一种经典的推荐算法，其基本原理是“协同大家的反馈、评价和意见，一起对海量的信息进行过滤，从中筛选出用户可能感兴趣的信息”。它主要依赖于用户和物品之间的行为关系进行推荐。 协同过滤算法主要分为两类： 基于物品的协同过滤算法：给用户推荐与他之前喜欢的物品相似的物品。 基于用户的协同过滤算法：给用户推荐与他兴趣相似的用户喜欢的物品。 协同过滤算法的优点包括： 无需事先对商品或用户进行分类或标注，适用于各种类型的数据。 算法简单易懂，容易实现和部署。 推荐结果准确性较高，能够为用户提供个性化的推荐服务。 然而，协同过滤算法也存在一些缺点： 对数据量和数据质量要求较高，需要大量的历史数据和较高的数据质量。 容易受到“冷启动”问题的影响，即对新用户或新商品的推荐效果较差。 存在“同质化”问题，即推荐结果容易出现重复或相似的情况。 协同过滤算法在多个场景中有广泛的应用，如电商推荐系统、社交网络推荐和视频推荐系统等。在这些场景中，协同过滤算法可以根据用户的历史行为数据，推荐与用户兴趣相似的商品、用户或内容，从而提高用户的购买转化率、活跃度和社交体验。 未来，协同过滤算法的发展方向可能是结合其他推荐算法形成混合推荐系统，以充分发挥各算法的优势。

  • JAVAWEB校园二手平台项目.zip

    JAVAWEB校园二手平台项目，基本功能包括：个人信息、商品管理；交易商品板块管理等。本系统结构如下： （1）本月推荐交易板块： 电脑及配件：实现对该类商品的查询、用户留言功能 通讯器材：实现对该类商品的查询、用户留言功能 视听设备：实现对该类商品的查询、用户留言功能 书籍报刊：实现对该类商品的查询、用户留言功能 生活服务：实现对该类商品的查询、用户留言功能 房屋信息：实现对该类商品的查询、用户留言功能 交通工具：实现对该类商品的查询、用户留言功能 其他商品：实现对该类商品的查询、用户留言功能 （2）载入个人用户： 用户登陆 用户注册 （3）个人平台： 信息管理：实现对商品的删除、修改、查询功能 添加二手信息：实现对新商品的添加 修改个人资料：实现对用户个人信息的修改 注销

  • 基于协同过滤和SVD算法的音乐推荐系统.zip

    协同过滤算法（Collaborative Filtering）是一种经典的推荐算法，其基本原理是“协同大家的反馈、评价和意见，一起对海量的信息进行过滤，从中筛选出用户可能感兴趣的信息”。它主要依赖于用户和物品之间的行为关系进行推荐。 协同过滤算法主要分为两类： 基于物品的协同过滤算法：给用户推荐与他之前喜欢的物品相似的物品。 基于用户的协同过滤算法：给用户推荐与他兴趣相似的用户喜欢的物品。 协同过滤算法的优点包括： 无需事先对商品或用户进行分类或标注，适用于各种类型的数据。 算法简单易懂，容易实现和部署。 推荐结果准确性较高，能够为用户提供个性化的推荐服务。 然而，协同过滤算法也存在一些缺点： 对数据量和数据质量要求较高，需要大量的历史数据和较高的数据质量。 容易受到“冷启动”问题的影响，即对新用户或新商品的推荐效果较差。 存在“同质化”问题，即推荐结果容易出现重复或相似的情况。 协同过滤算法在多个场景中有广泛的应用，如电商推荐系统、社交网络推荐和视频推荐系统等。在这些场景中，协同过滤算法可以根据用户的历史行为数据，推荐与用户兴趣相似的商品、用户或内容，从而提高用户的购买转化率、活跃度和社交体验。 未来，协同过滤算法的发展方向可能是结合其他推荐算法形成混合推荐系统，以充分发挥各算法的优势。

Global site tag (gtag.js) - Google Analytics