大数据中台架构栈

近来数据中台概念大火，大家对它的定义也五花八门，不一而足。但无论怎么定义，一个完善的数据技术 架构必不可少。了解这些架构里每个部分的位置，功能和含义，不仅能让我们更好了解数据产品的范围和 边界，知道技术能帮我们实现什么，能怎么实现得更好，另一方面，很多技术的设计理念对我们认知世界， 了解复杂系统也会有所裨益。因此这篇文章旨在梳理市面上常见的开源技术方案，背后原理及应用场景， 帮助产品经理对大数据技术体系有个大致全面的了解。一般来说，我们将数据整个链条区分为四个环节，从数据采集传输，到数据存储，再到数据计算&查询，到 后续的数据可视化及分析。框架图如下：图義控件HighCtiarts/Echarte可视化框架fit据廉示H甘析数据挖掘机器学习任务调HiveSparkKinPrestoDruid便卑 MR/3? SQL快遇/内存计M/ttl多划dm樓计尊内存It斛5熾銮吋分析用武徵据计鼻&世遛ZooKBcpcrYarnHDFSHBaseMySQLTiDB分祁式州Hdoop展曬列凤存 fii/hlciSQL应用rv单wi?关昴誉S6AU金爾軽合式I酸誓存fiiSqoopFUebeat轻量堀日志KafkaT ourStone?1. 数据采集传输这个一般对应于公司的日志平台，任务是将数据采集后缓存在某个地方，供后续的计算流程进行消费使用。针对不同的数据来源有各自的采集方式，从APP/服务器日志，到业务表，还有各种API接口及数据文件 等等。其中因为日志数据有数据量多，数据结构多样，产生环境复杂等特点，属于重点关照的对象。 目前市面针对日志采集的有Flume，Logstash，Filebeat，Fluentd ，rsyslog几种常见的框架，我们挑 应用较广泛的前两者介绍下：1.1 Flume和Logstash Flume是一款由Cloudera开发的实时采集日志引擎，主打高并发，高速度，分 布式海量日志采集。它是一种提供高可用、高可靠、分布式海量日志采集、聚合和传输的系统。Flume支 持在日志系统中定制各类数据进行发送，用于采集数据；同时，它支持对数据进行简单处理，并写到各种 数据接收方。目前有两个版本，0G和NG，特点主要是：1. 侧重数据传输，有内部机制确保不会丢数据，用于重要日志场景2. 由java开发，没有丰富的插件，主要靠二次开发3. 配置繁琐，对外暴露监控端口有数据F Web ServerSourceSirtkHDFSChannel微信号：丁戊也门巳Logstash是Elastic.co旗下的一个开源数据收集引擎，可动态的统一不同的数据源的数据至目的地，搭 配ElasticSearch进行分析，Kibana进行页面展示，是著名的ELK技术栈中的L部分。特点主要是：1. 内部没有一个persist queue，异常情况可能会丢失部分数据2. 由ruby编写，需要ruby环境，插件很多3. 配置简单，偏重数据前期处理，分析方便IIIAnalysisArchivinglogstashMonitoringAlertingu-.微信号从两者的设计思想来看，Flume最初并不是为了采集日志而设计，而是定位在把数据传入HDFS中，这和 Logstash有根本的区别。所以它理所应当侧重于数据的传输和安全，且需要更多的二次开发和配置工作。 而Logstash明显侧重先对日志数据进行预处理，为后续的解析做铺垫。它搭配ELK技术栈使用起来比较 简单，更像是为你准备好的便当，开盒即食。1.2日志采集如何工作我们以Flume为例子讲些日志采集Agent是怎么工作的。Flume由三个部分组成：Source， Channel和Sink，对应于采集，缓存和保存三个环节。 其中，Source组件用来采集各种类型的数据源，如directory、http、kafka等。Channel组件用来缓存 数据，有memory channel， JDBC channel和kafka channel三种。最后再通过Sink组件进行保存，分 别支持HDFS, HBase, Hive和Kafka四种存储方式。下面结合一个大数据实时处理系统阐述下Flume在实际应用中所扮演的重要角色。该实时处理系统整体架 构如下：通过将Agent部署在Web服务器，一旦发生新增的日志数据，就会被Flume程序监听到，并且 最终会传输到Kafka的Topic中，再进行后续的一系列操作。1.3数据传输KafkaKafka最初是由领英开发，并随后于2011年初开源，并于2012年10月23日由Apache Incubato孵 化出站。该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。其持久化层本质上是一 个“按照分布式事务日志架构的大规模发布/订阅消息队列”，这使它作为企业级基础设施来处理流式数据 非常有价值。2. 数据存储数据库存储方面，有单机/分布式、关系型/非关系型、列式存储/行式存储三个维度的划分，各种维度交叉 下都有对应产品来解决某个场景下的需求。在数据量较小的情况下，一般采取单机数据库，如应用非常广泛，技术成熟的MySQL。数据量大到一定程 度后，就必须采取分布式系统了。目前业界最知名的就是Apache基金会名下的Hadoop系统，它基本可 以作为大数据时代存储计算的经典模型。A兀-j?卷信寻：和加两莎而丁lkafka九2GraphXULBSp專 itfcamingSpCifK -HDFSHDFS作为Hadoop里的分布式文件系统，为HBase和Hive们提供了高可靠性的底层存储支持，对应于 Google GFS的开源实现。一般也会用于一些批次分析的场景。HBaseHBase是Hadoop数据库，作为基于列的非关系型数据库运行在HDFS上。它具备HDFS缺乏的随机读写 能力，因此比较适合实时分析。HBase以Google BigTable为蓝本，以Key-Value形式存储，能快速在 主机内数十亿行数据中定位所需的数据并访问它。Hive 和 PigHive和Pig都是集成在Hadoop顶层的查询语言，提供静态数据的动态查询，支持类SQL语言，底层经 过编译转为MapReduce程序，省去了自己编写MR程序的繁琐。区别是Hive SQL是类SQL的査询语言， 要求数据存储于表中，而Pig是面向数据流的一个程序语言，常用于开发简洁的脚本来转换数据流从而 嵌入到较大的应用程序中。MapReduceMR开创了分布时代计算的先河，使得大批量数据处理成为可能。简单来讲，就是将比较庞大的计算任务先 分组，再汇总，提高计算效率。举例来讲，如果你新家需要装修，要在不同地方购置很多东西。你一个人（单机）去买估计得花十天。现在叫了一堆小伙伴（分布式），每个人负责去一个地方买东西（Map），最 后再拿到家里分类汇总（Reduce），天就搞定了。其他辅助工具上图中的其他工具是为了保证整个大数据计算存储系统更加健壮和开放，如Zookeeper提供了稳定服务和 failover机制，Sqoop则为Hadoop提供了方便的RDBMS (关系型数据库)数据导入功能，使得传统数据 库数据向HBase中迁移变的非常方便。值得一提的是，Hadoop生态其实是建立在Google 2003年发表的三大论文的基础之上。可能是当时 Google有意改善业内落后的现状，让大家稍微跟得上他的脚步才发布的论文这么多年过去了，不知道 Google内部对数据的理解和使用又到了什么样的高度。3. 数据计算&查询3.1批计算和流计算大数据处理场景可分为批处理和流处理两个，分别对应离线分析和实时分析。常见框架分类有：1. 仅批处理框架：Hadoop MapReduce2. 仅流处理框架：Storm， Samza3. 混合框架：Spark， Flink篇幅所限，除了上文已经提到的Hadoop生态外，我们再简单科普下Spark：3.2 Spark 和 FlinkApache Spark是一种包含流处理能力的下一代批处理框架。批处理模式下，Spark与MapReduce不同，它将数据处理工作全部在内存中进行，计算性能大幅改善。流 处理模式下，Spark主要通过Spark Streaming实现了一种叫做微批(Micro-batch)的概念。该技术可 以将数据流视作一系列非常小的“批”，借此即可通过批处理引擎的原生语义进行处理。这种方式的实际 效果非常好，但相比真正的流处理框架在性能方面依然存在不足。综上所述，Spark是多样化工作负载处理任务的最佳选择。Spark批处理能力以更高内存占用为代价提供 了无与伦比的速度优势。对于重视吞吐率而非延迟的工作负载，则比较适合使用Spark St reaming作为 流处理解决方案。而Flink作为更新一代的处理框架，拥有更快的计算能力，更低的延迟，已经慢慢崭露头角。不过一个框 架的应用，特别是开源框架，需要足够长的时间进行运行，测试和优化。大数据技术在开源社区的推动下， 迭代日新月异。在不久的将来，相信Flink会像Spark取代Storm 一样，逐渐成为大数据处理技术的主 流。3.3数据查询经过处理后的数据，还需要有高效的查询引擎才能被用户接触和使用。目前OLAP的查询技术框架大致可 分为三类：1. 基于HBase做预聚合：如Opentsdb, Kylin等，均需指定预聚合的指标，在数据接入的时候进行聚合运 算，适合相对固定，维度较多的业务报表类需求2. 基于Parquet做列式存储：如Presto, Drill, Impala等，基本是完全基于内存的并行计算，Parquet系 能降低存储空间，提高10效率，以离线处理为主，很难提高数据写的实时性，超大表的Join支持可能不 够好3. 基于Lucene做外部索引：如ElasticSearch, Solr等，能够满足的的查询场景远多于传统的数据库存储， 但对于日志、行为类时序数据，所有的搜索请求都也必须搜索所有的分片，另外，对于聚合分析场景的支 持也是软肋我们以常见的Pres to, Druid，Kylin三个模型来讲讲各自的特点：1. Presto：由Facebook开源，是一个分布式数据查询框架，原生集成了 Hive、Hbase和关系型数据库。 它背后所使用的执行模式与Hive有根本的不同，并没有使用MapReduce。因其所有的处理都在内存中完成（与上文的Spark类似），大部分场景下要比Hive快一个数量级2. Druid:由MetaMarket开源，是一个分布式、面向列式存储的准实时分析数据存储系统，延迟性最细颗粒 度可到5分钟。它能够在高并发环境下，保证海量数据查询分析性能，同时又提供海量实时数据的查询、 分析与可视化功能3. Kylin： Cube预计算技术是其核心，基本思路是预先对数据作多维索引，查询时只扫描索引而不访问原始 数据从而提速。劣势在于每次增减维度必须对Cube进行历史数据重算追溯，非常消耗时间。据说 Kylingence在前几天的新品发布会上已经解决了这个问题，拭目以待下图引自快手在OLAP技术选型时的评价，以供大家参考:OLAP技术实现方案对比Hiw / Spark SQLKylinESDnjtd好中好好中差中好好弄奸好奸轨hems灵活性好好好中很多时候，在计算和查询这块没有明显的边界区分。这里为了方便阐述分成了两个部分。事实上，对于技 术能力比较强的团队，可以针对这些开源系统进行魔改，比如采用Kylin的预计算能力+Druid的查询引 擎，来提高查询的速度等等。4. 数据可视化及分析在数据可视化这块，一般会采取三个途径来进行数据展示。最基础的利用开源的图表库，如国外的 HighCharts、D3，百度的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丰富的类库来方便的操作D0M,绘制任何想绘制的图形，以增加开发复 杂度的代价，覆盖更加全面的可视化场景。Visual IndexBullet ChartsCalendar Viewizi-mj rfahflJ-T rDendrogram1* 厂r .Force-Di re 匚 说Graph二-金、:靈:而国外的HighCharts是基于SVG开发的图表库，ECharts和G2则均基于Canvas。ECharts有完整的 图表封装，开箱即用，而G2则是一套基于可视化编码的图形语法，以数据驱动，具有高度的易用性和扩 展性。阿里后续基于G2又往上圭寸装了一套基于React的图表库Bizcharts，主打电商业务图表可视化, 沉淀电商业务线的可视化规范。在React项目中实现常见图表和自定义图表。ECharts和G2的对比可借用ECharts作者的一句话，G2是面粉，ECharts是面条，皆微小但美好。crinw PiNan on MapUm Inm- ht wvw 1 EilWn py 曲地理坐敬地屢 GEOuMsp屮18 52口阳厂1凹 tfeantijiW微;旨号:DurcneKHB.Ki厂.AT Uuiilv - Bacu Map4.2可视化框架这里主要介绍下业内比较出名的Superset和Metabase。前者的方案更加完善，支持集合不同数据源形成 对应的指标，再通过丰富的图表类型进行可视化。在时间序列分析上比较出色，支持移动平均及周期偏移 等分析方法。同时与Druid深度集成，可以快速解析大规模数据集。劣势则是不支持分组管理报表，一旦 报表多了使用起来很麻烦。且不提供图表下钻及联动功能，权限管理也不够友好。Tim右 Scrips Table?Birth NamesFintSectn-Dashboard如|工巴兰：二兰記Trh.血.知Wh 需:二：二：器=二 工二：a1 JIMV-2Z.55fcOf ST .MnrlkupPivot TableScpciratDrTr*em*pCflieridar Hea帕坤Bok Plot日ul牯t ChartMetabase则比较注重非技术人员（如产品经理和运营人员）的使用体验，让他们能自由地探索数据，回答 自己的问题，界面相对来讲更加美观。在权限管理上做得较为完善，甚至无需账号也可以对外共享图表和 数据内容。Dashboard支持分类，便于管理报表。劣势在时间序列分析上不支持不同日期对比，还需要自 定义SQL实现。每次查询仅能针对一个数据库查询，操作比较繁琐。KPIs川 + O J0 Moniii hdsfew7361,12217,624Average review rat-ineAwrajge order 旳Tcrtal ordersOrdtn brdAy trF wMk在数据挖掘这块，目前主要集中在商用公司这块，通过和某些行业深度合作，从而训练和深化自己的学习 模型，这里不多赘述。