想问下大佬对大数据数仓开发怎么看的？

[castleknight]

毕业后在一家小厂做了一年左右的 Java 开发，两年左右的大数据数仓开发。最近觉得做数仓没有意思，工作内容基本就是写 SQL 做表，技术难度低并且属于支持类型的工作很难看到直接的价值，做久了感觉自己的代码能力也变弱了，现在考虑是否要转回 Java 。不知道是否是自己的认知有限，看不到大数据数仓开发的价值，想知道大佬对大数据数仓开发是怎么看的

[q474818917]

OLAP 不都是这样吗

[Maxwe11]

1 、费力不讨好；
2 、实际上针对大规模业务和相对稳定的业务但是多变的产品，核心数据仓库依然是非常好的稳定支持选择；
3 、但是建设这个东西是个玄学，不懂的人都认为没价值，你让谁去做，基本上短时间也能怼一个；
4 、真正做出一套成型体系，让每个层的人都用起来舒服的数据仓库，是相当考验功力的；
5 、综上所述，久而久之这东西也就失传了，因为小公司业务不稳定没必要，中公司雇不起人，大型公司数据核心系统的坑少，一般人也进不去；
6 、传统企业基本都不懂，追风，基本都是听营销企业编出一个新名词就去追，拿数仓说大家都会认为技术太老了，不够 fashion ；
7 、最后：数据仓库不是写表的，而是定标准和研究数据流结构的，做表那是应用层的事儿。

[castleknight]

@Maxwe11 对大佬的一些观点感同身受，最后一点可能和大佬理解有偏差，表是数仓的物理实现，做数仓也要写表吧，我们公司应用层的表也是数仓开发在做，岗位分得细的公司可能由 ETL 或者 BI 做吧, 你说的"数据仓库是定标准和研究数据流结构"感觉更偏向设计，可能你们岗位分得更细和了吧，将设计实现交给不同的人来做

[dqzcwxb]

大数据数仓开发 ×
sql 小子 √

[outoftimeerror]

数仓重业务轻技术，了解业务流程，做好维度建模，数据治理，帮助业务理解数据并驱动业务，很多都是沟通工作。另外一个方向是转项目管理，从传统瀑布模式到 agile ，管理 budget capex opex 。
如果只是写 sql ，和 java 搬砖没啥区别。

[asensio]

是不是可以往 spark\flink 方向靠一靠，不过也是业务计算编写，再想做技术一些可以是大数据组件运维吧，或者一些平台开发

[castleknight]

@asensio 做业务开发基本都是写 SQL 了, 离线写 SparkSQL, 实时写 FlinkSQL ；大数据组件运维是偏技术一些，但现在云服务吃掉了这块部分岗位；平台开发我现在了解到的很多都是做数据相关的内部系统和工具，很多云产品提供现成的解决方案，也会吃掉这块部分岗位，平台开发更接近后端开发，后续有意往这个方向发展

[muyiluop]

兄弟，我们最近也要搞数仓，能否请教下需要用到哪些技术。大概的流程架构是个啥。我这啥也不清楚，一头雾水