Drop的数据湖现在每天从Postgres数据库中提取十亿条记录，并处理TB级的作业，该数据湖已被众多团队采用，并为增强了数据分析能力以及开发和交付机器学习模型的能力。总体而言，该架构效果不错，并且我们相信数据基础架构的发展将使我们处于更好的位置，以适应当前和未来的需求。
7. 重点总结我们的实施过程踩过不少坑，总结如下：
提取列式的数据的好处：尽管存储层的“原始”部分与文件格式无关，但是以列式提取数据对下游更有利，当从Postgres表中摄取数据时，这些表包含冗长和复杂文本Blob的列（例如jsonb列），下游解析数据就成了噩梦，进一步依赖serDe文件来协助解析数据只会增加整体复杂性，由于Parquet的固有特性，将DMS配置为以Parquet格式输出文件可保持列的架构完整性，并且我们的下游处理层作业也可提升速度和数据质量性能，这种折衷是以增加DMS生成parquet文件所需的内存资源为代价的。
技术栈使用Spark：我们的工程团队以前在内部Hadoop方面的经验非常有限，因此采用Spark带来了很多麻烦。尽管有大量可用的Spark资源，但我们最大的痛点还是资源管理和错误排除，我们选择EMR而不是AWS Gule构建ETL作业，这会提交已利用资源的控制级别，提升了性能和节约成本节约，但代价是复杂性的提升。为每个Spark作业配置最佳EMR资源非常复杂，我们很快了解到这些优化工作需要浪费高昂的时间。当EMR作业失败时，我们也很难解决根源问题，在很多情况下，EMR群集生成的错误日志不够细致，并且有时也掩盖了重要细节。通过改进日志记录过程并直接引用Spark执行程序日志，我们能够发现更详细的信息，从而更快发现根本原因。
关闭空闲资源：我们可以将节省的大部分费用归功于我们在处理临时工作负载方面的经验，通过将几乎所有的数据湖操作都构造为Airflow DAG，我们可以自动化何时删除未使用的资源，我们只有在需要通过Airflow进行批量提取作业时才启动DMS复制实例的能力，这使我们节省了始终保持实例可用的等效成本的90％以上。类似地，当我们的Airflow调度处理层作业时，我们仅使用竞价型实例启动EMR集群，并在完成时终止集群，这与我们始终拥有可用节点相比，平均节省了70％以上。
8. 下一步计划我们也在寻找改善数据基础架构的方法，并且已经开始制定下一步计划，包括：
通过诸如Apache Hudi或Delta Lake之类的技术改善数据可用性以及存储层中的版本控制管理。
通过Apache Kafka和Debezium进行事件驱动开发来调整我们的摄入层功能。
使用AWS Lake Formation等工具改善数据访问治理，这样可以对团队访问哪些数据进行严格控制。