数仓建设沉思录（六）：步子大了，会扯到蛋

古人云：抬头看路，埋头干活。

最近一段时间投身于实时风控与国密改造两个项目，数仓建设工作有所停滞，随着实时风控项目业已渐入轨道，暂不会有大的变化，唯一需要优化的就是性能问题，但目前还不是瓶颈，可以暂缓执行，再则依据经验来看，过早的设计优化是万恶之源，一不小心就会造成项目失败。测试环境测试结果居然比正式环境还好，让我有点郁闷，话说可能的原因就是公司堡垒机到最终服务器这一段网络造成的延迟，给了我错觉吧！国密改造一期也进入收尾阶段，终于又能腾出时间去琢磨琢磨数仓下一个阶段要解决的问题了。

前一段时间在基础设施建设完成后，就勇敢的往前跨了一大步，一方面是掂量掂量自己对业务迅速掌握的能力，一方面毕竟做数仓也有一段时间了，虽然前段时间将精力全部投注到基础设施上了，要到年底盘点的时候了，数仓在业绩上总得出点东西吧！

于是，便揽下了业务部门一个数据整合的需求，这事从定位来讲，也确实是数仓做。“数据基本都是全的，稍加整理就好了”，我居然信以为真了，细粒度往粗粒度走，当然容易，但没想到的是事实上是反过来的，粗粒度往细粒度走，也就是说之前同事所做的工作都作废，我们要从头来才行，不然是满足不了业务部门的需求的，更让我有点郁闷的是：我们无法对我们整理出来的结果辨别对错，业务部门也不能，这就尴尬了。为此没少挨投诉，吐槽这个没成本的事，偶尔发泄一下就可以了，成事才是最可贵的，吐槽多了，也显得肤浅，除非自己经历过，而且也成事了，否则是没有资格吐槽的。

真是哑巴吃黄连，有苦说不出，估计还要被小兄弟们埋怨了，尽管没在我面前说，可执行力上还是一如既往的支持，这就足够了。说几句题外话（发现每次都有题外话），其实我也出于对他们负责，对自己负责，对公司负责的态度才会积极的将这类脏活、累活揽下来的哈，说说几个原因：1、公司是不会养闲人，也就是说不可能让你闲着2、工作做什么都是做，如果能做点你喜欢的，而且对你自身能力提升有帮助，何乐而不为？3、公司养着你是希望你要有产出的，不是让你坐那里玩的4、出于对我们组负责的态度，年底盘点了，谁谁绩效多少多少的时候，你拿着自己的可怜兮兮的年终奖的时候，没有一点想法么？当然如果你看得开，那也无所谓了，既然这样的话，你应该在体制内活着。年终奖虽然不是很多，但这是公司对你的认可，根据马斯洛需求层次理论，这是对自我价值的追求，是最高层次的人生需求。一句话总结就是：闲着也是闲着，与其等着别人安排你不喜欢做的事，不如去争取点自己喜欢做的事，虽然有的时候会苦点，但也是开心的，是不是？既然打算是靠它来吃饭的，那么就应该将这饭碗给端好了，否则还是趁早改行……

这是第一个问题，第二个问题是公司在朝着互联网转型，大大小小的系统都在演进，演进就意味着不停的变化，对于数仓来说最为关心的是库表的变化，前几期中有一期讲过这个问题，那时候希望依靠行政流程来减小库表变化对数仓的影响，现在想来，这个影响最多也就是降低数仓对外的服务出故障的风险，提高数仓组对外服务能力的形象，尽管我也注重这个问题，但依靠这个没有解决根本性的问题，所以得想法子在数仓与前端业务系统之间加一个缓冲区、过滤器什么的，前端所有的数据经过这一套设备之后，进入数仓是一个全新的领域，说的挺玄乎，实际上就是ETL + 元数据，不过之前我将ETL和元数据理解的狭隘了，即使读完了杰弗里波梅兰茨的《元数据》，对于建设元数据系统并没有实质性的帮助。看来还是需要两条腿并行走才行，一条腿小步快跑，一条腿稳步推进，小步快跑发现问题，及时反馈到稳步推进的工作中，以调整正确的姿势前进。

下一个阶段，继续推进数据大一统的工作，小步快跑的脏活轮流干，值得庆幸的事这活是绝对值得。

第三个问题：数据的实时性与海量是鱼和熊掌不可兼得的，这个问题早前就意识到了，但后来出现了像以Tidb，CockroachDb为代表的新一代分布式云数据库，就以为有了救世良药，事实实践下来并没有如它们宣传的那样，可能现在好一些了，Tidb已经发布了正式版，效果反馈一片叫好，但我也无力做小白鼠，时间成本对我来说太珍贵了，手上仅有的资源和技术力量也不允许我再做一次尝试。所以接下来还有一件重要的事情，就是将数据服务分类，对于T0类服务必须加上数据期限，T+1类数据服务可以无限期，有多少给多少，而且服务有保证。还得发布公告，对于T0类数据服务不保证正确性，原因自不必说。从我个人的数据认识来讲，实时性服务，应该是由业务系统自己保证更为妥当。

好了，这个系列的下一篇估计要等到元数据系统已经初步建立了才有吧，目测周期较长，要与时俱进的跟着业务变化的脚步，这是一个有困难的事。