传统数据需求的路径：
- 第一阶段：临时需求；在数据平台搭建的早期，几乎所有的需求都来自于临时需求，数据化运营的概念从2012年才开始逐渐被行业接受并提升到公司战略的层面。因此当需求被提交给数据团队时，数据工程师需要手工编写代码，将数据跑好，再交给用户，基本靠人力来完成各类支持。但这个阶段是很有必要的，为后续数据产品的思考和规划积累了丰富的原始需求素材。
- 第二阶段：自动化报表；随着业务的不断发展壮大，业务需求越来越多，数据工程师通过人工的方式来完成需求开始变得非常低效，远远跟不上业务飞速的发展需求。在这个时期里，自动化就成为了工程师工作的重点，在数据平台中，我们称这种自动化报表平台为：Dashboard，也就是将日常的各类需求固定下来，并通过定时任务来完成统计。此外，报表平台通常还会提供一定的数据可视化功能，使更多人能够看懂和简单的分析数据。
- 第三阶段：自助BI系统；BI系统是真正意义上数据产品的雏形，随着业务的继续发展，公司规模开始膨胀，需求开始变得更加复杂和层次不齐，人力已经不能满足需求了，所以功能更强大BI平台被提上了日程。这个时期中，BI平台面向的就是专业的数据人员，一般的公司会有专业的数据分析人员来提供各类决策支持，而如何更快的满足数据分析师的需求是这个阶段的重点。一般情况下，BI平台会提供简单的SQL支持功能，用于分析更加复杂的数据需求，也能满足更加灵活的数据分析，同时报表开始变得自动化，通过更加丰富的形式来展现和组织数据。
- 第四阶段：数据产品；当公司进入到数据产品阶段时，其规模一定是不小的，很多垂直的数据团队会被合并，为了规避重复建设、提高效能，数据团队的分工也更加明确：集群维护、平台开发、工具开发、数据开发、数据分析、数据测试、数据挖掘……业务线也从简单的离线需求，转向了更加复杂的实时需求和个性化需求。
数据仓库的产品分层：
- 报表分析：报表分析是数据仓库的基础功能，提供各业务线日常数据的统计，并提供数据监控功能，产品以Dashboard为主要展示形态。
- 多维分析：由于业务场景的复杂性，很多情况下简单的报表是无法满足也无需求的，因而引入多维分析系统，支持产品及运营自主通过sql分析数据，通过OLAP的思想来实现即时查询非常重要，该产品十分依赖Sql on hadoop的查询性能。
- 专题分析：对于一些运营人员，对于部分专题有着非常强烈的分析诉求，需要通过成熟的平台和产品来沉淀分析思路，以更好的发现行业潜在机会。该部分产品是实现“人人都是分析师”的重要组成部分，从360来全景看待行业数据，从看我情、看行情延伸到看敌情等需求。
- 智能应用：该部分与其他部门合作较多，包括了个性化搜索、个性化推荐、定向推送等系统，数据平台负责提供基础数据，智能分析环节由合作部门完成。
数据仓库对上层数据应用的支持：
主要体现在三个方面：
- 业务监控数据（大盘数据洞察）；
- 数据挖掘(用户画像、推荐等）；
- 数据分析(业务诊断、提升优化等)。
其中按支持的优先级来分，首先就是业务监控数据，然后是数据分析、再然后数据挖掘，这也是数据应用由浅到深的递进。但由于数据仓库的建设依赖于元数据、调度等子系统的建设维护，故应做全局方案以避免重复开发与返工的情况。
数据仓库的技术搭建流程：
- 日志采集（浏览器、无线客户端）；主要技术：Web端日志采集技术，例如Apache Flume等；App端日志采集技术，例如友盟U-App AI、Google Analytics等。
- 数据同步（直连、文件、数据库）；主要技术：消息通道，例如Kafka、Redis等。
- 离线数据开发（开发平台、任务调度）；主要技术：离线计算平台：Hadoop（Cloudera等）等。
- 实时技术（流式）；主要技术：实时计算平台：Storm、Spark Streaming、Flink等。
- 数据服务（架构、性能、稳定性）；主要技术：传统关系型：Mysql、PostgreSQL；传统分布式：Hive、HBase；实时分布式：Impala、Dremel、Spark、Presto。
- 数据挖掘（中台、算法、案例）。
数据仓库的理论建设流程：
数据整合及管理体系 --> 维度 --> 事实表 --> 元数据 --> 计算管理 --> 存储与成本 --> 数据模型（建模、模型方法论）--> 数据质量 --> 数据应用。
数据分层理念（后续会写文章详解）：操作数据层（ODS）、明细数据层（DWD）、汇总数据层（DWS）、应用数据层（ADS）。
数据应用层：
- 实时数据：数据监控、收入预警、异常监控等；
- 宏观决策：数据门户、数据小站、大盘走势等；
- 对象分析：行业数据、流量分析、自助查询等。
阿里巴巴数据仓库流程图示例：
