何谓五横，基本还是根据数据的流向自底向上划分五层，跟传统的数据仓库其实很类似，数据类的系统，概念上还是相通的，分别为数据采集层、数据处理层、数据分析层、数据访问层及应用层。同时，大数据平台架构跟传统数据仓库有一个不同，就是同一层次，为了满足不同的场景，会采用更多的技术组件，体现百花齐放的特点，这是一个难点。
具体见下图示例，这张图是比较经典的，也是妥协的结果，跟当前网上很多的大数据架构图都可以作一定的映射。
数据采集层：既包括传统的ETL离线采集、也有实时采集、互联网爬虫解析等等。
数据处理层：根据数据处理场景要求不同，可以划分为HADOOP、MPP、流处理等等。
数据分析层：主要包含了分析引擎，比如数据挖掘、机器学习、 深度学习
数据访问层：主要是实现读写分离，将偏向应用的查询等能力与计算能力剥离，包括实时查询、多维查询、常规查询等应用场景。
数据应用层：根据企业的特点不同划分不同类别的应用，比如针对运营商，对内有精准营销、客服投诉、基站分析等，对外有基于位置的客流、基于标签的广告应用等等。
数据管理层：这是一纵，主要是实现数据的管理和运维，它横跨多层，实现统一管理。
--------------------------------------------------
数据采集层：
实时采集现在也成了大数据平台的标配，估计主流就是FLUME+KAFKA，然后结合流处理+内存数据库吧，这个技术肯定靠谱，但这类开源的东西好是好，但一旦出现问题往往解决周期往往比较长。除了用FLUME，针对ORACLE数据库的表为了实现实时采集，也可以采用OGG/DSG等技术实现实时的日志采集，可以解决传统数据仓库抽全量表的负荷问题。
企业级的爬虫中心的建设难度蛮大，因为不仅仅是需要爬虫，还需要建立网址和应用知识库，需要基于网页文本进行中文分词，倒排序及文本挖掘等，这一套下来，挑战很大，当前已经有不少开源组件了，比如solr、lucent、Nutch、ES等等，但要用好它，路漫漫其修远兮。
------------------------------
总得来讲，建设大数据采集平台非常不易，从客户的角度讲，至少要达到以下三个要求：
多样化数据采集能力：支持对表、文件、消息等多种数据的实时增量数据采集（使用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的多维分析的杀手级工具，应用的场景非常多，希望有机会使用。
-------------------
数据应用层
每个企业应根据自己的实际规划自己的应用，其实搞应用蓝图很难，大数据架构越上层越不稳定，因为变化太快，以下是运营商对外变现当前阶段还算通用的一张应用规划图，供参考：
▲滴滴大数据体系架构图
▲知乎大数据平台架构图
▲腾讯云大数据平台架构图(EMR)