从“摆渡人“到“造桥者“，Doris湖和仓的牵手历程

还记得小时候看《西游记》，唐僧师徒遇到一条大河，八戒嫌弃：“师傅，这河又宽又深，没桥咋过啊？” 结果悟空一个筋斗云就把师徒四人送到了对岸。
数据世界也遇到过类似的难题 —— 数据湖和数据仓库好比两岸，数据工程师们每天都在为数据"过河"发愁。
有人选择慢慢"蹚水"，有人尝试"造桥"，但总觉得不够完美。
直到有一天，“数据界的孙悟空"带着法宝出现了，经过’七七四十九天’化解了这个令人头疼的难题。
今天，一起来看看从"摆渡人"到"造桥者” —— Doris湖和仓的牵手历程。

数据世界的湖仓"双城记"

清晨,小明一如既往打开电脑准备处理分析任务。突然,产品经理急匆匆跑来:

“能马上给我一份近三年用户行为分析报告吗?营销部门需要做新活动决策。”

小明心里"咯噔"一下 —— 近三年的数据分散在数据仓库和数据湖里,这下有得忙了…

这样的场景想必让很多数据工程师倍感熟悉。

数据此时好比城市里的居民,有的住在整齐规划的现代化数据仓库小区,有的散落在错综复杂的数据湖城中村。两边人口越来越多,通勤越来越难,数据工程师们每天都在当"摆渡人"：

湖仓一体之前，数据分析经历了数据库、数据仓库和数据湖分析三个时代。

• 首先是数据库，它是一个最基础的概念，主要负责联机事务处理，也提供基本的数据分析能力。

• 随着数据量的增长，出现了数据仓库，它存储的是经过清洗、加工以及建模后的高价值的数据，供业务人员进行数据分析。

• 数据湖的出现，主要是为了去满足企业对原始数据的存储、管理和再加工的需求。这里的需求主要包括两部分，首先要有一个低成本的存储，用于存储结构化、半结构化，甚至非结构化的数据；另外，就是希望有一套包括数据处理、数据管理以及数据治理在内的一体化解决方案。

数据仓库解决了数据快速分析的需求，数据湖解决了数据的存储和管理的需求，而湖仓一体要解决的就是如何让数据能够在数据湖和数据仓库之间进行无缝的集成和自由的流转，从而帮助用户直接利用数据仓库的能力来解决数据湖中的数据分析问题，同时又能充分利用数据湖的数据管理能力来提升数据的价值。

Apache Doris看不下去了:“让我来修一座两城之间的高架桥吧!”

-- 使用示例,简单高效的高架桥
CREATE CATALOG hive PROPERTIES (
    'type'='hms',
    'hive.metastore.uris' = 'thrift://172.21.0.1:7004'
);

于是,Doris湖仓一体架构应运而生。这不是简单地用水泥把两座城市连接起来,而是建立了一套智能化的立体交通网络。

Doris湖仓一体的"黑科技"解密

记得前几天一位数据工程师开玩笑说:“以前处理数据就像是在古代赶路,现在用上Doris的湖仓一体,感觉直接坐上了高铁。” 确实,这套系统里藏着不少有趣的技术"黑科技"。

Multi-Catalog: 数据世界的"共享办公区"

说到这里,可能有人会问:“这么多数据源,管理起来不是很复杂吗?”

不用担心,Doris的Multi-Catalog功能就像现代化的"共享办公区"。不管你是传统企业(传统数据库)、新兴互联网公司(Hadoop)还是高科技创业团队(Paimon…),通过简单注册就能入驻办公。

小明现在终于不用在多个系统间频繁切换了。早上查询Hive的历史数据,中午分析MySQL的实时订单,下午统计数据湖的用户行为,并且可以高效的读取存放在 HDFS、对象存储上的 Parquet、ORC、Text 格式数据。也可以通过 JniConnector 对接 Java 大数据生态，只需要一个平台就搞定。相当于带着一张"万能门禁卡",畅通无阻。

更妙的是,Multi-Catalog还内置了智能权限管理系统。好比高级写字楼的门禁系统,既要保证入驻企业能自由活动,又要防止串门闲逛,让数据访问既灵活又安全。

高速缓存:数据的"超级记忆术"

别看缓存技术名字朴实无华,实际上是Doris湖仓一体最厉害的"记忆大师"。除了常见的元数据缓存，它的"过目不忘"能力分三个层次:

热点数据缓存就像你的短期记忆,把最常用的数据放在"大脑"里随时调用。通过一致性哈希将数据分布在各个脑神经上,并且会及时淘汰缓存以保障数据的一致性。

查询结果缓存更是独具匠心,相当于给系统配备了"最强大脑"。当看到相同的查询请求时,直接返回之前的计算结果,就像老师问同一个问题,学霸立刻就能答出来一样。

分区缓存则是建立了专门的"记忆宫殿"。比如分析最近7天的订单数据,系统会巧妙地把前6天的计算结果缓存起来,只需要处理当天的新数据。这不就是复习考试,把已经背熟的知识放一边,专注在新内容上了！

Native Reader: 数据阅读的"透视眼"

Native Reader技术堪称是Doris湖仓的"火眼金睛"。它不仅能直接读取各种格式的数据,会使用"透视"技能,还能够向量化读取数据：同时在文件数据的读取过程中我们引入向量化的方式读取数据，极大加速了数据读取效率。

一个典型场景:假设你要在1000万用户中找出注册时间是2023年的北京用户。普通系统可能会傻傻地把所有数据都读一遍,而Native Reader会先"透视"出注册时间和城市这两列,快速过滤掉不符合条件的数据,大大减少处理量。

这让我想起朋友圈里的一个段子:“其他人找东西像是大海捞针,Native Reader找东西像是用磁铁捞针。” 这个比喻非常形象。

Merge IO：数据里的"大型停车场"

Merge IO好比解决了周末去商场停车的烦恼，毕竟那一个个小车位找起来特别费时。

Doris看到数据世界也有类似困扰 —— 太多小文件导致读取效率低。于是灵机一动:建立"大型停车场",把分散的"小车位"(小文件)集中管理。这一招对付"碎片化"存储特别有效。

比如我们设置一个策略将小于 3MB 的 IO 请求合并（Merge IO）在一次请求中处理。那么之前可能是有 8 次的小的 IO 请求，我们可以把 8 次合并成 5 次 IO 请求去去读取数据。这样减少了网络 IO 请求的速度，提高了网络访问数据的效率。

Merge IO 的确定是它可能会读取一些不必要的数据，因为它把中间可能不必要读取的数据合并起来一块读过来了。但是从整体的吞吐上来讲其性能有很大的提高，在碎文件（比如：1KB - 1MB）较多的场景优化效果很明显。同时我们通过控制 Merge IO 的大小来达到整体的平衡。

统计信息优化:数据的"最强大脑"

统计信息优化就像给查询引擎装上了"AI大脑"。它会收集数据分布特征,为查询优化提供决策支持。这一个经验丰富的导航系统,不仅知道所有的路线,还能根据实时路况选择最优路径。

一个实际案例:某金融公司的风控系统需要从海量交易记录中筛选可疑交易。传统方法可能需要扫描所有记录,而有了统计信息优化,系统能迅速定位到高风险区间的数据,把查询时间从分钟级降到秒级。

这种优化还支持采样功能,就好比医生看病不需要化验全身的血液,只需要抽取一管血样本就能得出结论。大大降低了系统负担,同时保证了分析的准确性。

Doris湖仓一体的实践小记

记得上周参加一个技术分享会,一位架构师打趣说:“以前我们像是在管理两个互不相往来的数据’部落’,现在用了Doris湖仓一体,感觉是把这两个’部落’都搬进了同一个智慧城市。”

从"双城记"到"一体城"

某互联网电商平台最近完成了一次精彩的技术改造。他们面临一个典型难题:历史订单数据存储在数据湖,实时交易数据在数据仓库,每次做全链路分析都要"两头跑"。

采用Doris湖仓一体后,他们只用了3天就完成了数据整合。原来需要4个小时的跨时间段订单分析,现在只要5分钟就能搞定。产品经理开玩笑说:“感觉像是把时光机和超级高铁结合在一起了。”

数据分析的"急诊室"

在金融风控领域,湖仓一体展现出惊人威力。某支付平台需要同时分析实时交易行为和历史交易模式,传统架构下经常被延迟困扰。

现在他们把Doris的Multi-Catalog功能用得炉火纯青。实时数据走Internal Catalog快速处理,历史数据通过External Catalog无缝关联。一位风控工程师形容:“这不就是给系统装了个’透视镜’,随时能看到用户的’前世今生’。”

数据湖的"智能管家"

最有意思的是在广告技术领域的应用。某广告平台每天要处理海量的用户行为数据,同时还要实时响应广告投放请求。

他们巧妙地运用了Doris的缓存策略和Native Reader技术。把热门广告数据放在缓存中快速响应,冷门数据则通过智能读取按需加载,效果也是相当惊艳。

广告团队的同学笑称:“感觉给数据装上了’顺风耳’和’千里眼’,想要什么数据,立马就能找到。”

…

写在最后

数据世界的进化永无止境。湖仓一体架构如似数据世界的"进化咒语",让数据仓库和数据湖的优势完美融合。正如一位资深工程师所说:“这不仅是技术的进步,更是思维方式的革新。”

下一站,也许就是你的数据架构升级之旅。期待在不久的将来,听到更多关于你们在数据世界中湖仓探索的精彩故事。

最后分享一句在技术圈流传的话:“工具千万种,选择最重要。今天不解决的问题,明天可能就会变成更大的麻烦。让数据’自由’流动起来,才能释放它的全部价值。”

下期，我们将一起探讨其它更有趣有用有价值的内容，敬请期待！