大数据平台组技术路线执行理念
写在最前：自己是一个思维灵活人员，就是太灵活，视角很宽，看到了很多新东西就想要尝试并学习、引入，但深入不够，同时架构太大出问题机率直线升高，有明确的执行理念指导，是非常必要的，做任何决定前必须想到这个基本理念，切切。
0、精兵强将，稳扎稳打
解读：不可盲目扩张人员，人多了管理成本增加，水平参差不齐，代码质量无法掌控。慢一点没关系，做一步回头看两步，
稳步向前。
1、足够简单，完全可控
解读：尽量使用熟悉可控的软件，尽量少。出问题可以自主检查分析的。
2、稳定第一，运维优先
解读：没有成功先想着失败，一旦要保证备份，监控先行，集中精力打造思考运维平台，一出故障就会受到严重质疑。
3、深度研究，谨慎扩展
解读：对于使用的技术，一定要深研到底，不可浅尝辄止。对于引入新技术栈，要慎之再慎。
=======================================================
选型：
1、选择Golang,放弃 Java
理由：为了将服务分割成微服务，各业务模块独立编译，彼此之间强制隔离，各部分代码独立成项目，一个可执行文件，独立数据库。
2、选择postgresql，放弃mysql
理由：mysql在断电等异常情况下表现不佳，同时，我们在数据仓库中选型是GreenPlum,同样是postgresql技术体系，双线做战不如统一技术路线。
3、选择自主研发go-sso项目，放弃cas和xxl-sso
理由：统一技术栈，把所有技术细节抓在自己手中，整个框架可以先慢后快，不要出现不可控制的细节。
# go-sso * "/login" 登录页面 * "/Success" 登录成功页面 * "/serviceValidate" 验证接口 * 使用全局拦截器进行授权拦截，即校验cookie中的用户名，与票据的正确性。（1：是不是存在，2：如果存在，那么是不是鉴权中心发放的密码（DES自加自解）） * jwt-go 创建签名 涉及到创建Token,和检验Token ## 使用 第三方直接点击跳转到 http://127.0.0.1:8080/login?service=http://www.xxxx.com.cn/ceo_data 账户密码验证成功后，会跳转到service中，并带上token 第三方系统只需要通过接口”/serviceValidate“ 验证就可以判断是否登录，并且能得到用户信息哦。
4、微服务的实现方案 rpcx
理由：选择简单，好用，基于golang，不支持其它语言。基于rpc通讯，性能高，符合选型的整体哲学。
5、选择greenplum
理由：做为数据仓库使用，系统日志采用也保存到这里，暂不上线ES。
6、ETL工具
DATAX,需要开发kafka的读插件和写插件。
7、spark或flink
理由：未来肯定会有流计算出现，目前的一期目标集中在greenplum，慢慢扩展。
8、推荐算法KNN等
需要不断学习概念，抽取模型。
9、全部使用POST请求，不允许使用GET方式。【强制】
https://www.v2ex.com/amp/t/595188
10、PostgreSQL备份
https://www.cnblogs.com/python-gm/p/9723478.html
11、golang gin框架 使用swagger生成api文档
https://www.cnblogs.com/Dong-Ge/p/11351559.html
12、全面禁止使JOIN，对，是全部禁止使用。
原因：
（1）以后分库后，可能表都不在一个实例的机器上，比如资源表与人员表可能存在分布式的两台机器上，没法跨机器JOIN.
（2）JOIN在大表上性能差，无法使用缓存。
（3）在代码层采用多次SQL查询，调用服务RPC接口，调用MODEL层方法，ID IN ( REDIS缓存 ) 等方式进行改造。我将在自已动手的第一个基础数据模块中进行全面实践，并整理出经验分享给团队所有成员。阿里的规则是不允许多于2张表，我再狠一点，直接禁止了，一了百了。
企业级数据仓库实战
https://www.bilibili.com/video/av63753220/?spm_id_from=333.788.videocard.6