189 8069 5689
目前，中国企业在×××通、交换、利用等方面仍处于起步阶段，但是企业应用数据集成市场却是庞大的。根据 Forrester 数据看来，2017 年全球数据应用集成市场纯软件规模是 320 亿美元，如果包括人工在内，将达到 3940 亿美元。
站在用户的角度思考问题，与客户深入沟通，找到宝应网站设计与宝应网站推广的解决方案，凭借多年的经验，让设计与互联网技术结合，创造个性化、用户体验好的作品，建站类型包括：网站设计、网站建设、企业官网、英文网站、手机端网站、网站推广、空间域名、网络空间、企业邮箱。业务覆盖宝应地区。
在数据应用集成领域中，既有 Oracle、SAP、微软、Informatica 等传统的 IT 大佬，更有众多的创新型企业，其中 DataPipeline 就是一家通过提供批流一体的数据融合、数据清洗、数据同步等服务，帮助企业连接内外部数据孤岛，实现数据交换与融合的公司。近日，DataPipeline CTO 陈肃谈及了 DataPipeline 的发展情况、数据应用集成行业、公司管理和个人经历等，以下为采访实录：
一、打破数据孤岛，重新定义数据应用集成
陈肃：DataPipeline 的目标客户集中于金融、零售、制造，地产、互联网行业，服务客户主要具备以下特征：大中型企业、数据价值密度较高、重视数据的时效性。
差异化战略包括：
陈肃：目前，中国企业在×××通、交换、利用方面大部分还处于起步阶段，关键原因是没有做好数据集成、数据清洗、数据同步等基础工作。
我认为，接下来数据应用集成未来会产生 3 个变化：
第一，相较过去而言，会变得更加复杂。原来可能只有一些数据库中的结构化数据，但是现在有结构化、半结构化、非结构化数据，云上、云下、混合云的途径，数据库和数据仓库的对象存储等。
第二，时效性更强。以前数据流转比较慢，商业整体运转的速度也会慢一些，但随着企业实时决策要求的提高，我们需要根据数据做到及时分析，因此时效性要求也随之提升。
第三，高扩展性、灵活变化。随着社会的快速发展，业务部门对数据的需求也在时刻变化。这就意味着用户的 IT 架构、软件和整体发展战略都需要适应这种变化。
复杂度变高，时效性变快，架构变化的程度加深，是数据使用面临的三大挑战，但相应地也会产生一些新的机会。
陈肃：Forrester 数据表明，2017 年全球数据应用集成市场纯软件规模是 320 亿美元，如果包括人工在内，将达到 3940 亿美元。
Gartner 数据也表明，应用数据集成的细分领域 iPaaS 在 2017 年首次突破了 10 亿美元，增长 72％。
陈肃：参与市场竞争的企业很多，在数据应用集成领域，既有 Oracle、SAP、微软、Informatica 等传统的 IT 大佬，也不乏一些创新型企业。但相对新一代云化、大数据实时化的数据应用集成方面来说，新玩家偏少。在中国，数据应用集成企业实际上是比较缺失的。
目前，在数据应用集成这个赛道，一些企业偏重数据集成，一些偏重应用集成。还有一些诸如阿里这样做数据中台的企业，他们的覆盖面与创新企业相比更为广泛，其中或多或少都会有一些差异化，而在基础技术创新方面的企业数量更少。
另一方面，市场上也有一些应用长达 10 年的工具，它们都是基于传统的软件架构；而新出现的工具则偏云化，主要部署在云上，以分布式架构支持大量数据和实时应用的工具还是比较少的。
陈肃：在技术上，DataPipeline 聚焦流式数据处理、高性能同步，快速解决数据融合问题。
在产品上，DataPipeline 是一家为企业提供批流一体数据融合服务的公司。通过提供数据的批流一体处理、任务调度、数据质量管理、可视化运维与监控、API 数据接入、元数据管理等功能，帮助客户更敏捷、高效地实现复杂异构数据源及目的地数据融合等综合服务，为客户灵活的数据消费需求提供强有力的技术驱动。
DataPipeline 已经成功服务了星巴克、喜茶、叮当快药等多家行业领先的企业客户，同时与数十家产业上下游合作伙伴建立了战略合作关系。
TGO 鲲鹏会：DataPipeline 下一步的规划是什么呢？
陈肃：会继续坚持既定的策略，以技术驱动来服务客户，同时会持续投入资源在客户成功上，为客户带来更大的价值。
二、平时多流汗，战场少流血
陈肃：DataPipeline 有明确的企业核心价值观，总结下来是客户成功和个人成长，具体有六条——即不忘初心、深挖本源、客户第一、言出必果、技术驱动、无私分享，技术团队的文化和这六条核心价值观一脉相承。
作为一家 ToB 企业，我们首先强调客户第一原则。运维、测试、开发都要把定位和解决客户问题放在自己工作的最高优先级。为了减少对日常研发工作的干扰，我们建立了轮岗制度，保证每周都有一个专门的团队来应对客户的支撑需求。客户环境是复杂的，有时候值班同学会遇到难以解决的棘手问题。无论何时，只要值班同学将问题抛到 On Call 群里，公司的技术骨干会立刻进行问题会诊、及时给予应对策略和建议，甚至立刻远程接入客户现场协助定位问题。当然，熬夜加班总归是不好的，所以我们有完善的倒休制度，保证员工身心健康。
我们每周至少会有一次团队的内部分享，分享内容可以是技术趋势、工作中的设计心得和技术点，也可以是健身技巧和旅游经历。一些较好的技术主题，经提炼后会由团队成员去开源社区的 meetup 进行分享。
我们强调技术驱动，只有能够通过程序解决的问题就不要采用“人肉”的办法，因此测试和运维团队的同事有很大一部分工作也是写代码，通过自动化测试和自动化运维来提升效率。如果研发和测试中遇到问题，我会鼓励他们尽可能地找到根本原因，用优雅的方式彻底解决问题。正所谓平时多流汗，战场少流血。
陈肃：面试时候主要看技术深度和理解力。
一般来说，求职者如果有好的学校背景，通过面试的概率要高一些，但我们也不是只看学校背景。面试过程中，求职者研发经历的真实性、体现出的技术深度、是否有关注技术论坛和阅读开源项目源码的习惯，这些都是我们着重考虑的点。
试用期的员工，我们会重点考察分析解决问题的能力以及抗压能力。
陈肃：2018 年初，我们建立了季度之星评选制度，旨在奖励每个季度做出突出贡献或取得显著进步的员工。在过去一年多时间里，获得季度之星的员工既有早期的技术骨干，也有新加入同事。我们通过这种形式选拔优秀的人才，赋予更多的责任，给予相应的回报。
随着公司人员的增长，我们在今年引入了绩效考核，以结果为导向评估员工的实际产出，作为晋升和调薪的主要依据。
技术人员选择一家企业，除了收入因素外，技术上的成长性也是重要的考量。DataPipeline 鼓励员工积极参与开源项目的研发，给予员工专门的时间做开源相关的工作。公司也乐于投入资源举办或参加技术论坛，让员工和领域内的高手交流，这也是大家觉得公司技术氛围很好的重要原因之一。
陈肃：创新是 DataPipeline 在竞争激烈的数据集成市场的生存之本。
我们公司的产品是基于开源框架 Kafka Connect 做的产品，为了适应业务需要，我们在这个开源框架基础上做了大量的改造和特性增强，包括端到端数据同步一致性、批流一体、源变化检测和自动适配，优化了框架的任务调度机制。
任何团队成员，只要有好的想法或者发现值得改进的点，都可以自由组织讨论会，邀请相关同事一起论证方案。当方案通过后，会根据优先级进行排期，纳入研发计划。我们特别重视员工自己提出的优化点，在评选季度之星和绩效评估时，我们也会优先考虑作出过这方面贡献的员工。
三、理解客户核心需求，尊重行业发展规律
陈肃：2010 年，我从×××博士毕业后，第一份工作是在中国移动研究院做精准营销平台的算法工程师，后来逐步升任项目经理、用户行为实验室技术负责人。
2015 年初，我离开了中国移动研究院，和朋友开始了第一次创业。我们做了一家在线教育公司，主打英语培训，最初的想法是希望用机器学习技术，帮助用户提升学习效率。公司从 36 氪孵化器起家，获得天使轮融资，成为第二期毕业企业。
在初期，为了获取流量，我们尝试了做一些引流功能，例如实时的托福考位查询和考位预定。靠着这些引流应用，我们的用户日活增长很快，应用程序在 App Store 和主要国内 Android 市场的细分品类下的排名也长期位于前列，因此顺利拿到了 A 轮融资。
A 轮之后，我们开始做流量转化，开发了一系列付费课程以及配套的自适应学习系统。为提升直播交互体验，我们自研了一套不依赖视频流的直播系统，能够以极低的带宽需求进行课件直播，同时减少网络卡顿的影响。2016 年教师节，这套系统正式上线运营。之后的一年多时间里，我们开始验证公司的商业运行模式。但很遗憾，营收情况一直没有大的起色。2017 年底，公司被另一家在线教育公司收购。此后，我便加入了 DataPipeline，由 ToC 领域转向 ToB。
第一次创业，我印象最深刻的是，团队用了 45 天就做出了一款 App，并在 90 天内完成了天使轮融资，这种成就感和幸福感是无与伦比的。我深刻体会到，无论资源有多么匮乏，一群有着共同愿景目标的伙伴都能够克服困难，爆发出无穷的战斗力。但后来商业化尝试失败让我认识到，市场是残酷的，仅有技术创新不足以让一家创业企业存活。你需要深刻理解客户群体的核心诉求，尊重行业的自身规律，才有可能获得商业上的成功。
因为有了第一次的经历，我相信选择和努力同样重要，于是我选择在 DataPipeline 开始了第二次创业。尽管在过去三年多里，公司已经取得一定的成绩，但整个团队依然有非常强的生存危机感。更难能可贵的是，团队总是非常坦诚的去讨论这些问题：到底是客户选择有问题，还是产品功能不够丰富，亦或是某些方面的深度不足？团队成员之间没有埋怨和相互推脱，有的只是共同发现问题和解决问题，这让我非常欣慰。
陈肃：在中国做 ToB 企业服务有一个共性的挑战：服务产品化和客户需求个性化的矛盾。
我们发现，单纯靠产品很难完全满足客户，尤其是大客户的全部需求。一些共性的新需求可以放到产品迭代去解决，但是与客户的其它系统集成和一些偏具体业务逻辑的需求，则要由现场实施团队进行定制化开发来解决。
为了解决这个矛盾，我们做了以下尝试。首先，将产品接口对外开放，以便于客户将 DataPipeline 与自有系统进行集成，包括可以通过已有的调度系统来控制 DataPipeline 的任务行为；其次，我们提供了二次开发工具，遇到暂时没有以标准化组件提供的上下游连接器需求，可以由客户或我们的驻场团队快速开发；最后，我们尽可能将运维流程标准化，并开发了一套排查工具，可以让客户快速定位问题是来自 DataPipeline，还是定制开发部分。
这些尝试的最终目标是，实现产品的运维自助化，尽可能降低运维服务的人力和时间成本。
陈肃：相比于技术上的问题，我觉得如何协调好研发和客户服务是一个更大的难题。
在 DataPipeline 成立初期，人员很少，研发、售前、运维都是由几个开发人员扛起来的。不可否认的是，在一定时间内，这种模式体现出了它的高效性：开发人员对于业务逻辑和代码最熟悉，他们可以直接回答客户的各种细节问题，必要的时候还可以现场写代码解决程序 bug 和适配方面的问题。
随着客户数量的增长，这种粗分工模式越来越暴露出它的问题。第一，产品越来越复杂，对研发进度和质量的控制要求日趋严格。开发人员频繁因为客户支持被打断手头的工作，严重影响效率；第二，部分开发人员并不擅长和客户沟通，容易产生误解；第三，大部分现场问题都可以按照一个标准的流程定位和解决，从成本考虑，让开发人员去做现场排查并不经济。
于是，我们开始招募售前、运维团队，尝试将研发人员从客户服务中剥离。但面临一个新的难题：如何将知识和技能有效地传递给售前和运维团队。DataPipeline 的产品定位决定了我们的售前工程师通常需要和客户进行技术细节的交流，而运维工程师要做到快速定位问题发生的环节。
举例来说，客户反馈说数据同步慢，这个慢可能发生在上游读取、Kafka 的 IO、下游写入目的地等各个环节，又或者是集群任务调度因为某些原因陷入了不稳定状态。运维工程师要有能力进行甄别，解决运维层面的问题，协同研发人员定位解决疑似代码层面的问题。为了让售前和运维团队能够相对独立的服务客户，我们定了如下规矩：
（1）所有售前和运维工程师进入公司后，从产品使用和技术原理方面开始集中培训。要求售前和运维都能够回答关于产品使用层面的问题，熟悉产品核心技术点，例如高可用、数据一致性、动态扩容、性能影响因素、高级清洗的使用等等。要求售前能够在客户现场进行 POC 部署，运维能够在研发不干预的情况下进行产品性能调优和故障排查；
（2）研发人员只有在确定是 bug 和性能缺陷的情况下，才能直接和客户接触。其余问题一律通过售前人员或运维人员进行解答。遇到未知问题，售前人员和运维人员可以向研发需求帮助，并记录后放到知识库中。
通过这种方式，我们目前基本将研发人员从日常的客户服务中解放出来，也进一步提升了客户的服务满意度。