大数据中台架构栈说课材料.docx
《大数据中台架构栈说课材料.docx》由会员分享，可在线阅读，更多相关《大数据中台架构栈说课材料.docx（13页珍藏版）》请在冰豆网上搜索。
大数据中台架构栈说课材料
大数据中台架构栈
近来数据中台概念大火，大家对它的定义也五花八门，不一而足。
但无论怎么定义，一个完善的数据技术架构必不可少。
了解这些架构里每个部分的位置，功能和含义，不仅能让我们更好了解数据产品的范围和边界，知道技术能帮我们实现什么，能怎么实现得更好，另一方面，很多技术的设计理念对我们认知世界，了解复杂系统也会有所裨益。
因此这篇文章旨在梳理市面上常见的开源技术方案，背后原理及应用场景，帮助产品经理对大数据技术体系有个大致全面的了解。
一般来说，我们将数据整个链条区分为四个环节，从数据采集传输，到数据存储，再到数据计算&查询，到后续的数据可视化及分析。
框架图如下：
1.数据采集传输
这个一般对应于公司的日志平台，任务是将数据采集后缓存在某个地方，供后续的计算流程进行消费使用。
针对不同的数据来源有各自的采集方式，从APP/服务器日志，到业务表，还有各种API接口及数据文件等等。
其中因为日志数据有数据量多，数据结构多样，产生环境复杂等特点，属于「重点关照」的对象。
目前市面针对日志采集的有Flume，Logstash，Filebeat，Fluentd，rsyslog几种常见的框架，我们挑应用较广泛的前两者介绍下：
1.1Flume和Logstash Flume是一款由Cloudera开发的实时采集日志引擎，主打高并发，高速度，分布式海量日志采集。
它是一种提供高可用、高可靠、分布式海量日志采集、聚合和传输的系统。
Flume支持在日志系统中定制各类数据进行发送，用于采集数据；同时，它支持对数据进行简单处理，并写到各种数据接收方。
目前有两个版本，OG和NG，特点主要是：
1.侧重数据传输，有内部机制确保不会丢数据，用于重要日志场景
2.由java开发，没有丰富的插件，主要靠二次开发
3.配置繁琐，对外暴露监控端口有数据
Logstash是Elastic.co旗下的一个开源数据收集引擎，可动态的统一不同的数据源的数据至目的地，搭配ElasticSearch进行分析，Kibana进行页面展示，是著名的ELK技术栈中的「L」部分。
特点主要是：
1.内部没有一个persistqueue，异常情况可能会丢失部分数据
2.由ruby编写，需要ruby环境，插件很多
3.配置简单，偏重数据前期处理，分析方便
从两者的设计思想来看，Flume最初并不是为了采集日志而设计，而是定位在把数据传入HDFS中，这和Logstash有根本的区别。
所以它理所应当侧重于数据的传输和安全，且需要更多的二次开发和配置工作。
而Logstash明显侧重先对日志数据进行预处理，为后续的解析做铺垫。
它搭配ELK技术栈使用起来比较简单，更像是为你准备好的便当，开盒即食。
1.2日志采集如何工作
我们以Flume为例子讲些日志采集Agent是怎么工作的。
Flume由三个部分组成：
Source，Channel和Sink，对应于采集，缓存和保存三个环节。
其中，Source组件用来采集各种类型的数据源，如directory、http、kafka等。
Channel组件用来缓存数据，有memorychannel，JDBCchannel和kafkachannel三种。
最后再通过Sink组件进行保存，分别支持HDFS，HBase，Hive和Kafka四种存储方式。
下面结合一个大数据实时处理系统阐述下Flume在实际应用中所扮演的重要角色。
该实时处理系统整体架构如下：
通过将Agent部署在Web服务器，一旦发生新增的日志数据，就会被Flume程序监听到，并且最终会传输到Kafka的Topic中，再进行后续的一系列操作。
1.3数据传输Kafka
Kafka最初是由领英开发，并随后于2011年初开源,并于2012年10月23日由ApacheIncubato孵化出站。
该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。
其持久化层本质上是一个“按照分布式事务日志架构的大规模发布/订阅消息队列”，这使它作为企业级基础设施来处理流式数据非常有价值。
2.数据存储
数据库存储方面，有单机/分布式、关系型/非关系型、列式存储/行式存储三个维度的划分，各种维度交叉下都有对应产品来解决某个场景下的需求。
在数据量较小的情况下，一般采取单机数据库，如应用非常广泛，技术成熟的MySQL。
数据量大到一定程度后，就必须采取分布式系统了。
目前业界最知名的就是Apache基金会名下的Hadoop系统，它基本可以作为大数据时代存储计算的经典模型。
HDFS
HDFS作为Hadoop里的分布式文件系统，为HBase和Hive们提供了高可靠性的底层存储支持，对应于GoogleGFS的开源实现。
一般也会用于一些批次分析的场景。
HBase
HBase是Hadoop数据库，作为基于列的非关系型数据库运行在HDFS上。
它具备HDFS缺乏的随机读写能力，因此比较适合实时分析。
HBase以GoogleBigTable为蓝本，以Key-Value形式存储，能快速在主机内数十亿行数据中定位所需的数据并访问它。
Hive和Pig
Hive和Pig都是集成在Hadoop顶层的查询语言，提供静态数据的动态查询，支持类SQL语言，底层经过编译转为MapReduce程序，省去了自己编写MR程序的繁琐。
区别是HiveSQL是类SQL的查询语言，要求数据存储于表中，而Pig是面向数据流的一个程序语言，常用于开发简洁的脚本来转换数据流从而嵌入到较大的应用程序中。
MapReduce
MR开创了分布时代计算的先河，使得大批量数据处理成为可能。
简单来讲，就是将比较庞大的计算任务先分组，再汇总，提高计算效率。
举例来讲，如果你新家需要装修，要在不同地方购置很多东西。
你一个人（单机）去买估计得花十天。
现在叫了一堆小伙伴（分布式），每个人负责去一个地方买东西（Map），最后再拿到家里分类汇总（Reduce），一天就搞定了。
其他辅助工具
上图中的其他工具是为了保证整个大数据计算存储系统更加健壮和开放，如Zookeeper提供了稳定服务和failover机制，Sqoop则为Hadoop提供了方便的RDBMS（关系型数据库）数据导入功能，使得传统数据库数据向HBase中迁移变的非常方便。
值得一提的是，Hadoop生态其实是建立在Google2003年发表的三大论文的基础之上。
可能是当时Google有意改善业内落后的现状，让大家稍微跟得上他的脚步才发布的论文…这么多年过去了，不知道Google内部对数据的理解和使用又到了什么样的高度。
3.数据计算&查询3.1批计算和流计算
大数据处理场景可分为批处理和流处理两个，分别对应离线分析和实时分析。
常见框架分类有：
1.仅批处理框架：
HadoopMapReduce
2.仅流处理框架：
Storm，Samza
3.混合框架：
Spark，Flink
篇幅所限，除了上文已经提到的Hadoop生态外，我们再简单科普下Spark：
3.2Spark和Flink
ApacheSpark是一种包含流处理能力的下一代批处理框架。
批处理模式下，Spark与MapReduce不同，它将数据处理工作全部在内存中进行，计算性能大幅改善。
流处理模式下，Spark主要通过SparkStreaming实现了一种叫做微批（Micro-batch）的概念。
该技术可以将数据流视作一系列非常小的“批”，借此即可通过批处理引擎的原生语义进行处理。
这种方式的实际效果非常好，但相比真正的流处理框架在性能方面依然存在不足。
综上所述，Spark是多样化工作负载处理任务的最佳选择。
Spark批处理能力以更高内存占用为代价提供了无与伦比的速度优势。
对于重视吞吐率而非延迟的工作负载，则比较适合使用SparkStreaming作为流处理解决方案。
而Flink作为更新一代的处理框架，拥有更快的计算能力，更低的延迟，已经慢慢崭露头角。
不过一个框架的应用，特别是开源框架，需要足够长的时间进行运行，测试和优化。
大数据技术在开源社区的推动下，迭代日新月异。
在不久的将来，相信Flink会像Spark取代Storm一样，逐渐成为大数据处理技术的主流。
3.3数据查询
经过处理后的数据，还需要有高效的查询引擎才能被用户接触和使用。
目前OLAP的查询技术框架大致可分为三类：
1.基于HBase做预聚合：
如Opentsdb,Kylin等，均需指定预聚合的指标，在数据接入的时候进行聚合运算，适合相对固定，维度较多的业务报表类需求
2.基于Parquet做列式存储：
如Presto,Drill，Impala等，基本是完全基于内存的并行计算，Parquet系能降低存储空间，提高IO效率，以离线处理为主，很难提高数据写的实时性，超大表的Join支持可能不够好
3.基于Lucene做外部索引：
如ElasticSearch，Solr等，能够满足的的查询场景远多于传统的数据库存储，但对于日志、行为类时序数据，所有的搜索请求都也必须搜索所有的分片，另外，对于聚合分析场景的支持也是软肋
我们以常见的 Presto，Druid，Kylin三个模型来讲讲各自的特点：
1.Presto：
由Facebook开源，是一个分布式数据查询框架，原生集成了Hive、Hbase和关系型数据库。
它背后所使用的执行模式与Hive有根本的不同，并没有使用MapReduce。
因其所有的处理都在内存中完成（与上文的Spark类似），大部分场景下要比Hive快一个数量级
2.Druid：
由MetaMarket开源，是一个分布式、面向列式存储的准实时分析数据存储系统，延迟性最细颗粒度可到5分钟。
它能够在高并发环境下，保证海量数据查询分析性能，同时又提供海量实时数据的查询、分析与可视化功能
3.Kylin：
Cube预计算技术是其核心，基本思路是预先对数据作多维索引，查询时只扫描索引而不访问原始数据从而提速。
劣势在于每次增减维度必须对Cube进行历史数据重算追溯，非常消耗时间。
据说Kylingence在前几天的新品发布会上已经解决了这个问题，拭目以待
下图引自快手在OLAP技术选型时的评价，以供大家参考：
很多时候，在计算和查询这块没有明显的边界区分。
这里为了方便阐述分成了两个部分。
事实上，对于技术能力比较强的团队，可以针对这些开源系统进行魔改，比如采用Kylin的预计算能力+Druid的查询引擎，来提高查询的速度等等。
4.数据可视化及分析
在数据可视化这块，一般会采取三个途径来进行数据展示。
最基础的利用开源的图表库，如国外的HighCharts、D3，XX的ECharts，还有阿里Antv的G2、G6、F2等。
往上一层是各个知名公司开源的可视化框架，如Airbnb的Superset，Redash，Metabase等等。
这些框架一般能够满足从数据源接入，自助制作报表和报表整理展示的功能，接入起来更加方便。
再往上一层就是商用的可视化软件，如国外的Tableau，Qlik，国内的FineReport，永洪BI等等。
这种软件需要付费，但都具备更丰富的可视化功能并提供一些技术支持，对于那些没有精力折腾可视化的公司会是个不错的选择。
4.1图表库
理解整个图表开源生态，我们得先了解下SVG和Canvas这两个浏览器提供的原生能力。
SVG全称叫可缩放矢量图，跟HTML一样，有自己的命名空间，使用XML标签来绘图。
而Canvas是HTML5中的新标签，用于客户端的图形绘制，有一个基于Java的绘图API。
D3.js全称是Data-DrivenDocuments，支持SVG和Canvas。
相对于其他产品，它更偏底层，并没有对图表进行归类。
开发者可以通过D3丰富的类库来方便的操作DOM，绘制任何想绘制的图形，以增加开发复杂度的代价，覆盖更加全面的可视化场景。
而国外的HighCharts是基于SVG开发的图表库，ECharts和G2则均基于Canvas。
ECharts有完整的图表封装，开箱即用，而G2则是一套基于可视化编码的图形语法，以数据驱动，具有高度的易用性和扩展性。
阿里后续基于G2又往上封装了一套基于React的图表库Bizcharts，主打电商业务图表可视化，沉淀电商业务线的可视化规范。
在React项目中实现常见图表和自定义图表。
ECharts和G2的对比可借用ECharts作者的一句话，G2是面粉，ECharts是面条，皆微小但美好。
4.2可视化框架
这里主要介绍下业内比较出名的Superset和Metabase。
前者的方案更加完善，支持集合不同数据源形成对应的指标，再通过丰富的图表类型进行可视化。
在时间序列分析上比较出色，支持移动平均及周期偏移等分析方法。
同时与Druid深度集成，可以快速解析大规模数据集。
劣势则是不支持分组管理报表，一旦报表多了使用起来很麻烦。
且不提供图表下钻及联动功能，权限管理也不够友好。
Metabase则比较注重非技术人员（如产品经理和运营人员）的使用体验，让他们能自由地探索数据，回答自己的问题，界面相对来讲更加美观。
在权限管理上做得较为完善，甚至无需账号也可以对外共享图表和数据内容。
Dashboard支持分类，便于管理报表。
劣势在时间序列分析上不支持不同日期对比，还需要自定义SQL实现。
每次查询仅能针对一个数据库查询，操作比较繁琐。
在数据挖掘这块，目前主要集中在商用公司这块，通过和某些行业深度合作，从而训练和深化自己的学习模型，这里不多赘述。
升级会员 