群雄并起，诸侯纷争，实时数仓今天的发展现状，像极了“战国时代”。
如果说，战国是齐、楚、燕、韩、赵、魏、秦七国实力比拼;那么，与之类似的实时数仓，是流批一体、湖仓一体、云数仓、HTAP数据库等多种技术路线并存。不同的是，战国是乱世，霸主们为生存而进行了一系列探索与努力，英雄大多以悲剧收场;而实时数仓则恰逢数智化盛世，在追求数据处理速度这条道路上，催生出百家争鸣。
星星之火
所谓 “天下大事合久必分，分久必合”，数据仓库经历30多年的发展后，开始出现分裂，以高吞吐、低延时、全链路实时加工为主要特征的实时数仓，诞生于大数据时代，并以星火燎原之势向互联网、金融、游戏、电商等领域蔓延。
事实上，实时数仓虽然是新提法，但不是一个新需求。PostgreSQL ACE Director、南京基石数据技术有限责任公司CTO 白鳝(徐戟)，在接受IT168&ITPUB 实时数仓系列专访时表示：早在20年前，在设计新一代金融交易系统时，就有人想基于客户画像提供个性化服务，包括可以基于历史数据进行分析，了解用户登录系统时的位置、时间、上网方式等，但那个时候受技术条件限制，无法做实时的指标分析。
那么，30年前的技术条件是什么水平呢?欧冶云商股份有限公司首席数据架构师 薛晓刚 ，则以存储为切入点，说明实时数仓的快速发展，是技术和业务双重推动的结果!
2000年左右，当时是1.44寸软盘。那个年代，硬盘驱动器只有1个G，读取速度也比较慢，只有4.5MB/秒。之后，随着存储技术的进步，出现了U盘，1TB级别的磁盘驱动器，再正常不过，但数据传输速度依然满足不了需求，只有 100 MB/s左右，这意味着用户需要花费半个小时以上的时间，才能读取整个驱动器的数据。
此种背景下，谷歌在2003年发表了三篇论文：分别是《GFS》(大型分布式文件系统)、《MapReduce》(大型集群海量数据处理分布式编程模型)、《BigTable》(结构化数据分布式存储系统)，标准着大数据时代来临。但从硬件角度看，以hadoop为代表的离线分析，还处于磁头寻道的阶段，通过分布式计算可以“变道超车”，改变之前磁盘IO慢的问题。
如今，随着硬件及其相关技术的发展，我们已经跨越GB级磁盘阶段，单盘SSD已经出现几十个TB级别的产品，IO的瓶颈不再那么明显，处理速度已经提升了万倍，数据处理量可以是TB级别，甚至出现了非易失性内存。
当技术条件足够成熟，企业可以在线处理TB或PB级数据，过去那种离线分析模式很明显已跟不上时代。尤其在数字化转型过程中，企业需要对市场做出快速反应，不管是报表分析(实时数据大盘)，还是用户画像(推荐)，都会有时间要求。对于后端支撑的数据仓库来说，在线交易完成后，企业可以马上将这些数据进行分析和处理，结合交易快速得出一些判断，进而辅助业务决策，这便是实时数仓最初诞生的 “摇篮”。
寻求新秩序
问题是，实时数仓到底是什么?是一款产品，还是一个解决方案?实时数仓系列专访调研了诸多专家、用户和服务商!
从梳理结果来看，有人说是一款产品，比如：阿里云提供的Hologres;有人说是一套解决方案，比如：星环科技的ArgoDB+ Slipstream，通过“混合架构+统一计算引擎+统一存储管理”形成了一整套方案。与此同时，还有一个方向，看上去不是纯粹的数仓产品或者解决方案，比如：滴普科技的FastData DLink，是通过“标准分层+流计算+批量计算+数据湖”实现了湖仓一体;另外，有很多企业则通过HTAP数据库这种混合架构，满足实时数仓的业务需求，比如：亚信的AntDB数据库、天云数据的Hubble数据库，走的都是HTAP路线。
除了阿里云，还有腾讯云、金山云等这类云数仓，则通过云原生、存算分离、无服务器的形式，实现了数据实时处理目标。包括很多国产数据库，也已经融合了Flink、Spark这样的计算框架，数据过来以后，可以实现行存和列存的自动转换。
最后一个梯队，传统数仓此刻也不会被“立刻革命”，在没有实际 CDC 功能的场景下，传统数仓一般基于 Kafka 里的流式数据生成 ODS、DWD、DWS 的各层数据，以便于查询实时的数据，同时以小时/天粒度修复ETL数据管道，这种近实时以及准实时数仓解决方案，也可以满足部分用户的需求。
业界有一种说法是，企业IT领域纷繁复杂，概念多到可以超过时尚行业。从实时数仓概念火爆，到真正在企业场景落地，每个人都有自己的看法，短期内无法达成统一。但任何事物的出现，都不是一蹴而就，如果单纯从数仓发展来看，我们可以概括出几个重要阶段。第一，数仓阶段;第二，大数据阶段;第三，大数据和MPP数据库并存的阶段;第四，以 Snowflake为代表的云数仓，近似于实时数仓这样一个概念;第五，Databricks重新定义了湖仓一体的概念，即围绕数仓的能力，打造出全新的实时数仓的状态;第六，流批一体阶段，用户可以基于一套架构解决流和批的场景问题，进而满足复杂业务需求。
整体来看，虽然各家技术路线不同，短期内无法实现统一，但最终目标一致，那就是让企业的数据分析变得更快、更易用。一般来说，实时数仓的数据展示能力都不是T+1天的更新频率，而是T+1秒，其中秒级响应，也不一定就是1秒，3-5秒用户也可以接受。我们还发现，大多数实时数仓都是以解决方案的形式呈现，通过很多自研或者开源技术，打通数据的采集、计算、加工处理等不同环节，进而满足时效性要求。
合纵连横
当实时数仓遍地开花，各条技术路线之间是怎样一种关系呢?虽然这一时期的外在表现是“大分裂”，但绝对不是各自为政，而是相互融合!
随着实时计算技术不断发展，Storm、Flink等实时流计算引擎逐渐发展起来，实时计算框架由原来的流批分离的Lambda架构，发展到流批一体的Kappa架构，且新的架构也在不断涌现。在大数据资深人士 数据一哥 看来，虽然离线大数据架构已不能满足实时需求，逐渐被新一代数据架构取代，但不意味着离线需求也跟着消失，这也是由Flink的火热带出的流批一体架构出现的根本原因。
以快手为例，企业最初也是Lambda架构，拥有成熟的离线计算方案，但缺点是不能满足实时需求，所以另外引入了一条实时链路，这样导致企业需要提供两套计算引擎，一个提供Streaming能力，一个提供Batch能力，不同引擎提供的API不同，需要两套业务开发逻辑，很难保证一致性的计算结果。为了解决Lambda的问题，企业最初通过Bean引入统一的API，但无法解决复杂的流批一体场景。之后，企业引入了Spark，通过批来模拟流，以达到实时计算目标，但无法满足极致的实时计算需求。之后，Flink成为流计算引擎的事实标准，快手进行了大胆尝试，率先在机器学习和数据集成场景引入Flink Streaming，最终实现了计算和存储引擎的统一，通过流批融合提供一致性体验。
同样，湖仓一体、HTAP都是混合架构下的典型模式，包括MPP数据库和云数仓，其实也在相互融合，满足特定场景需求。目前，HTAP已经是很多国产数据库的标配，很多人甚至认为HTAP是解决实时数仓问题的有效手段。至于，是不是真的做到了，我们还需要拭目以待。另外，湖仓一体、云与AI的结合，都是实时数仓走向开放式架构的典型特征，最终谁能具备更快的数据加工能力，在短时间内满足用户的数据消费需求，谁就能赢得市场。
需要重点强调是，诸多技术路线，各有优势，也会有缺点。但既然是实时数仓，首先在线交易就要达成实时，否则和离线相比没有太多优势。其次，要具备统一的存储能力，如果存储问题不解决，最终也会影响数据分析结果。其三，实时数仓考验的是强大的运算处理能力，如何将数据更好地进行运算和处理，是实时数仓落地过程中必须要面对的问题。
最后，针对不同技术路线，不同用户是如何一步步落地的，我们需要结合具体的业务场景进行尝试和探索，为了寻找更多“灯塔”类用户，寻找行业优秀解决方案，IT168&ITPUB搭建了实时数仓选型指南专区(实时数仓选型指南-ITpub)， 最终我们梳理出近十家客户的实践案例，和近二十家服务提供商的解决方案，并且未来还会持续更新，希望能为企业和用户搭建良性互动和沟通平台，以推动实时数仓走向更高阶段。
通过实时数仓变法图强， 2023精彩还在继续，《实时数仓选型指南》将以电子书的形式，推送给更多行业用户，具体内容敬请期待!