- Java锁的逻辑(结合对象头和ObjectMonitor)
- 还在用饼状图?来瞧瞧这些炫酷的百分比可视化新图形(附代码实现)⛵
- 自动注册实体类到EntityFrameworkCore上下文,并适配ABP及ABPVNext
- 基于Sklearn机器学习代码实战
在Delta Lake官网上提到的一篇新一代湖仓架构的论文. 这篇论文由Databricks团队2021年发表于CIDR会议. 这个会议是对sigmod和vldb会议的补充. 可以看到这篇论文和前一篇 Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores 发表时间仅隔了一年. 论述的内容也是对Delta Lake这套架构的补充(场景拓展). 。
第一代数仓只将数据库操作的结构化日志通过ETL清洗存储到专门的数据仓库中, 典型的如基于Hive的数仓. 这一代数仓的主要服务的目标场景是BI分析. 他的架构也是一种计算存储紧耦合的架构, 例如hive上计算节点就和存储的数据节点部署在一起, 通常还会有data colocate的优化. 第二代演化成了2层的结构, Data Lake 可以存储半结构化, 和非结构化的数据, 例如视频, 音频 这种架构下可以支持非结构化数据, 也支持直接的数据访问, 可以更好的对接非SQL的机器学习系统. 但目前自己在业界没有明显的感受到这种两层的结构, 可能是因为我对AI场景没怎么接触 论文中描述这已经是绝大部分公司的架构了 那么有没有将传统基于标准格式的数据湖转化成既有数仓管理能力, 高性能的分析能力, 又有快速的开放的数据访问的架构呢? 答案是 Lakehouse = Data Lake + Data warehouse. 数据直接存储于Object store之上, 而上层的BI系统, 机器学习, 数据科学计算都直接从Lakehouse中取数分析, 这样就实现了存储层的统一. 通过Data Lake 和 Data warehouse的结合实现了两者能力的结合. 而Lakehouse 就可以基于前文所介绍的Delta lake来构建, 可以看出Lakehouse是对传统数仓的一次升级. 但是纯粹这样的架构性能也许没有原先数仓中计算存储紧耦合的性能好, 毕竟多了额外的跨网络拉取数据的开销 。
最大的问题就是性能问题 。
如何保障性能呢?
有待探索的优化 。
与传统数仓的性能和cost对比. 咋没有snowflake呢 ? 不管是性能和性价比上都非常不错. 。
不过, 在SQL上能很好的利用下推, 剪枝优化. 但是机器学习库的很多api, 并没有将query的语义下推到存储层, 导致这种框架中就无法很好的利用这些statistics. 因此这里就需要重新设计这些机器学习库的api. 。
M. Brantner, D. Florescu, D. Graf, D. Kossmann, and T. Kraska. Building a database on S3. In SIGMOD, pages 251–264, 01 2008. 看到一篇2008年就尝试将DBMS存储落在s3上, 真是先进 。
这篇论文的干货比较少, 感觉只是把Delta lake的使用场景泛化了一下, 推出了一个新名词, lakehouse. 现在确实有这个演进的方向, 统一存储, 并在统一的存储上运行各种workload. 不过其中的性能挑战也不小. 。
最后此篇关于Lakehouse:ANewGenerationofOpenPlatformsthatUnifyDataWarehousingandAdvancedAnalytics的文章就讲到这里了,如果你想了解更多关于Lakehouse:ANewGenerationofOpenPlatformsthatUnifyDataWarehousingandAdvancedAnalytics的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
在Delta Lake官网上提到的一篇新一代湖仓架构的论文. 这篇论文由Databricks团队2021年发表于CIDR会议. 这个会议是对sigmod和vldb会议的补充. 可以看到这
我是一名优秀的程序员,十分优秀!