从数据到大数据,数据技术&工具的演变

0 评论 3261 浏览 9 收藏 22 分钟

编辑导语:大数据近些年来是一个十分火热的话题,关于大数据的文章也是数不胜数。本文作者通过梳理自己看过的大数据相关的资料和书籍,为我们介绍了从“小数据”演化为“大数据”的过程是怎样的?并且分享了一些数据技术以及工具。

对于大数据,叮当一直都很感兴趣,最近正好在看数据相关的书和资料,就把这些东西梳理了一下。本文将用4张逻辑图为主线,简单介绍一个产品从“小数据”演化为“大数据”的过程,及可能用到的工具。

本文核心逻辑:

一、一个简陋版互联技术架构

假设我们要搭建一个小网站,在不使用成熟SaaS产品的前提下,我们的产品里面最少要有以下两个部分:

1. 客户端

可以是APP,小程序,甚至是一个Web网站,作为入口给我们的用户访问。

2. 服务端

服务端包括应用服务器和数据库,应用服务器用来部署应用端程序,处理前端请求,并进行服务响应;数据库用来存储数据,服务器通过专门与数据库交互的程序对数据库进行读写操作(如:SQL)。

1. 我们是如何与技术系统交互的?

假设一个场景:张三打开了一个小网站,打开后出现了登录界面,张三输入自己的账号和密码之后点击“登录”,这时客户端会发送给服务端一个请求,查询一下数据库里有没有张三的账号信息。

如果数据库有的话张三就能登录成功,可以使用小网站了;如果数据库没有张三的账号信息,可能就会引导张三先进行注册,注册成功后数据库中的用户表中就会新增一条张三的信息,张三就能愉快的使用小网站了。

我们通过客户端入口与这个系统交互,我们通过操作客户端界面,对服务端进行请求拉取服务器&数据库中的信息,给予我们反馈。

2. 服务器与数据库有什么区别?

一般我们常称为“服务器”的全称叫“应用服务器”,数据库全称叫“数据库服务器”,它们都是服务器,只是由于应用环境的不同,需要的性能不同做了区分。

数据库服务器的处理器性能要求比较高,因为其要进行频繁的操作,内存要求大,加快数据存取速度,应用服务器相对而言要求低一些。

3. 常用数据库有哪些?

常用数据库主要有“关系型数据库”和“非关系型数据库”:

1)关系型数据库

折射现实中的实体关系,将现实中的实体关系拆分维度,通过关系模型表达出来(表及表与表之间的关系),常用的有MySQL(开源数据库)、SQL Server(微软家的)、Oracle(甲骨文家的,有完善的数据管理功能可以实现数据仓库操作)。

2)非关系型数据库

一种相对松散且可以不按严格结构规范进行存储的数据库,一边叫NoSQL(常用的有mongoDB、 CouchDB,在MongoDB中使用键值对的方式表示和存储数据,键值类似关系型数据库表中的字段名对应的值,在MngoDB中,使用JSON格式的数据进行数据表示和存储)。

二、随着用户增长技术架构的升级

小网站的用户逐渐越来越多,小网站变成了大网站,单个服务器的负载很快就到了极限,这时就需要增加多台服务器,组成服务器组,同时引入负载均衡服务器,对流量进行动态分配。

由于数据是互联网产品的核心资产,为了保证系统数据的安全性,还需要增加数据备份服务器,多台数据库服务器同时运行,这样哪怕一个数据库出问题了,也不会影响业务正常运转。

三、数据仓库的诞生

随着产品用户量越来越大,市场竞争也更加激烈,迫切需要更加准确的战略决策信息,数据库中的数据虽然对于产品的运营非常有用,但由于结构复杂,数据脏乱,难以理解,缺少历史,大规模查询等问题对商业决策和目标制定的作用甚微。

在更好的发挥数据价值,1990数据仓库之父比尔·恩门(Bill Inmon)提出了“数据仓库”的概念,构建一种对历史数据进行存储和分析的数据系统,支撑企业的商业分析与战略决策。

1. 数据仓库的实现原理是什么?

数据仓库的数据来源通常是历史业务数据(订单数据、商品数据、用户数据、操作日志、行为数据……),这些数据统一汇总存储至企业数据仓库,通过对仓库里的综合数据进行有目的的分析支撑业务决策。

2. 数据库与数据仓库有什么区别?

数据库是对实时数据进行存储和事务性处理的系统,而数据仓库则是为了分析而设计。

3. 数据仓库与大数据仓库有什么区别?

数据仓库与大数据仓库的区别:大数据=海量数据+处理技术+平台工具+场景应用,数据仓库是一个数据开发过程,其区别主要体现在:商业价值、处理对象、生产工具三个方面。

1)商业价值

都是业务驱动的,有明确的业务场景需求,通过海量数据分析为业务提供决策依据,“传统数仓”出现更早,场景单一保守(报表,BI);而大数据技术更成熟成本更低,应用场景更多(用户画像、推荐、风控、搜索……)

2)处理对象

都是对数据进行获取、加工、管理、治理、应用处理,但大数据处理数据类型更多样化,传统数仓基本只擅长处理结构化和半结构化的数据。

3)生产工具

“传统数仓”一般采购国外知名厂商成熟方案,价格昂贵可拓展性差,“大数据”则有成套的开源技术。

建设方法:大数据技术沿用了“传统数仓的数据建设理论,但由于在处理技术上新增了非结构化数据,生产工具上新增了流式计算(比实时计算要稍微迟钝些,但比离线计算又实时的多)。

四、大数据技术架构

1. 什么是大数据?

一种规模大到在获取、存储、管理、分析方面大大超出了传统数据库软件工具能力范围的数据集合,具有海量的数据规模(一般以TB为起始单位)、快速的数据流转、多样的数据类型和价值密度低四大特征——麦肯锡全球研究

根据“海量的数据规模”、“快速的数据流转”、“多样的数据类型”、“价值密度低”去看,符合这些特点的大都是平台型公司,有海量用户产生内容。

Facebook基础设施工程副总裁杰·帕里克(Jay Parikh)曾透露,Facebook每天处理的数据量多达500TB(1TB=1000GB)。

2. 什么是分布式计算?

看完上面,你可能会想,像Facebook每天500TB的数据量要用什么样的技术才能处理呢?

这就要引入“分布式计算”了,既然单个数据库的计算能力有限,那我们就把大量的数据分割成多个小块,由多台计算机分工完成,然后将结果汇总,这些执行分布式计算的计算机叫做集群。

如果还不理解的话我们举个栗子:假期要结束了张三还有有10份作业没写,他找了5个同学,每个同学写2份,最后汇总给张三。

大数据时代存储计算的经典模型,Apache基金会名下的Hadhoop系统,核心就是采用的分布式计算架构,也是Yahoo、IBM、Facebook、亚马逊、阿里巴巴、华为、百度、腾讯等公司,都采用技术架构(下方逻辑图中黄框部分都是Hadoop生态的成员)。

3. 大数据架构与模块主要有哪些?

大数据架构主要可以分为:数据采集,数据存储,计算查询,数据服务,数据应用5个环节。

1)数据采集

通过采集工具把结构化数据进行采集、分发、校验、清洗转换;非结构化数据通过爬取,分词,信息抽取,文本分类,存入数据仓库中。

2)数据存储

一般分3层,最底层的式ODS(操作数据)层,直接存放业务系统抽取过来的数据,将不同业务系统中的数据汇聚在一起;中间是DW(数据仓库)层,存放按照主题建立的各种数据模型;最上层是DM(数据集市)层,基于DW层上的基础数据整合汇总成分析某一个主题域的报表数据。

3)计算查询

根据具体的需求选择对应的解决方案:离线、非实时、静态数据的可以用批处理方案;非离线、实时、动态数据、低延迟的场景可用流处理方案。

4)数据服务

通过API把数仓中海量的数据高效便捷的开放出去支撑业务,发挥数据价值。

5)数据应用

基于数据仓库中结构清晰的数据高效的构建BI系统支撑业务决策;根据海量的数据构建以标签树为核心的用户画像系统,为个性化推荐、搜索等业务模块提供支撑。

4. 大数据采集模块

一般应用于公司日志平台,将数据缓存在某个地方,供后续的计算流程进行使用 针对不同数据源(APP,服务器,日志,业务表,各种API接口,数据文件……)有各自的采集方式。

目前市面上针对日志采集的有 Flume、Logstash、Kafka……

1)Flume

是一款 Cloudera 开发的实时采集日志引擎,主打高并发、高速度、分布式海量日志采集,支持在日志系统中定制各类数据发送,支持对数据简单处理并写给各种数据接受方,主要特点:

  • 侧重数据传输,有内部机制确保不会丢数据,用于重要日志场景;
  • 由java开发,没有丰富的插件,主要靠二次开发;
  • 配置繁琐,对外暴露监控端口有数据。最初定位是把数据传入HDFS中,跟侧重于数据传输和安全,需要更多二次开发配置。

2)Logstash

是 Elastic旗下的一个开源数据收集引擎,可动态的统一不同的数据源的数据至目的地,搭配 ElasticSearch 进行分析,Kibana 进行页面展示,主要特点:

  • 内部没有一个persist queue(存留队列),异常情况可能会丢失部分数据;
  • 由ruby编写,需要ruby环境,插件很多;
  • 配置简单,偏重数据前期处理,分析方便 侧重对日志数据进行预处理为后续解析做铺垫,搭配ELK技术栈使用简单。

3)Kafka

最初是由领英开发,2012 年开源由Apache Incubato孵化出站。以为处理实时数据提供一个统一、高吞吐、低延迟的平台,适合作为企业级基础设施来处理流式数据 (本质是:按照分布式事务日志架构的大规模发布/订阅消息队列)。

4)Sqoop

与上面的日志采集工具不同,Sqoop的主要功能是为 Hadoop 提供了方便的 RDBMS(关系型数据库)数据导入功能,使得传统数据库数据向 HBase 中迁移变的非常方便。

5. 大数据存储&资源管理模块

在数据量小的时候一般用单机数据库(如:MySQL) 但当数据量大到一定程度就必须采用分布式系统了,Apache基金会名下的Hadhoop系统是大数据时代存储计算的经典模型。

1)HDFS

是 Hadoop里的分布式文件系统,为HBase 和 Hive提供了高可靠性的底层存储支持。

2)HBase

是Hadoop数据库,作为基于非关系型数据库运行在HDFS上,具备HDFS缺乏的随机读写能力,比较适合实时分析。

3)Yarn

是一种新的 Hadoop 资源管理器,它是一个通用资源管理系统,可为上层应用提供统一的资源管理和调度,它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

6. 大数据计算查询模块

这里首先要介绍一下批处理和流处理的区别:

  • 批计算:离线场景、静态数据、非实时、高延迟(场景:数据分析,离线报表……)
  • 流计算:实时场景,动态数据,实时,低延迟(场景:实时推荐,业务监控……)

大数据常用的计算查询引擎主要有:Hive、Spark、Presto、Presto、Kylin、Druid……

1)Hive

是基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张数据库表,并提供完整的sql查询功能,可以将sql语句转换为MapReduce任务进行运行,其优点是学习成本低。

2)Spark

Spark是加州大学伯克利分校AMP实验室所开源的专门用于大数据量下的迭代式计算,是为了跟 Hadoop 配合:

  • 批处理模式下的类Hadoop MapReduce的通用并行框架,Spark 与 MapReduce 不同,它将数据处理工作全部在内存中进行,提高计算性能;
  • 流处理模式下,Spark 主要通过 Spark Streaming 实现了一种叫做微批(Micro-batch)的概念可以将数据流视作一系列非常小的“批”,借此即可通过批处理引擎的原生语义进行处理;
  • Spark适合多样化工作负载处理任务的场景,在批处理方面适合众数吞吐率而非延迟的工作负载,SparkSQL兼容可以把Hive作为数据源spark作为计算引擎。

3)Presto

由 Facebook 开源,是一个分布式数据查询框架,原生集成了 Hive、Hbase 和关系型数据库。但背后的执行模式跟Spark类似,所有的处理都在内存中完成,大部分场景下要比 Hive 快一个数量级。

4)Kylin

Cube 预计算技术是其核心,基本思路是预先对数据作多维索引,查询时只扫描索引而不访问原始数据从而提速。劣势在于每次增减维度必须对 Cube 进行历史数据重算追溯,非常消耗时间。

5)Druid

由 MetaMarket 开源,是一个分布式、面向列式存储的准实时分析数据存储系统,延迟性最细颗粒度可到 5 分钟。它能够在高并发环境下,保证海量数据查询分析性能,同时又提供海量实时数据的查询、分析与可视化功能。

7.  数据可视化模块

1)可视化框架

开源可视化框架:业界比较有名的式Superset和Metabase

Superset的方案更加完善,支持聚合不同数据源形成对应的指标,再通过丰富的图表类型进行可视化,在时间序列分析上比较出色,与Druid深度集成,可快速解析大规模数据集;但不支持分组管理和图表下钻及联动功能,权限管理不友好。

Metabase比较重视非技术人员的使用体验,界面更加美观,权限管理上做的比较完善,无需账号也可以对外共享图表和数据内容;但在时间序列分析上 不支持不同日期对比,还需要自动逸SQL实现,每次查询只能针对一个数据库,操作比较繁琐。

2)可视化软件

商用软件主流的主要有:PowerBI 、Tableau、FineBI

Tableau:操作简单,可视化,基本所有的功能都可以拖拽实现,但价格贵,且数据清洗功能一般,需要有较好的数据仓库支持 ;

FineBI:操作简单,与Tableau类似,但数据清洗能力比Tableau要好,付费方式采用按功能模块收费,永久买断;

PowerBI :可以做复杂报表,筛选、计算逻辑清晰,可自定义,但很多功能要用DAX编程序,托拉拽能实现的功能很有限,不易入门。

 

【参考书籍】

《产品经理必懂的技术那点事》:主要是关于产品经理需要了解的技术知识的科普,无论是为了减少撕*,还是提高自己写需求的专业能力,这本书都值得产品经理一读。

《大数据架构商业之路》:主要是关于大数据技术的介绍,和常用大数据技术的优缺点,可以当作词典使用。

【参考文章】

《深入浅出大数据:到底什么是Hadoop?》

《数据人必须了解的大数据中台技术架构》

 

作者:小叮当,前营销工具产品经理,做过各种C端营销工具,设计过SaaS工具,数据产品经理转行中,坐标北京,有相关机会欢迎联系;公众号:小叮当运营笔记;微信:zxxp153

本文由 @小叮当 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!