数据和湖. 仓库:如何为您的堆栈选择正确的解决方案

随着宣布 砖的SQL的分析, 雪花雪崩般的新产品特性, 以及数据工程领域的其他各种进步, 很明显,云数据仓库不会消失, 但它们正在迅速进化. 

在第一篇文章中 数据平台系列,推荐一个正规滚球网站讨论了如何将你的数据平台建设成产品. 现在, 推荐一个正规滚球网站共享您需要知道的关于您的数据基础设施基础的一切:数据仓库和数据湖.

二十年前,你的 数据仓库 可能不会被选为最热门的技术. 这些办公室地下室的堡垒长期以来都与竖井式的数据工作流联系在一起, 本地计算机集群, 和有限的业务相关的任务(i.e.、处理工资单和存储内部文件). 

现在, 随着数据驱动分析的兴起, 数据跨职能团队, 最重要的是, 云, “云数据仓库”这个短语几乎与敏捷性和创新类似. 在许多方面, 云使得数据更容易管理, 更容易获得更广泛的用户, 处理速度也快得多. 公司 字面上的 如果不利用云数据仓库解决方案(或两个、三个……或更多),就无法有意义地使用数据. 

当涉及到为数据平台选择正确的云数据仓库时, 然而, 答案并不那么简单. 随着2013年亚马逊红移的发布,接下来是雪花, 谷歌大查询, 在随后的几年里, 这个市场变得越来越热. 添加 数据的湖泊 在这种混合中,做出决定变得更加困难. 

无论你是刚刚开始还是正在重新评估现有的解决方案, 以下是你需要知道的一切,以便为你的数据堆栈选择正确的数据仓库(或湖): 

是什么构成了数据仓库/湖泊?

数据仓库和湖泊是数据基础设施的基础, 提供存储, 计算能力, 以及关于生态系统中数据的上下文信息. 就像汽车的引擎一样,这些技术是数据平台的主力. 

数据仓库和数据湖包含以下四个主要组成部分:  

元数据

仓库和湖泊通常提供了一种管理和跟踪所有数据库的方法, 模式, 以及你创建的表格. 这些对象通常附带附加信息,比如模式, 数据类型, 用户描述, 甚至是数据的新鲜度和其他统计数据. 

存储

存储指的是仓库/湖泊物理地存储所有表中存在的所有记录的方式. 通过利用各种存储技术和数据格式, 仓库/湖泊可以为各种各样的用例提供所需的成本/性能特性.

计算

计算是指仓库/湖泊对其存储的数据记录执行计算的方式. 这是允许用户“查询”数据的引擎, 摄取数据, 改变它——而且是更广泛的改变, 从中提取价值. 通常,这些计算是通过SQL表示的. 

为什么选择数据仓库? 

数据仓库是完全集成和管理的解决方案, 使它们易于构建和操作. 使用数据湖时, 通常使用元数据, 从单个解决方案中存储和计算, 由单一供应商构建和操作.

湖泊的数据不同, 数据仓库通常需要更多的结构和模式, 在读取和使用数据时,哪些通常会强制更好的数据卫生并降低复杂性. 

由于其预先打包的功能和对SQL的强大支持, 数据仓库方便快捷, 可操作的查询, 让他们成为数据分析团队的好帮手.  

常用的数据仓库技术包括: 

  • 亚马逊红移:第一个广泛流行(且随时可用)的云数据仓库, 亚马逊红移位于Amazon Web Services (AWS)之上,利用源连接器将数据从原始数据源传输到关系存储中. Redshift的柱状存储结构和并行处理使其成为分析工作负载的理想选择. 
  • 谷歌BigQuery:就像红移, 谷歌BigQuery利用其母公司的专有云平台(谷歌cloud), 使用列存储格式, 并利用并行处理进行快速查询. 与Redshift不同的是,BigQuery是一个根据使用模式扩展的无服务器解决方案.
  • 雪花:不像红移或GCP,它们依靠自己的专有云来运行, 雪花云的云数据仓库功能是由AWS提供的, 谷歌, Azure, 以及其他公有云基础设施. 与红移, 雪花允许用户为计算和存储支付单独的费用, 让数据仓库成为团队寻找更灵活的薪酬结构的一个很好的选择. 

为什么选择数据湖?  

数据湖是数据仓库的diy版本, 允许数据工程团队挑选各种元数据, 存储, 他们想要使用的计算技术取决于他们系统的需求. 

数据湖对于希望构建更定制化平台的数据团队来说是理想的选择, 通常由少数(或更多)数据工程师支持. 

数据湖通常是由开源和闭源技术结合而成的, 使它们易于定制,并能够处理日益复杂的工作流. 图片由Lior Gavish/蒙特卡罗提供.

数据湖的一些共同特征包括: 

  • 解耦存储和计算这个功能不仅可以节省大量的成本, 但它也有助于解析和丰富用于实时流和查询的数据.
  • 支持分布式计算:分布式计算可以提供更好的分段查询性能,有助于提高大规模数据处理的性能, 更容错设计, 和优越的并行数据处理.  
  • 定制和互操作性:由于它们“即插即用”的特性, 随着公司数据需求的发展和成熟,数据湖支持数据平台的可伸缩性,使堆栈的不同元素可以很容易地协同工作.
  • 主要基于开源技术:这有助于减少对供应商的锁定, 并提供了良好的定制, 哪些方法适合拥有大型数据工程团队的公司. 
  • 处理非结构化或弱结构化数据的能力:数据湖可以支持原始数据, 这意味着您在处理数据时具有更大的灵活性, 数据科学家和数据工程师的理想选择. 使用原始数据可以让您更好地控制聚合和计算. 
  • 支持复杂的非sql编程模型:与大多数数据仓库不同,数据湖支持 Apache Hadoop, Apache火花, PySpark以及其他用于高级数据科学和机器学习的框架.

重要的是要注意许多数据仓库解决方案, 包括雪花和BigQuery, 是否可以支持上面的一些功能, 这就引出了下一点……

等等,还有更多:介绍数据湖屋

就在你觉得这个决定已经够艰难的时候, 另一种数据仓库选择已经成为一种越来越流行的选择, 特别是在数据工程团队中. 

来看看数据湖屋, 结合了数据仓库和数据湖特性的解决方案, 结果就是, 将传统的数据分析技术与那些为更高级的计算(i.e.机器学习). 

数据湖屋为数据团队提供了更大的可定制性, 允许他们在云上存储数据,并利用一个专门用于其计算引擎的仓库. 图片由Lior Gavish/蒙特卡罗提供.

当云仓库提供商开始添加提供湖泊风格的功能时,数据湖屋首次出现, 比如红移光谱或三角洲湖. 类似的, 数据湖已经加入了提供仓库式功能的技术, 如SQL功能和模式. 今天, 仓库和湖泊之间的历史差异正在缩小,因此您可以在一个包中访问这两个词的最佳效果. 

以下功能将帮助数据湖屋进一步模糊这两种技术之间的界限: 

  • 高性能的SQL: Presto和Spark等技术提供了接近于数据湖交互速度的SQL接口. 这开启了数据湖直接服务于分析和探索需求的可能性, 而不需要摘要和ETL进入传统的数据仓库.
  • 模式:像Parquet这样的文件格式为数据湖表引入了更严格的模式, 以及柱状格式,以提高查询效率.
  • 原子性、一致性、隔离性和持久性(ACID):湖泊技术,如 三角洲湖Apache Hudi 在写/读事务中引入更高的可靠性, 并使湖泊更接近传统数据库技术中标准的、非常理想的ACID属性. 
  • 管理服务:适用于希望减少与构建和运行数据湖相关的操作提升的团队, 云提供商提供各种湖泊管理服务. 例如,Databricks提供了一个托管版本 Apache蜂巢, 三角洲湖, Apache火花亚马逊雅典娜 提供了一个完全管理的湖泊SQL查询引擎和 亚马逊的胶水 提供完全托管的元数据服务.

随着实时数据聚合和流媒体的兴起,光速分析(想想硅谷科技巨头的速度: 超级, DoorDash, Airbnb), 未来几年,数据湖屋可能会越来越受欢迎,对各行各业的数据团队来说也越来越重要. 

那么,你应该选择什么呢?

“一个仓库和一个湖在数据栈中分叉,我……我选择了人迹更少的管道。, 这就是一切的不同.” (对不起,罗伯特·弗罗斯特.)图片由 迦勒琼斯 on Unsplash

答案并不简单. 事实上,经常出现数据团队也不足为奇 从一个数据仓库解决方案迁移到另一个 随着他们的数据组织的需求转变和发展,以满足数据消费者的需求(现在, 几乎每一个功能领域的业务, 从市场和销售到运营和人力资源). 

而数据仓库通常适用于主要用例是数据分析和报告的数据平台, 数据湖变得越来越友好, 特别是通过管理数据湖屋解决方案,比如 Dremio 还有开源项目 三角洲湖.

越来越多地, 推荐一个正规滚球网站发现,数据团队不愿满足于仅仅拥有一个数据仓库, 一个数据湖, 或者甚至是一个数据湖屋——而且有充分的理由. 随着更多的用例出现和更多的涉众(具有不同的技能集)!,一个单一的解决方案几乎不可能满足所有的需求.     

推荐一个正规滚球网站在5号楼采访了一位数据主管,尽管他的数据工程团队坚持要建立一个数据湖, 他们最终建立了一个内部报告系统, 访问控制, 数据质量使最终产品更像是一个数据仓库. 

推荐一个正规滚球网站发现不管你选择哪条路, 应用以下最佳实践是很重要的: 

对齐映射到公司数据目标的解决方案. 

如果您的公司在特定的工作流程中只定期使用一个或两个关键数据源, 那么从头开始建立一个数据湖就没有意义了, 在时间和资源方面. 但如果你的公司试图用数据来告知天下的一切, 那么,混合仓库-湖泊解决方案可能就是你快速前进的门票, 跨角色用户的可操作的见解. 

知道你的核心用户是谁. 

您的数据平台的主要用户是您公司的商业智能团队吗, 分布在几个不同的功能? 有一个专门的数据工程师团队怎么样? 或者几组数据科学家用不同的数据集进行a /B测试? 以上都是?  不管, 选择最适合用户技能和需求的数据仓库/湖/湖屋选项. 

不要忘记数据的可观察性. 

数据仓库、数据湖、数据湖屋:无所谓. 所有这三种解决方案(以及它们的任何组合)都需要 数据治理的整体方法数据质量. 毕竟, your data platform is only as powerful 和 reliable as the data that informs it; if your data is broken, 失踪, 或者不准确(推荐一个正规滚球网站称之为这个问题 数据停机时间),不管你的管道有多先进. 

如果您不能信任自己的数据,那么您对最新和最伟大的数据仓库进行的深思熟虑的投资就没有意义了. 为了解决这个问题,一些最好的数据团队正在利用 数据可观测性它是一种端到端的方法,用于监控和提醒数据管道中的问题. 在以后的文章中会详细介绍.

接下来是什么?

当谈到数据平台的这个基本元素时,我很高兴看到数据行业的发展方向. 我预测一个成熟的数据堆栈很可能包含多个解决方案, 数据组织最终将从更大的成本节约中受益, 敏捷性, 和创新. 

在一天结束时, 这不是选择一种或另一种工具的问题,而是为工作选择正确的工具(或工具). 

如果您有兴趣构建一个更好的数据平台,或者想要讨论适合您堆栈的数据仓库/湖泊, 接触 Lior Gavish可以玩滚球的正规app队