未来数仓：不是简单的HTAP

作为职场“老马”，做过电商运营系统开发、做过BI、目前在做数仓。不同的需求场景，要求研发对“数据”的掌控能力有很大不同。

TP事务处理，侧重数据流转的逻辑要贴合业务逻辑，需要保证业务逻辑的准确稳定表达；

AP分析处理，侧重数据旋转的切割要剖析业务痛点，从数据中找到业务精细化运营的策略；

流转的数据是明细的重分发交互的行数据（比如查询存款记录），旋转的数据是批次的重聚合分析的列数据（比如：城市列分组聚合销售额列，可以分析各城市销售额分布情况）。

2014 年 Gartner 提出的 HTAP 概念，使用 In-Memory+列存技术同时处理 TP 和 AP。无非想借助内存处理TP，借助列存技术处理AP。

或者行列混合可以是一种折中格式如PAX，也可以是在同一存储引擎中通过聪明的算法糅合两种形态。但是这种简单的TP+AP的HTAP 却很难等价于TP和AP。

HTAP 也是一种技术框架的创新，在部分场景中有用武之地。HTAP的主要代表有TiDB、OceanBase、CockroachDB等。

AP代表的数据开发，也经历过与TP混合的蜘蛛网开发模式，可以笑称是盘丝洞，慢慢随着数据量激增和hadoop等技术的发展多维建模的数据仓库出现了。

随着互联业务的精细化运营，增量市场转向存量市场，数据反哺业务，慢慢的耦合到业务运营策略出现了数据湖/数据中台。目前比较前卫的云数仓也开始出现在这变化莫测的数据市场。

我想未来的数仓应该是这样的：人人为数仓，数仓为人人。

1，数据存储中心：能够自动化同步多模态的数据，并支持多种数据存储格式（行、列、向量）。

2，元数据中心：消除长链路的数据分层加工，通过对原数据人工打标签、智能识别、安全校验等生产元数据来描述数据实体、业务过程以及实体关系，为数据分析提供知识图谱。

3，云数仓（云计算中心）：数据使用者语言提取数据，AI解析、优化、执行，并辅助人工投票机制保障数据指标的一致性和中肯性。人人负责指标体系的建设、数据质量的维护。计算逻辑在云上，可以快速向数据移动，减少移动数据，提升数据生产效率。数据的生命周期 使用者共同维护。

期待这样的未来数仓早日到来，解放苦力的数据开发劳动，让更多人得闲享受生活。

欢迎-留言-你期待未来数仓是？