传统数据湖与AWS湖形成
我一直在为客户建立数据湖，在那里我们将数据从onprem或任何其他来源加载到S3 (一个数据湖)中。我们将在这些原始数据上创建一个AWS Glue目录来创建模式。
下一步是使用EMR或AWS Glue进行数据清理，将转换后的数据加载到RDS / REDSHIFT / S3中作为最终目标。
根据使用的用例/服务，可以使用数据管道、Glue Jobs或AWS Lambda事件触发器来调度作业。
分析人员、其他用户将使用IAM服务提供所需的数据/ S3桶访问，用于Quicksight可视化或使用雅典娜、data等进行数据查询，或在Sagemaker中为ML应用程序使用数据。
我的问题是，AWS湖的形成与传统的数据湖有何不同？
我可以定义AWS提供上述所有服务，如S3、Glue目录、Glue中的ETL代码生成器、作业调度器等。对于用户/数据(记录/列级别)有一些更高级的安全性，可以在中进行配置。
还有什么能让湖的形成从传统的基于云的数据湖中脱颖而出吗？
谢谢
回答 2
Stack Overflow用户
发布于 2020-04-02 21:35:57
您的理解是正确的，lake基本上只是Glue Catalog上的一个权限模型，它允许与其他AWS数据湖工具(雅典娜、S3、Glue、EMR等)紧密集成，以及一些附加特性，如蓝图(用于从关系数据库到S3的数据同步)、乔布斯(用于ETL)和爬虫(用于数据发现)。
Lake允许通过Lake和API集中管理环境中的“用户”IAM角色的权限管理。与每次角色需要新的访问时都必须更新单独的IAM /桶策略不同，Lake允许您在一个单独的“服务”IAM角色上进行桶访问，然后将数据库/表/列级别的访问权限授予需要它的用户IAM角色。
用户角色本质上承担执行其操作的服务角色(可能不会完全假定为AWS黑匣子)。因此，Lake可以帮助您避免不得不通过一堆IAM /桶策略来管理所有用户IAM角色的权限。
它还提供了一些易于集成的共享数据，以跨帐户资源，如果你的设置需要它。
Stack Overflow用户
发布于 2020-09-12 06:04:37
AWS湖的形成主要是一个权限控制层，它与AWS Glue相连，基本上提供目录和权限控制。湖的形成提供了暂缓管理IAM权限，而是提供了自己的基于格兰特的细粒度权限控制，使用简单的DB类似的授权。
在与一些数据服务(如EMR)集成方面，lake仍然存在一些挑战。(它需要额外的IAM策略)，但总体上使用S3的Lake，Glue ETL提供了构建数据湖所需的一切。
湖的形成仍然可以受益于改进的UI和数据发现。
您可以使用Lake来实现传统的样式Data，或者使它们更加模块化，并提供跨多个AWS帐户的支持。
https://stackoverflow.com/questions/57569020
复制相似问题
腾讯云开发者
