如何设计一个元数据管理系统
利用周末的时间学习了关于大数据工程师职业发展规划的一些课程，其中有个很好的问题分享给大家，如果让你从0到1设计一个元数据管理系统你如何设计？需要具备哪些必要的技能？就这两个问题分享一下关于我的思考。首先一个元数据管理系统是一个门户入口，是一个服务，服务的对象当然是使用数据的人或者部门，那提供服务的原材料是什么呢？那必然是数据，这里更具体的就是每一张hive数据表吧，那么我们是不是可以把每一张表它本生看做就是一个商品呢？假如我们的这个门户就是卖商品(hive表)的，我觉得就得提供一下几点要素：
商品的名称：也就是表信息，包括表英文名,中文注释,当然商品还有状态(在线&下线)
商品的内容和说明书：包括字段类型,英文名,中文名,字段注释,保密级别(机/密保密/一般),统计逻辑说明
商品的制造商：表的负责人信息，包括业务/开发负责人名超链接,所在部门等详细信息，方便商品溯源
商品一些特殊信息：比如分区信息，分区名,分区大小,分区记录条数,生成分区的时间
商品的供应链关系：也就是血缘信息，表上游,下游节点信息
商品的制造过程： 生成该表对应的代码地址超链接
商品的购买人群： 权限信息，申请访问超链接,权限审批到单人单表单字段粒度,不同保密级别字段对应不同审批流程
商品的热度到底好不好卖的衡量：也就是表的热度信息，标识被下游依赖的多寡
商品的评论：对每一张表使用情况的反馈，到底表设计的是否合理，进而可能反推出数仓建设的好坏，造的好不好用户用的爽不爽也是关键
当然最后还需要一些商品使用的注意信息和QA，也就算做是客服功能吧
那既然具备了以上的一些东西，我们这个服务如何才能搞起来呢？就从开发的角度来说无非就是前后端的设计开发，技术的选型。站在巨人的肩膀上会走的更远，所以先扒拉扒拉开源的东西。关于技术选择都是因人而异，先跑起来再说，毕竟数据的东西太容易变了，不可能一步到位，后期见招拆招吧，慢慢优化吧。
写到这里突然又想到了几个类似的问题，假如让你设计一个数仓如何设计呢？假如让你再搞数据平台你又改如何设计？假如让你设计一个调度系统呢？假如设计一个能满足离线和实时的计算平台呢？假如让你搞一个数据质量监控系统呢？
以上问题也是随机想到的东西，后期我也会分享一些我的一些想法，希望大家留言与diss。
数据职业发展发力点
