具体仓库的分层情况需要结合业务场景、数据场景、系统场景进行综合考虑，常见的分层：
-
ODS：Operational Data Store，操作数据层
在结构上其与源系统的增量或者全量数据基本保持一致。它相当于一个数据准备区，同时又承担着基础数据的记录以及历史变化。其主要作用是把基础数据引入到数仓。
-
CDM：Common Data Model，公共维度模型层，又细分为 DWD 和 DWS
它的主要作用是完成数据加工与整合、建立一致性的维度、构建可复用的面向分析和统计的明细事实表以及汇总公共粒度的指标
- DWD：Data Warehouse Detail，明细数据层
- DWS：Data Warehouse Summary，汇总数据层
-
ADS：Application Data Service，应用数据层
目前，互联网行业大数据的主流存储框架是基于 Hadoop 的分布式文件系统 HDFS。由于其具有高容错性和适合批处理数据的特点适合部署在低廉的 PC 服务器上存储海量的数据，数据存储的性价比较高。
在 HDFS 的基础上，Hadoop 生态又开发了离线数据仓库计算引擎 Hive。Hive 基于 MapReduce 技术支持分布式批处理计算，同时支持以 SQL 操作的方式对存储在 HDFS 上的数据进行“类数据库”的操作、计算和统计分析。Hive 适合海量数据的批处理操作场景操作简单，容错性和扩展性好，缺点是高延迟，查询和计算都比较慢。因此 Hive 被广泛应用在离线计篡场景中，尤其是对海量数据的批处理操作和分析场景中。
因为基于 MapReduce 技术涉及磁盘间高频的 I/O 操作，所以 Hive 的计算效率较低，时效很长。为了提高计算的效率，Hive 社区增加了新的计算引擎，即 Spark 。与 MapReduce 相比，Spark 的 RDD 计算引擎基于内存进行计算，计算和查询效率显著提升。
目前，主流的离线计算框架采用 Hive 和 Spark 结合的方式。在 100 个节点以下时，可以选用 Hive 作为数据仓库、Spark作为计算引擎。另外，对于海量数据场景（如节点数需要几百个甚至上千个时)，Hive 的优势是稳定性和容错性好，可以用于处理海量数据的复杂计算。Spark 的优势是计算速度快，缺点是容易出现内存泄漏和不足，从而导致计算缓慢或者任务失败。在海量数据场景中，出于稳定的要求，Spark 一般用于处理数据仓库上层的查询、计算和分析操作。而底层的操作由 Hive 完成。笔者重点推荐使用 Hive 和 Spark工具。
开源的实时计算框架比较多，如 Spark、Storm 和 Flink 等。与 Storm 相比，Spark 的优势是用一个统一的框架和引擎支持批处理、流计算、查询、机器学习等功能 。由于 Spark 的微批处理的设计机制，在处理流数据的时候，效率比 Storm 要低 。
Flink 比 Spark 诞生得晚，因此有很多新的设计思路和特色，如数据流模型、反压机制、内存自管理、异步节点检查机制和有状态处理机制等。Flink 和 Spark 一样，也提供查询、机器学习、图计算等功能，但是 Spark 在 SQL 语句丰富程度、 API 功能完备和简单易用方面比 Flink 更优秀。而 Flink 在数据流的实时处理能力、界面设计和操作友好性、平台化管理、任务分析能力等方面要优于 Spark。
**整体而言，Spark 体系更加成熟，易用性较好、社区文档和案例更加丰富，**如果对于数据延迟要求是秒级，那么 Spark 更容易上手且能满足性能要求。**Flink 是后起之秀，特别是 Flink 1.10 之后的版本，强化流批一体数据仓库，高度兼容 Hive，其实时处理能力和设计理念要优于 Spark，成为实时数据仓库计算引擎的热门选择。**因此笔者重点推荐使用 Spark 和 Flink 工具 。
为了提高数据交互性查询的效率，在大数据时代根据不同的业务要求诞生了很多新的查询引擎，常见的查询引擎有 HBase、Redis、MongoDB 等。按照大类划分，查询引擎可以分为 SQL 交互式查询引擎和 NoSQL 交互式查询引擎。HBase、Redis、MongoDB 都属于 NoSQL 交互式查询引擎。
常用的 SQL 交互式查询引擎有 Impala、Presto、ClickHouse、Kylin 等。Impala 和 Presto 基于 MPP 架构，通过分布式查询引擎提高查询效率。ClickHouse、Kylin 是目前主流的联机分析处理（Online Analytical Processing，OLAP） 计算和查询引擎。
Kylin 通过预计算机制，提前将客户经常查询的维度和指标设计好并进行预处理操作，以数据立方体模型（Cube）形式缓存，以便加快聚合操作和查询的速度，特别适合对海量数据的 OLAP 场景。由于需要提前将数据预处理好，Kylin 需要消耗额外的空间，且无法高效支持随机的计算和查询。
ClickHouse 适合海量数据的大宽表(维度和指标较多的表）的灵活和随机的查询、过滤和聚合计算，写入和查询性能很好，而多表关联操作性能一般，尤其是多个数据量较大的表（即大表）关联的情况。其劣势是不擅长高频的修改和删除操作，在多用户高并发场景中性能一般。
Presto 由 Facebook 开源，支持基于内存的并行计算，支持多个外部数据源和跨数据源的级联查询，在对单表的简单查询和多表关联方面性能较好，擅长进行实时的数据分析。在处理海量数据时，Presto 对内存容量要求高，多个大表关联容易出现内存溢出。
Impala 由 Cloudera 推出，是一个 SQL on Hadoop 的查询工具，也基于内存进行并行计算，目标是提供 HDFS、HBase 数据源复杂的高性能交互式查询。Impala 的单表和多表关联查询性能和 Presto 相近，支持窗口函数、增量统计、多用户高并发查询，但是数据源的丰富程度不如Presto。Impala 对内存容量要求高，多个大表关联容易出现内存不足。
目前，ClickHouse 和 Kylin 的热度很高，很多“互联网大厂”都开始采用这两个计算和查询框架作为 OLAP 的主流框架。一般而言，预先设计好维度和指标，然后进行聚合计算和查询的场景适合使用Kylin，而对于随机（ad_hoc）查询更适合使用 ClickHouse。
在实际应用中，根据不同的应用场景，一般会部署多种引擎，比如 ClickHouse 和 Kylin 。
HBase 是基于 key-value 原理的列式查询引擎，适用于频繁进行插入操作且查询字段较多的场景，如统计每分钟每个商品的点击次数、收藏次数、购买次数等。HBase 的列式扩展能力较强，理论上硬盘有多大，HBase 的存储能力就有多大。HBase 不适用于大量更改了(update)操作的场景。HBase 的主要缺点是 update 操作性能较低。
Redis 是内存数据库。Redis 的原理是基于内存进行计算和查询。Redis 的存储容量与内存容量有关，支持的数据类型比较丰富，有一定的持久话能力，适用于高频 update 操作的场景，读写的速度都非常快。其缺点是内存容量有限，价格较高，一般用于存储非常有价值且需要高频读写的数据。比如，实时统计全站客户累计点击次数、收藏次数、购买次数等用于数据看板（dashboard）的展示。
MongoDB 主要以 JSON 数据串格式存储数据，适用于表结构变化大的海量数据查询和聚合计算的场景，这是其区别于其他数据库的重要特色。比如，构建客户大宽表，客户的有关字段经常发生改变或增删，在这种场景中很适合用 MongoDB 存储并高效读取客户的单一维度信息或聚合信息。但是其写入操作和多表关联复杂操作性能一般，很少用于复杂的多表关联的计算场景。在实际应用中，一般会综合部署上述 NoSQL 引擎，满足不同的应用场景。
开源的数据采集工具很多，如 Sqoop、Data X、Scrapy、Flume、Logstash 和 StreamSets 等。Sqoop 和 DataX 主要用于采集结构化数据，Flume 和 Logstash 主要用于采集非结构化数据。StreamSets 同时支持结构化和非结构化数据的采集。
在结构化数据采集方面，与 DataX 相比，Sqoop 的综合性能更好，社区更活跃，插件更丰富，使用更广泛。
Logstash 更轻量，使用更简单，插件丰富，对技术要求不高，运维比较简单。Flume 框架更复杂，偏重于数据传输过程中的安全，不会出现丢包的情况，整体配置更复杂，入门难度较高，运维难度更高。StreamSets 通过可视化界面的拖、拽等操作实现数据的采集和传输，支持多种数据源，组件丰富，功能强大，简单易用，且内置监控组件，可以实时监控数据传输情况。由于 StreamSets 的这些优势，目前它在数据采集领域大有一统江湖的趋势。笔者重点推荐使用 StreamSets。
有时候还需要从第三方平台获取一些公共数据，数据爬虫工具 Scrapy 可以支持从网上爬取数据。
在数据平台选择好后，下一步的重要工作是实现企业的数据资产化，满足前端业务对数据应用的需求。数据资产化的关键举措是对企业的原始数据进行清洗和规整，将其转化为价值数据，然后从中抽离出主数据，进一步构建不同主题的数据标签体系。这些关键举措离不开数据仓库的标准化、存储、计算和建模体系化的支撑。
目前，主流的数据仓库分为离线数据仓库和实时数据仓库，两者的典型区别是数据服务时间粒度。传统的离线数据仓库一般的数据服务时间粒度是天，实时数据仓库的数据服务时间粒度是分钟，甚至秒。从数据仓库存储和计算框架开源解决方案来看，目前行业的离线数据仓库普遍采用 Hive + Spark 的综合方案，而实时数据仓库当前的主流方案之一是 HDFS + Flink + Kafka 。目前，大部分企业在建设数据仓库时，综合考量性能、健壮性、投入产出比和运维复杂度，主要策略是以离线数据仓库的批处理计算为主，以实时数据仓库为辅助。
数据分析是实现数据价值的关键举措之一。透过错综复杂的数据关系发现价值点是一项费力、费时的工作。好的工具能够使这项工作事半功倍。为了提高数据分析的效率，行业涌现了多种解决方案，集中体现在自助取数、自助分析、多维分析、分析可视化这几个方面，目标是实现可视化自助数据分析。可视化自助数据分析的核心功能是支持多数据源接入、权限管理、高性能计算和可视化多维分析。
日前，自助 OLAP 开源主要使用的计算引擎有 Impala、 Presto、ClickHouse 和 Kylin。在查询引擎部分，已经介绍过这几种计算引擎的特点，在此不再赘述。开源可视化解决方案主要有 Superset、 Redash 和 Metabasea。Superset 出自 Airbnp，目前是 Apache 的开源项目，功能比较强大，网上的参考案例较多。Redash 是一个轻量级的应用，部署简单，短小精悍，能满足日常分析需求。Metabase 的功能丰富程度介于 Superset 和 Redash 之间，网上的参考案例较少。在实际应用中，笔者重点推荐 ClickHouse+Kylin+Superset的统一解决方案。预计算的 OLAP 使用 Kylin 引擎，及时查询的计算使用 ClickHouse。
规则引擎是常用的实现数据价值的基础工具之一，常用的应用场景有风险管理、动态定价、精准营销、监控预警等。笔者过去一直使用开源工具 Drools 结合二次开发搭建规则引擎，其优点是语法规则简单、支持动态规则配置、社区热度高、网上落地案例丰富、功能丰富且不断升级迭代，缺点是相对较重、应用门槛较高、聚合计算效率低等。对于实时规则应用场景，建议使用流式计算引擎计算复杂的聚合规则，而简单的规则计算使用 Drools 内核。
要从错综复杂的数据中挖掘出核心价值离不开算法的支持。智能化的真谛是使用机器学习算法、AI算法和其他算法不同程度地实现用机器替代人工。目前，各种开源的算法包特别多，当建模数据行数在千万级别时，笔者常用 Anaconda 包和XGBoost 包。当建模数据行数在亿级别时，笔者常用 Spark MLlib。笔者使用的AI算法框架是 TensorFlow。在自然语言处理方面，笔者常用的是百度的 ERNIE 框架，该框架在多个公开中文数据集下的性能比 Google 的 BERT 框架略好。
笔者一直使用的元数据管理的开源工具是 Apache Atlas 。Atlas 和 Hadoop 无缝连接，能有效地支持元数据管理、数据资产分类、元数据搜索、血缘关系可视化和数据治理。
Atlas 支持对元数据添加标签，然后通过标签对数据资产进行分门别类的管理，并基于标签进行统一权限控制和数据资产的安全管理。同时，Atlas 还可以捕获各种元数据信息（如数据的产生、表的建立和执行、数据交互、数据ETL执行、数据存储、数据安全访问、数据的使用等），并支持查看元数据和血缘的可视化，便于及时发现数据的变化，快速定位数据问题。数据具有时效性，Atlas 支持数据全生命周期管理（如在过了数据时效后，临时表被自动删除)。
Atlas 还支持和多个外部平台（如Hive、SAS 等）的元数据互联互通。我们可以将这些平台的元数据导入 Atlas 中，然后应用 Atlas 进行无数据管理和数据治理。
目前，数据应用百花齐放，系统后台需要对这些数据应用的工作流进行合理调度和监控，确保数据应用的及时性和稳定性。当任务运行失败时，系统要能及时发现并实时通知相关数据运维人员。这些功能是对工作流调度和监控工具的基本要求。
**目前，行业常用的开源工作流调度和监控工具主要是 Oozie 和 Azkaban。**笔者一直使用 Azkaban。两者的工作原理的最大区别是前者的工作流运行靠捕捉和监控更加细粒度的 MapReduce 批处理任务执行级别信息，而后者的工作流运行仅仅靠捕提和监控较粗粒度的操作进程级别的信息。这会导致在任务出现失败或者断电后，Azkaban 需要重新执行工作流，而Oozie 可以基于失败的工作流重新执行。不过 Azkaban 的这个功能可以通过二次开发进行优化。Azkaban 的优势是有完善的权限、控制、支持对工作流的读写进行权限控制。
整体而言，Oozie 的功能更加丰富，比如支持 Web、Rest API、Java API 操作工作流，支持工作流的状态持久化存储、基于时间的定时任务调度及丰富的数据源等，但是其配置更复杂，开放性较弱，二次开发难度高，使用门槛更高。Azkaban是一个轻量级的应用，聚焦批量工作量的调度和监控，简单易用，更开放，支持二次开发。