• 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会给服务器带来不小的压力,扩展性也很差。

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

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

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

     
  • 相关阅读:
    怎么在excel单元格里原有的筛选里面添加新选项
    redis通信协议
    nginx路由文件配置
    R语言绘制相对性关系图
    Generator函数的语法
    360前端星计划作业
    工厂模式
    ReferenceError与undefined的区别
    for...in与点语法
    博客申请成功
  • 原文地址:https://www.cnblogs.com/zeromyth/p/1614189.html
Copyright © 2020-2023  润新知