洪荒之力已无,追求之心尚在

原创 2017年06月16日 16:03:44


一、致谢

        我的第一本习作《Hadoop构建数据仓库实践》出版了。感谢CSDN博客提供的技术学习平台,能让我把自己平时积累的技术心得加以总结,形成一篇篇博文与人分享。正因如此才有了将博文整理成书的机会。

二、写书动因

        技术的发展实在太快了。就拿数据仓库来说,从Bill Inmon在1991年提出数据仓库的概念至今已有将近三十年的时间。在这期间人们所面对的数据,以及处理数据的方法都发生了翻天覆地的变化。最初的数据量不是很大,即便是一个大规模企业级数据仓库(EDW),往往也都是集中式存储,并使用关系数据库系统本身的集群予以支撑。然而随着互联网和移动终端应用的普及,运行在单机或小型集群上的传统数据仓库不再能满足处理需求。首先是数据量呈爆炸式增长,现在PB级的数据已经很普遍。其次是数据结构的多样性,关系数据库很适合处理结构化数据,但处理非结构化的数据往往能力不足。最后是扩展问题,由于关系数据库技术关注的重点是数据的一致性与完整性,从理论上就是难于横向扩展的,因此可扩展性成为传统数据仓库难以跨越的一道鸿沟。
        为了解决这些问题,以Hadoop及其生态圈组件为代表的的新一代分布式大数据处理平台逐渐流行。尤其是近些年,围绕大数据这个主题开展的讨论几乎完全压倒了传统数据仓库的风头。某些大数据狂热者甚至大胆预测,在不久的将来,所有企业数据都将由一个基于Hadoop的系统托管,企业数据仓库终将消亡。
        但实际情况怎样呢?一方面企业级数据仓库中已经积累了大量的数据和应用程序,它们仍然在决策支持领域发挥着至关重要的作用。另一方面,传统数据仓库本身的架构也在不断发展,这一点不容置疑。从关系数据库到多维技术,再到Data Vault的演化就是最好的例证。并且在其不断发展过程中,从业人员的技术水平和经验也随之逐步提升。如何才能使积淀的大量历史数据平滑过渡到Hadoop上,让熟悉传统数据仓库的技术人员能够有效利用已有的知识,也可以在大数据处理平台上一展身手,这才是一个亟待解决的问题。
        实际上,尽管所有人都在讨论某种技术或者架构可能会胜过另一种,但我更倾向于IBM的观点,从“Hadoop与数据仓库密切结合”这个角度来探讨问题,两者可以说是天作之合。一年来,我一直在撰写相关的文章和博客,并在利用Hadoop平台开发传统数据仓库方面做了一些基础的技术实践,所写的这本书,就是对所有这些工作的系统归纳与总结。书中通过简单而完整的示例,论述了在Hadoop平台上设计和实现数据仓库的方法,旨在将传统数据仓库建模与SQL开发的简单性与大数据技术相结合,快速、高效地建立可扩展的数据仓库及其应用系统。 

三、计划与后续

        从今年春节上班后,按原计划系统研究了HAWQ。下一步准备再写一本关于HAWQ构建数据仓库的书。没有完美的解决方案,HAWQ的虽然在性能上是我用过的SQL-on-Hadoop中最快的,但使用中也有些不尽人意的地方。例如:缺少行级更新(Hive有,但实现很烂)、不支持外部分区表(Hive有)、不支持索引(Hive有)、缺少Postgresql原生支持的递归查询(with recursive)和第三方扩展tablefunc等等。庆幸的是,今天和偶数科技的常雷博士交流得知,行级更新、索引特性马上就会提供,其它的特性如果需求强烈也会考虑研发。希望能尽快提供HDFS外部分区表特性,毕竟此功能用的还是很广泛的。

        后面还想再学习一下tungsten-replicator和MADLib,这些都与HAWQ作为一个数据采集->ETL->OLAP->数据挖掘的完整解决方案密切相关的技术。


四、高龄IT技术人的一点思考

        从96年毕业工作至今已经21年,这期间也和大多数IT技术从业者一样,换过若干家公司。这些公司所属的行业与业务领域各不相同,但对于我自己来说,似乎都是干了一件事,研究与数据库相关的技术,并加以高效应用。从最初的FoxPro,Informix,到Oracle、SQLserver,再到后来的MySQL,一直到近两年SQL-on-Hadoop的各种解决方案,无不经历了一个“从入门到精通”的艰苦又充满乐趣的学习过程。而当我把一门技术用到得心应手的程度时,内心是惬意的。
        这么多年的工作中,每当我设计并实现了一个适当的数据库解决方案、让一个难缠SQL的执行时间从数分钟缩短到几秒钟、让一个瘫痪的数据库系统起死回生,此时客户的认可、同事的称许、老板的信任,所有这些带来的满足感是无以替代的。我在工作中听到了最好的褒奖就是“这事给你做我放心”,直到今天,我也坚定地认为这是一名IT技术人员价值的最直接体现。
        然而,随着年龄的增大,逐渐感觉到精力与体力都大不如前。现在熬一个通宵,甚至要花一周时间调节。越来越多的时候,精力不能高度集中,开发速度与反应也没有以前快。我想表达的是,在生老病死的自然规律面前,无人可逃,没什么值得大惊小怪的,重要的是怎样做。要时刻保持求知欲与好奇心,持之以恒地学习实践,跟上技术发展的步伐。做技术的就该这样。适当保持一定的压力,不要强求,也不要太过安逸。四十多岁还没到安度晚年的阶段,否则就像任正非所说:“刚四十就想躺在床上数钱,想什么呢”,也就别怪人家研发40岁一刀切。只要保持良好的心态并勤于学习实践,哪怕就是被切了也不怕。
        洪荒之力已无,追求之心尚在!以此标记我出第一本书的心境,并与高龄IT技术人共勉。
版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

维度模型数据仓库(三) —— 准备数据仓库模拟环境

(二)准备数据仓库模拟环境         上一篇说了很多数据仓库和维度模型的理论,从本篇开始落地实操,用一个小而完整的示例说明维度模型及其相关的ETL技术。示例数据库和ETL的SQL实现是在《Dim...

维度模型数据仓库(一) —— 概述

最近看了三本关于数据仓库的书,很有收获,也很受启发。这三本书分别是《数据仓库工具箱(第三版)》、《Dimensional Data Warehousing with MySQL: A Tutorial...

维度模型数据仓库(二) —— 维度模型基础

(一)维度模型基础         既然维度模型是数据仓库建设中的一种数据建模方法,那不妨先看一下几种主流的数据仓库架构。         1. Kimball的DW/BI架构 图(一)- 1  ...

维度模型数据仓库(十) —— 快照

(五)进阶技术         5. 快照         前面实验说明了处理维度的扩展。本篇讨论两种事实表的扩展技术。         有些用户,尤其是管理者,经常会要看某个特定...

数据仓库之三种事实表

在数据仓库领域有一个概念叫Transaction fact table,中文一般翻译为“事务事实表”。事务事实表是维度建模的数据仓库中三种基本类型事实表中的一种,另外两种分别是周期快照事实表和累积...

HAWQ + MADlib 玩转数据挖掘之(十二)——模型评估之交叉验证

一、交叉验证概述        机器学习技术在应用之前使用“训练+检验”的模式,通常被称作“交叉验证”,如图1所示。图11. 预测模型的稳定性        让我们通过以下几幅图来理解这个问题:图2 ...

kettle子转换即映射

kettle的子转换,及映射类的步骤详细介绍。是重用转换的一种有用的方式,让一些公共算法重构成子转换,供其它转换调用。

直接调用模型 model出错

在arccatalog与arcmap中如果我们使用到扩展模块是要勾选的 python脚本中也需要进行验证 以3D模块为例: C:\>python Python 2.6.5 (r265:790...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)