目录
数据库 VS 数据仓库
数据库是面向事务的设计，数据库一般存储在线交易数据， 数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据库是为捕获数据而设计。
数据仓库是面向主题设计的， 数据仓库存储的一般是历史数据，数据仓库在设计是有意引入冗余，采用反范式的方式来设计，数据仓库是为分析数据而设计。
实时数仓的需求与发展
当前各大公司的产品需求和内部决策对于数据实时性的要求越来越迫切,需要实时数仓的能力来赋能。传统离线数仓的数据时效性是 T+1,调度频率以天为单位，无法支撑实时场景的数据需求。即使能将调度频率设置成小时，也只能解决部分时效性要求不高的场景，对于实效性要求很高的场景还是无法优雅的支撑。因此实时使用数据的问题必须得到有效解决。
实时计算框架已经经历了三代发展，分别是: Storm、SparkStreaming、Flink，计算框架越来越成熟。一方面，实时任务的开发已经可以线上完成，在技术层面能很好地继承离线数仓的架构设计；另一方面，开发平台所提供的功能对实时任务开发、调试、运维的支持也日渐趋于成熟，开发成本逐步降低，有助于去做这件事。|
实时数仓的优势
通常，数仓都是希望从业务上线的第一天开始有数据，然后一直记录到现在。但实时流处理技术，又是强调当前处理状态的一个技术,结合当前一线大厂的建设经验和滴滴在该领域的建设现状，我们尝试把公司内实时数仓建设的目的定位为，以数仓建设理论和实时技术，解决由于当前离线数仓数据时效性低解决不了的问题。
而实时数仓则有以下几点：
1、公司业务对于数据的实时性越来越迫切,需要有实时数据来辅助完成决策；
2、实时数据建设没有规范，数据可用性较差，无法形成数仓体系，资源大量浪费;
3、数据平台工具对整体实时开发的支持也日渐趋于成熟，开发成本降低。
实时数仓可以应用于：
- 实时OLAP分析;
- 实时数据看板;
- 实时业务监控;
- 实时数据接口服务。
滴滴打车实时数仓建设
滴滴数据团队建设的实时数仓,基本满足了业务方在实时侧的各类业务需求，初步建立起顺风车实时数仓，完成了整体数据分层，包含明细数据和汇总数据，统一了DWD层，降低了大数据资源消耗，提高了数据复用性，可对外输出丰富的数据服务。
数据架构如下图：
从数据架构图来看，顺风车实时数仓和对应的离线数仓有很多类似的地方。例如分层结构;比如 ODS 层，明细层，汇总层，乃至应用层，他们命名的模式可能都是一样的。但仔细比较不难发现，两者有很多区别:
- 实时数仓的层次更少，从目前建设离线数仓的经验来看，数仓的数据明细层内容会非常丰富，处理明细数据外一般还会包含轻度汇总层的概念﹐另外离线数仓中应用层数据在数仓内部，但实时数仓中，app应用层数据已经落入应用系统的存储介质中，可以把该层与数仓的表分离;
- 数据源存储不同，在建设离线数仓的时候，目前滴滴内部整个离线数仓都是建立在 Hive表之上。但是，在建设实时数仓的时候，同一份表，会使用不同的方式进行存储。比如常见的情况下，明细数据或者汇总数据都会存在 Kafka 里面，但是像城市、渠道等维度信息需要借助Hbase，mysql或者其他KV存储等数据库来进行存储。
数据湖概念
数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。
数据湖 VS 数据仓库
使用数据湖无疑能够在更短的时间内从更多来源利用更多数据，并使用户能够以不同方式协同处理和分析数据，从而做出更好、更快的决策。
但是，对于使数据可用的数据湖，它需要有定义的机制来编目和保护数据。没有这些元素，就无法找到或信任数据，从而导致“数据沼泽”的出现。 满足更广泛受众的需求需要数据湖具有管理、语义一致性和访问控制。
由于Iceberg本身是将数据文件全部存储在 HDFS 上的，HDFS读写这块对于秒级分析的场景，还是不能够完全满足我们的需求，所以接下去我们会在 Iceberg底层支持 Alluxio这样一个缓存，借助于缓存的能力可以实现数据湖的加速。这块的架构也在未来的一个规划和建设中。