很久没有更新博客了，今天主要是想谈一谈自己工作几年总结的心得。
1.浅尝辄止
数据库：基于mysql，oracle来实现数据库分析（存储在数据库，使用数据库语言直接分析，最后成报表形式）。
数仓&大数据平台；随着数据量暴增，业务复杂度增高，以及烟囱式开发的弊端（导致了数据不互通、重复造轮子、研发效率低的问题，相似的数据产品也有非常多，占用了大量的存储和计算资源，数据口径也无法对齐，内部沟通和管理成本变得很高），追求时效性等，采用大数据hadoop平台组件hdfs做存储，以hive为主的数仓体系，大数据计算引擎（一代是mapreduce,二代是tez，三代是spark）,依据公司的适用性，会采用其他的计算引擎，比如MPP计算引擎架构（impala，presto，click house等），注重时效性，会采用实时组件，flink、spark streaming等，存储非关系性数据，采用no_sql组件，redis、hbase、mongondb、log4j等，构建一套完整数据仓库，对外提供出即席查询、报表开发、多维分析的能力。
数据中台：在大数据平台基础套了个数据服务的马甲。以数据中台组件化、智能化的方式，将通用的数据开发场景和工具进行沉淀，来提升开发效率，再通过数据的资产化、服务化的方式提升业务数据使用效率，让业务更加聚焦在数据应用和业务创新上，而不是花费大量的精力进行数据能力的重复建设。
补充说明：
关于批处理和MPP架构的不同：
相同点：
批处理架构与MPP架构都是分布式并行处理，将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果。
不同点：
批处理架构和MPP架构的不同点可以举例来说：我们执行一个任务，首先这个任务会被分成多个task执行，对于MapReduce来说，这些tasks被随机的分配在空闲的Executor上；而对于MPP架构的引擎来说，每个处理数据的task被绑定到持有该数据切片的指定Executor上。
正是由于以上的不同，使得两种架构有各自优势也有各自缺陷：
批处理的优势：
对于批处理架构来说，如果某个Executor执行过慢，那么这个Executor会慢慢分配到更少的task执行，批处理架构有个推测执行策略，推测出某个Executor执行过慢或者有故障，则在接下来分配task时就会较少的分配给它或者直接不分配，这样就不会因为某个节点出现问题而导致集群的性能受限。
批处理的缺陷：
任何事情都是有代价的，对于批处理而言，它的优势也造成了它的缺点，会将中间结果写入到磁盘中，这严重限制了处理数据的性能。
MPP的优势：
MPP架构不需要将中间数据写入磁盘，因为一个单一的Executor只处理一个单一的task，因此可以简单直接将数据stream到下一个执行阶段。这个过程称为pipelining，它提供了很大的性能提升。
MPP的缺陷：
对于MPP架构来说，因为task和Executor是绑定的，如果某个Executor执行过慢或故障，将会导致整个集群的性能就会受限于这个故障节点的执行速度(所谓木桶的短板效应)，所以MPP架构的最大缺陷就是——短板效应。另一点，集群中的节点越多，则某个节点出现问题的概率越大，而一旦有节点出现问题，对于MPP架构来说，将导致整个集群性能受限，所以一般实际生产中MPP架构的集群节点不易过多。
2.不想当将军的士兵不是一个好士兵
怎么做好一个数仓团队
1.人员配置
2.技术选型
3.领导决策
1.人员配置，至少一个有经验的高级开发leader，在搭配几个合格的开发人员组成
2.技术选型，开源/阿里+华为
3.领导决策，一个好的团队，需要一个掌控全局，带领团队的好领导
for me：
业务调研：去业务区实地参考业务流程，了解业务具体操作，了解系统
需求调研：带着需求与业务沟通，明确业务具体的目的，避免理解错误，导致返工，基础要打好
规范流程：制定适合的开发流程，测试到生产环境的流程，需求到上线的流程，BA-开发-测试-业务的流程
开发规范：表命名，字段命名，存储格式，建表方法，开发脚本规范，数据字典记录
架构设计：数仓分层设计，数据建模设计，数据开发，调度流程，脚本优化，数据治理
具体每个部分都可以开展详细细节描述，需要每个人自己根据个人情况展开，这里只能提供大纲思路。
