细数一下，大数据架构目前比较热的词包括：
* 数据湖、湖仓一体
* 批流合一、实时计算
* 存算分离、存储虚拟化
* 交易和分析融合，OLAP、HTAP、HSAP
等等，基本上还是围绕大数据平台的存储和计算的两大主题。
动机方面，依然可以概括为多快好省：
* 多：
** 支持更大的数据量
** 支持更大的访问量，如AP的并发访问问题
* 快：
** 配置变更更快，使用集成度更好的工具
** 数据接入速度更快，在源端(数据库等)、接入工具端(cdc)、存储端(增量写入)有更好的支持
** 数据处理快，直接消费接入端数据，增量处理(依赖于存储格式)和实时处理(直接消费接入流)
** 访问速度快，索引、压缩、预计算等方法，缓存、向量化等手段，适合场景的加速化设计(lsm、时序库)等
* 好
** 对业务人员友好，提供更好的服务，更低的使用门槛(自动建模、业务术语)，与业务过程更好地融合(增强分析)
** 对开发人员友好，框架、算子、算法更友好，不同层的开发分离关注点(业务层SQL、平台层各种语言)
** 对运维人员友好，部署统一化、云化，监控、告警、自动优化
* 省
** 计算资源，存算分离，计算可以灵活调度、扩缩容、与其他系统共享资源池
** 存储资源，冷热分离(auto tiering)，存储虚拟化(caching，RAM、disk等多种存储提供统一访问，自动优化)
架构技术上，从存储和计算分开来看
～ 存储无非数据读写，目前的重点是增量写，也就是数据湖的相关技术，基于版本的文件系统，借鉴的还是数据库的概念，hudi也号称自己是serverless的数据库
～存储虚拟化，即user space fs，在linux平台还是很早就有的fuse，Windows是ifs(installable)，对cache、ssd、hd、archive基层的存储进行合成和按需调度，支持重复访问等场景
～计算，可以分为微观优化和宏观优化
～～ 微观方面借助向量化等更好的工程手段压榨硬件潜力
～～ 宏观方便借助执行计划、多引擎、文件系统深度融合(s3-select)等，追求与场景的适配
存储结合方面，计算模式的历程包括
# map-reduce利用分布式、批量和局部性，偏向于静态的处理能力
# micro-batch这个局部优化环节，平衡计算能力与中间存储代价，并初步支持非静态的近线数据，以及数据多次计算场景(ml)
# 到增量式的存储和计算协调设计，structed streaming和flink都有这样的设计，数据湖也是这个思路
# TP和AP的结合设计，同时支持点查询(行式)和统计查询(列式)，这里有hologres和tidb，同一年发的paper，理念也是类似
# mpp分布式数据库的继续探索，包括greenplum、ADB、redshift，在支持更多场景的同时，都在做更深层的优化。与传统数据库的同宗同源可能是它们的最大优势
# 一体化设计，做大数据是否真的需要这么多的组件，小公司做大数据，以及资源受限情况下的大数据应该怎么做，snowflake一骑绝尘，人人都想成为snowflake，但大多数还处于思想对齐的阶段。
