相对来说BI还是目前比较吃香的IT工种之一。
按照技术线进行划分，结合市场上的一些招聘风向，说说个人发展方向和就业前景吧：
ETL，这块是BI永恒的重点主题之一，人员需求也是一直持续，只是相对来说,ETL会比较枯燥，在这一块，掌握一两款顺应潮流的大工具，拥有相应年限的工作经历，行业性要求不太高，可以找到一个不错的岗位，对于喜欢技术，喜欢钻研的人来说挺不错的。而且据了解，互联网行业不少公司也会找不少专职ETL工程师，不错。DS、INFA、SSIS这些都是蛮有需求的。
数据仓库，主要指的数据仓库设计，架构设计等，一般来说LEVEL会比较高了，薪水待遇也会蛮高的，属于偏高端人才了，一般都会要有5年、7年或更多年限的经验，对行业性经验要求比较高。
OLAP技术，以前会有专门的建CUBE方面和OLAP开发的工程师的，现在慢慢失去其独立性了，很多已经跟其他岗位混合到一起了。
前端应用，由于工具很多，所以这方面的人才需求也会是百花齐放。掌握一两款高端的工具， 一定年限（甚至都不需太长）即可谋得一份不错工作，更好的一点是，从前端应用去切入，可以更多的接触到业务更多的和客户方业务人员沟通以及和己方的需求顾问沟通，对于个人业务上的成长满有好处的。努力后未来亦可往需求分析方向发展。这方面，COGNOS、BIEE、BO等工具会有优势，工具都这么贵了，人才待遇自然也能水涨船高。
数据挖掘方面，真的蛮高端的，要求也一样极高。
后期可以试试项目经理，当然，不要那种水一下就行的，最好是正规些的企业，比较磨练人的，亦看到有朋友从技术到项目经理，到项目群经理，到项目总监这样的发展的。铁了心不喜欢做技术，技术只是初期的敲门砖。

我以前对这个职位也非常的感兴趣，曾一度自荐到易车网发了一堆邮件，但是都石沉大海，因为我一直给同一个 HR 发邮件，后来被证实此人已离职了....
 
我当时也看过他们数据方面的产品经理职位，总的来说就是利用现有的在易车网上面的用户访问数据去做分析。这些数据是非常有价值的，比如哪些用户点击了哪些车型，浏览了哪些相关车型的信息、报价、图片，浏览了这种车型的还浏览了哪些车型、大概价位等等。诸如此类的数据信息是非常有价值的，据我当时观察到的信息他们自己在做数据分析并将这种分析的结果做成了产品买给一些厂商或者4S店，这种对用户分析的数据信息如何体现，如何帮助到厂商或者客户就体现在这个产品本身的数据价值了，而产品经理要做的就是把这些需求提炼出来融合到产品中去。
 
数据产品经理既要有对数据和数据分析的敏感和犀利，又要具备产品经理自身对产品的理解与设计控制能力。
 
这是以前收录的一个数据产品经理的对这个职位的理解和感悟：
------------------------------------------------------------------------------------------------------------------------------------------
如何做一个好的数据产品经理？PD（指产品经理，下同）本身就是在做牛做马，关系圈异常复杂。数据PD也不例外。而且打交道的人更多。以下是我用PPT绘制的数据产品经理关系圈。如果你也做过数据产品的产品经理（好拗口），相信也有同感。既然要和这么多人打交道，要推动数据产品的上线，数据产品经理自然有着一定的要求。

我的体会如下——也借此去鞭策自己在朝这个方向努力：

1.要极其熟悉公司业务及动向。所以要了解公司的商业模式、战略、以及业务流程、要考核的各种指标，以及指标背后的业务含义等。这一点，再了解都不够。

2.要了解数据分析。好的数据PD，即使不做数据PD，也应该是个数据分析师。数据PD的一大要务就是将数据分析做成可复制，可自动运转的系统。虽然有数据分析师们围绕在自己周围，但是自己也要清楚业务的问题，分别要看什么数据，或者当数据出现后，意味着业务出现了什么问题或者会出现什么问题。这一点，要向最好的数据分析师们看齐。

3. 要了解数据仓库及商务智能。

这两个关键词背后都是庞大的体系，恐怕我短短半年的转岗时间太短，虽然能够对别人讲解一通商务智能产品的架构。嘴里虽然会抛出若干个类似于汇总，钻取，度量，指标，维度，缓慢变化维，层次，属性，仪表盘等等术语，但是也不支持多几层的知识钻取，遇到异常问题，也不知道该从什么地方分析原因。幸而身边有数据仓库的同事，可以多多学习。这一点，没有天花板。

而商务智能，做为一门学科，起源于20世纪90年代，它的出发点是帮助用户更好地获取决策信息，最初商务智能的动机是为用户提供自助式的信息获取方式，这样，用户就可以不用依赖于IT部门去获取定制的报表。（引自《信息仪表盘》一书P41）。而如今，商务智能除了提供信息，更主要的是降低用户获取数据的门槛，提升数据的实时性等方面。从降低用户获取数据的门槛一个方向，我们就可以做很多事情，比如如何设计信息仪表盘（designing of information dashboard）？如何让数据以更亲和的更直观的方式展示（数据可视化）？如何能够让用户离线访问？如何能够实现警戒数据的主动发送？这一点上，花多少功夫都不多。

4. 要精通数据产品开发流程。数据开发+产品开发。

数据PD的最终目的是要做数据产品。这里要拆开看，其一，数据产品本身也是在线可供用户实现的产品，既然是产品，产品的整套研发思路和普通的产品没有太大区别，用户是谁，他们需求是什么，满足需求需要什么feature list，每个feature list的资源评估以及优先级如何，产品的生命周期如何？这是产品开发。然后他是个数据产品，意味着这比普通的产品，多了更多的要求。在数据这个内核之外，它需要各种feature list，如订阅，搜索，自定义，短信接口，邮件接口等。但是数据这个内核，也需要一套数据开发流程。

比如：

数据源——是否足够，是否稳定——数据PD需要足够了解目前的业务处理系统建设情况，以及数据源的积累程度，用以判断数据产品的建设时间是否合适。不合适的时机会导致项目组的重复劳动和残缺的数据产品诞生。数据产品是用以支持监控，分析，决策的，而业务处理系统的定位在于提升工作效率，解放工作人员手脚。业务系统采集的数据未必满足所有分析需要。比如或许领导要分析大量攀升的退换货的详细原因，而业务系统目前并没有要求用户在申请退换货的时候选择原因或只有输入而非标准化选项，负责退换货出力的员工也只有在excel里登记原因，而不是录入到系统里。所以可能会导致需求方要看的数据提供不出来，那么数据pd就有必要反向驱动数据源得以采集。

分析模型的设计——分析模型的好与不好，其实决定了数据产品的成败。

在项目中，可以由BI的数据分析师们担纲此职责，也可以由数据PD担纲，更多则由双方一起确认，内容以数据分析师们为主，功能评估及优先级、项目计划和协调、统筹以数据PD为主。所以数据PD要更加清楚数据分析师们所需要的需求是否能够实现，背后的商业价值如何，并与数据开发、产品开发保持比数据分析师们更加通畅的合作关系，能够借力进行可行性和资源的评估。有的时候，我们不是没有数据，而是有了太多的数据，不知道怎么去看。如果只是抛给用户一堆数据，很难想象用户会如何去解读它。以前做交互设计的时候，我们流行一句话：把用户当成傻瓜。

而数据平台，因为可能本身就要求有一定的使用门槛，所以想成不会互联网的傻瓜不太现实，那么我们就要想成“用户是不懂数据的傻瓜”。他们或许也能通过一串串数据体悟到什么，但是如果是一条上升的退款率趋势线，或许他们会体悟到更多——毕竟，上和下本身就是直观的。然后再想一下，如果将这条线上加上一条警戒点的线，他们会知道从什么时候开始数据是异常的。再然后，就要设想，当他发现从7月12日数据上升后，想干什么？他会不会想了解是哪个行业上升了？他会不会想了解是那个渠道上升了？那么，就要提供行业和渠道的选项或者对比给他。

再然后，当他过问了这个行业的负责人后，负责人想不想再了解是哪个供应商或者哪类商品上升了？那么要如何将这些维度、层次都融合在一起，同时又能将用户非常方便地去用呢？分析模型的建设至关重要，也可以说，分析模型是前期需求分析的最有价值的产物。分析模型应该会包含几点：

主题的划分：整块分析会划分成什么主题，比如销售可能会分成销售走势及构成分析，行业排名，商品排名等 度量及指标：分析主题会涉及到的度量及指标的算法、定义等（这通常会产生一份指标以及维度的定义及描述文档） 维度：要分别从什么维度去看这些指标和度量，如时间，渠道，这些维度是要筛选还是要对比 钻取：这些维度本身有没有层次，需要不需要进行钻取，如渠道可钻取到渠道类型，行业可钻取到子行业，商品类目可钻取到商品叶子类目等 输出：分析需要用何种图表进行展现

数据的ETL开发——数据的清洗，转换，装载流程占用了数据产品开发的大半资源，不规范的数据源会导致这一块的资源更大程度的占用。比如同样是供应商编码，系统之一称为供应商编码，系统二命名为供货商编码，系统三命名为供应商ID，这三个系统同时是公司的系统，这种情况虽然想起来匪夷所思，但是现实情况却也存在。虽然ETL开发是DW开发工程师在做，但是作为数据PD，焉能对这些工作缺乏了解，对ETL工程师反馈的问题，缺乏认知，不理解对于项目的潜在风险是什么？而且更多时侯，当遇到数据不规范，不统一的问题，数据PD需要反向驱动业务系统进行数据规范性建设，无论是功能上，还是驱动直接的使用方——如负责录入数据的行业小二，建立一套录入规范。这些工作看似和数据PD无关，我们大可以推脱说：那没办法，这是数据源的问题，不是我们功能的问题。但是，用户是有权利选择使用不使用你的数据产品的，当数据产品提供的数据不值得信赖的话，无疑是自取灭亡。一旦用户对数据不信任，再想挽留他们，是很难的。即使有很多“无能为力”的借口,我们也不能坐观其变。

前端交互与体验的优化——虽然内容定义好了，但是那么多度量、指标、维度、钻取，如何划分信息层级，如何划分栏目，如何设计用户的行为路径？这些就不是数据分析师们的重要工作范畴。而是交互设计师？鉴于很多数据产品项目可能会没有交互设计师，所以数据PD应该对内容进行封装，进行信息架构、页面布局以及图表各种功能设计。设计，然后撰写详细的功能需求文档，交付给产品开发，前端开发以及数据开发，以及前端展现开发四种类型的开发人员。

数据产品的功能描述文档，除了产品开发部分，其他的就是在描述“内容”，即分析模型，除了主题、度量、维度、钻取、筛选、输出图表类型，有些内容还需要详细定义到“排序方式”等等细节，这就case by case来看了。

环境，技术，工具——或许做一个普通的产品，你把需求描述清楚，与产品开发工程师确认好可行性，接受资源评估就OK了。但是数据产品，受制于所部署的环境，所选型的工具，如Oracle，IBM的Cogos，以及SQL Server。其他的产品我不知道怎么样，我们用的是Oracle BIEE。那么作为数据PD，是否需要了解BIEE能够提供的功能是哪些呢？看文档，请教别人，不能知其不可而为之。另外，也需要逐渐摸透BIEE的坏脾气，实现不了的功能，无法克服的难点等。这一点，也需要继续了解，继续学习。
------------------------------------------------------------------------------------------------------------------------------------------
 
其它相关文章参考：
支付宝高级分析大师的深度好文-数据分析从入门到大师
深度好文：从设计到数据-写给非数据人的数据入门 (如何跟客户业务人员普及数据分析)

作为过来人，建议你在国内公司至少摸爬滚打到5年，至少获得独立带项目的经验，然后在加入IBM或者HP这样的外企。个人感觉会有以下好处
1， 起点会比较高，因为你已经可以独挡一面，会有更大的机会获得更好的salary和职位。
2， 在有充分实践经验的前提下，可以进入大公司来进行理论和系统方面的学历与归纳。这种外企会有很多成型的方法论和实践。如果么有充分实践的经验，很难去理解和主动学习这些财富。
3， 在国内公司多认识认识人脉。
 

这个还是要看个人的喜欢：
1.报表工程师：利用HQL来生成各种各样的报表
2.大数据产品工程师：利用大数据来做一些产品。
3.ETL工程师：利用HQL来做ETL处理
4.数据分析师：利用HQL来做数据分析
5.数据挖掘工程师：用户行为分析，用户画像，数据建模。
6.数据仓库工程师：利用hive构建大数据数据仓库工程师。
7.hive开发工程师：UDF，UDAF，UDTF等等Hive开发
8.架构师：熟悉Hive开发，报表开发，构建整套的系统
9.测试：
以上，等等。。。可以工作的内容太多太多了。不要现在纠结做什么，先老实做几年，以后就不纠结了。。

首先我觉得有专业方向比如会计懂财务相关类知识这本身就是一大优势，特别是正好碰到了跟财务相关的BI项目，懂业务与不懂业务的差别很大，所以你要有信心。

第二，BI项目有很多，不一定每一个项目都会和会计相关的业务结合，或者这么说没有一个公司就只做与会计相关的 BI 项目，BI 项目跨越各个行业面对各种需求不仅仅是会计相关。

第三，你如果学习过 BIEE，个人建议你辅修一下咖啡的 BIEE http://www.hellobi.com/course/17 ​  真正的加深一下，如果咖啡的公司正好有实习机会岂不是更好。

第四，如果你英语沟通没有问题的话，我可以介绍你到北京或者上海一家德企做 BI 相关的工作，前提是英语基本沟通没有问题、二是实习期不能太短，最好是实习通过后能够留在公司。

第五，BI 找工作机会还是有很多的，来这个论坛的每个人背后都代表一家公司，不乏有负责公司BI团队的 Lead 或者 PM，有合适的实习职位一定会提供给你的。
          

是刚刚大学，还是刚刚大学毕业呀？这两个差别还是有些大的。
我想，如果你立志成为大数据架构师，那么不管spark，storm乃至更多更多的技术及方向，都是需要了解的。
这种纠结是完全没有必要的。
拿spark，storm这些来说，他们都是会有共同性的，找一个走走，可以借鉴了解，举一反三。如果你熟练了，可以很容易的切换的。至少我身边碰到水平稍高些的朋友都是如此。
因此，我觉得你纠结着两个，跳出来看，还是太小的范围了，建议你涉猎更多更多还要更多的技术方向，为了你的大数据架构师目标。
祝好运~