数据分析工作隐藏在业务系统的背后，但有着非常重要的作用，数据分析的结果对决策、业务发展有着重要的作用。 随着大数据技术的发展，数据挖掘、数据搜索等专有名词的曝光度越来越高，但在Hadoop系列这样的大数据分析系统普及之前，数据分析工作已经有了很大的发展，特别是以BI系统为中心的数据分析
在BI系统中，可以看到核心模块是Cube，Cube是更高级的商业模型抽象，在Cube上可以进行向上钻、向下钻、切片等各种操作。 大多数BI系统基于关系数据库，关系数据库使用SQL语句进行操作，但由于SQL的多维操作和分析表达能力相对较弱，Cube有自己的查询语言MDX，MDX表达式具有更强的多维表达能力以Cube为中心的分析系统基本上占了数据统计分析的一半江山，大部分数据库服务厂商直接提供BI包服务，可以轻松构建Olap包，但BI的问题也随着时间的推移而凸显出来
BI系统以分析商业数据生成的密度高、价值高的结构化数据为中心，对非结构化数据和半结构化数据的处理非常无力，如图像、文本、音频的存储、分析等。 由于数据仓库是结构化存储，因此数据从其他系统进入数据仓库通常称为ETL过程。 ETL的行为和业务紧密相连，通常需要与业务合作的专业ETL团队来决定如何清洗和转换数据。 随着异构数据源的增加，例如在存在视频、文本、图像等数据源的情况下，要分析数据的内容来访问数据仓库，需要非常复杂的ETL程序，ETL变得巨大，变得庞大。 如果数据量过多，性能将成为瓶颈，对TB/PB级别的数据量表示明显的困扰。 数据库范式等约束规则是为了致力于解决数据冗余问题，保障数据的完整性，但对于数据仓库来说，不需要数据的修改和完整性的保障，原则上数据仓库的原始数据都是只读的基于ETL动作的数据预假设和处理，由于机器学习部取得的数据是假设后的数据，所以效果不好。 例如，如果需要使用数据仓库进行异常数据的挖掘，则需要明确定义数据入库到ETL时应该提取的特征数据。 只有这样才能结构化入库，但大多数情况下需要根据异构数据提取特征。 在一系列问题中，以Hadoop系统为首的大数据分析平台逐渐显示出优越的性能，围绕Hadoop系统的生态圈也在不断扩大，对Hadoop系统来说，传统的数据仓库瓶颈问题从根本上来说是
从数据仓库升级到大数据架构，没有平稳的进化，基本上等于推翻了重做。 由于大数据下的分布式存储强调数据的只读性质，像Hive一样，HDFS这样的存储方式都不支持更新，HDFS的write操作也不支持并行处理，所以这些特性有限基于大数据架构的数据分析平台侧重于解决传统数据仓库的数据分析瓶颈。
分布式计算：分布式计算的理念是让多个节点进行并行计算，强调数据的本地性，尽可能减少数据的传输。 例如，Spark以RDD的形式表示数据的计算逻辑，可以在RDD上进行一系列优化，减少数据的传输。 分布式存储：分布式存储是指将较大的文件分成n个，每个文件独立放置在一台计算机上。 其中涉及文件的复制、分片、管理等操作。 分布式存储的主要优化趋势就在这一部分。 搜索和存储的组合：早期的大数据组件相对来说存储和计算比较单一，但现在为了更高效地进行搜索和计算，对存储采取了很多措施。 对计算而言，高效的不仅仅是数据的检索和读取速度快。 因此，当前的存储不仅存储数据的内容，还会添加许多元信息，如索引信息。 parquet和carbondata就是这样的思想。 一般来说，目前以Hadoop系统为中心的大数据体系结构包括：
传统大数据架构
之所以被称为传统的大数据架构，是为了解决传统BI的问题。 简单来说，数据分析的业务没有什么变化，但是如果由于数据量、性能等问题导致系统无法正常工作，需要升级或改造，就是为了解决这个问题。 可以看到，在保持ETL行为的同时，数据通过ETL行为存储在数据存储区中。
优点：简单易懂，对BI系统来说，基本思想没有发生变化。 变化的只有技术选型，将BI的组件替换为大数据架构。
优点：对大数据来说，没有比BI下更完整的Cube体系结构了。 虽然目前有kylin，但kylin的局限性非常明显，远远没有BI下的Cube的灵活性和稳定性，因此对业务支持缺乏灵活性，存在大量的报告
，或者复杂的钻取的场景，需要太多的手工定制化，同时该架构依旧以批处理为主，缺乏实时的支撑。适用场景：数据分析需求依旧以BI场景为主，但是因为数据量、性能等问题无法满足日常使用。
流式架构
在传统大数据架构的基础上，流式架构非常激进，直接拔掉了批处理，数据全程以流的形式处理，所以在数据接入端没有了ETL，转而替换为数据通道。经过流处理加工后的数据，以消息的形式直接推送给了消费者。虽然有一个存储部分，但是该存储更多的以窗口的形式进行存储，所以该存储并非发生在数据湖，而是在外围系统。
优点：没有臃肿的ETL过程，数据的实效性非常高。
缺点：对于流式架构来说，不存在批处理，因此对于数据的重播和历史统计无法很好的支撑。对于离线分析仅仅支撑窗口之内的分析。
适用场景：预警，监控，对数据有有效期要求的情况。
Lambda架构
Lambda架构算是大数据系统里面举足轻重的架构，大多数架构基本都是Lambda架构或者基于其变种的架构。Lambda的数据通道分为两条分支：实时流和离线。实时流依照流式架构，保障了其实时性，而离线则以批处理方式为主，保障了最终一致性。什么意思呢？流式通道处理为保障实效性更多的以增量计算为主辅助参考，而批处理层则对数据进行全量运算，保障其最终的一致性，因此Lambda最外层有一个实时层和离线层合并的动作，此动作是Lambda里非常重要的一个动作，大概的合并思路如下：
优点：既有实时又有离线，对于数据分析场景涵盖的非常到位。
缺点：离线层和实时流虽然面临的场景不相同，但是其内部处理的逻辑却是相同，因此有大量冗余和重复的模块存在。
适用场景：同时存在实时和离线需求的情况。
Kappa架构
Kappa架构在Lambda 的基础上进行了优化，将实时和流部分进行了合并，将数据通道以消息队列进行替代。因此对于Kappa架构来说，依旧以流处理为主，但是数据却在数据湖层面进行了存储，当需要进行离线分析或者再次计算的时候，则将数据湖的数据再次经过消息队列重播一次则可。
优点：Kappa架构解决了Lambda架构里面的冗余部分，以数据可重播的超凡脱俗的思想进行了设计，整个架构非常简洁。
缺点：虽然Kappa架构看起来简洁，但是施难度相对较高，尤其是对于数据重播部分。
适用场景：和Lambda类似，改架构是针对Lambda的优化。
Unified架构
以上的种种架构都围绕海量数据处理为主，Unifield架构则更激进，将机器学习和数据处理揉为一体，从核心上来说，Unifield依旧以Lambda为主，不过对其进行了改造，在流处理层新增了机器学习层。可以看到数据在经过数据通道进入数据湖后，新增了模型训练部分，并且将其在流式层进行使用。同时流式层不单使用模型，也包含着对模型的持续训练。
优点：Unifield架构提供了一套数据分析和机器学习结合的架构方案，非常好的解决了机器学习如何与数据平台进行结合的问题。
缺点：Unifield架构实施复杂度更高，对于机器学习架构来说，从软件包到硬件部署都和数据分析平台有着非常大的差别，因此在实施过程中的难度系数更高。
适用场景：有着大量数据需要分析，同时对机器学习方便又有着非常大的需求或者有规划。
总结
以上几种架构为目前数据处理领域使用比较多的几种架构，当然还有非常多其他架构，不过其思想都会或多或少的类似。数据领域和机器学习领域会持续发展，以上几种思想或许终究也会变得过时。
原文地址：https://insights.thoughtworks.cn/common-big-data-infrastructure/