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

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

01 关于自己

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

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

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

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

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

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

02 关于 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 的安装部署及运维门槛。

03 参与社区

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 等，也要通过扩展或者内置的方式支持起来。
• 可以通过和一些技术社区合作，通过举办一些活动，鼓励在校学生积极参与开源软件的开发维护，培养社区后继力量，促进社区的蓬勃发展。

04 展望未来

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：最后有什么话想对社区的小伙伴们说呢？

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

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