何谓五横，基本还是根据数据的流向自底向上划分五层，跟传统的数据仓库其实很类似，数据类的系统，概念上还是相通的，分别为数据采集层、数据处理层、数据分析层、数据访问层及应用层。同时，大数据平台架构跟传统数据仓库有一个不同，就是同一层次，为了满足不同的场景，会采用更多的技术组件，体现百花齐放的特点，这是一个难点。

具体见下图示例，这张图是比较经典的，也是妥协的结果，跟当前网上很多的大数据架构图都可以作一定的映射。

数据采集层：既包括传统的ETL离线采集、也有实时采集、互联网爬虫解析等等。

数据处理层：根据数据处理场景要求不同，可以划分为HADOOP、MPP、流处理等等。

数据分析层：主要包含了分析引擎，比如数据挖掘、机器学习、 深度学习

数据访问层：主要是实现读写分离，将偏向应用的查询等能力与计算能力剥离，包括实时查询、多维查询、常规查询等应用场景。

数据应用层：根据企业的特点不同划分不同类别的应用，比如针对运营商，对内有精准营销、客服投诉、基站分析等，对外有基于位置的客流、基于标签的广告应用等等。

数据管理层：这是一纵，主要是实现数据的管理和运维，它横跨多层，实现统一管理。

逻辑上，一般都有数据采集层、数据存储与分析层、数据共享层、数据应用层，可能叫法有所不同，本质上的角色都大同小异。

————————————————–

数据采集层：

实时采集现在也成了大数据平台的标配，估计主流就是FLUME+KAFKA，然后结合流处理+内存数据库吧，这个技术肯定靠谱，但这类开源的东西好是好，但一旦出现问题往往解决周期往往比较长。除了用FLUME，针对ORACLE数据库的表为了实现实时采集，也可以采用OGG/DSG等技术实现实时的日志采集，可以解决传统数据仓库抽全量表的负荷问题。

企业级的爬虫中心的建设难度蛮大，因为不仅仅是需要爬虫，还需要建立网址和应用知识库，需要基于网页文本进行中文分词，倒排序及文本挖掘等，这一套下来，挑战很大，当前已经有不少开源组件了，比如solr、lucent、Nutch、ES等等，但要用好它，路漫漫其修远兮。

数据源的种类比较多：

• 网站日志：

作为互联网行业，网站日志占的份额最大，网站日志存储在多台网站日志服务器上，一般是在每台网站日志服务器上部署flume agent，实时的收集网站日志并存储到HDFS上；

• 业务数据库：

业务数据库的种类也是多种多样，有Mysql、Oracle、SqlServer等，这时候，我们迫切的需要一种能从各种数据库中将数据同步到HDFS上的工具，Sqoop是一种，但是Sqoop太过繁重，而且不管数据量大小，都需要启动MapReduce来执行，而且需要Hadoop集群的每台机器都能访问业务数据库；应对此场景，淘宝开源的DataX，是一个很好的解决方案，有资源的话，可以基于DataX之上做二次开发，就能非常好的解决。当然，Flume通过配置与开发，也可以实时的从数据库中同步数据到HDFS。

• 来自于Ftp/Http的数据源：

有可能一些合作伙伴提供的数据，需要通过Ftp/Http等定时获取，DataX也可以满足该需求；

——————————

总得来讲，建设大数据采集平台非常不易，从客户的角度讲，至少要达到以下三个要求：

多样化数据采集能力：支持对表、文件、消息等多种数据的实时增量数据采集（使用flume、消息队列、OGG等技术）和批量数据分布式采集等能力（SQOOP、FTP VOER HDFS），比基于传统ETL性能有量级上的提升，这是根本。

可视化快速配置能力：提供图形化的开发和维护界面，支持图形化拖拽式开发，免代码编写，降低采集难度，每配置一个数据接口耗时很短，以降低人工成本。

统一调度管控能力：实现采集任务的统一调度，可支持Hadoop的多种技术组件（如 MapReduce、Spark 、HIVE）、关系型数据库存储过程、 shell脚本等，支持多种调度策略（时间/接口通知/手工）。

——————————-

数据处理层

MPP应该来说，是采用分布式架构对于传统数据仓库最好的替代，毕竟其实际上是变了种的关系型数据库，对于SQL提供完整支持，在HIVE做了转化分析后，数据仓库的融合建模用它来做性能绰绰有余，其性价比较传统DB2更好一点，比如经过实用，Gbase30-40台集群就能超过2台顶配的IBM 780。

MPP现在产品很多，很难做优劣判断，但一些实践结果可以说下，GBASE不错，公司很多系统已经在上面跑了，主要还是国产的，技术服务保障相对靠谱，ASTER还有待观望，自带一些算法库是有其一些优势，GreenPlum、Vertica没用过，不好说。

———————————–

只尝试过STORM和IBM STREAM，推荐IBM STREAM，虽然是商业版本，但其处理能力超过STORM不是一点半点，据说STORM也基本不更新了，但其实数据量不大，用啥都可以，从应用的角度讲，诸如IBM这种商业版本，是不错的选择，支撑各类实时应用场景绰绰有余。

流处理集群以流处理技术结合内存数据库，用以实时及准实时数据处理，基于IBM Streams流处理集群承载公司的实时业务：

———————————

数据开放层

　　HBASE很好用，基于列存储，查询速度毫秒级，对于一般的百亿级的记录查询那也是能力杠杠的，具有一定的高可用性，我们生产上的详单查询、指标库查询都是很好的应用场景。但读取数据方面只支持通过key或者key范围读取，因此要设计好rowkey。

—如何设计好HBASE RowKey？

　　Redis是K-V数据库，读写速度比HBASE更快，大多时候，HBASE能做的，Redis也能做，但Redis是基于内存的，主要用在key-value 的内存缓存，有丢失数据的可能，当前标签实时查询会用到它，合作过的互联网或广告公司大多采用该技术，但如果数据越来越大，那么，HBASE估计就是唯一的选择了？

　　另外已经基于IMPALA提供互联网日志的实时在线查询应用，也在尝试在营销平台采用SQLFire和GemFire实现分布式的基于内存的SQL关联分析，虽然速度可以，但也是BUG多多，引入和改造的代价较大。

　　Kylin当前算是基于hadoop/SPARK的多维分析的杀手级工具，应用的场景非常多，希望有机会使用。

——————-

数据应用层

每个企业应根据自己的实际规划自己的应用，其实搞应用蓝图很难，大数据架构越上层越不稳定，因为变化太快，以下是运营商对外变现当前阶段还算通用的一张应用规划图，供参考：

 什么是Druid,Flink,phoenix,redis?

▲滴滴大数据体系架构图

▲知乎大数据平台架构图

▲腾讯云大数据平台架构图(EMR)

 —————————–

什么是canal? Presto? Kylin? 

数据开发的平台，这张图比较细，这是详细的整体数据流架构图。包括最左边是数据接入，上面是流式计算，然后是Hadoop离线计算。

将上图左上角扩大来看，首先是数据接入与流式计算，电商系统产生数据分两个场景，一个是追加型的日志型数据，另外是关系型数据的维度数据。对于前一种是使用Flume比较标准化的大家都在用的日志收集系统，最近使用了阿里开源的Canal，之后有三个下游，所有的流式数据都是走Kafka这套流走的。

数据收集特性：

对于数据收集平台，日志数据是多接口的，可以打到文件里观察文件，也可以更新数据库表。关系型数据库是基于Binlog获取增量的，如果做数据仓库的话有大量的关系型数据库，有一些变更没法发现等情况，可以通过Binlog手段可以解决。通过一个Kafka消息队列集中化分发支持下游，目前支持了850以上的日志类型，峰值每秒有百万介入。

流式计算平台特性：

构建流式计算平台的时候充分考虑了开发的复杂度，基于Storm。有一个在线的开发平台，测试开发过程都在在线平台上做，提供一个相当于对Storm应用场景的封装，有一个拓扑开发框架，因为是流式计算，我们也做了延迟统计和报警，现在支持1100以上的实时拓扑，秒级实时数据流延迟。

这幅图是离线数据平台的部署架构图，最下面是三个基础服务，包括Yarn、HDFS、HiveMeta。不同的计算场景提供不同的计算引擎支持。如果是新建的公司，其实这里是有一些架构选型的。Cloud Table是自己做的HBase分装封口。我们使用Hive构建数据仓库，用Spark在数据挖掘和机器学习，Presto支持Adhoc上查询，也可能写一些复杂的SQL。对应关系这里Presto没有部署到Yarn，跟Yarn是同步的，Spark是on Yarn跑。

建设敏捷数据仓库，除了对架构技术上的要求之外，还有一个很重要的方面，就是数据建模，如果一上来就想着建立一套能兼容所有数据和业务的数据模型，那就又回到传统数据仓库的建设上了，很难满足对业务变化的快速响应。应对这种情况，一般是先将核心的持久化的业务进行深度建模（比如：基于网站日志建立的网站统计分析模型和用户浏览轨迹模型；基于公司核心用户数据建立的用户模型），其它的业务一般都采用维度+宽表的方式来建立数据模型，这块是后话。

数据共享

这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库；

前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据；和数据采集层到HDFS刚好相反，这里需要一个从HDFS将数据同步至其他目标数据源的工具，同样，DataX也可以满足。另外，一些实时计算的结果数据可能由实时计算模块直接写入数据共享。

即席查询一般是通过SQL完成，最大的难度在于响应速度上，使用Hive有点慢，可以用SparkSQL，它的响应速度较Hive快很多，而且能很好的与Hive兼容。

实时计算：Storm在这块是比较成熟了，但我选择Spark Streaming，原因很简单，不想多引入一个框架到平台中，另外，Spark Streaming比Storm延时性高那么一点点，那对于我们的需要可以忽略。

我们目前使用Spark Streaming实现了实时的网站流量统计、实时的广告效果统计两块功能。

做法也很简单，由Flume在前端日志服务器上收集网站日志和广告日志，实时的发送给Spark Streaming，由Spark Streaming完成统计，将数据存储至Redis，业务通过访问Redis实时获取。

当前，头条每日处理数据量为 7.8 PB、训练样本量 200 亿条、服务器总量 40000 台、Hadoop 节点 3000 台。

数据生命周期分为生成、传输、入库和统计/分析/挖掘，每个环节的难度都会随着数据规模的变大而上升。平台建设面临的挑战是由庞大的数据量和业务复杂度给数据生成、采集、传输、存储和计算等带来的一系列问题。

(1)数据生成与采集——SDK、用户埋点

一般情况下，数据生成与采集是很简单的事，但对于头条这个功能众多的 APP 来讲，难点就在于每个功能背后都是一个团队独立运营。如果每个团队都用自研的数据采集方法，那会给后续的进程带来巨大的困扰。

怎么办呢?因为头条属于 C 端业务公司，主要以日志形式为主，数据的主要来源是用户行为，那么就采用事件模型来描述日志，以 SDK 形式接入，支持客户端、服务端埋点。

这里需要注意的是：数据质量很重要，埋点规范趁早确立，脏数据是不可避免的，可以引入必要的约束、清洗等。

• 埋点。埋点是用户在使用某一个功能时，产生的一段数据。头条初期，埋点由各业务场景自定义日志格式，之后埋点统一到事件模型，保证了信息的结构化和自描述，降低了后续使用成本，并复用统一的解析和清洗流程、数据仓库的入库和行为分析平台的导入。

埋点的管理，也由通过文档、Wiki 等方式演进成埋点管理系统，覆盖整个埋点生命周期。这样一来，也得到了埋点元信息的描述，后续可应用在数据清洗、分析平台等场景，同时埋点的上线流程实现标准化，客户端也可进行自动化测试。

SDK。数据平台实现了通用的客户端埋点 SDK 和服务端埋点 SDK，放弃之前按约定生成数据的方式，可以保证生成的日志符合埋点规范，并统一 App 启动、设备标识等的基本口径，也减少了新 App 适配成本。

对数据的描述由使用 JSON 改为 Protobuf，这样就可通过 IDL 实现强制约束，包括数据类型、字段命名等。

除了日志数据，关系数据库中的数据也是数据分析的重要来源。头条在数据的采集方式上，用 Spark 实现类 Sqoop 的分布式抓取替代了早期定期用单机全量抓取 MySQL 数据表的方式，有效的提升了抓取速度，突破了单机瓶颈。

再之后为了减少 MySQL 压力，选用 Canal 来接收 MySQL binlog，离线 merge 出全量表，这样就不再直接读 MySQL 了，而且对千万/亿级大表的处理速度也会更快。

(2)数据传输——Kafka 做消息总线连接在线和离线系统

数据在客户端向服务端回传或者直接在服务端产生时，可以认为是在线状态。当数据落地到统计分析相关的基础设施时，就变成离线的状态了。在线系统和离线系统采用消息队列来连接。

头条的数据传输以 Kafka 作为数据总线，所有实时和离线数据的接入都要通过 Kafka，包括日志、binlog 等。这里值得注意的是：尽早引入消息队列，与业务系统解耦。

头条的数据基础设施以社区开源版本作为基础，并做了大量的改进，也回馈给了社区，同时还有很多自研的组件。

因为以目前的数据和集群规模，直接使用社区版本乃至企业版的产品，都会遇到大量困难。像数据接入，就使用自研 Databus，作为单机 Agent，封装 Kafka 写入，提供异步写入、buffer、统一配置等 feature。

Kafka 数据通过 Dump 落地到 HDFS，供后续离线处理使用。随着数据规模的增加，Dump 的实现也经历了几个阶段。最初实现用的是类似 Flume 模式的单机上传，很快遇到了瓶颈，实现改成了通过 Storm 来实现多机分布式的上传，支持的数据吞吐量大幅增加。

现在开发了一个叫 DumpService 的服务，作为托管服务方便整合到平台工具上，底层实现切换到了 SparkStreaming，并实现了 exactly-once 语义，保证 Dump 数据不丢不重。

(3)数据入库——数据仓库、ETL(抽取转换加载)

头条的数据源很复杂，直接拿来做分析并不方便。但是到数据仓库这一层级，会通过数据处理的过程，也就是 ETL，把它建设成一个层次完备的适合分析的一个个有价值的数仓。在数仓之上，就可以让数据分析师和数据 RD 通过 SQL 和多维分析等更高效的手段使用数据。

数据仓库中数据表的元信息都放在 Hivemetastore 里，数据表在 HDFS 上的存储格式以 Parquet 为主，这是一种列式存储格式，对于嵌套数据结构的支持也很好。

头条有多种 ETL 的实现模式在并存，对于底层数据构建，一种选择是使用 Python 通过 HadoopStreaming 来实现 Map Reduce 的任务，但现在更倾向于使用 Spark 直接生成 Parquet 数据，Spark 相比 MapReduce 有更丰富的处理原语，代码实现可以更简洁，也减少了中间数据的落地量。对于高层次的数据表，会直接使用 HiveSQL 来描述 ETL 过程。

(4)数据计算——计算引擎的演进

数据仓库中的数据表如何能被高效的查询很关键，因为这会直接关系到数据分析的效率。常见的查询引擎可以归到三个模式中，Batch 类、MPP 类、Cube 类，头条在 3 种模式上都有所应用。

头条最早使用的查询引擎是 InfoBright，Infopight 可以认为是支持了列式存储的 MySQL，对分析类查询更友好，但 Infopight 只支持单机。随着数据量的增加，很快换成了 Hive，Hive 是一个很稳定的选择，但速度一般。

为了更好的支持 Adhoc 交互式查询，头条开始调研 MPP 类查询引擎，先后使用过 Impala 和 Presto，但在头条的数据量级下都遇到了稳定性的问题。

头条现在的方案是混合使用 Spark SQL 和 Hive，并自研 QAP 查询分析系统，自动分析并分发查询 SQL 到适合的查询引擎。在 Cube 类查询引擎上，头条采用了 Kylin，现在也是Kylin 在国内最大的用户之一。

(5)数据门户——为业务的数据分析提供整体解决方案

对于大部分需求相对简单的公司来说，数据最终可以产出报表就够用了，如做一个面向管理层的报表，可以让老板直观的了解一些关键性指标，这是最基础的数据应用模式。

再深入一点，就需要汇总各种来源的业务数据，提供多种维度和指标来进行更深入的探索型分析，得到的结论用来指导产品的迭代和运营。头条绝大部分业务都是数据驱动的，都需要产出和分析大量的数据，这就或多或少需要用到平台提供的系列工具。

头条开发了一套叫数据门户的平台系统，提供给业务部门使用，对数据生命周期各个环节都提供了相应支持。数据门户提供的工具都是声明式的，也就是让使用者只需要说明要实现什么目的，具体实现的复杂细节都隐藏起来，对使用者更友好。

通过这些工具，可以让业务部门的 RD 、分析师、PM 等将精力放在业务分析本身，而不是去学习大量数据基础设施的使用方法。

———————
作者：JackSun924
来源：CNBLOGS
原文：https://www.cnblogs.com/sundy818/p/10382478.html
版权声明：本文为作者原创文章，转载请附上博文链接！
内容解析By：CSDN,CNBLOG博客文章一键转载插件