• XX项目记录(一)


    记得以前听某人说过,最坏的方法是武断,最好的方法是倾听。

    XX是加入公司以来接触的第一个项目,这个项目大体上是实现数据从源A,B,C(可能还有D,E,F)发布到B,B是DATA-CENTER,从而帮助客户搭建具有统一、高质量、全面的数据平台

    该项目就围绕数据中心设计、数据转换及应用调度等相关项目建设。

    说实话,以前我没有过ETL项目的经验,但单从技术层次来说, 这样的项目从表面看起来似乎并没有多大的难度。建立转换字典,使用ETL工具,开发业务workflow,应用程序调用API,定时跑起来,监控一下问题数据,做一下异常处理报告,然后泡杯咖啡数着客户付的钱....岂不美哉。

    大概是因为我刚进公司的缘故,对公司的技术实力、管理水平、人力资源都不太了解,所以碰到了很多看似算不上问题的问题。没有相关的项目实施文档,缺少相关的技术share,还有过度的依赖application。我想起在之前公司做的一个广告operation系统,(我对前台开发不甚了解,但对后台数据库开发有一点自己的见解)。这套系统也是要从多套系统后台(广告后台、游戏后台、支付网关)采集相关的数据,项目决策者对这样的系统有点束手无策(原谅我这么说),因为要采集很多系统的数据,决策者不想开发数量众多的API,并且公司大多数人不懂数据库,项目从原先定位的DW降到ODS,使用MYSQL+LINUX平台,采用FTP定时接收的平面文件导入临时数据库进行处理,最后发布到产品库,应用系统由一个小女生开发,从头到尾不用关心数据库,连数据的展现都由SP来完成,应用程序只要调用SP分页,把数据展现在页面上。最后这套系统看似成功的实施上线了,而且给市场部带来不小的视觉冲击,可以说是一种梦幻般的客户体验(数据计算都是由SP来实现了呀,不用再去手工统计啦....)。然而在我看来,这套系统非常的失败,彻头彻尾的失败,因为系统太过于“依赖”数据库,根本不用关心数据的流向,所有的工作都通过调用所谓的API(store procedure)。而且B/S构架采用sp会给服务器带来不小的压力,扩展性也很差。

    于是乎我看到现在的项目“过度”的依赖应用程序就产生了种不详的预感。 但我不是那种能被依赖和掌握该技能的专家

    顺便给“专家”一点建议,如果你觉得自己能够搞定(当然自信是件好事),但是没有在项目中真正的应用实施成功过,那么请认真的倾听。

    大家都在相互磨合,在实施大中型项目中不断摸索成功的经验。

     
  • 相关阅读:
    2019.10.31 答辩回来后;
    2019.10.22
    2019.10.21 上周总结+今天
    2019.10.20 没有人可以阻挡自己努力,男朋友也不可以。少情感,多学习;;多夸夸他肯定他
    2019.10.19 干什么? 不要纠结了于下手什么了 趁还年轻 去做吧!!
    2019.10.16 每天问自己 三遍 或者更多:我收获了什么?我收获了什么?我收获了什么???
    Java 错误:Constructor call must be the first statement in a constructor
    2019.10.14 解决讨好型人格;时间管理划分等级+设定时间上限
    2019.10.14 今天看到的业务大佬的肺腑之言
    放几张吴悠校园行
  • 原文地址:https://www.cnblogs.com/zeromyth/p/1614189.html
Copyright © 2020-2023  润新知