大数据文摘授权转载自数据派THU
编译:张玲、丁楠雅
本文的目的是构建数据湖,并提供适应企业数据策略的背景信息。咨询公司和提供商提出的意见相互矛盾,因此,这些信息历来一直不透明,令人困惑。
不幸的是,这些令人困惑和颇具误导性的建议导致人们不断就技术平台的背景信息发问,而不是就一个战略或者业务成果来发问。这种技术驱动的决策过程试图使主观的讨论变得更加客观,例如,他们会追问什么是亚马逊数据湖?或者什么是最好的数据湖软件。也许有一个供应商急于求成,正在医疗领域里推广符合流行语的、兼容HIPPA的数据湖。所以,对于那些想要厘清数据湖如何赋能数据洞察的人来说,这些关于数据湖的讨论令人更加困惑。
亚马逊数据湖:
https://mp.weixin.qq.com/cgi-bin/appmsg?t=media/appmsg_edit&action;=edit&type;=10&isMul;=1&isNew;=1〈=zh_CN&token;=1763595143&token;=1763595143〈=zh_CN#data-lakes
兼容HIPPA的数据湖:
打破这些与数据湖策略、架构和实现建议相关的错误认知,将有助于你理解数据湖失败的原因及其实现面临的各种挑战,还有助于阐明供应商和咨询公司提供的建议可能与数据湖最佳实践背道而驰的原因。
让我们开始一一打破这些错误认知吧!
错误认知1:数据湖与数据仓库,必须二选一
人们普遍建议在数据湖和数据仓库之间二选一,但这是错误的。
审视现实-数据仓库和数据湖之间的区别
这种必须在数据湖和数据仓库之间二选一的认知错误地限制了讨论的框架。当人们通过询问数据仓库是否过时来开启讨论时,似乎在告知是时候抛弃你的企业级数据仓库。这些问题的出发点都有误,而且正在引你误入歧途。
通常,一家公司需要就某一特定的设计模式进行某种形式的技术投资时,就会引发这些问题的讨论。例如,他们声称某些操作可以或必须发生在数据仓库中,然后将这些操作定义为是采用数据湖架构的限制和风险。
那供应商推广的数据湖架构限制示例是什么?
供应商会说数据湖无法像数据仓库那样便于按需扩展计算资源,从而它是受限的。这是真的,但具有误导性。就这就像抱怨汤姆布拉迪肯定是一名可怕的运动员,因为他从未在职业橄榄球生涯中打过本垒打。既然汤姆布拉迪是一名橄榄球运动员,你会期望他成为一名在芬威棒球场(好吧,也叫Pesky’pole)投球飞过左外野全垒打墙的全垒打投球手吗?不。
Pesky’pole
那么,为什么供应商和咨询公司会在这里应用数据仓库计算概念?
事实上,声称数据湖没有计算资源是一种FUD行销手法(灌输数据湖的负面观念,在你的头脑里注入疑惑和恐惧,使你误以为除了数据仓库以外,别无选择)。数据湖无法按需扩展计算资源,是因为没有需要扩展的计算资源。
FUD行销手法:
在数据湖体系结构中,计算资源分离是一种核心的抽象,这是Redshift Spectrum、Presto和Athena解决方案存在的原因。以Amazon的Athena为例,Athena不是一个数据仓库软件,而是一个基于开源FaceBook Presto开发的按需查询引擎,它将按需提供“计算”资源查询数据作为一项服务来提供。Amazon的Redshift Spectrum和Athena一样可以查询数据湖中的数据,利用的是从一个Redshift集群中分离出来的计算资源。
Redshift Spectrum
Presto
Athena
根据设计,数据湖中的查询数据服务可以很好地抽象出这个引擎模型,而且无论你在Google云上是否有亚马逊数据湖(AWS数据湖)、Oracle数据湖、Azure数据湖或BigQuery数据湖,模型都是类似的。可以通过Athena这类的查询引擎或者像Redshift、 BigQuery、Snowflake等“仓库”来查询数据湖数据内容,这些服务提供计算资源,而不是提供一个数据湖。
Redshift
BigQuery
所以,对于大多数企业来说,数据湖和数据仓库如何共存才是正确的讨论内容,而不是讨论如何二选一。当有人向你提出只能二选一时,他们可能是利益相关方,也就是说他们的产品或者商业伙伴也提供相关的功能。
错误认知2:数据仓库就是一个数据湖
这种想法会诱使你放弃数据湖,将所有数据都扔进数仓中。
审视现实-定义有效的数据湖
的确,有一些供应商和咨询公司主张将数仓作为数据湖模型。
不同的供应商和咨询公司会建议使用模式(或其他物理或逻辑结构)来表示数据从“原始”到数仓中其他状态的生命周期,业务所需的任何成熟度数据都可以在仓库范围内完成。
传统上,数仓旨在反映企业已经完成的事务,也反映企业完成一系列的一致事务,例如一个已经完成的事务可能提供有关收入、订单、“最佳客户”和其他领域的重要事务。
但是,在数仓“导入所有数据”模型中,数仓包含所有的数据内容,其中会包括暂时的和易失的原始数据。
将所有的原始数据重新打包到数仓中的操作更像是操作型数据库(Operational Data Store,ODS)或者数据集市的操作,而不像是数仓的操作。你能将所有的数据都扔进数仓吗?不能。不能仅仅因为你可以在技术上做一些事情,就可以使它成为正确的体系结构。
操作型数据库:
将所有数据放进仓库的建议说,事务数据只是逻辑组织数据的一个功能。在企业内部定义和推广这个逻辑定义的人将无法得到理解,甚至更糟的是他将被忽视,原因是这种方式几乎就是一种发生在数仓中的“数据沼泽”,尽管教科书上定义数据沼泽发生在数据湖中。对于任何一个被迫善后处理的人来说,这都是一场数据处理的噩梦。
数据处理:
这个模型会将你限制在数仓技术及其模型中,同时还需要你将所有数据都导入数仓。如果你喜欢四处寻找供应商、设定各种人为限制、降低数据认知能力和背负各种技术债务,那么这种方法肯定很适合你。
技术债务:
正确的做法是,数据湖可以最小化技术债务,同时还可以加速企业团队对数据的消耗。考虑到数仓、查询引起和数据分析市场的变化在加快,你战略的核心应该是最小化风险和技术债务。
错误认知3:数据湖只能用Hadoop来实现
你会经常发现有讨论和示例将数据湖等同于Hadoop或者Hadoop相关供应商技术栈,这会给人一种错觉:数据湖和Hadoop特定的技术紧密相关。
审视现实-Hadoop不是一个数据湖
虽然Hadoop技术可以用于数据湖的构建和运行,但它们并不能反映出所支持的数据湖的基本战略和架构。
认识到数据湖最先反映的是战略和架构,而不是技术,这一点很重要。Pentaho联合创始人兼首席技术官詹姆斯·狄克逊(也就是创造“数据湖”这个词的人)说:
这种情况和传统的商业智能分析程序构建方式类似,根据终端用户给出的数据问题清单,从数据流中筛选出与问题相关的字段属性,并批量记载到数据集市中。在你提出新问题之前,这个方法是可行的。数据湖可以完全解决这个问题,你可以将所有数据存储在数据湖中,填充数据集市和数据仓库以满足传统的数据需求,针对新问题,则可以启用数据湖中的原始数据以供即席查询和生成报告。
Hadoop和其它技术一样,可以支持战略和架构的实现。如果现在你有一个数据湖,会有很多非Hadoop的选择,即使这些选择使用了Hadoop相关技术。例如,你的数据湖需要同时支持Snowflake这样的数仓解决方案和在AWS Athena、Presto,、Redshift Spectrum和BigQuery这样的就地查询方式。
AWS Athena
Redshift Spectrum
别以为数据湖只能使用Hadoop实现,如果你遵循一个精心抽象的数据湖架构,那么就可以根据技术的发展性及其对更广泛的企业生态系统的支持度选择其它技术,从而最小化风险。
错误认知4:数据湖仅用于“存储”数据
在这种情况下,数据湖只是一个存储你所有数据的地方。你只需要所有数据放入数据湖,而后启用新的数据管理模型就可以大功造成,这就和将所有的文件都放进笔记本电脑上超大硬盘中的“无标题文件夹”一样。
审视现实-数据湖不仅仅是一个存放数据的地方
当供应商将数据湖定义为存储的同义词时,这可能会变得复杂。例如,微软将产品打包为Azure Data Lake Storage或Azure Data Lake Storage Gen2,数据湖确实提供了存放数据的功能,但这只是其特征之一。
如前所述,应该将数据湖视为是企业更为广泛的数据栈中的战略元素,这包括在下游系统中(如数仓)支持事务数据集成,或者在Tableau或Oracle ETL等工具中支持数据处理。
因此,数据湖不仅仅可以存储数据,还可以兼容数仓、数据分析技术栈中的技术。事实上,大多数数据湖是动态的生态系统,而不是静态的封闭系统。当数仓负载适中时,数据湖是一个活跃数据源,源源不断为其输送数据,反之亦然,负载过重时,数据湖进行对数据进行适当地动态处理,以降低成本和提高效率。
数据湖对数据进行适当地组织,以便将下游价值传递给使用数据的下游系统,包括数仓。例如,数据湖在支持数仓整合事务数据方面发挥了积极的作用。
我们有一位客户使用数据湖对数十个网站和第三方酒店的标签进行质量控制分析,这有助于识别负责这项工作的不同团队可能存在的差异和执行错误。还有一位客户在将数据导入企业级数据仓库前,使用数据湖过滤来自不同部门、第三方和合作伙伴系统中的不准确订单或重复的多渠道订单。
这两个例子都强调了,数据湖在保证下游事务数据的准确性和合规性上发挥了积极的作用。
正如麦肯锡员工所说:“…数据湖不仅保证了技术栈的灵活性,而且还保证了业务能力的灵活性。”数据湖作为一种服务模型,是为了交付业务价值,而不仅仅是存储数据。
交付业务价值:
错误认知5:数据湖仅存储“原始”数据
和错误认知2相关,“把所有数据都倒进数仓”的方法表示,数据湖不会增加价值,原因是只有原始数据驻留在数据湖中。他们主张:“如果数据湖只处理原始数据,那么就不用担心数据湖了,只需将所有的原始数据或者已被处理的数据转存至数仓中”。
审视现实–定义有效的数据湖策略和架构
正如之前所说的,这和数仓旨在反映既定事务数据的基本前提相矛盾。一个更好的历史数据比较不是在数仓和数据湖之间进行,而是在ODS和数据湖之间进行。
从历史数据角度上看,数据湖是一个ODS,而不是一个数仓,因为数据湖从上游获取粗糙和不稳定的原始数据。一个ODS数据通常时间范围很窄,可能只有90天内的数据,针对某一特定数据领域,时间范围可能更窄。另一方面,数据湖对于保留的数据没有时间范围限制,从而时间范围更广些。
那么,数据湖仅是为了存储“原始”数据吗?
不。
根据设计,数据湖应该有一定程度的数据输入管理(即管理什么数据要进入数据湖)。如果你没有管理数据进入模式的意识,那么你其它地方的技术栈可能存在问题,这对于数仓或任何其它数据系统也是一样的,垃圾进,垃圾出。
数据湖的最佳实践应该包括一个配备初始数据池的模型,在这个初始数据池里,你可以最低限度地优化模型,以为下游处理数据或辅助处理数据。数据处理可能发生在Tableau或PowerBi之类的分析工具中,也有可能发生在加载数据到数仓(如Snowflake、Redshift和BigQuery)的应用程序中。
优化:
与我们合作的一位客户将Adobe事件数据发送到AWS,以支持企业Oracle云环境。为什么要从AWS到Oracle呢?因为这是Oracle BI环境中最高效的和最具成本效益的数据处理模式,尤其是考虑到使用AWS数据湖和Athena作为按需查询服务的灵活性和经济性。
Adobe事件数据发送到AWS,以支持企业Oracle云环境:
通过最大限度地保证数据的有效性,提高处理数据的效率,你可以最大限度地降低下游数据处理者所要付出的数据处理成本。
错误认知6:数据湖仅适用于“大”数据
如果你花时间阅读过数据湖的相关资料,你会认为数据湖只有一种类型,看起来像里海(它是一个湖,尽管名字中有“海”)。人们将数据湖描述成一个庞大的、包容一切的实体,旨在保存所有的知识,因此只会有一个企业大数据湖或者大数据架构的同义词。
审视现实-数据湖有各种形状和大小
不幸的是,“大数据”角度给人以一种错觉:数据湖仅适用于里海范围那么大的数据,这当然会让数据胡的概念令人生畏。因此,用如此量大的术语来描述数据湖会使那些本可以从中获益的人无法接近。
另一个观点是数据湖和大数据只能二选一。像自然界中的湖泊一样,数据湖有各种不同的形状和大小。每一种数据湖都有一种自然状态,通常反映数据的生态系统,就像自然界中反映鱼、鸟或其它有机体的生态系统一样。
以下是一些例子:
-
诺大的“Caspian”: 就像里海是大片水域一样,这种类型的数据湖是一个存放各种半结构化和非结构化数据的大型数仓,这些整合了不同数据集的超大数据集反映了来自企业方方面面的信息。 -
临时的“Ephemeral”:就像沙漠可以有小的、临时的湖泊一样,临时的数据湖“Ephemeral”也是短暂存在的。它们可以用于项目、试生产、PoC或者一个点解决方案,可以很快打开,也可以很快关闭。 -
领域性的“Project”:这种类型的数据湖和“Ephemeral”一样往往集中在特定的知识领域中。然后,和临时“Ephemeral”不同的是,这种数据湖可以持续一段时间。这些数据湖可能也很浅,可能专注于一个狭窄的数据领域,如媒体、社交、网络分析、电子邮件或类似的数据源。有一位客户称他们的项目为“Tableau数据湖”。
数据湖示例
-
访问:通常,对针对基础数据定义良好的访问策略。在AWS中,你可以定义针对S3的IAM策略及其相关服务。除此以外,微软还有一个描述类似安全策略方法的Azure数据湖架构。 -
工具:处理数据的工作和系统也会确保一定的安全性。例如,查询引擎可以有一个表级和列级数据的访问控制机制。此外,数据处理工具(如Tableau或Power BI)也可以对数据湖中的数据设置访问控制。 -
加密:通常会希望(或强制)在数据传输和静止时对其进行加密。 -
分区:逻辑分区和物理分区在一定水平上进一步简化了安全策略,例如团队可以将数据从初始数据池ETL至另一个位置,实现匿名化敏感数据,以供下游使用。
https://mp.weixin.qq.com/cgi-bin/appmsg?t=media/appmsg_edit&action;=edit&type;=10&appmsgid;=100013110&isMul;=1&token;=698435870〈=zh_CN#amazon-data-lake
-
焦点: 寻找可以部署“Ephemeral” 和“Project”解决方案的机会,确保你可以降低风险,克服技术和组织挑战,从而使你的团队能够建立对数据湖的信心。 -
激情: 确保你有一个内部的“福音传道者”或“大力倡导者”,这个人对公司内部的解决方案和应用充满激情。 如果缺少这样充满激情的人或团队,你会发现构建数据湖的热情就很快殆尽,正如健身房新年促销4周会员卡一样。 -
简单: 坚持简单和敏捷的理念,根据这一点,做出人、流程和技术的选择。 缺乏复杂性不应该被视为缺陷,而应该视作是精心设计的副产品。 -
缩小: 缩小数据范围,可以很好地定义数据湖,以便了解从ERP、CRM、Point-of-Sales、Marketing or Advertising data从导出地数据,这个阶段的数据处理经历有助于你了解数据的基本结构、获取、治理、质量和测试的工作流。 -
实验: 将你的解决方案和现代BI分析工具(如Tableau、Power BI、Amazon Quicksight或Looker)结合起来,这可以让非技术用户有机会通过访问数据湖来测试和探索数据,同时也有助于你利用不同的用户群来评估性能瓶颈,发现改进机会,及时补充与现有EDW系统或其它数据系统的连接和其它候补数据源。除此之外,还允许你发现对团队有意义的数据湖工具以及适合投入资源的数据湖自动化部分。
https://aws.amazon.com/lake-formation/
使用无代码、全自动和零管理的Amazon Redshift Spectrum或Amazon Athena Services来启动你的工作。
https://www.openbridge.com/warehouse/amazon-redshift-spectrum
https://www.openbridge.com/warehouse/amazon-athena
https://calendly.com/openbridge/project-discussio
https://blog.openbridge.com/8-myths-about-data-lakes-c0f1fc71240
实习/全职编辑记者招聘ing
加入我们,亲身体验一家专业科技媒体采写的每个细节,在最有前景的行业,和一群遍布全球最优秀的人一起成长。坐标北京·清华东门,在大数据文摘主页对话页回复“招聘”了解详情。简历请直接发送至zz@bigdatadigest.cn
朋友会在“发现-看一看”看到你“在看”的内容