大数据平台架构剖析
大数据平台架构剖析是当前数据分析领域中的热点话题。随着大数据技术的发展，数据挖掘、数据探索等专有名词曝光度越来越高。在类似于 Hadoop 系列的大数据分析系统中，数据分析工作已经经历了长足的发展，尤其是以 BI 系统为主的数据分析，已经有了非常成熟和稳定的技术方案和生态系统。
BI 系统的核心模块是 Cube，Cube 是一个更高层的业务模型抽象，在 Cube 之上可以进行多种操作，例如上钻、下钻、切片等操作。大部分 BI 系统都基于关系型数据库，关系型数据库使用 SQL 语句进行操作，但是 SQL 在多维操作和分析的表示能力上相对较弱，所以 Cube 有自己独有的查询语言 MDX，MDX 表达式具有更强的多维表现能力。
然而，BI 系统也存在一些问题，如：
1. BI 系统更多的以分析业务数据产生的密度高、价值高的结构化数据为主，对于非结构化和半结构化数据的处理非常乏力，例如图片，文本，音频的存储，分析。
2. 由于数据仓库为结构化存储，在数据从其他系统进入数据仓库这个东西，我们通常叫做 ETL 过程，ETL 动作和业务进行了强绑定，通常需要一个专门的 ETL 团队去和业务做衔接，决定如何进行数据的清洗和转换。
3. 随着异构数据源的增加，例如如果存在视频，文本，图片等数据源，要解析数据内容进入数据仓库，则需要非常复杂等 ETL 程序，从而导致 ETL 变得过于庞大和臃肿。
4. 当数据量过大的时候，性能会成为瓶颈，在 TB/PB 级别的数据量上表现出明显的吃力。
5. 数据库的范式等约束规则，着力于解决数据冗余的问题，是为了保障数据的一致性，但是对于数据仓库来说，我们并不需要对数据做修改和一致性的保障，原则上来说数据仓库的原始数据都是只读的，所以这些约束反而会成为影响性能的因素。
在这些问题下，以 Hadoop 体系为首的大数据分析平台逐渐表现出优异性，围绕 Hadoop 体系的生态圈也不断的变大，对于 Hadoop 系统来说，从根本上解决了传统数据仓库的瓶颈的问题，但是也带来一系列的问题：
1. 从数据仓库升级到大数据架构，是不具备平滑演进的，基本等于推翻重做。
2. 大数据下的分布式存储强调数据的只读性质，所以类似于 Hive，HDFS 这些存储方式都不支持 update，HDFS 的 write 操作也不支持并行，这些特性导致其具有一定的局限性。
基于大数据架构的数据分析平台侧重于从以下几个维度去解决传统数据仓库做数据分析面临的瓶颈：
1. 分布式计算：分布式计算的思路是让多个节点并行计算，并且强调数据本地性，尽可能的减少数据的传输，例如 Spark 通过 RDD 的形式来表现数据的计算逻辑，可以在 RDD 上做一系列的优化，来减少数据的传输。
2. 分布式存储：所谓的分布式存储，指的是将一个大文件拆成 N 份，每一份独立的放到一台机器上，这里就涉及到文件的副本，分片，以及管理等操作，分布式存储主要优化的动作都在这一块。
3. 检索和存储的结合：在早期的大数据组件中，存储和计算相对比较单一，但是目前更多的方向是在存储上做更多的手脚，让查询和计算更加高效，对于计算来说高效不外乎就是查找数据快，读取数据快，所以目前的存储不单单的存储数据内容，同时会添加很多元信息，例如索引信息。像类似于 parquet 和 carbondata 都是这样的思想。
目前围绕 Hadoop 体系的大数据架构大概有以下几种：
1. 传统大数据架构：其定位是为了解决传统 BI 的问题，简单来说，数据分析的业务没有发生任何变化，但是因为数据量、性能等问题导致系统无法正常使用，需要进行升级改造，那么此类架构便是为了解决这个问题。可以看到，其依然保留了 ETL 的动作，将数据经过 ETL 动作进入数据存储。
优点：简单，易懂，对于 BI 系统来说，基本思想没有发生变化，变化的仅仅是技术选型，用大数据架构替换掉 BI 的组件。
缺点：对于大数据来说，没有 BI 下如此完备的 Cube 架构，虽然目前有 kylin，但是 kylin的局限性非常明显，远远没有 BI 下的 Cube 的灵活度和稳定度，因此对大数据分析产生了较大的影响。
大数据平台架构剖析是当前数据分析领域中的热点话题，Hadoop 体系的生态圈也不断的变大，对于 Hadoop 系统来说，从根本上解决了传统数据仓库的瓶颈的问题，但是也带来一系列的问题。我们需要考虑到这些问题，选择合适的解决方案，以满足我们的业务需求。
jiangbinggui2022-07-24资源内容总结地很全面，值得借鉴，对我来说很有用，解决了我的燃眉之急。
