抛砖引玉, 淘宝统一离线数据分析平台设计

把这个拿出来的目的, 是想得到更多的反馈意见, 请邮件至[email protected]

[size=large]历史[/size]
Hive 由 2009 年 3 月引入淘宝作为数据平台的海量数据分析基础框架, 引入的原因有如下
几点:
(1) 不是所有用户都懂计算机编程, 特别是 MapReduce 的分布式程序, 并且数据平
台的用户大多数会 SQL, Hive 则提供了由 SQL 解析成 MapReduce 作业的功能, 用
户只需要掌握 SQL 即可上手, 学习曲线较为平滑.
(2) Hive SQL 表意精简, 大幅度地减少开发量, 提高数据分析的生产效率. 例如,
之前统计网站 UV 的代码至少需要 Mapper, Reducer, JobDriver 三个类共计数百
行 Java 代码, 使用 Hive 只需要一行 SQL.
(3) Hive 具有查询优化引擎, 结合了一部分传统数据库的优化理论以及针对
MapReduce 分布式程序的一些优化理念. MapReduce 原生程序达到 Hive 同等的效
率,需要编写大量的优化代码.
(4) Hive提供元数据服务, 而原生MapReduce以及Pig都不提供. 元数据有助于数
据血缘分析,数据生命周期定义,数据共享以及权限控制等数据仓库的基础功能.
经过两年的发展, Hive 已经成为淘宝数据平台的主要离线数据分析基础框架. 在横向
上诞生了极限存储,DIP,Web IDE 等项目, 同时影响了天网调度系统,数据同步工具
(DataX, DbSync),数据平台生命周期分析系统的发展历程;在纵向上, Hive 产生的结
果数据已经成为量子统计,数据魔方,搜索,BI 业务的主要数据来源,并且一淘,淘宝商城,
支付宝,B2B,阿里金融集团子公司也开始使用 Hive 作为他们的数据分析工具, 提取他们
所需要的数据.

[size=large]问题[/size]
随着 Hive 在淘宝的深度使用, 有一些问题逐渐暴露出来:
(1) 根据 Hive 培训的结果反馈, 集团内有一些数字化运营, PD 员工开始使用 Hive.
这部分用户的特征是对数据的商业价值敏感度及对数据化产品的认识度都相对于开
发人员更高, 但他们往往不会 SQL 语言, 更容易接受可视化操作.
(2) Hive 使用的 SQL 语言不利于图形化操作.市面上出现的一些成熟的 SQL 图形化操
作工具都可以有效地解决 Join 操作的图形化,但都无法较好地解决如何实现子查
询以及 aggregation 操作的图形化.
(3) SQL是一种描述型语言, 开发SQL的用户必须把他所需要的结果关系Schema化分
为多个子 Schema, 全部想清楚才能编写 SQL 程序. SQL 不符合人类循序渐进的思
维方式, 初次使用 Hive 的用户经常反馈不知如何下手取数据.
(4) Hive由于SQL表意的局限性, 有一些分析程序不得不使用原生MapReduce编写.
但原生的MapReduce 无法方便地共享 Hive 的数据, 因为 MapReduce 无法获取Hive 的元数据信息.
(5) 数据分析是一道复杂的过程, 查询数据库往往是其中的一个步骤,所以众多数据库
系统都可以将其 SQL 嵌入到其它编程语言中, 作为数据化产品的一个组成部分.淘
宝有一些用户曾尝试在 Python/Java 语言中嵌入 Hive SQL, 但都以失败告终.
(6) Hive 是 Facebook 公司主导的开源项目, 代码质量存在一定的问题. 研发人员普
遍反映 Hive 代码结构紊乱, 添加一个新功能经常需要涉及 Hive 所有的核心类.
并且由于 Facebook 的生产环境和淘宝的环境有较大的差异, 所以采纳社区的
patch 经常需要数个月的稳定期. 在这段稳定期, 给用户体验带来了负面影响.
(7) Hive 没有关注错误提示信息的友好性. 对于一些简单的错误, 用户都没有办法自
我判断, 需要报告给研发人员.
因为以上几个原因, Hive 在淘宝的发展受到制约. 从用户看, Hive 无法顺利地挖掘
潜在的用户群, 而这些用户确实需要数据; 从开发上看, Hive 进展缓慢, 开发人员疲于
解答和解决各类 Hive 错误

详情见附件pdf

你可能感兴趣的:(抛砖引玉, 淘宝统一离线数据分析平台设计)