上篇：架构及组件 一、数据平台的发展 1.1 背景介绍
随着数据时代的到来，数据量和数据复杂度的增加推动了数据工程领域的快速发展。为了满足各类数据获取/计算等需求，业内涌现出了诸多解决方案。但大部分方案都遵循以下原则：
降低数据处理成本
合理提高数据使用/计算效率
提供统一的编程范式
宜人贷的数据服务平台也是遵循这三个原则。本人有幸亲身经历了宜人贷数据平台Genie的整个发展过程，纵观宜人贷和业内，可以说Genie的发展是工业界数据平台发展的缩影。
Google 的三大论文和Apache Hadoop 开源生态圈的发布应该是大数据处理技术走进“寻常百姓家”的起点。Hadoop 的组件均可在普通的廉价机器上运行，加上其代码是开源的，因此得到了众多公司的热捧。那么一开始这些公司都用它来做什么呢？
答案是数据仓库。
注：Google三大论文：Bigtable: A Distributed Storage System for Structured Data；The Google File System；MapReduce: Simplefied Data Processing on Large Clusters
所以早期的数据平台大概的架构都是由Sqoop+HDFS+Hive这三个组件组成，因为这个是搭建数据仓库最廉价高效的方式。此时数据仓库只能回答过去发生了什么（离线阶段），因为Sqoop离线抽取一般采用的t+1快照方案，也就是说只有昨天的数据。
紧接着由于对数据实时性的需求提高了，需要实时做增量数据的关联聚合等复杂运算，这个时候数据平台就会加入分布式流计算的架构，如：Strom ，Flink， Spark Streaming 等。此时的数据仓库可以回答的是正在发生什么（实时阶段）。
由于离线数据处理流程（如：Sqoop+HDFS+Hive）和实时数据处理流程（如：Binlog+Spark Steaming+Hbase）两套流程计算逻辑耦合较大，并且通过组合才能支持实时全量的数据分析，所以就产生了很多架构，如早期的Lambda，Kappa等。此时历史数据和实时数据结合数据仓库可以回答什么终将会发生（预测阶段）。
数据平台发展至此已经不再是一个数据仓库就能解释的了，它与各类业务部门紧密合作（如营销、电销、运营）打造出诸多数据产品。此时数据仓库（数据平台）已经进入了主动决策阶段。
其实预测和实时的发展顺序不同的公司有所不同，只用历史数据就可以做出预测。
数据平台应该属于基础架构的重要环节，曾经互联网行业内有很多公司跟风搭建了大数据集群后发现很难发挥真正价值，其实最重要的原因应该是对数据使用的定位以及对数据平台的定位问题。目前的数据平台定位有以下几点：
决策赋能
为决策层赋能，决策层通过使用BI报表快速了解公司运营情况，因为数据不会说假话。
业务数据分析/业务数据产品
平台可以提供Adhoc即时分析，帮助分析师快速分析业务、快速定位问题、快速反馈。
计算存储
业务数据产品也可以充分利用平台的计算存储资源打造数据产品，如推荐、智能营销等等。
效率
提升数据处理效率，从而节约数据挖掘/处理的时间成本。
大部分公司早期人员架构如下图：
运营、营销以及决策层直接使用平台，大部分就是直接查看BI报表。业务分析师梳理完业务需求会把需求提供给数据仓库工程师，然后专业的数据仓库工程师会把新的需求加入已存在的公司级别的数据仓库之中。数据工程团队主要负责运维集群。
1.3 初期架构的缺点初期为什么是这样的架构这里就不做过多描述了，我们直接说一下它的缺点。
当决策层使用报表时发现总是慢了一拍，总会有新的需求出来。原因很简单：其实互联网公司的业务并不像传统行业（如银行、保险等）的业务那么稳定，因为互联网公司的发展比较快，业务更新迭代的也很快。
业务分析总有各种临时的需求，原因和1类似。
数据仓库工程师累成狗。数据仓库庞大笨重，很难灵活的运作，总是牵一发而动全身。
集群作业运维困难，作业间耦合性太大，例如：A业务的表a 没跑出来直接影响了整个公司的所有作业。
1.4 常见解决方案相信这些头疼的问题很多公司都遇到过，解决方式应该也是类似的。大体如下：
搭建产品化的数据服务平台。
数据仓库能量转移到更加基础更加底层的数据问题，如数据质量问题、数据使用规范、数据安全问题、模型架构设计等。
业务分析师直接利用平台搭建业务数据集市，提高敏捷性和专用性。
数据工程主要职责不再是运维集群，而是搭建数据服务平台和构建业务数据产品。
这样做的好处是：
解决了数据仓库的瓶颈问题。
让最熟悉自己数据的人自己搭建数据集市，效率更高。
业务数据产品可以直接使用数据服务平台提高效率，缩减公司成本。
