社区人物志｜张家锋：一个人可能走得更快，但一群人会走得更远

最新推荐文章于 2024-11-12 17:21:52 发布

ApacheDoris

最新推荐文章于 2024-11-12 17:21:52 发布

阅读量498

点赞数

文章标签：运维大数据编程语言数据库 python

本文链接：https://blog.csdn.net/ucanuup_/article/details/119142282

版权

「社区人物志」是 Apache Doris 社区推出的系列专栏，我们关注每一个对 Doris 做出过贡献的 Contributor ，会定期从对 Doris 做出突出贡献的小伙伴中选出一位「社区之星」，并会对「社区之星」进行专访，希望 TA 与 Doris 的故事可以被大家听见，也希望有更多的小伙伴参与到社区建设中来。

本期我们采访了蜀海供应链大数据团队负责人张家锋，来听听一个纯粹的技术人的开源经历与技术思考。

关于自己

Q：请先简单介绍一下自己过往的技术经历？

大家好我是张家锋，目前在海底捞旗下蜀海供应链带整个公司大数据团队，主要负责整个公司大数据平台及数据中台建设，同时负责公司数据分析团队。

自从 2003 年毕业进入软件行业以后，从一开始的 OA 办公系统、企业 ERP 、电子政务、移动增值业务、安卓手机 OS ，到 2011 年进入大数据领域从事大数据相关开发，期间做过移动运营商的大数据平台（信令分析及数据共享），再后来做过金融行业的大数据平台，在 2015 年开始做 B2B 供应链及零售行业的大数据相关数据分析，一直到现在。

从 2011 年开始，关注的技术领域主要是大数据相关，包括 Hadoop 生态体系的技术研究及架构设计，期间也因为项目需要研究过智能补货（机器学习）及图像识别（货架商品识别）。

Q：除了以上方向以外，还在关注哪些技术方向或领域呢？

平时除了大数据相关最新技术的跟踪及研究之外，我还一直关注数据挖掘、数据分析、机器学习方向，以及微服务、 K8s 等。

关于 Doris

Q：您是如何了解到 Doris 的？

最早知道 Doris 其实挺早的了，那个时候叫 Palo ，在 Github 上只是百度的一个开源项目，并没有引起我的注意。后来在 2020 年初，当时是为了解决在海量数据上实时高并发查询的问题，当时的技术架构满足不了需求，也调研和测试了很多框架。在使用 Doris 之前我们公司的架构和其他公司的架构基本差不多，Hadoop、Hive、Spark、Presto，但是这些都满足不了我的需求，在调研 Clickhouse 的时候，发现了 Doris ，看网上介绍性能、并发性及易用性上都非常好。在深度做了测试之后给我的是更大的惊喜，我之后就将架构全部转向以 Doris 为核心去构建。

Q：使用 Doris 期间您有没有遇到过什么问题或挑战，是如何解决的呢？

Doris 是一个简单易用、运维简单的分布式 MPP 数据库，但如果使用不当的话也会认为这个框架没有大家说的那么好，我在开始使用中也遇到了一些问题，说出来和大家分享。

合理设计你的数据分区及分桶。设计数据表的时候，在分区、分桶的设计上，要充分考虑你的数据量大小，单个 Tablet 的大小建议在 1G - 10G 的范围内。如果单个 Tablet 数据量过小，则数据的聚合效果不佳，且元数据管理压力大。如果 Tablet 数据量过大，则不利于副本的迁移、补齐，且会增加 Schema Change 或者 Rollup 操作失败重试的代价，我们开始设计的分区分桶太多，导致 Tablet 数量非常多，达到了 80 多万，经常创建一张表要几十秒甚至分钟级别，后来发现是我们分区分桶不合理，重新调整分区分桶、把历史数据压缩到 5000 个 Tablet 之后，一切问题解决。
我们使用的是 Stream Load 入库，因为这种方式其实是 HTTP 方式，这种方式入库很多小伙伴都是通过连接 FE 进行。如果你的数据量很大，操作很频繁，建议直接和 BE 通讯，避免 FE 的压力，同时这种方式我们建议采用微批的方式，不要一条条的入库，这样会造成 BE 频繁的 Compaction ，给 BE 造成很大的压力。
如果你单库数据导入任务很多，不建议采用 Routine Load 方式。因为 Doris 为了避免过高的并发数可能导致系统负载过大，对同一个 DB 的并发导入任务数做了限制，最多 100 个任务。如果超过这个任务数，就会进入等待重试，甚至可能失败。

Q：除了遇到的问题以外，还有没有一些有趣的案例或故事可以分享呢？

在 0.14.7 版本刚发布的时候，我们立马就上了这个新版本，但是每隔三四天就会出现 Stream Load failed to call frontend service 异常，同时也影响到 JDBC 连接，只能重启。最后和社区一起排查，是因为 Load 任务太多， Doris 元数据写锁占用时间太长，通过修改 label_keep_max_second 将默认的三天改成 12 小时解决了问题。这个参数主要是用来删除已完成或者取消的 Load 作业标签。在高并发写的情况下，如果出现大量作业积压，出现 call frontend service failed 的情况，查看日志如果是元数据写占用锁的时间太长，可以将这个值调成 12 小时，或者更小 6 小时。

另外就是在 0.13.12 版本， FE 出现问题（包括升级）重启失败，同时会导致其他 FE 宕机的情况，最后发现这个其实是 Doris 当时版本的一个 Bug ，后来在 0.14.7 版本没有再出现，具体这个问题可以参照我的博客：https://my.oschina.net/hf20012/blog/4923055

还有就是我们在使用 Doris上的一些经验和方式，比如零代码入仓、API接口零代码开发、元数据管理及血缘关系自动化生成等，这些大家可以参考之前的文章：【应用实践】Apache Doris 在蜀海供应链的实践

Q：您认为 Doris 有哪些做得比较好的地方？有哪些方面还需要继续优化？

天下武功唯快不破，大数据快是永恒的主题，这方面一直都是 Doris 的优势，也是我选择 Doris 最主要的原因。
Doris 的简单易用，完全兼容 MySQL 协议，大大减低了大数据的使用门槛。
社区在做的向量化引擎是我非常期待的，性能会有 5 倍左右的提升。
自动化安装部署监控及运维，这个是 Doris 需要改进的，我也在和社区沟通，计划和社区一块去开发这样一个工具，降低 Doris 的安装部署及运维门槛。

参与社区

Q：是什么样的契机，让您开始向 Doris 提交 PR 及贡献代码呢？

从 2011 年开始使用 Hadoop 开始，其实一直在使用开源项目，也会基于开源项目针对自己的业务场景做一些修改，包括一些 Bug 的修改，但是那个时候不了解开源，也没有给开源做过共享或提交过 PR 。在开始使用 Doris 的时候我是被 Doris 惊艳到了，而且社区的开发人员真的很 open ，一开始使用的时候遇到困难，社区人员积极帮我解决问题，当时我就想我要参与进去。最开始贡献的代码是感觉 Doris 的 Web UI 太丑了，想先把这个给改进一下。在改进的过程中，发现 HTTP 这块是基于 Netty，页面都是写死在程序里的，很难做到前后端分离，这时候和社区的陈明雨讨论，想把这块使用 SpringBoot 进行重构，接口全部改成 Rest 方式，做到前后端分离，方便后面的扩展及其他小伙伴有定制的需求，这个想法也很快得到了社区的支持，最终我完成了这块的重构及改造，提交给社区并被社区采用。

后面我就不断地参与到社区中，包括我的团队提交 Flink Doris Connector 、 Bug修改、帮助社区完善文档、在社区群里解答一些小伙伴的问题等。

Q：在参与社区建设的过程中，您有什么样的收获？

通过为开源项目做出贡献，最终与其他志趣相投的人进行协作，很多人的深厚友谊都是通过共同参与开源项目所建立起来的。开源项目一般都会有一个和谐、热心的社区，在社区里我们可以不断提升技能，大家会把自己的工作成功和经验分享出来，这样大家就不再花费时间去探索相同的问题，大大降低重复劳动的现象，最后你可在社区中不断提升能力，并树立信心。

帮助他人解决问题也是一种乐趣，在一次成功 PR 过程后，或许会暗喜很久，毕竟大型的开源项目里都是大型团队，他们在认可你做出的努力，对编程人员或设计人员的鼓舞或者说精神支柱，就是他们设计的软件受欢迎，那是一种难以言喻的体验，在提升技能同时也能从帮助他人树立自信心。

Q：后续会更关注或计划参与哪些方面的 Issue 呢？

我和社区在 Doris Manager 上做了一些沟通，特别是 Doris 一键自动化安装部署、运维监控等，我希望我的团队和社区一起去完成，给大家提供一个非常友好的 Doris Manager 可视化运维工具。

向量化引擎是我非常期待的，相信向量化引擎将会给 Doris 带来质的飞跃。

Q：对于 Doris 社区的建设，您有什么样的建议呢？

定期举办一些线上或者线下的 Meetup ，通过技术及案例分享，让大家更多的了解 Doris 以及怎么使用 Doris 。
在官网专门添加一个专栏「应用实践」，将业界优秀的使用案例分享出来，方便大家查阅。
打造 Doris 生态圈，现在 Doris 已经通过扩展和其他方式支持了 Kafka / Spark / Flink / ES 等，对于一些新的技术框架比如 Pulsar 等，也要通过扩展或者内置的方式支持起来。
可以通过和一些技术社区合作，通过举办一些活动，鼓励在校学生积极参与开源软件的开发维护，培养社区后继力量，促进社区的蓬勃发展。

展望未来

Q：您如何看待OLAP引擎未来的技术趋势呢？

实时分析：传统的 OLAP 需要做各种 Pipeline 、 ETL导入数据，这样的架构会存储多份数据，冗余并且一致性不好保证，会引入过多的技术栈和复杂度，也不能满足实时分析，即使 mini-batch 的处理仍然需要最快数分钟。业界的趋势在于赋予 OLAP 高吞吐实时写、提供实时查询能力，例如上游数据源经过流计算系统，老的架构基于 Lambda 写历史数据到存储再清洗，实时数据入一些 NoSQL ，使用方需要做各种数据源 Merge 操作，流行的方式是流计算系统直接写 OLAP ，这样避免了数据孤岛，保证了链路简单。

HTAP ：事务处理和分析处理在一个数据库中提供，是最理想的状态，但是二者的技术体系往往又很难融合，因此现在很多数据库厂商都在做这方面的尝试，保证数据一致性是很大的挑战，一种思路是从 OLTP 到 OLAP ，多副本存储时有些副本是专门为 OLAP 定制的，使用专用的 OLAP 引擎提供查询，另外就是赋予 ACID 和事务能力到 OLAP 系统中，使得 OLAP 也支持 INSERT / DELETE / UPDATE 操作。
云原生：传统的 OLAP，例如 Exadata 等依赖于高端硬件，很多 On-Premise 的解决方案也面临扩展性和成本问题，云原生的架构通过虚拟化技术，可实现更好的弹性计算，如果采用存储计算分离的架构还可以实现弹性存储，这些水平扩展的机制可以很好的兼顾高性能、成本和扩展性
多模数据结构分析：不仅限于结构化数据，半结构化、非结构化的数据分析也逐渐在 OLAP 中应用，包括向量检索、 JSON 、ARRAY 检索等。

Q：对于云原生时代，您有什么样的展望呢？

我认为符合云原生架构的应用程序应该是：采用开源堆栈（ K8S + Docker ）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、 DevOps 支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。

Doris 在这方面，其实百度 Palo 云端数仓已经在这样做，只不过我们的业务场景目前还没有这方面需求，一个企业是不是要切换到云原生架构，不过我个人认为理想很丰满，现实经常很骨感，需从应用的实际需要出发，目前的问题是否真的影响到业务发展，而推倒重来的代价能否承受得来，还是根据自己实际的业务需求来选择。

Q：最后有什么话想对社区的小伙伴们说呢？

一个人可能走得更快，但是一群人会走得更远。在开源过程中，你会结识志同道合的朋友，获得朋友的认可与支持，甚至能够与自己崇拜的业界大佬共同交流。是不是想想就让人感到兴奋？所谓“一荣俱荣，一损俱损”，开源社区的发展离不开开源者的贡献，开源者的诉求、成长、交流以及思想也需要依赖开源社区，开源领域的发展与每一位开发者都息息相关。

如果有自己的想法，就动手去实现，通过开源可以为人们带来各种超乎想象力的事情。

写在最后

我们诚邀社区的小伙伴一同参与讨论开发，共同打造一款世界级高效易用、性能卓越、技术领先的分析型数据库系统。如果你对 Doris 的技术方向感兴趣，希望一同开发，或者有其他建议或意见，可以通过以下渠道参与：

1.订阅并发送邮件至dev@doris.apache.org‍

以 Apache Way 的方式参与社区，订阅方式见官网：

http://doris.incubator.apache.org/master/zh-CN/community/subscribe-mail-list.html#_1-发送订阅邮件

邮件列表是 Apache 社区最常用的沟通方式。我们会积极回复邮件列表中的问题。

2.在Doris论坛发帖留言

在百度开发者社区Doris论坛发帖留言讨论：

https://ai.baidu.com/forum/topic/list/209

我们也会不定期的将一些用户常见问题在论坛中进行汇总和答复，方便用户查找。

3. 微信公众号后台留言