数据仓库建模，数据治理

数据仓库建模，数据治理

数据仓库建模，数据治理

现在数据源来自sap wms crm 财务共享平台 oa 网报等各个公司系统
公司各种系统相互关联，数据之间已经形成了错综复杂的关系模型，拥有500多张表，并在此基础上开发了200多张dws dim和ads数据仓库表

合适的数据仓库模型一定是一个工作量最少 元数据管理清晰的，对于数据开发的难点在于对所有系统的数据结构并不特别清晰，导致大量的重复开发，每当遇到新的问题不仅需要相关的业务人员配合 还需要相关的系统开发运维同事协助 一但有一个环节中断 开发效率大大降低。所以要求数据开发人员不仅能较快速理解业务需求 也需要对企业系统的核心模块有个清晰的认识 这样许多系统取数问题自己就能轻松解决

数据开发流程1 数据抽取。各个系统的抽取需要统一抽取，这个需要azkanbn的protect依赖处理，在完成数据库底层表抽取后 才能做数据仓库开发 而不是想现在一样 通过时间拉取，底层表的kettle自动生成 通过Python生成相应的转换文件，数据的重跑 将已经处理好的job记录 下次重跑时跳过，数据清写 将特殊字符处理，日志相关已经由运维同事放入elk 暂时未开发相应数据

数据存储建模 现在基与hadoop hive，ods存放历史数据 dwd当日最新数据 由于从系统抽取的底层表已经是ER建模 暂时未对公司全部数据重新构建企业级数仓 当然这个是有必要的，特别是对于大型公司 业务复杂。构建企业级数据仓库核心思路就是不从各个系统考虑 而是从公司全部业务流程考虑，如 用户从sap发现订单需要修改 从oa提交订单更改 进入共享提交付款申请 上级领导审批，我们关心的是用户 销售订单 oa申请单 共享付款单 上级领导等实体类，这样就可以构建全局ER模型 。当前我们依然按照业务模块生成了数据集市 如出货宽表 销售订单宽表，mrp宽表等相应的维度表 如物料维度 公司客户维度等

ads开发不够规范 有部分ads数据直接取dwd 导致了重复开发 并且开发难度高，如果我们把事实表已经处理好 隐藏了各个系统的内部逻辑 ads可以只用dws 并且业务逻辑一有变动 只需要修改dws逻辑

数据的存储 本来以hive hadoop为核心 但是重要数据 要求数据稳定输出 并且etl过程快速 考虑后面这样数据直接放入 tidb gp等数据库，实时数据放入hbase kudu

etl加速 对tez内存调优 安装spark引擎 将慢的任务切换为spark，用presto做etl任务，kettle内存调优

数据仓库安全，初步使用ranger和ldap数据隔离，发现spark可以直接绕过thriftServer相关认证，这个还需要安装kerberos来做隔离，但是也无法划分权限，kerberos是一个比较复杂的框架，hdp已经支持kerberos管理集群但是外部系统连接集群就会变的复杂，如kettle连接hive hadoop,还需要考虑kerberos密钥文件过期问题。在开发人员不多的时候kerberos使用要慎重，只能通过网络隔离。

元数据管理，监控，HIVE Hook LineageLogger获取hive元数据信息，可以根据该信息动态获取hive元数据变化，结合Prometheus，可以把制定好的监控信息放入Prometheus平台，并制定异常规则写及时通知开发人员，如表的变化，namenode宕机，hiveserver2宕机等

实时数据仓库，flink有着丰富的api,和离线的本质区别在与数据是流动的，没错都是处理当前时间的数据，思维和做法已经发生了本质变化。如order by的使用，事实表与事实表的join,事实表与维度表join,在无界流的join还是初级发展阶段，维度表的选择用hive最新分区还是hbase，数据的存储选择clickhouse还是kudu,内存模型调优，部署在k8s还是yarn上。如果实时任务中断如何分析自动重启等。

数据分析价值体现。为了取数据而去取数据那么工作的意义就很小，如何通过BI分析出领导业务希望看到的数据，如我们子公司通过销售预测分析各个物料产品的趋势，对于销售不理想的直接放弃，销售前景不错的立马成立项目组来跟踪这个物料，用数据来驱动业务发展已经是趋势。除了传统的数据分析现在机器学习深度学习已经趋与成熟，通过相关算法来构建用户画像，产品推荐，发掘潜力客户将更加简单。