企业数据仓库在大数据分析时代的角色变迁


企业数据仓库在大数据分 析时代的角色变迁 Kimball 集团白皮书 作者:Ralph Kimball 目录 引言 ........................................................................................................................ 1 关于作者 ................................................................................................................. 1 简介 ........................................................................................................................ 2 数据也是资产负债表上的一种资产 .................................................................. 3 揭开大数据分析的面纱 ........................................................................................... 4 大数据分析使用案例 ........................................................................................ 4 使大数据分析使用案例获得价值 ...................................................................... 7 大数据分析系统要求 ............................................................................................... 9 扩展关系数据库管理系统 ............................................................................... 10 MapReduce/Hadoop 系统 ............................................................................. 13 MapReduce 如何在 Hadoop 中工作 ............................................................. 13 Hadoop 环境的工具 ....................................................................................... 15 未来十年中的技术汇聚 .................................................................................. 18 可复用分析 ..................................................................................................... 19 复杂事件处理 (CEP) .................................................................................... 20 未来十年中的数据仓库文化变迁 .......................................................................... 20 沙盒 ............................................................................................................... 20 低延迟 ............................................................................................................ 21 永远精益求精 ................................................................................................. 21 低干涉数据的相关性正待揭示 ........................................................................ 22 所有数据的简单分析胜过部分数据的复杂分析 .............................................. 22 数据结构应在查询时而非数据加载时声明 ..................................................... 23 支持大数据分析的 EDW 必须有磁性、灵活性和深入性 ............................... 23 抽象和控制之间的冲突 .................................................................................. 23 未来十年中的数据仓库组织变化 .......................................................................... 24 需要的技术技能集 .......................................................................................... 24 需要的新组织 ................................................................................................. 25 需要的新开发范式 .......................................................................................... 26 数据仓库时代早期得到的教训 ........................................................................ 27 云中分析 ........................................................................................................ 27 EDW 的前景如何? ....................................................................................... 28 致谢和参考资料 .................................................................................................... 29 企业数据仓库在大数据分析时代的角色变迁 企业数据仓库在大数据分析时代的角色变迁 1 引言 在本白皮书中,我们描述了设计企业数据仓库 (EDW) 为“大数据”时代的业务分析 提供支持的快速发展场景。我们还介绍了构建和发展 EDW 来满足新业务要求的范围和 挑战。这包括高度集成、半结构化和非结构化数据源、以拍字节计的行为和图像数据 (通过 MapReduce/Hadoop 进行访问) 以及大规模并行关系数据库,然后是构造 EDW 来支持高级分析。本文为设计和管理部署所需的必要流程提供了详细的指导。在 EDW 需要如何对大数据分析挑战作出响应,以及需要什么必要的设计元素来支持这些新的要 求等方面,业内缺乏具体的指导,本白皮书就是针对这种情况编写的。 关于作者 Ralph Kimball 是 Kimball 集团的创始人。他从 1980 年代中期开始就是数据仓库/商业 智能 (DW/BI) 行业维度方法方面的思想领袖,培训了超过 10,000 名 IT 专业人才。 Ralph 在施乐的 Palo Alto 研究中心 (PARC) 共同发明了 Star 工作站,其后在 Metaphor 工作,之后成立了 Red Brick Systems。Ralph 在斯坦福大学获得电子工程 博士学位。 Kimball 集团是维度 DW/BI 咨询和教育的资源提供者,这与我们最畅销的 Toolkit 丛 书、设计小贴士和获奖文章相一致。请访问 www.kimballgroup.com 了解更多信息。 企业数据仓库在大数据分析时代的角色变迁 2 简介 什么是大数据?大数据的大实际上并不是最令人关注的特征。大数据是很多不同格式的 结构化、半结构化、非结构化和原始数据,在某些情况下看起来与过去 30 年来我们存 储在数据仓库中清一色的标量数字和文本完全不同。很多大数据不能使用任何类似 SQL 这样的工具进行分析。但是最重要的是,大数据是我们如何看待数据资产、在哪里 收集、怎样分析以及如何将分析得到的见解转化为利润的一种范式转换。大数据革命关 乎发现常规数据源内部和外部的新价值。因为过去的软件和硬件环境还不能在合理的开 发时间或处理时间内捕获、管理或处理新形式的数据,所以需要一种新的方法。我们面 临的挑战是要重新组织信息管理布局,从相当稳定的 EDW 体系架构前进到大数据分析 的新时代。 在阅读本白皮书的过程中,请时刻牢记,本文作者的观点始终认为“数据仓库”包含提 取、清洗、集成数据并将数据交付给决策者的完整生态系统,因此包括提取-转换-加载 (ETL) 和商业智能 (BI) 功能,而更保守的作者则认为这些功能在数据仓库之外。本文 作者始终所持的观点是,数据仓库在捕获所有形式的企业数据以及在其后准备这些数据 供全企业决策者使用的过程中起到非常广泛的作用。本白皮书认为企业数据仓库将被赋 予重托,承担非常激动人心的新职责。EDW 的范围将会显著扩大。 还有,在本白皮书中,尽管我们一直使用术语“ETL”来描述数据在企业数据仓库中的 运动,这条术语的常规用法却并没有正确体现大数据分析世界中跨网络并在系统间以及 完全不同流程之间运动的数据所担负的更大责任。ETL 所属的技术远大于此,这种技术 被称为数据集成 (DI)。因为我们很多年来一直在我们的专著和课堂中使用 ETL 这个 词,所以本文中仍旧沿用这条术语,但是牢记 ETL 指的是更大意义上的 DI 范畴。 本白皮书根据 2011 年初的市场的情况,突出说明大数据革命所带来的全新趋势。大数 据本身就是一场革命。Informatica 的执行副总裁兼首席技术官 James Markarian 评论 道:“数据库市场最终又重获关注。”因为很多新型大数据工具和方法还处于第 1 版甚 至第 0 版的开发阶段,所以局面将继续快速变化。市场普遍认识到进行此类新型分析的 可能性,重要的竞争者尤其是电子商务企业已经开始利用这种新范式的优势。本白皮书 旨在成为商业智能、数据仓库和信息管理专业人员及管理团队了解大数据并为大数据做 好准备的一个指南。 企业数据仓库在大数据分析时代的角色变迁 3 数据也是资产负债表上的一种资产 企业日益认识到数据本身是一种资产,应该和制造业时代始终在资产负债表出现的设备 和土地这样的传统资产一样,也在其中体现出来。确定数据资产的价值有多种方法,其 中包括:  产生数据的成本  数据丢失时替换数据的成本  数据所带来的收入或获利机会  如果数据落入竞争对手手中所造成的收入或利润损失  如果数据向错误对象公开而面临罚款和诉讼的法律风险 但是比数据本身更重要的是,企业已经展示了对数据的洞察可以转化为利润。在电子商 务网站通过实验性广告处理探测到偏好点击意愿增加时,这种洞察可以立竿见影地对企 业最终业绩造成影响。这种直接的因果关系很容易被管理层理解,最高管理层将一贯显 示出这种洞察力的分析研究小组作为企业的战略资源来看待。在数据驱动洞察力价值方 面,商业认知程度的这种提高正迅速从电子商务扩展到几乎每个商业细分领域。 当然,数据仓库证明数据驱动洞察力的价值至少有 20 年的历史。但是直到最近,数据 仓库注重的还是历史交易数据。在 2000 年到 2009 年的最近十年中,数据仓库方面发 生了三个翻天覆地的转变。第一个转变发生在这十年的初期,就是决定性地将低延迟运 营数据与已有的历史信息一起引入数据仓库。当然,这些新的运营数据中有很多使用受 益于实时数据的案例,在一些案例中要求即时交付。第二个在这十年中一直在不断深化 的巨大转变是客户行为数据的收集,这不仅包括包括购买和点击这样的传统事务,还加 入了巨量“子事务”,其体现的是引向交易本身的可衡量事件。例如,客户在最终交易 事件之前参与的所有网页事件变成客户行为的记录。通过这些网页事件历史的“良好路 径”给出了很多对有生产效益 (即可货币化) 的客户行为的洞察。 第三个翻天覆的事件在我们跨入新的十年时得到了巨大的动力,这件事就是从社交媒体 提取产品偏好和客户的情感,尤其是由 .com 公司的新业务范式产生的巨量由机器生成 的非结构化数据。就是最后这种翻天覆地的转变推动很多企业第一次认真审视非结构化 数据,他们在问“我们究竟该怎样分析这种素材?”在这一点上,并不是说非结构化数 据是最近才发现的什么新事物,而是说非结构化数据的分析直到最近才成为主流。 企业数据仓库在大数据分析时代的角色变迁 4 揭开大数据分析的面纱 大数据分析使用案例 大数据分析使用案例正成为燎原之势。这里就是一组最近报道的使用案例,包括 Cloudera 的首席科学家 Jeff Hammerbacher 提出的“Hadoop-able”(适用 Hadoop) 基准使用案例集。在这些简要说明后是总结每个案例突出结构和处理特征的一个表格。 请注意,这些使用案例没有一个能用标量数值数据满足,也不能用简单的 SQL 语句进行 正确分析。按照适当的业务设想,所有这些案例可以扩展到拍字节甚至更高的范围。 贷款风险分析和保单承保。为评价预期贷款或预期保单的风险,很多数据源可以调用, 其范围包括偿付历史、信用报告、就业数据和财务资产披露内容等。在一些情况下,贷 款抵押物或被保项目可能配有图像数据。 客户流失分析。关心客户流失的企业希望了解造成客户流失的预测性因素,包括客户的 行为以及很多外部因素,其中包括经济、年龄段和其他人口统计学信息,最后还有竞争 的问题。 搜索排名。所有的搜索引擎都试图对搜索请求排出网页与其他所有可能的网页相比的相 关性次序。当然,谷歌的排序算法就是这种使用案例的一个范例。 广告追踪。电子商务网站一般都记录包括每次用户会话中每个页面事件的海量数据。这 样就可以在很短的时间内就完成一次广告位置、颜色、大小、用词和其他特征的试验。 当试验表明广告中的这种特征更改促成了更好的点击行为,这个更改几乎可以实时实 施。 位置和邻近追踪。很多使用案例在操作应用程序、安全分析、导航和社交媒体中加入了 精确 GPS 位置追踪,同时有频繁的更新。精确位置追踪为 GPS 测定点附近其他位置 的海量相关数据打开了大门,这些其他位置可能带来销售或服务的机会。 因果因素发现。销售点数据一直以来都能够向我们表明产品销售何时急剧上升或下降。 但是对解释这些背离的因果因素的寻找、充其量是一个猜谜游戏或一门艺术。答案可能 会在竞争价格数据、包括平面和电视媒体在内的竞争促销数据、天气、节日、包括灾害 在内的国家大事以及社交媒体中像病毒一样传播的观点中找到。同见下一个使用案例。 社交 CRM。这个使用案例是市场分析最热门的新领域之一。Altimeter 集团描述了一套 非常有用的社交 CRM 关键绩效指标 (KPI),包括语音共享、观众参与、对话范围、主 动倡导、倡导的影响、宣传的影响、解决率、解决时间、满意度评分、主题趋势、情感 比和思想影响。这些 KPI 的计算涉及对巨量数据源尤其是非结构化的社交媒体的深入 挖掘。 企业数据仓库在大数据分析时代的角色变迁 5 文件相似度检测。可以对两个文件进行比较,得出相似度的度量。存在大量的学术研究 和经过检验的算法,例如潜在语义分析,但它们直到现在才开始激发大数据从业人员对 货币化洞察方面的兴趣。例如,可将单个源文件作为一种多层面模板使用,与一大组目 标文件进行比较。可将此用于威胁发现、情感分析和民意调查。例如:“找出所有与我 关于全球变暖的文件观点一致的文件。” 基因组分析:例如商业化种子基因组测序。几个月前,一则基因组测序的声明震动了棉 花研究界,这则声明的一部分说的是“这个序列将作为未来组装更大的棉花作物基因组 的基准而起到关键作用。棉花是全世界最重要的纤维作物,这个序列信息将为更高产、 更高纤维品质以及适应环境压力并且抗虫害和病害的更快育种开辟道路”。科学家 Ryan Rapp 强调了棉花研究界参与分析序列、识别基因和基因族以及确定未来研究方向 的重要性 (SeedQuest,2010 年 9 月 22 日)。这个使用案例仅是一个正在形成整个行 业广泛从事基因组分析的一个例子,超越了种子基因测序这个例子的范畴。 客户队列群体的发现。很多企业使用客户队列群体来识别一般的人口统计学趋势和行为 历史。我们都熟悉 Amazon 的队列群体,我们听到过他们说,和你买相同一本书的其 他客户也买下面这些书。当然,如果你能够将产品或服务出售给队列群体的一名成员, 那么所有剩下的成员自然而然都有希望。队列群体在逻辑和图形上用链接表示,队列群 体的分析很多都涉及特殊的链接分析算法。 在航飞机状态。无所不在的传感器技术的引入使这个使用案例以及后面两个使用案例成 为可能。在飞机系统的案例中,发动机、燃油系统、液压和电力系统数以百计的变量组 成了在航状态,不到几微秒就被测量和发送一次。这个使用案例的数值不仅仅是未来某 个时间点能够分析的工程遥测数据,而且还促进实时自适应控制、燃油使用、零件故障 预测和飞行员通报。 智能电表。电力公司不用多久就可以知道,智能电表能够用来做的远不止是生成客户 电 费账单的每月读数。通过将整个客户全局中读数频率大幅缩短到每秒每只表一次,可以 进行很多有用的分析,包括动态负载平衡、故障响应、分时电价和鼓励客户 提高用电 效率的长期战略 (从客户的角度和电力公司的角度都有利!) 楼宇传感器。现代化工业建筑和高楼都装有数以千计的小型传感器,来探测温度、湿 度、振动和噪声。和智能电表类似,因为每天 24 小时每隔几秒就收集一次这种数据, 所以可以实现很多形式的分析,包括用电量、不正常问题 (包括违反安全规定、空调和 供暖系统及管道系统的零部件故障) 的分析以及施工规范和定价策略的制定。 企业数据仓库在大数据分析时代的角色变迁 6 卫星图像对比。来自卫星的地球上各地区的图像是在某个卫星每次经过时捕获的,间隔 是短短几天。将这些图像重叠并计算差异,可以创建显示发生过什么变化的热点地图。 这种分析可以识别施工、破坏、由于飓风、地震和火灾等灾害造成的变化以及人类侵入 范围的扩大。 CAT 扫描对比。CAT 扫描是作为人体“切片”拍摄的图像的堆叠。可对大型 CAT 扫 描库进行分析,帮助对医疗问题及其患病率进行自动诊断。 金融账户欺诈行为检测和预防。账户欺诈当然会对金融秩序造成直接和明显的影响。在 许多情况下,可以通过帐户的行为模式检测到欺诈,在某些情况下,这种行为跨越多个 金融系统。例如,“空头支票”需要钱在两个独立账户之间来回快速转账。特定形式的 经纪欺诈牵涉到两个合谋经纪人以不断抬高的价格售出证券,直到不知情的第三方受骗 购买证券,使欺诈的经纪人能够快速退出。这种行为同样也可能在很短的时间内跨越两 个单独的交易所发生。 计算机系统黑客入侵检测和干预。在许多情况下,黑客入侵系统涉及不寻常的进入模 式,或其他事后回想可以寻到蛛丝马迹,但可能很难实时检测的某种行为。 在线游戏手势跟踪。在线游戏公司通常以最细粒度水平记录每位玩家每次点击和移动。 这样大量涌入的“遥测数据”可以实现欺诈检测、对屡战屡败 (并因此灰心) 的玩家的 干预、向将要完成游戏而要离开的玩家提供额外的剧情或游戏目标、新游戏剧情的想法 以及游戏中新剧情的试验。这一点可以推广到电视收看上。你的 DVR 盒可以捕获遥控 器的按键行为、录像事件、播放事件,画中画观看以及收视指南的背景情况。所有这些 可以发回给你的服务提供商。 大科学包括原子对撞机、天气分析、空间探测遥感馈送。重大科学项目总是需要收集大 量数据,但现在大数据分析的技术允许数据更广泛的访问和更及时访问。当然,大科学 数据是所有形式的数据、标量、向量、复杂结构、模拟波形和图像的混合体。 “数据包”探索。最后,在商业环境和科研团体中,有许多情况会收集大量的原始数 据。一个例子可能是建筑火灾的相关数据收集。在时间、地点、火灾的主要原因以及响 应的消防队员这些可预见的范围之外,还可能存在大量不可预见的零星数据,这些数据 充其量只能作为一个名称值对的无序集合建模,如“造成火灾的天气 = 雷电”。另一个 例子是被告在诉讼中所有相关金融资产的清单。这样一份清单很可能也同样是名称值对 的无序集合,如“共享房地产所有权=共管”。这样的例子数不胜数。它们的共同点在 于需要封装名称值对的无序集合,一般被称为 “数据包”。复杂数据包可能既包含名 称值对,又包含嵌入的子数据包。这个使用案例中的挑战是,在数据加载后可能需要发 现数据内容的情况下,找到一个执行数据包分析的通用方法。 企业数据仓库在大数据分析时代的角色变迁 7 使大数据分析使用案例获得价值 当然,编写这个使用案例列表的目的是让读者确信,使用案例可能有各种形态、大小和 格式,并且需要许多特殊的方法来分析。直到不久以前,所有这些使用案例都作为单独 的努力存在,往往涉及为特殊用途而构建的系统。但行业的“大数据分析挑战”意识激 发着每个人在所有这些使用案例中寻找体系架构的相似性和差异。任何特定的企业都越 来越有可能遇到一个或多个这些使用案例。这种认识正在使人们对通过通用方式解决大 数据分析问题的系统体系架构越来越感兴趣。请研究以下的表格。 企业数据仓库在大数据分析时代的角色变迁 8 向 量 、 矩 阵 或 复 杂 结 构 自 由 文 本 图 像 或 二 进 制 数 据 数 据 “ 包 ” 迭 代 逻 辑 或 复 杂 分 支 高 级 分 析 例 程 快 速 重 复 的 测 量 超 低 延 迟 需 要 对 所 有 数 据 的 访 问 权 限 金融风险分析 X X X X X X X X 流失分析 X X X X X X X 搜索排名 X X X X X X 广告追踪 X X X X X X X X 位置和邻近 X X X X X 因果发现 X X X X X X X 社交 CRM X X X X X X X X 文件相似度 X X X X X X X 基因组分析 X X X X X 队列群体 X X X X X X 在航发动机状态 X X X X X X 智能电表 X X X X X X 楼宇传感器 X X X X X X X X 包装追踪 X X X X X X 卫星图像 X X X X CAT 扫描 X X X X X X 金融欺诈 X X X X X X X X X 黑客入侵检测 X X X X X X X X X 游戏手势 X X X X X X X X 广告优化 X X X X X X X X 大科学 X X X X X X X X X 数据包探索 X X X X X X 这张密密麻麻的表格清楚表明,支持大数据分析的系统与 1980 年代和 1990 年代以来 的传统关系数据库系统肯定会非常不同。最初的 RDBMS 并不是为处理本表各列中列 出的所有要求创建的! 企业数据仓库在大数据分析时代的角色变迁 9 大数据分析系统要求 在讨论 2010 年代令人振奋的新技术和体系架构发展之前,让我们先总结一下为大数据 分析提供支持的总体要求,请牢记我们不要求单一系统或单一供应商的技术提供每个使 用案例的整体解决方案。在 2011 年,我们从最近几年中收集的所有这些使用案例得到 了大量支持,现在颇有自信满足这些要求。 大数据分析的发展已达到一个高度,具有独立于一系列使用案例的总体使命声明和个 性。我们中的很多人都经历了早期高级分析方法的实例化,这些方法依次是高级统计 学、人工智能和数据挖掘。这些早期的浪潮都没有跳出单个实例的范畴,并没有像本来 那样引人注目。 这里我们尝试后退一步,在最高的层面定义大数据分析的特征。下文中使用广义的术语 “UDF”,指可能出现在端到端分析体系架构中任何地方的任何用户定义的函数或程序 或算法。 在我们正迈入的 2010 年代,大数据分析将需要技术或技术组合能够做到:  经过扩展轻松支持以拍字节 (太字节的一千倍) 计的数据  分布到数以千计的不同处理器,这些处理器可能地理位置不同,也可能异构。  对高度限定的标准 SQL 查询的亚秒级响应时间  在处理请求内嵌入任意复杂的用户定义函数 (UDF)  以各种行业标准过程语言执行 UDF  组合大部分或全部使用案例的大量可复用 UDF 库  几分钟内对拍字节大小的数据集执行 UDF “关系扫描”  支持各种各样的数据类型,扩大到包括图像、波形、任意层次数据结构和数据包  以至少每秒千兆字节的高速加载数据,随时进行分析  在很高速度 (GB/秒) 的加载过程中集成来自多个来源的数据  在声明或者发现数据结构前加载数据  在传入的加载数据上实时执行某些“流”分析查询  以满负荷速度就地更新数据 企业数据仓库在大数据分析时代的角色变迁 10  不需预先将维表与事实表群集即可将十亿行的维表加入万亿行的事实表  调度和执行数百节点的复杂工作流  配置不受单点故障的影响  处理节点故障时的故障转移和流程继续  支持极端的混合工作负载,包括数以千计地理上分散的在线用户和程序,这些用户和 程序执行各种各样的请求,范围从临时性的请求到战略分析的请求,同时以批量或流的 方式加载数据 有两种体系架构浮出水面,来应对大数据分析:扩展 RDBMS 和 MapReduce/ Hadoop。这些体系架构正在作为完全独立的系统以及涉及两种体系架构的各种有趣混 杂组合进行实施。我们将从分别讨论这两种体系架构开始。 扩展关系数据库管理系统 所有主要的关系数据库管理系统供应商都在添加从坚实的关系视角解决大数据分析的功 能。两个最重要的体系架构发展是大规模并行处理 (MPP) 高端市场的迎头赶上和列存 储的日益普及。MPP 和列存储双剑合璧时,上面列出的很多系统要求开始迎刃而解, 其中包括  经过扩展支持以艾字节 (拍字节的一千倍) 计的数据  分布到数以万计分散在不同地理位置的不同处理器  对高度限定的标准 SQL 查询的亚秒级响应时间  以满负荷速度就地更新数据  配置不受单点故障的影响  处理节点故障时的故障转移和流程继续 此外,RDBMS 供应商都在其语法中加入了一些复杂的用户定义函数 (UDF),但是在 此时的关系环境中,大数据分析所需的通用过程式语言计算要求没有得到满足。 同样,RDBMS 供应商允许复杂的数据结构以单个字段存储。这些类型的嵌入式复杂数 据结构多年来被称为“二进制大对象 (blob)”。重要的是要了解关系数据库往往很难 为解释 blob 提供常规的支持,这是因为 blob 并不适合关系范式。RDBMS 的确通过在 结构化的框架中托管 Blob 提供了一定的价值,但是在 blob 上进行的很多复杂解释和 企业数据仓库在大数据分析时代的角色变迁 11 计算必须通过特制的 UDF 或 BI 应用程序层面客户端完成。blob 与本文其他部分中讨 论的“数据包”有关。请参见标题为数据结构应在查询时间声明的章节。 MPP 的实施从来没有圆满解决“大合并”的问题,其中尝试不靠集群存储就将十亿行 的维表合并到万亿行的事实表。对维表加临时约束条件时,造成潜在非常巨大的一组维 度键值必须物理下载到 MPP 系统中分开存储的万亿行事实表的每个物理片段中,这时 就发生了大合并的危机。由于维度键值要随机散布在万亿行事实表的单独片段中,所以 很难避免非常庞大的维表到事实表每个存储分区的冗长下载步骤。平心而论, MapReduce/Hadoop 体系架构也不能解决大合并问题。 列数据存储非常适合关系范式,尤其是维度建模的数据库。除了稀疏数据高压缩比的显 著优势,与面向行的数据库相比,列数据库还允许非常大的列数,在现有架构中添列时 几乎不增加系统开销。唯一致命的弱点是数据加载到列格式的速度很慢,至少在 2011 年是这样。虽然列数据库供应商宣布的加载速度提高令人印象深刻,但是仍然没有达到 上面所列的每秒吉字节的要求。 基于维度建模原理实施企业数据仓库的标准 RDBMS 体系架构非常简单,也很好理 解,如图1所示。回想一下,贯穿本白皮书的 EDW 的定义都是全面包括所有后台和前 台流程,这些流程包括 ETL、数据演示和 BI 应用程序。 图 1. 企业数据仓库基于标准 RDBMS 的体系架构 在这种标准的 EDW 体系架构中,ETL 系统是位于源系统和演示服务器之间的一个重要 组成部分,负责向商业智能应用程序揭示所有数据。在这个视图中,ETL 系统清理、统 一数据并将数据安排到一系列的维度架构中,然后再将这个架构物理存储在演示服务器 中,从而形成了巨大的增值。这个体系架构的一个关键因素是在起 BI 应用程序集成基 础作用的 ETL 系统中准备好统一的维度。本文作者坚信,将维度结构的构建和集成问 题一直推迟到查询时间是错误的体系架构。这种“延迟计算”方法需要一个过于昂贵的 源系统 EDW 后台 EDW 前台 ETL 系统 演示服务器 BI 应用程序 - 提取 - 清理 - 统一 - 交付 - 运营和 ODS - ERP 系统 - 用户桌面 - MDM 系统 - 外部供应商 - RDBMS - 纯文本文件和 XML 文档 - 消息队列 - 专有格式 ETL 管理服务 ETL 数据存储 - 含聚合导航的自动业务流程维 度模型 - 驱动 EDW 集成的统一维度/ 事实 - 查询 - 标准报表 - 分析应用程序 - 运营 BI - 数据挖掘和模型 BI 管理服务 BI 数据存储 BI 门户 元数据 基础设施和安全 企业数据仓库在大数据分析时代的角色变迁 12 查询优化器,在每次提交查询时正确查询复杂的非维度模型,查询处理时集成的计算通 常也需要 BI 工具中同样可能每次查询都必须执行的复杂应用程序逻辑。 支持大数据分析的扩展 RDBMS 体系架构保留了标准的体系架构,又加上很多重要的 补充,如下面的大箭头所示: 图2. 企业数据仓库基于扩展 RDBMS 的体系架构 高层次企业数据仓库体系架构并未因新数据结构的引入或日渐增大的特制用户定义函数 库,或因为基于过程式语言的强大程序作为功能强大的 BI 客户端而发生重大改变,这一 点正是大数据分析扩展 RDBMS 方法的魅力所在。主要的 RDBMS 参与者能够汇集他 们服务市场几十年积累的数百万行的代码、强大的治理能力和系统稳定性等巨大遗产。 但是,本文作者认为扩展 RDBMS 系统不可能是大数据分析的唯一解决方案。在某些 时候,将非关系数据结构和非关系的处理算法嫁接在基本、连贯的 RDBMS 架构上会 变得难以驾驭并且效率低下。这时自然而然会联想到瑞士军刀的类比。另一种更切题的 类比是编程语言 PL/1。这种语言最初是要设计成一种全面多用途的编程语言,用于所 有形式的数据和所有应用程序,但最终变成想用一种语言包打天下的一个庞大杂乱的语 料库。自从 PL/1 的全盛时期以来,出现了编程语言的奇妙演变,在某一天后,出现了 具有很多新概念和功能的关注面更窄的语言,它们就是不能嫁接在 PL/1 上。关系数据 库管理系统将如此多的事情做得这么好,所以不会有重蹈 PL/1 覆辙的危险,但是大数 据分析空间发展如此迅速,发展方向如此激动人心和出人意料,所以除 RDBMS 系统 之外的更轻量级、更灵活和更敏捷的处理框架可能是一个合理的选择。 源系统 EDW 后台 EDW 前台 ETL 系统 演示服务器 BI 应用程序 - 提取 - 清理 - 统一 - 交付 - 含聚合导航的自动业务流程维 度模型 - 驱动 EDW 集成的统一维度/ 事实 - 嵌入 DBM 内层循环的特制 UDF ETL 管理服务 ETL 数据存储 - 运营和 ODS - ERP 系统 - 用户桌面 - MDM 系统 - 外部供应商 - RDBMS - 纯文本文件和 XML 文档 - 消息队列 - 专有格式 - 复杂结构 - 非结构化文本 - 图像、视频 - 数据包 - 查询 - 标准报表 - 分析应用程序 - 运营 BI - 数据挖掘和模型 - 通用程序 BI 门户 BI 管理服务 BI 数据存储 元数据 基础设施和安全 全自动化反馈数据流 企业数据仓库在大数据分析时代的角色变迁 13 MapReduce/Hadoop 系统 MapReduce 最初由谷歌在 2000 年代初期开发,是一个为在数千物理上分离的计算机上 执行网页搜索而开发的处理框架。MapReduce 方法极为通用。完整的 MapReduce 系 统可以用各种各样的语言实施,但是最重要的实施还是使用 Java。MapReduce 确确 实实是一个 UDF (用户定义函数) 执行框架,其中的“F (函数)”可以出奇复杂。 MapReduce 作业一开始针对的是创建谷歌的网页搜索索引,它几乎可以为所有的数据结 构和任何应用程序进行定义。实际执行所请求的计算的目标处理器可以是同构的 (“集 群”),也可以是处理器类型的异构混合 (“网格”)。每个处理器中的数据在执行最终 计算时可存储在数据库中,或更常见存储在文件系统中,可以存储为任何数字格式。 MapReduce 最重要的实施是 Apache Hadoop,其被简称为 Hadoop。Hadoop 是一个 开源的顶级 Apache 项目,有成千上万的贡献者,整个产业由各种各样的应用程序组 成。Hadoop 可以原生运行在其自身的分布式文件系统 (HDFS) 上,同样也可以用 Amazon S3 等读取或写入。传统的数据库供应商也在实施对接,使 Hadoop 作业可以 在其数据库的大规模分布式实例上运行。 正如我们在简要概述 Hadoop 作业如何工作时会看到的那样,独立处理器之间的带宽可 能是一个很大的问题。HDFS 是一种所谓的“机架感知”文件系统,因为中央名称节点知 道哪些节点属于同一个机架,哪些节点通过一个以上网络多跳连接。Hadoop 利用中央作 业调度器和 HDFS 之间的关系,通过拥有数据实际驻留位置的详细知识来显著优化大规 模分布式处理任务。这也意味着,控制性能的一个重要方面是数据片段在实际物理硬件机 架上的联合定位,这样 MapReduce 通信可以在背板速度而不是较慢的网络速度下完 成。请注意, Amazon S3 和 CloudStore 等基于云的远程文件系统,本质上无法提供机 架感知功能。当然,基于云的文件系统有很多引人注目的优势,我们会在后面加以讨论。 MapReduce 如何在 Hadoop 中工作 MapReduce 作业被提交到中央 JobTracker,接下来由其将作业的各部分调度到很多 TaskTracker 节点。虽然通常 TaskTracker 可能出现故障,其任务可由 JobTracker 重 新指派,JobTracker 还是一个单点故障组件。如果 JobTracker 死机,就必须重新启动 MapReduce 作业,或从中间快照恢复。 MapReduce 作业总是分为完全不同的两个阶段:map 和 reduce。MapReduce 作业的 总输入被拆分成很多等分的分片,每个分片被分配给一个 map 任务。然后对每个分片 中的每个记录应用 map 函数。对于大型作业,由 job tracker 并行调度这些 map 任 务。MapReduce 作业的整体性能很大程度上依赖于实现并行分片的数量平衡,即其数 量足以保持占用多台计算机,但不会达到因管理所有分片的进程间通信而使整体工作停 滞的程度。MapReduce 在 HDFS 文件系统上运行时,典型的默认分片大小是 64 MB 的输入数据。 企业数据仓库在大数据分析时代的角色变迁 14 顾名思义,map 任务是 MapReduce 作业的前半部分。每个 map 任务生成一组中间结 果记录,写入执行 map 任务的计算机本地磁盘。MapReduce 作业的后半部分是 reduce 任务,这个任务可以运行在任何处理节点上。mapper (运行 map 任务的节点) 的输出以能够将这些输出传送到 reducer (运行 reduce 任务的节点) 的方式进行排序 和分区 。reducer 的最终输出包含总体 MapReduce 作业经过排序和分割的结果集。运 行在 HDFS 上的 MapReduce,其结果集被写入到 HDFS 并进行复制以实现可靠性。 在图 3 中,我们复制了 Tom White 的专著 Hadoop, The Definitive Guide 2nd Edition (Hadoop 权威指南第二版)(O'Reilly, 2010) 的图 2.3,显示用三个 mapper 节点向两 个 reducer 节点提供数据的 MapReduce 作业任务流程。 图 3. MapReducer 作业实例 在 Tom White 的书中描述了一个简单的 MapReduce 作业,我们在这里复述这个作 业。假设未进行分割之前的原始数据包括非常大数量 (也许是数十亿) 的未排序温度测 量结果,每个结果为一个记录。这种测量可能来自成千上万遍布美国各地的自动传感 器。分片被分配到单独的 mapper 节点,尽可能让每个节点分配到的记录数一样多。 mapper 输入的实际形式是键-值对,在本案中是顺序记录标识符和包含温度测量以及其 他数据的完整记录。每个 mapper 的作业仅仅是解析提交给它的记录,并提取年、州和 温度,这三个值成为第二组从 mapper 传递到 reducer 的键-值对。 每个 reducer 的作业是在传递给它的记录中找出每个州和每个不同年份报告的最高温 度。每个 reducer 负责一个州,所以为了完成传输,每个 mapper 的输出必须排序,这 样键-值对可以分配到正确的 reducer。在本案中要有 50 个 reducer,每个州一个。 输入 HDFS 输出 HDFS HDFS 复制 HDFS 复制 排序 复制 分片 0 分片 1 分片 2 部分 0 部分 1 合并 复制 企业数据仓库在大数据分析时代的角色变迁 15 然后在一个步骤中将这些排序的块段传输到 reducers,这是 MapReduce 体系架构 的一个关键功能,在这里被称为“洗牌”。 请注意,洗牌涉及数据在处理节点之间真正的物理传输。这使机架感知功能的价值更 加明显,因为有大量的数据需要从 mapper 转移到 reducer。聪明的读者可能会问, 如果通过将 mapper 的数据合并,就能将单独一个州或一年的很多读数作为单一的键- 值对而不是很多键-值发送给 reducer ,是否可以通过这种方法减少数据传输。答案是 肯定的,Hadoop 提供了 combiner 函数恰恰达到了这种效果。 每个 reducer 收到大量的州/年-温度的键-值对,并找出给定年份的最高温度。每年的 最高温度是每个 reducer 的最终输出。 这种方法可以无限制地放大或缩小。真正在 HDFS 上运行的 MapReduce 作业可能 有数百或数千 mapper 和 reducer,处理拍字节级的输入数据。 现在 MapReduce/Hadoop 方法引人注目的地方应该清楚了。对于整体作业的输入形 式几乎没有限制。仅仅需要一些创建分片和读取记录的合理基础,本案中是 Tom White 示例中的记录标识符。在 mapper 和 reducer 中的实际逻辑可以用几乎所有编 程语言编程,可以和上面的例子一样简单,也可以是复杂得多的 UDF。读者应该能 够想象本文前面描述的一些更复杂的使用案例 (例如,卫星图像比较) 可以如何放入 这个框架。 Hadoop 环境的工具 到目前为止我们所描述的是 MapReduce 在 Hadoop 环境中运行时的核心处理组件。 这大致相当于描述关系数据库管理系统中的内层处理循环。这两种情况下,实施完整 的运作环境都要有这些系统以外更多的东西。下面是 MapReduce/Hadoop 环境中使 用的典型工具的简要概述。我们按照整体功能将这些工具归类。上面提到的 Tom White 的专著是了解这些工具使用方法很好的入门指导。 企业数据仓库在大数据分析时代的角色变迁 16 导入数据和提取数据  ETL 平台 – ETL 平台在关系数据库的数据导入和导出方面有很长的历史,为 数据进出 HDFS 提供了专门的接口。基于平台的方法与手工编码截然不同,提 供了对元数据、数据质量、文档以及系统构建的可视化风格的广泛支持。  Sqoop - Sqoop,由 Cloudera 开发,是一种开源工具,它允许将数据从关系源 导入到 HDFS 以及从 HDFS 导出到关系数据库。 MapReduce 应用程序和 HBase 应用程序都可以使用由 Sqoop 导入到 HDFS 的数据。下面会对 HBase 进行说明。  Scribe – Scribe 在 Facebook 开发,作为开源程序发布,用于聚合来自很大数 量 Web 服务器的日志数据。  Flume – Flume 由 Cloudera 开发,是一个可靠的分布式流数据收集服务。它使 用由 Zookeeper 管理的中央配置,支持可调的可靠性和自动故障转移和恢复。 编程  低层次 MapReduce 编程 - mapper 和 reducer 的主代码,可以用很多语言书 写。Hadoop 的原生语言是 Java, 但是 Hadoop 公开 API 用于以 Ruby 和 Python 等其他语言编写代码。提供了与 C++ 的接口,其名称为 Hadoop Pipes。在最低层次进行 MapReduce 编程显然提供了最大的潜力,但这种编程 层次非常像汇编语言编程。这种做法可能非常费力,在尝试完成将两个数据集合 并这样概念简单的任务时尤其如此。  高层次的 MapReduce 编程 - Apache Pig,或仅仅是 Pig,是一个提供高层次 编程语言的客户端开源 MapReduce 应用程序,用于处理 MapReduce 中的大 数据集。编程语言本身被称为 Pig Latin。Hive 是设计出来更像 SQL 的一种替 代应用程序,用于数据仓库的使用案例。Pig 和 Hive 在用于适当的使用案例时 相比低层次 MapReduce 编程带来了巨大的编程效率提升,可以达到10 倍或更 高。Pig 和 Hive 将应用程序开发人员的视野从管理详细的 mapper 和 reducer 进程提升到应用程序的更多重点上。  集成开发环境 - MapReduce/Hadoop 开发需要果断摆脱主流 IT 厂商采取的纯 手工编码。MapReduce/Hadoop 的集成开发环境需要包括源代码编辑器、编译 器、自动化系统构建工具、调试器和版本控制系统。 企业数据仓库在大数据分析时代的角色变迁 17  集成应用程序环境 - 比集成开发环境还要高的层次可以被称为集成应用程序环 境,在这里通过图形用户界面将复杂的可复用分析路线组装成完整的应用程序。 这种类型的环境可能使用开源算法,例如 Apache Mahout 项目提供的算法,这 个项目将机器学习算法分布在 Hadoop 平台上。  Cascading – Cascading 是另一个工具,是编写复杂 MapReduce 应用程序的抽 象层。它的最恰当描述是一个瘦 Java 库,通常被作为查询 API 和进程调度器 使用的命令行调用。Cascading 并不用作 Pig 或 Hive 的全面替代方案。  HBase – HBase 是一个基于列存储的开源非关系数据库,直接运行在 Hadoop 上。HBase 不是一种 MapReduce 的实现。HBase 与 Pig 或 Hive (MapReduce 的实现) 的主要区别是能够提供非常大数据集的实时读取和写入 随机存取。  Oozie - Oozie 是一个基于服务器的工作流引擎,专门运行有执行 Hadoop 作业 (如 MapReduce、Pig、Hive、Sqoop,HDFS 操作) 行为的工作流作业和子工 作流。  ZooKeeper – ZooKeeper 是一个分布式应用程序的集中配置管理器。Zookeeper 也可以独立于 Hadoop 使用。 管理  嵌入的 Hadoop 管理功能 - Hadoop 支持全面的运行时环境,包括编辑日志、 安全模式运行、日志审计、文件系统检查、数据节点块验证、数据节点块分布均 衡器、性能监控、综合日志文件、管理员度量,MapReduce 用户计数、元数据 备份、数据备份、文件系统均衡器、节点启用和弃用。  Java 管理扩展 – 一种用于监控和管理应用程序的标准 Java API。  GangliaContext – 一种用于超大群集的开源分布式监控系统。 企业数据仓库在大数据分析时代的角色变迁 18 未来十年中的技术汇聚 可以很保险地说,关系数据库管理系统和 MapReduce/Hadoop 系统在未来十年中将越 来越多地找到完美并存的方式。但是系统都有鲜明的特点,如下表中所述: 在即将到来的十年,RDBMS 将扩展其对复杂数据类型托管的支持,将复杂数据作为 “blob”,并将扩展 API,使任意分析路线可以在记录内容上操作。MapReduce/ Hadoop 系统,尤其是 Hive, 将加深其对 SQL 接口的支持以及对完整 SQL 语言更全 面的支持。但两者都不会在大数据分析市场一家独大。正如前面说过的那样,RDBMS 无法为大数据分析所需的很多复杂使用案例提供“关系”语义。RDBMS 充其量只是会 围绕复杂的有效负荷来提供关系结构。 与此类似,MapReduce/Hadoop 系统将永远不会接管 ACID 兼容事务处理,或在行和 列存储表上的索引查询方面优于 RDBMS。 正如本文所写的那样,在开发采用关系数据库技术和 MapReduce/Hadoop 技术的混合 系统方面正取得重大的进展。图 4 所示为两个主要替代方案。第一个替代方案将数据直 接交付到 MapReduce/Hadoop 配置进行初步的非关系分析。正如我们所描述的那样, 这种分析可以覆盖全部范围,从复杂分析路线到看起来像常规 ETL 步骤那样的简单排 序。MapReduce/Hadoop 步骤完成时,将结果加载到 RDBMS 中,用 SQL 进行常规 的结构化查询。 第二种替代配置将数据直接加载到 RDBMS,即使主数据有效负荷不是常规的标量测 量。这时两种分析模式都是可能的。数据可以用特制的用户定义函数分析、从 BI 层有 效分析或传递到下游 MapReduce/Hadoop 应用程序。 未来更为复杂的组合将使这些体系架构更紧密的联系在一起,其中包括 MapReduce 系 统,其 mapper 和 reducer 实际上就是关系数据库,还有底层存储由 HDFS 文件组成 的关系数据库。 关系 DBMS MapReduce/Hadoop 大多数为专有 开放源码 昂贵 不太贵 数据需要结构化 数据不需要结构化 对快速的索引查找非常好 对大规模完整数据扫描非常好 对关系语义的深入支持 对关系语义的间接支持,例如 Hive 对复杂数据结构的间接支持 对复杂数据结构的深入支持 对迭代、复杂分枝的间接支持 对迭代、复杂分枝的深入支持 对事务处理的深入支持 对事务处理的很少或没有支持 企业数据仓库在大数据分析时代的角色变迁 19 图 4. 同时使用 RDBMS 和 Hadoop 的混合体系架构方案。 IT 组织可能很难厘清供应商的说法,他们几乎肯定会说他们的系统能做所有的事情。在 某些情况下,这些说法是“先入为主”,这意味着这些说法有一点点道理,也让你感觉 很好,但是经不起在有竞争和现实的环境中的检验。买家要当心! 可复用分析 直到现在我们都在纠结于所有特殊分析软件来自哪里的问题。如果每一个实例是自定义 编码的解决方案,大数据分析将永远不会发展壮大。RDBMS 和开放源码界认识到这一 点,两个主要的开发主题应运而生。SAS 等高端统计分析供应商已经为包括高级统计、 数据挖掘、预测分析、功能检测、线性模型、判别分析等等在内各种各样的分析应用程 序开发出广泛的专有可复用库。开放源码界有很多的方案,其中最著名的是 Hadoop- ML 和Apache Mahout。引自 Hadoop-ML 的网站: “Hadoop-ML 是一个方便并行机器学习/数据挖掘 (ML/DM) 算法在 Hadoop 上实施的基础设施。HADOOP-ML 是考虑到任务并行和数据并行 ML/DM 算法 的规范而设计的。此外,它还支持使用串行和并行构建块的 ML/DM 算法 - 这 允许人们编写可重用的并行代码。建议的抽象只要求用户指定计算和它们的依赖 性,而不必担心调度、数据管理和通信,因而简化了实施流程。因此,代码是可 移植的,用户永远不需要编写专门的 Hadoop 代码。这潜在允许人们利用未来 的并行化平台而不需重写代码。” Apache Mahout 实现了机器学习算法在 Hadoop 平台上的自由实施。 MapReduce/Hadoop 中 的迭代处理、复杂逻 辑、非标量源 (HDFS) 关系 DBMS EDW 中 的结构化查询 标准 BI 工具 原始数据源、 Weblog、传感器 原始数据源、 Weblog、传感器 大数据在 DBMS EDW 中的结构化托管 标准 BI 工具外加下游应用程序或 UDF 用于迭代处理、复杂逻辑、非 标量源 MapReduce/Hadoop 中 的迭代处理、复杂逻辑、 非标量源 (HDFS) 企业数据仓库在大数据分析时代的角色变迁 20 复杂事件处理 (CEP) 复杂事件处理 (CEP) 包含处理组织内部和外部发生的所有事件,识别出有意义的模 式,以便实时采取后续行动。例如将 CEP 用于公用事业网络 (电力、燃气和水),在可 能存在的问题造成危害之前就把它们找出来。这些 CEP 部署实现了关键网络或基础设 施状况的实时干预。可将深入 DW 分析和 CEP 的结合应用于零售客户环境下,分析行 为并识别出公司在哪种情况下可能会失去客户,或能够在他们直接参与时向他们出售更 多的产品或服务。在银行业,完善的分析可能有助于找出 10 种最常见的欺诈模式,然 后可使用 CEP 监视这些模式,这样就可能在造成损失之前将其挫败。 在编写本白皮书时,人们普遍认为 CEP 不是的 EDW 的一部分,但本文作者相信,未来 十年中连续查询处理方面的技术进步将促成 CEP 和 EDW 共享数据并更紧密地协作。 未来十年中的数据仓库文化变迁 企业数据仓库必须绝对保持与业务有关。随着大数据分析价值和可见性的增长,数据仓 库必须包含大数据分析所需的新的文化、技能、技术和系统。 沙盒 例如,大数据分析推动了进行试验的探索沙盒。这些沙盒是正由组织获取的大规模数据 集的副本或片段。鼓励分析师个体或非常小的群体用非常广泛的工具来分析数据,这些 工具范围广泛,从 SAS、Matlab 或 R 这样严格的统计工具到预测模型以及很多形式的 临时查询和通过高级 BI 图形界面的可视化。允许负责指定沙盒的分析师对数据进行任 何操作,他们可以使用任何想用的工具,即使所用的工具不是公司标准也没有问题。 探索沙盒通常有时间限制,持续数周最多是几个月。其数据可以是被冻结的快照,或是传 入数据特定片段的窗口。分析师可能有权限来运行试验,改变市场上产品或服务的特征, 然后进行 A/B 测试,看变化如何影响客户行为。通常情况下,如果这样的试验产生了成 功的结果,沙盒试验就被终止,然后将特征转入生产环节。这时,通常是由其他人员在 EDW 环境中使用公司标准工具再次实施追踪应用程序,这个程序可能是在沙盒中已经用 一种快而脏的原型语言实施过。在为编写本白皮书而采访过的几家电子商务企业中,分析 沙盒极为重要,在某些情况下同时进行数以百计的沙盒试验。正如一位受访者所评论的那 样,“最新发现的模式最具杀伤力,从中洞察到的信息可以实现最高的投资回报。” 从体系架构上讲,最好的沙盒不是对整个数据集甚至这些数据集主要片段进行暴力复 制。用维度建模的话说,分析师需要的不仅仅是用来运行试验的一个事实表。分析师要 企业数据仓库在大数据分析时代的角色变迁 21 进行完整的“横向钻取”分析,最少还需要一个或一个以上非常大的维表,可能还需要 另外的事实表。如果有 100 名分析师在创造沙盒数据的暴力副本,所有的冗余副本将会 产生磁盘空间和资源的巨大浪费。请记住,像客户维度这样的维表,最大的可以有 5 亿 行!对于严肃的沙盒环境,建议体系架构是使用统一的 (共享的) 维度构建每个沙盒, 将这些维度作为关系视图或其等价物 (在 Hadoop 应用程序下) 结合到每个沙盒中。 低延迟 在我们这些设计数据仓库的同时收集业务需求的人中间流传的一个众所周知的笑话,那 就是问业务用户是否想要“实时”数据。每种业务环境下的每个用户都会说“那当 然”!虽然这个回答在过去可能有点没有来由,现在几乎每种情况下都可以创造出良好 的业务案例,得到证明的是以越来越低的延迟向业务部门提供更加频繁的数据更新。 RDBMS 和 MapReduce/Hadoop 系统竭尽全力加载巨大的数据量,并使数据在创建后 的数秒内就可用。但市场要的就是这个,无论技术人员对这种要求的疑问如何,这种要 求是真实的,在未来十年内必须要解决。 对低延迟数据的一个有趣的角度是需要在数据流入但是数据收集流程远没有最终结束前 开始数据上的认真分析。人们对流分析系统有很大的兴趣,该系统允许类 SQL 查询在 数据流入系统时对其进行处理。在一些使用案例中,当流查询的结果超过阈值时,分析 可能中止,不会让作业运行到底。被称为连续查询语言 (CQL) 的一项学术工作在定义 流数据处理要求方面取得了令人瞩目的进展,其中包括流数据上动态移动时间窗口的巧 妙语义。在加载程序中为 RDBMS 和 HDFS 部署的数据集寻找 CQL 语言扩展和流数据 查询功能。理想的实施会使数据以每秒吉字节加载时的流数据分析得以实现。 通过提供极高频度和极详细的事件测量功能,可以推动交互式干预的进行。这种干预非 常重要的使用案例涵盖很多情况,从在线游戏到产品建议,到金融帐户欺诈,再到网络 的稳定性。 永远精益求精 分析师们都永远渴望得到每次市场观察中的更多细节,尤其是客户行为的细节。例如, 每一个网页事件 (绘制在用户屏幕上的页面) 都产生数百个描述页面上每个对象的记 录。网络游戏中,当每个手势进入数据流,就有多达 100 个描述符加在每个这样的微事 件上。例如,在一个假设的网络棒球游戏中,当击球员挥棒击球时,描述球员位置、得 分、上垒的跑垒员甚至好球的特征的所有内容都与单独的记录存储在一起。在这些例子 中,必须将完整上下文捕获在当前记录中,因为在事后从单独的数据源计算这种详细的 上下文是不切实际的。未来十年的课题就是对极致细节的渴望只会继续增长。可以想 像一下,成千上万的属性附在某些微事件上,这些属性的类别和名称将以不可预知的方 企业数据仓库在大数据分析时代的角色变迁 22 式增长。这使本文前面讨论的数据包方法变得愈加重要。这意味着依赖位置并使用键值 (数据名称) 预先声明作为列名的模式在设计上行不通。 最后,网页曝光等事件的完美历史重建需要的不仅仅是网页在显示时属性的列表,即便 这个列表无比详细。网页的完美历史重建需要通过多媒体用户界面 (也就是浏览器) 来 观看。 低干涉数据的相关性正待揭示 低干涉数据是上一章节中所述极其详细数据的一个方面。例如,如果一位客户在进行购 买前大量浏览网页,在购买前就有大量的微上下文存储在所有网页事件中。购买完成 时,有些微上下文就马上变得重要得多,并且从“低干涉数据”上升为真实数据。这 时,同期接触所选产品或竞争产品的序列就有可能进入会话。这些微事件在购买事件之 前几乎毫无意义,因为有如此多能想到不相干的线程,分析都到此为止。这要求将海量 的低干涉数据存储起来,等待这些微事件所选线程的相关性最终暴露出来。传统的季节 考虑建议将这种低干涉数据至少在线保留五个季度 (15 个月)。 本白皮书所做的访谈 过程中,一直都谈及的是分析师想要“更长的尾巴”,这意味着他们想要的历史比当前 他们得到的要多得多。 所有数据的简单分析胜过部分数据的复杂分析 尽管数据采样在数据仓库方面从来都没有成为流行的技术,但令人吃惊的是,吉字节巨 大数据集的到来并没有提高分析数据子集的兴趣。相反,一些分析师指出,货币化洞察 可能是从非常小的人群中取得的,只对一部分数据取样可能会错过这些人群。当然这是 一个有些争议的一点,因为相同的分析师也承认,如果你有 1 万亿的行为观察记录,只 要观察足够仔细,就可能找到任何行为模式。 一些分析师提出的另外一个有些争议的一点是,他们担心对传入数据任何形式的数据清 理都可能擦除低频的“边缘兴趣案件”。归根结底,引起误导的罕见行为模式和误导性 的受损数据都需要从数据中小心过滤出来。 假定来自很小的人群行为洞察有效,则存在可能向小人群进行微营销的广泛共识,这一 点做得足够就可以建立一种可持续的战略优势。 支持分析完整数据集的最后一个争论是,这些“关系扫描”在分析之前不需要计算索引 或聚合。这种方法与基础的 MapReduce 分布式分析架构配合得很好。 企业数据仓库在大数据分析时代的角色变迁 23 数据结构应在查询时而非数据加载时声明 很多本白皮书采访的分析师说,他们尝试分析的庞大数据集需要以可查询的状态加载, 数据集结构和内容完全理解是后面的事。同样,我们来考虑数据包形式的市场观察值, 其中在良构维度测量流程中实际的观察是无序且潜在不可预测的键值对集,这种数据包 的结构可能需要被发现,需要在不用重新加载数据库的情况下就能进行结构的变换解 释。一位受访者评论说:“昨天的边缘数据是明天的良构数据”,这意味着我们在探索 新类型的数据源时需要极大的灵活性。 RDBMS 方法和 MapReduce/Hadoop 方法之间的主要区别是一直到 MapReduce/ Hadoop 系统的查询时间之前数据结构声明的延迟。但强制每个 MapReduce 作业都声 明目标数据结构的 RDBMS 团体对此有相左意见,这就引起了一种混乱,因为每个分 析师可以做自己的事。但是,这种反对似乎忽视了一点,那就是标准的数据结构声明可 以很容易地作为库模块发布,可供每个分析师在实施他们的应用程序时拾取。 支持大数据分析的 EDW 必须有磁性、灵活性和深入性 Cohen 和 Dolan 在他们大数据分析的开创性文章中主张,EDW 必须摆脱一些旧观念, 以便具有磁性、灵活性和深入性。有磁性的环境对新的、预料外以及潜在的脏数据源设 置障碍最少。这尤其支持将数据结构声明一直延迟到数据加载后的需要。灵活的环境避 开了大范围的精心设计和规划!深入的环境允许在大规模数据集上运行复杂的分析算法 而不需采样,甚至有可能连清理都不用。我们在本白皮书的其他地方已经得出了这些观 点,但是 Cohen 和 Dolan 的文章是尤其有力的主张。请访问参考文献中这篇文章的链 接。 抽象和控制之间的冲突 在 MapReduce/Hadoop 的世界里,Pig 和 Hive 被广泛视为宝贵的抽象,使程序员专 注于数据库的语义,而不是直接用 Java 编程。但是有本文采访的几位分析师表示,太 多的抽象和与实际存储位置的太大距离可能使效率低得可怜。在处理非常大的数据集时 这似乎是一个合理的关注,其中坏的算法可能会导致数以天计的运行时间。对于汹涌而 至的最大数据集,编程工具将需要允许对存储策略和处理方法有相当大的控制,但不能 要求编程使用最低层次的代码。 企业数据仓库在大数据分析时代的角色变迁 24 未来十年中的数据仓库组织变化 大数据分析日益增加的重要性达到了企业数据仓库中途修正和彻底革新之间的这样一个 程度。很多公司将会需要吸收新的技能集、新的组织、新的开发范式,那些面临本文中 所述使用案例的公司尤其如此。并非每个企业都需要跳入拍字节的海洋,但是根据本文 作者的预测,未来十年中认识大数据分析价值的大型企业的比例将稳步增长。 大多数观察家都同意,大数据分析属于“信息管理”,但同样的观察家们可能对此是否 会影响“数据仓库”而争论不休。我们不是操心组织结构图标记 EDW 的框框是否有大 数据分析的责任,而是从我们采取的视角来看,一般意义的企业数据仓库也绝对包含了 大数据分析。尽管如此,随着行业扩张其信息管理,还是会有许多不同的组织结构和管 理视角。对新范式的这种修补和调整也是正常的,在意料之中。我们经历过 1980 年代 中期非常类似的阶段,当时数据仓库本身是 IT 和商业的新范式。最成功的早期数据仓 库方案有很多始于业务组织,最终被纳入 IT 组织, IT 组织又做了巨大努力使其具有业 务相关性。这很像大数据分析将要发生的演进。 大型企业的信息经理所面临的挑战是如何推动三个独立的数据仓库工作:常规 RDBMS 应用程序、MapReduce/Hadoop 应用程序和高级分析。 需要的技术技能集 这里值得再重复一下本白皮书开篇的第一句话。拍字节规模的数据集当然是一个很大的 挑战,但是大数据分析遇到的困难往往超出数据量的范畴。你可能面临快速到达的数 据、复杂数据或者复杂分析的挑战,即使你只有太字节的数据! 照看面向 RDBMS 的数据仓库时涉及一整套的技能,这很好理解:SQL 编程、ETL 平 台专业知识、数据库建模、任务调度、系统构建和维护技能、一种或一种以上脚本语 言,如 Python 或 Perl、UNIX 或 Windows 操作系统技能以及商业智能工具技能。 SQL 编程处于 RDBMS 实施的核心,是一种声明性语言,与 MapReduce/Hadoop 编 程需要过程式语言技能的倾向完全不同,至少在 Java 中是这样。数据仓库团队还需要 IT 的其他领域中的良好合作伙伴关系,这些领域包括存储管理、安全、网络以及对移动 设备的支持。最后,良好的数据仓库还需要与商业界的广泛联系,以及终端用户的认知 心理学的广泛联系! 照看包括本文所述大数据分析使用案例在内的 MapReduce/Hadoop 数据仓库时涉及与 传统 RDBMS 数据仓库技能仅有部分重叠的技能。其中就有一个重大的挑战。这些新 的技能包括较低层次的编程语言,如 Java、C++、Ruby、Python 和最常见通过 Java 接口可用的 MapReduce。尽管未来十年通过基于过程式的低层次编程语言编程的要求 将会大大减少,有利于 Pig、Hive 和 HBase,但是如果数据仓库工作的申请者缺乏编 企业数据仓库在大数据分析时代的角色变迁 25 程和 UNIX 技能,从编程团体招募到 MapReduce/Hadoop 应用程序开发员要比数据仓 库团体更加容易。如果 MapReduce/Hadoop 数据仓库专门用开源工具管理,那么还将 需要 Zookeeper 和 Oozie 技能。请记住,开放源码界创新很快。Hive、Pig 和 HBase 不是 Hadoop 进行分析的高层次接口的终结。我们在这个十年很可能看到包括全新接口 在内更多创新。 ETL 平台提供商有机会大展身手,将大数据源、MapReduce/Hadoop 应用程序和现有 关系数据库结合在一起。具有 ETL 平台技能的开发人员在结合 MapReduce/Hadoop 应用程序时将能够利用到他们在系统构建方面的大量经验和直觉。 最后,我们已经说到经常在沙盒环境中工作的分析师将会出场,他们拥有兼收并蓄并且 无法预测的技能集,这套技能的第一项就是深度分析的专业知识。对于这些人来说,熟 悉 SAS、MATLAB 或 R 可能比熟悉具体的编程语言或操作系统技能更重要。这些人通 常会拥有 UNIX 技能和一定的编程水平,这些人大多极为适应学习复杂新技术的环境。 传统分析师的最大挑战可能是让他们依靠 IT 部门内部向他们提供的其他资源,而不是 构建他们自己的提取和数据交付管道。这是一个微妙的平衡,因为你想给分析师不同寻 常的自由,但你又需要监督他们,确保他们没有浪费自己的时间。 需要的新组织 在这个大数据分析革命的早期阶段,毫无疑问分析师必须是业务组织的一部分,既要了 解业务的微观运作,而且还要能够进行我们在本文所描述的快速周转试验和调查。正如 我们所描述的那样,必须在技术上对这些分析师提供大力支持,为他们提供潜在的大规 模计算能力和数据传输带宽。所以,尽管分析师可能置身于业务组织,这仍是 IT 组织获 得业务组织信任以及关注的巨大机会。分析师如果不认清并利用他们对传统 IT 世界深度 依赖的优势,而是作为业务世界中的一个非法技术前哨,将会犯重大错误并丧失机会。 在本白皮书采访的一些组织中,我们看到嵌入不同业务组织的单独分析组,但是在分析 组之间没有很多的交叉沟通或没有在分析组中确定共同身份。在一些值得注意的案例 中,这种“分析团体”的缺乏导致失去互相利用对方工作的机会,造成多个小组反复发 明相同的方法、重复的编程工作以及基础设施需求,因为他们制作的是相同数据的单独 副本。 我们建议成立一个跨部门分析小组,模仿我们在过去十年已经看到的一些成功的数据仓 库团体构建工作。这样的分析小组应该有定期的跨部门会议和一种私人 LinkedIn 应用 程序,促进对所有这些人在自己的调查中收集的接触和观点以及资源的意识,以及一个 私人 web 门户,在这里分享信息和新闻事件。可举办定期会谈,有希望同样邀请到业 务团体的成员,最重要的是分析小组需要 T 恤衫和杯子这样的小礼品! 企业数据仓库在大数据分析时代的角色变迁 26 需要的新开发范式 在大数据分析到来之前,数据仓库就已经在进行自身的转换,对新的机遇提供更快的 响应,提供与业务团体的更多接触。灵活软件开发运动的一些做法已经被数据仓库团 体成功采纳,但现实中还没有一个非常明显的转变。但是灵活开发方法通过围绕业务 驱动而非常见的 IT 驱动的小团队加以组织,特别地为数据仓库提供支持。灵活开发 工作也产生了频繁的有形交付,减重文件和正式开发方法,并容许新要求的中途修正 和增量接收。灵活开发项目成功的最敏感因素是最终负责的业务领导者的个性和技 能。灵活业务领导者需要是一位开发流程和信息世界现实的有思想和老练的观察者。 希望灵活业务领导者同样也是一个很好的经理。 大数据分析当然要向业务部门参与打开大门,因为集中分析有可能直接在业务环境下 完成。但专业分析师可能不像是整个灵活数据仓库项目领导人的合适人选。灵活项目 领导者需要在推动高效短会、解决问题和开发选择、确定个别开发人员进度报告的真 实性、与组织其他部分的沟通以及取得方案的资金方面有良好的技能。 传统的数据仓库开发已经发现从适度起点出发但打好体系架构基础、为未来开发的方 向提供蓝图这样一种方式的吸引力。本文作者在多篇论文中描述了维度数据仓库架构 “得体修改”的技术。在维度建模的数据仓库中,新的测量事实、新的维度属性甚至 新维度,可以添加到现有的数据仓库应用程序中,而不用改变向终端客户提交数据的 现有信息交付管道,或者使其无效或延期。我们在本文中描述的很多大数据分析使用 案例都建议例行提供新的事实、新的属性和新维度。 新数据源集成到数据仓库中始终是一个巨大的挑战,因为经常这些新数据源到来时并 没有任何要集成到现有数据源的想法。大数据分析无疑属于这种情况。这次还是数据 仓库维度建模,本文作者已经描述了增量集成技术,其中定义了“企业维度属性”并 将其植入单独数据源的维度中。我们将此称为统一维度。统一维度的开发和部署完美 适合灵活开发的方法,因为这种集成可以一次在一个数据源上实施,一次可在一个维 度属性上实施,也可以通过对现有应用程序不造成破坏性的方法实施。有关一致维度 的更多信息请见本白皮书结尾的参考资料部分。 最后,至少一个本白皮书采访的组织已经将灵活采取到其符合逻辑的极致。单独的开 发人员项目被赋予完全的端对端责任,从最初的数据获取,一直到试验分析、重新实 施项目进行生产使用,以及通过支持模式与终端用户及其 BI 工具合作。尽管这种开 发方法仍在试验阶段,但是早期的结果非常有趣,因为这些开发人员感受到很强的责 任感以及对他们项目的自豪感。 企业数据仓库在大数据分析时代的角色变迁 27 数据仓库时代早期得到的教训 企业花去了 1990 年代的大部分时间来了解数据仓库是什么以及如何构建和管理这些 种类的系统。有趣的是,1990 年代末,数据仓库被有效地重新贴上商业智能的标 签。这是一个非常积极的发展,因为这反映了业务部门拥有并负责使用数据的需求。 最早的数据仓库先驱别无选择,只能做他们自己的系统集成,组装同类最好的组件, 以及应付在与多个供应商打交道时不可避免的不兼容性问题。截至 1990 年代末,最 好方法让位给供应商的集成产品堆栈,这种趋势一直继续到今天。这时,在数据仓库 领域只有几家独立供应商,这些供应商已通过几乎每一个可以想到的格式和接口进行 接驳而取得成功,从而在更有限的专有供应商堆栈之间架起桥梁。 有了传统数据仓库取得的事后收益经验,大数据分析的数据仓库版本可能很快就会巩 固自己的地位。只有具有非常强大软件开发技能且最勇敢的组织才应考虑将其大数据 分析应用程序直接移植到原始 MapReduce/Hadoop 上。对于希望关注业务问题而不 是集中在软件开发浪潮上的信息管理组织来说,打包 Hadoop 分布 (如 Cloudera) 意义很大。 云中分析 本白皮书并没有讨论大数据分析在云中的实施。本白皮书的大部分受访企业都没有使 用公共云实施进行生产分析。然而,云实施在分析工作的开始阶段可能非常有吸引 力。云服务在这种启动阶段可以提供即时的可扩展性,而不需要利用大规模的旧有硬 件投资。数据分析项目可以短时间内打开或关闭。回想一下,典型的分析环境可能涉 及成百上千的单独沙盒和并行试验。 本文中采访的许多组织指出,应在企业内部引入成熟的分析,采取云的方式,但仍在 组织的界限以内。当然,这种内部云可能会减少对安全性的担忧和侵犯隐私 (不管公 平与否)。 远程云实施带来了网络带宽的问题,尤其是在不同的地点有多个非超大数据集的广泛 集成应用程序。想象一下解决大合并问题,上万亿行的事实表在云上,十亿行维表位 于内部。 虽然最佳性能的系统试图实现 CPU、磁盘速度和带宽之间的三向平衡,本文采访的 大多数组织预测带宽将成为大数据分析系统性能的头号限制因素。 企业数据仓库在大数据分析时代的角色变迁 28 EDW 的前景如何? 企业数据仓库必须扩展,将大数据分析作为整体信息管理的一部分包括进来。数据仓 库的使命始终是收集组织的数据资产,并以对决策者最有用的方式进行结构化。虽然 有些组织可能会拘泥于组织结构图上标有的 EDW 框框,将其限制为交易数据的遗留 报表活动,但是 EDW 的范围应增加,以反映这些大数据的新发展。从某种意义上 说,IT 部门只有两个职能:取得数据 (交易处理)和放出数据。EDW 就是放出数据。 大数据分析投入不断攀升的商家所面临的一大选择是要选择一个仅 RDBMS 的解决 方案,还是双重的 RDBMS 和 MapReduce/Hadoop 解决方案。本文作者预测,双 重解决方案将占据主导地位,在许多情况下,两种体系架构将不会作为孤岛存在,而 是将会有丰富数据的管道让数据在两个方向流动。可以很保险地说,两种体系架构将 在未来十年有巨大发展,但本文作者预测,在十年结束时,这两种体系架构将分享大 数据分析市场。 有时,一种令人兴奋的新技术到来时,就为一种老的技术关上大门,犹如为其送行。 数据仓库已经建立了一个经验、最佳实践、支持结构、技术专长和商业世界可靠性的巨 大遗产。随着数据仓库扩展而将大数据包括在内,这将是未来 10 年信息管理的基础。 企业数据仓库在大数据分析时代的角色变迁 29 致谢 本文作者十分感谢 Informatica 对本白皮书提供的赞助,感谢其绝对无“供应商偏 见”态度。本白皮书中的观点仅由作者负责。 很多睿智博学的大数据从业人员在白皮书研究阶段参与采访。他们提供了很多有用 的见解。在此感谢 (按组织的字母顺序排列) Amr Awadallah, Mike Olson, Cloudera Brian Dolan, Discovix Oliver Ratzesberger, eBay Alex Ignatius, Electronic Arts William Schmarzo, EMC Ashish Thusoo, Facebook Julianna DeLua, John Haddad, Sanjay Krishnamurthi, Ron Lunasin, Informatica Nicholas Wakefield, LinkedIn Dan Graham, Dilip Krishna, Ron Kunze, Teradata Professor Michael Franklin, Computer Science Department, U.C. Berkeley Raymie Stata, Yahoo! Dan McCaffrey, Ken Rudin, Zynga 参考资料 Hadoop, The Definitive Guide 2nd Edition, Tom White, O’Reilly, 2011 MAD Skills: New Analysis Practices for Big Data, Cohen, Dolan et al, http://db.cs.berkeley.edu/jmh/papers/madskills-032009.pdf Hadoop-ML 网站: http://videolectures.net/nipsworkshops09_pednault_hmli/
还剩30页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享pdf获得金币 ] 0 人已下载

下载pdf

pdf贡献者

coredump

贡献于2015-08-27

下载需要 10 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf