如果你正在从事于大数据相关工作，例如你是数据开发，可能从来不会关心你的数据最后被谁用了，而如果你是分析师，那么数据来自于哪里，经过了什么环节你也不会关心。这看起来没有什么问题，但是很多问题也由此而生，那么该怎么办？这篇文章或许能够启发你。当然如果你是数据团队的管理者，也许你已经在不知不觉中践行其中的一些原则了，那么你也可以一读，并考虑将这些原则整理为日常工作的指导方针。
如果你希望利用数据科学和机器学习，那么有一点你可能忽视了。这其中要处理的模型和复杂的想法都离不开数据，而快速获取想要的数据的最佳方法正是 DataOps。
那么什么是 DataOps 呢？其实就是一个企业或组织处理数据的思路或者想法。它包含一组工具用于自动化处理和个人授权。它是一种全新的 DataOps 工程师的角色，旨在通过构建和管理这些工具来实现这些想法。
DataOps 的原则
DataOps 受到了 DevOps 的启发，DevOps 改变了软件开发的方式，而 DataOps 改变了数据管理的方式。
通常大一点的企业都会有专门的数据工程团队，DataOps 的出现就是为了打破障碍、重排优先级。而像我们这些的初创型公司的话，DataOps 可以帮助我们处理以前无法处理的复杂的大数据问题。
关于 DataOps 的原则已经有别人提出了，但是我们有自己的定义：
自助化的数据服务而非一个个的取数需求
自主化（Autonomation）而非人工处理
小步快跑而非大步慢走
一切皆可重现
数据科学家、数据分析师以及 DataOps 工程师必须要在一个团队里
以数据价值论成败
对于优秀的技术和设计持续关注
把简单纳入设计标准的考量之一
最好的架构、需求和设计一般来自于自我组织起来的团队
自助化的数据服务而非一个个的取数需求
这一条是数据工程和 DataOps 的最大区别之一。
如果有个人的工作就是写 SQL 来处理取数需求或者是从各种系统下载数据，那则说明你的团队方向错了。这种人会因为不断重复的取数需求搞得烦躁不已，而需求方也会因为在排队中搞得很沮丧。再加上一些官僚主义和复杂的流程手续，会让这些人更加痛不欲生。
所以这里需要一个数据平台，数据科学家和分析等人员可以在上面运行自己的查询程序，并能构建自己的数据转换逻辑，甚至重用自己构建的一些视图。这样可以释放出极大的生产力，并且体现了数据界的民主甚至不止，因为它让每个人都能成为数据的生产者和消费者。所以这里可以看出 DevOps 实际上是通过智能化的现代化工具来授权并信任那些依赖数据的人们。
自主化（Autonomation）而非人工处理
Autonomation 在 Automation 的意思上更进一步，目的在于失败时及时阻止甚至自动纠错。
一开始我们需要人工去理解问题的领域，接下来就是将重复的工作自动化并人工监控这些自动化的部分，最后通过监控和人工检查性能等指标来自动纠错。
我个人建议的做法是“一而再，再而自动化”。也就是说，对于一个新的流程或者事件，先人工做两遍，再进行自动化和抽象提炼等。这样既确保我们不会过早地走在错误的路线上，同时也能利用自动化的强大益处。
一般需要自主化的场景有：
基础设施即代码或无服务
数据的可用性和延迟
数据格式验证
数据质量检查
业务逻辑校验
数据治理的需求
小步快跑而非大步慢走
变更，其实有时候并不恐怖。无论是当引入一个新的数据源，还是进行一次新的数据存储的迁移，还是实现了一个新的数据用例之时，都有可能导致意想不到的失败结果。传统的做法就是控制改变的频率以及加入人工测试的环节。可是这些限制带来了不小的机会成本——有些价值本可以通过快速地改变而产生（如今却丧失了）。
DataOps 的做法是批量处理少量的变更，通过自动化测试来持续监控质量，并在需要回滚时提供一个“Undo"按钮。少量的变更一般不会产生意想不到的后果，所以出了问题也比较容易定位。并且，有了这么一个回滚的按钮之后，你可以放下心来去思考问题的解决之道而不用承受系统崩溃的压力。持续的自动化监控保证了在做变更时，对外也是可靠并且可用的。
DataOps 让你大胆地计划和实施对于基础设施的变更。而且一旦你实现了这些小步的变更后，会发现比你大步慢走要走得更远。
一切皆可重现
不论是数据分析、数据管道甚至基础设施的搭建，都应该是可重现的。这样的话，我们会更容易排除故障。
对于数据分析来说，这意味着你要利用数据快照的功能，并且锁定分析代码中所有的依赖。而对于数据管道来说，你可以再次使用相同的输入数据来定位问题。这样就可以做到像之前类似地进行数据转换等操作。
数据及其操作的可重现对于 DataOps 是极其重要的。
数据科学家、数据分析师以及 DataOps 工程师必须要在一个团队里
数据项目的失败首要因素就是沟通问题。数据科学家往往不知道他的数据是如何收集和准备的，那么就有可能把时间浪费在从噪音数据中做一些推断，或者被这些数据所蒙蔽。而数据工程师由于不清楚他的数据被用做什么，因而有可能会开发出无用的数据结构，甚至忽视重要的数据质量问题。将这些任务分配给不同的团队，那么就会造成在不同团队的重排优先级，这样对于数据项目来说就是一个半成品。
使用数据和准备数据的技能要求不同，但同时是互补的。每个数据团队至少配备一名 DataOps 成员和一名数据科学家或者分析师。一个数据项目应该由一个小团队来完成，这样团队的成员要求技能不同，但是目标一致。
这似乎是个常识，但事实往往并非如此。数据科学家经常被迫花费大量的时间在各种 API 和大数据系统上。而数据工程师经常是外包的，并且不知道数据被用来做什么。
以数据价值论成败
任何数据项目的核心价值应该都是获取商业价值。对于一个团队来说，实现 DataOps 的途径就是将这个价值最大化，并尽快实现。
我们一定要记住数据项目最有价值的输出不是文档，也不是数据库、表、图、模型等。重要的是在于我们能够基于数据可采取的想法和行动。
对于 DataOps 来说，一个合适的做法是将当前做的事情与最终的商业价值联系起来。正如实现自动化的数据质量检查是为了确保对于业务来说数据能够产生有意义的洞察。对于一个数据集创建相关的文档的原因是这个数据集本身的商业价值。所有围绕数据的流程和程序都是为了确保安全、可靠、高质量的数据洞察。而超越数据的商业价值之外的一切都可以认为是浪费的。
我们曾经可能在数据工程项目上投入大量的工作，但收效甚微。而一个企业特别是初创企业浪费不起这样的时间，因此不应该在与商业价值有关的事情上犯错误。应用精益工程（lean engineering）的原则关注核心目标可以减少这样的浪费，这样 DataOps 才能做好。
对于优秀的技术和设计持续关注
技术前进的关键在于质量的保证以及技术的先进。对于 DataOps 来说，如果一个数据平台不可用或者不可靠，或者数据不干净或者不可信，那么就是没用的。数据管道的成败取决于它最薄弱的一环，所以要确保数据管道的每个环节都是精心设计的。
当一个团队利用 DataOps 来构建高质量的基础设施时，就能减少花费在排除问题的时间，这样才能够有信心进一步加强自身及平台的能力。相反，通过牺牲质量来节约时间的团队，将在后来的故障排除和 bug 修复上付出更多的代价。
把简单纳入设计标准的考量之一
设计良好的数据架构可以让复杂的数据容易获取。
而设计糟糕的数据架构会让简单的数据难以获取。
普通的数据管理与伟大的 DataOps 工程之间的差距在于面对复杂问题时的简单方案的考量与应用。这意味着你在画架构图的时候，可以少几个方块和线条，而具有更多的功能。
简单的数据系统容易理解，方便问题定位，以及变更。一定要记得选择更简单一点的方案。
最好的架构、需求和设计一般来自于自我组织起来的团队
说到底，DataOps 就是关于人的。一个自我驱动的团队，同时拥有各种适合的技能，明白自己的任务就是从数据中产出商业价值并发扬光大。他们会选择最合适的数据架构，以最简单的方式满足他们的需求。他们会记录需求并确定优先级，并且完成最重要的。因而他们也会设计更加正确的数据产品以及进行合理的数据分析。
任何自上而下的微观管理，或者提前计划大量的任务以及规划到非常远的时间，都将最终导致失败。这项原则其实来自于 Agile Manifesto，它让我们认识到最好的结果不是来自于伟大的计划，而是来自于伟大的团队。
智领云关于DataOps
DataOps对于数据团队的重要性不言而喻，智领云云原生DataOps，云原生技术下的DataOps方法论实践，以云原生的方式在平台上运行大数据应用，使数据不再孤立地分布于多个云的孤岛中，从而可以从任何地方流畅安全地进行移动，并以一致、整体的方式管理数据从准备到报表阶段的整个生命周期。
目前，由智领云自主研发的Kubernetes Data Platform（简称KDP），作为市场上首个可完全在Kubernetes上部署的容器化云原生大数据平台，深度整合了云原生架构的优势，将大数据组件及数据应用纳入Kubernetes管理体系，标准化系统管理，提升系统运行效率，降低运维成本，消除应用孤岛及数据孤岛，解决传统Hadoop大数据平台在部署、运维，运行效率上由于架构限制带来的难点。
扫码关注云原生大数据平台KDP
践行云原生DataOps
原文：https://retina.ai/blog/dataops-principles/
翻译：数据Man
- FIN -
更多精彩推荐
👇点击阅读原文，了解更多详情。
扫一扫
1062
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
