各组件选型
数据集成
数据集成最主要考虑数据同步的能力也就是数据源的多样，同步场景（离线全量、增量，CDC，实时同步等）的丰富度，如果集成工具自带数据源管理，数据质量，监控等一些管理能力的话会优先考虑。
数据存储
1. 数据湖选型
构建湖仓一体的前提是要引入数据湖以及配套的数据存储组件，以适配类型多样化的结构、半结构、非结构化等数据类型；目前市面上流行且被广泛采用的数据湖有Delta、Hudi、Iceberg三种，由于Delta 必须绑定 Spark，在上层数据处理引擎支持上不够灵活，流行程度也没有后两者高，加上后续要考虑实时流处理的场景，Delta数据湖显然不合适； 对于Hudi和Iceberg优劣，我们可以从起功能和适用场景上进行对比：
从上述功能对比看，Hudi和Iceberg实际不分伯仲，数据读取，引擎支持、事务支持、数据的增删改等数据湖核心功能两者均支持； 接下来从两者的使用场景进行对比：
在结合了功能和场景对比后，我们可以得到以下结论:
Iceberg 和 Hudi 都支持行级更新的能力
Iceberg 和 Hudi 在能力上接近，但是定位不同。Iceberg 定位成为数据湖格式的标准接口，更重视兼容性和可扩展性;Hudi 定位成为一个综合的数据湖平台，功能更丰富，迭代更快，但是架构上劣势会造成版本的不稳定，功能可移植性较差。
Iceberg 和 Hudi 都支持较好的数据回溯能力。
Iceberg 在分区变更和隐藏分区上支持相对较好。
Iceberg 和 Hudi 对于实时场景下的 CDC 数据流式读取，支持较弱或不支持，都不满足上生产构建实时数仓的条件，所以基于 Iceberg 或 Hudi 构建实时数仓的方案目前还不够成熟。
最终结论为：Iceberg在计算引擎多样化、底层存储可插拔、文件格式几方面兼容性和可扩展性更优，对后续平台发展和迭代更加友好，推荐使用Iceberg作为数据湖的管理组件；
注：数据湖号称是集中式存储库，但实际更准确的应该称之为数据管理框架，真正的底层存储必须依赖于HDFS或者对象存储组件；
2. 数据存储
开源对象存储系统比较多，apache Ozone，MinIO，Ceph，LakeFS。由于选定Iceberg作为数据湖管理组件，结合公司现有存储（MiniO），优先推荐使用MiniO作为对象存储组件（https://blog.min.io/lakehouse-architecture-iceberg-minio/）； 另外鉴于Iceberg起初就是为了解决hive仓库的弊端而诞生的新组件，天然支持对HDFS分布式文件系统的读写访问，因此存储的备选方案也可以定位HDFS;
结论：数据湖底层存储组件优先推荐MiniO，便于复用公司现有的存储服务，但是对于大数量情况下，MiniO方案可行性未知； 备选存储为HDFS，作为Hadoop体系下最为核心的数据存储服务，其可靠性和稳定性已经过成千上万公司验证。
3. 存储格式
主流的三种格式: parquet、avro、orc, 数仓模型表使用列式 parquet格式压缩存储
//todo 补一下
数据加工
批处理使用spark；流处理使用flink；离线数仓引擎使用MMP数据库，主要考虑两款 doris 和 starrocks
调度系统
调度系统主要分为两部分：工作流调度、计算引擎调度
1. 工作流调度
工作流调度系统是大数据平台核心组件，是驱动离线批任务正常运转关键能力，同时组件应该自带一些运维功能，保障系统可管理，因此稳定性，易用性，可维护性，扩展性为核心考虑因素，以下对4大主流调度系统进行对比
结论：推荐使用 DolphinScheduler 作为工作流调度平台。从功能丰富度，社区活跃度，生态集成/扩展性，可维护，当前团队的技术栈，过往使用经验综合判断优先推荐DolphinScheduler。
2. 计算引擎调度
大数据组件主流的两个Hadoop Yarn 和 Kubernetes，Yarn是专门解决大数据组件资源调度而设计的也是当前主流的方式，但是云原生，容器化部署时未来的趋势，所以k8s是未来趋势，当前大数据组件都基本支持k8s了
结论：前期推荐 Yarn，聚焦大数据引擎调度，方案成熟且稳定，学习成本低可快速落地，客户具体的场景是私有化部署不涉及超大集群资源管理
运维部署
1. 实施部署
组件部署 + 脚本 → 半自动化部署
Helm + Docker + k8s 容器化部署
2. 监控 + 告警
统一的监控管理平台：Prometheus + Grafana
自研统一管理界面，并聚合各组件提供的管理界面
整体架构
