目录
- 背景
- 第一部分 Spark内存管理详解
- 第二部分 Spark参数说明
- 第三部分 Spark内存优化
- 第四部分 常见线上问题解决
- 参考文献及资料
背景
数据湖（data Lake），这个术语最早由James Dixon为了与数据集市对比而提出，当时他是Pentaho的首席技术官。
在维基百科中，数据湖是这样定义的。
数据湖，是一类存储数据自然/原始格式的系统或存储，通常是对象块或者文件，包括原始系统所产生的原始数据拷贝以及为了各类任务而产生的转换数据，包括来自于关系型数据库中的结构化数据（行和列）、半结构化数据（如CSV、日志、XML、JSON）、非结构化数据（如email、文档、PDF等）和二进制数据（如图像、音频、视频）。
大部分介绍材料都在传达一个含义：数据湖并没有一个确认的定义。
第一部分
Delta Lake 、Iceberg和Hudi三个定位类似的开源项目从数据库方法论中汲取灵感，将事务等能力带到了大数据领域，并抽象成统一的中间格式供不同引擎适配对接。
其本质上并不定义数据存储方式，而是定义数据、元数据的组织方式，向上提供统一的“表”的语义。“表”的底层数据存储仍然使用 Parquet、ORC 等格式。
第三部分 湖仓一体(Lake House)
总之，一个后期成本高，一个前期成本高，对于既想修湖、又想建仓的用户来说，仿佛玩了一个金钱游戏。
比如，让“数仓”在进行数据分析的时候，可以直接访问数据湖里的数据（Amazon Redshift Spectrum是这么干的）。再比如，让数据湖在架构设计上，就“原生”支持数仓能力（DeltaLake是这么干）。
湖里的“新鲜”数据可以流到仓里，甚至可以直接被数仓使用，而仓里的“不新鲜”数据，也可以流到湖里，低成本长久保存，供未来的数据挖掘使用。
数据积累得越多，移动起来就越困难，这就是所谓的“数据重力”。
所以，Lake House不仅要把湖、仓打通，还要克服“数据重力”，让数据在这些服务之间按需来回移动：入湖、出湖、环湖……
参考文献及资料
1、数据治理对运维数据体系的思考与启发，链接：http://blog.itpub.net/69994525/viewspace-2762789/