治理技术
文章推荐
- 顶级商业智能计划为用户提[2017-02-15]
- 数据湖:不治理便破产[2017-02-15]
- 经典场景化商业智能(BI)服[2017-02-07]
- 从数据仓库到数据湖——浅[2017-02-07]
- 2017年商业智能BI发展趋势[2017-02-07]
数据湖:不治理便破产
发布时间:[2017-02-15]
来源:作者:Nicole 编辑:杜森
点击量:
在当今的数据架构中,治理已成为一个关键的组成部分。没有它,公司可能会失去有意义的商业智能。
当STEVE CRETNEY仔细查看存储数量时,他从中发现了颠覆Colony BrandsIT战略的细节。
“我们观察到,在我们的SAN(存储区域网络)中,有几百TB的存储,”Colony Brands公司的CIO Cretney说,该直销零售商位于威斯康星州门罗。
其中的大部分,来源于操作系统,一部分会用于分析,但大多数则打包,成了闲置数据。相比之下,Colony Brand的数据仓库内只包含10到15 TB的数据,用于特定的业务分析和报告。 两者之间的差异让Cretney和他的团队思考:如果数据科学团队能够获取SAN里的数据,会有什么发现呢?
Cretney,3年前加入Colony Brands,就一直深信云计算。为了能够利用闲置数据,并推动公司向云方向发展,他选择了Amazon S3云存储服务,以及Amazon Redshift数据仓库。他的计划中,第一阶段将在4月完成,不仅是将公司的数据仓库功能迁移到云,还要使用数据湖开发公司数据。
数据湖,或数据中心,是一种在不牺牲数据结构的情况下, 摄取数据的存储仓库和处理系统,已经成为现代数据架构和大数据管理的同义词。数据湖的优势,是它对于数据的摄取没有严格的模式或处理要求,使企业更容易收集所有类型和大小的数据。而对于CIO和高级IT领导者,比较困难的部分是维持数据规则。专家认为,因为没有预先设置的数据架构,数据湖治理,包括元数据管理,对于保持数据湖的原始状态至关重要。
适合大数据的中央数据存储库
一直以来,分析和商业智能的工作都是使用数据仓库完成的,IT部门都尝试过这一技术,但在很多情况下,都失败了,无法完成中央数据存储库。“数据仓库和数据库,本质上都太贵了,而且过多受制于存储和性能,因为要将所有的数据都存储在一个地方,”Phil Shelley说,他是位于印度,提供Hadoop服务的DataMetica Solutions Private公司的顾问和总监。
IT部门开始使用提取、转换和加载(ETL)工,具“将数据分解成可管理的块,然后将数据归档,”Shelley说。但是这样做,会给分析师带来耗时的任务,不得不拼凑和追踪可能藏在数据集市、数据库和数据档案内的数据集。尽管如此,分析师可能只能获得可用存储中被认为有价值的数据集。“如果他们想要更久远的数据,或更多细节,通常由于性能和成本原因,这些数据都不在他们的数据仓库内,”Shelley说。
随着企业比以往更迫切的需要利用更多的,更复杂的数据,建立在廉价商用硬件,比如Hadoop上的文件系统,提供了不同的方法。 “不需要使用传统的ETL工具,我们可以几乎实时的把所有的历史数据和新数据,都汇总到同一个地方,” Shelley说。
作为结果,建立的数据还提供了另一个优势: 不要求数据结构,使数据科学家不需要预先设计模式, 就可以分析数据。 二十年前,数据仓库被视为一个可行的中央存储库,因为公司 “控制”用于分析的数据。
“我指的是你企业内的数据,比如SAP ERP系统的数据,”纽约公司Caserta Concepts的创始人和总裁Joe Caserta说、, “但是现在我们会从未知的,而且不受我们控制的第三方获取数据。”在摄取前, 要结构化第三方的数据很困难,因为诸如数据是如何生成的,数据的内容这些基本要素,是无法马上获知的。使用数据湖,公司可以摆脱死板的结构-摄取-分析流程,转而使用更灵活的摄取-分析-理解流程。“一旦我们理解了(数据),那么我们就可以结构化,”Caserta说。
治理:不成功即失败
数据湖提供的相对灵活性也是要付出代价的:没有数据湖治理,企业可能失去有意义的商业智能,甚至破产。
最近,在德克萨斯州举行的Gartner Business Intelligence and Analytics Summit上,分析师Nick Heudecker说,一位消费服务行业的客户,在它的关系数据库表现不佳后,决定实施数据湖。但该公司的项目范围太有限,主要集中在数据摄入。
“所有数据的上下文、数据来源、创建的原因、创建的人,都丢失了,”Heudecker说,“等到公司解决这个问题,再回到原来的平台时,他们已经失去了三分之二的顾客,几乎破产。”
这是一个极端的事例,但是可以肯定的是,数据湖治理的重要性,包括数据目录、索引和元数据管理,CIO都不应该忽视。“这是一个巨大的挑战,”Colony Brands的Cretney说。“除非你有元数据,要不你就丢失了上下文。”而这只是数据湖管理难题的一部分。Cretney还建议CIO考虑全面的数据湖治理,包括是谁引入的数据、谁负责数据,以及数据的定义,以确保数据的妥善标记和使用。
波士顿公司State Street的副总裁兼首席科学家David Saul表示完全同意。“如果最初你没有健全的元数据集,用于描述数据、说明它代表了什么,然后就将它引入数据湖,这个情况比建立数据仓库还要糟糕,”他说,“这样可能更快,但你不知道数据湖里有什么。”
语义数据库:“元数据的升级版”
与传统数据仓库和其预定义的模式不同,Heudecker认为,数据湖既需要CIO们足够的管理以提供必要的上下文,又不能过多的管理,压制了数据湖提供的灵活性。
“这需要大量的工作,也可能变得很糟糕,”他说,“所以要慢慢来,找出你完成这一工作所需要的,然后开始。”
在State Street,数据湖是一个语义数据库,利用了与创建网络超链接相同的标准和技术的概念模型。数据湖的优势,就是不强调任何数据结构,也是它的弱点,至少在Saul看来。“它不需要任何关于数据的语义、结构或关系,”他说,“Hadoop是一个并行文件系统,它运行的很好;它执行得很快。但是你需要知道更多的数据含义,而不仅仅是文件系统和位置。”
语义数据库,Saul称之为“元数据的升级版”,为数据增加了一层上下文、定义数据的含义,以及和其他数据之间的相互关系。State Street的语义数据库依赖万维网联盟的标准来定义数据描述:语义数据表示模型被称为资源描述框架(RDF),和一个Web本体语言,称为OWL数据。使用这些标准,State Street生成数据的语义信息,可以使用SQL查询语言,SPARQL进行搜索。
Saul说,把语义数据库看作为一个拥有成千上万书籍的图书馆的卡片目录。没有它,找出一个特定的名称是不可能的。“Hadoop就是如此,”他说,这种受欢迎的文件系统技术几乎成为数据湖的代名词。“否则你就必须一本书一本书,一页一页,逐字逐句地去寻找。”
多亏有了这一系统和元数据,拥有一个健全的卡片目录,就没有艰苦的任务了。“只有语义模型能够做到,文件系统是无法完成的,”他说。
对于State Street这样的金融机构,监管机构要求数据历史,数据从何而来,如何获得,强大的数据治理是必须的。然而,传统技术将数据保存在数据孤岛中,可能导致视野狭窄,或者不良分析。数据湖,State Street使用的这一概念,提供了灵活性,以消除数据孤岛。语义数据库增加了一定程度的治理和元数据管理,保持数据湖良好的工作秩序。
“我认为数据湖被过分夸大,让CIO们和(首席数据官)认为是一种高招,”Saul说,“如同数据管理中的一切,如果你不详细管理,你就不会获得你所期待的结果。”